Shader Color Mix Node doesn't work with monochromatic colors #123934

New Issue

Mason · 2024-06-29T02:12:22+02:00

Mason commented

2024-06-29 02:12:22 +02:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.61

Blender Version
Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: e1743a0317bc
Worked: N/A

Short description of error
It seems that there are parameters for which the color mixing doesn't work.

Exact steps for others to reproduce the error
Make a new scene with this node setup:

On the screenshot, the color for the box is almost white, which is fine.
The B color is this:

However, if I change the saturation to 0, no visible mixing of colors takes place at all.

My intuition is that this should work with any color, including monochromatic colors. A saturation of 0.0001 works, a saturation of 0 doesn't work. In this case I really wanted to mix a color with plain complete white (part of this tutorial: https://www.youtube.com/watch?v=m1PkSViBi-M), but it doesn't work with any gray color (saturation 0), either.

If in this case the B color came from another computation that came out monochromatic by chance, exactly those pixels would be color-mixed wrong while their direct, subtly non-monochromatic neighborhood would be color-mixed right.

Kind regards

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.61 **Blender Version** Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: `e1743a0317bc` Worked: N/A **Short description of error** It seems that there are parameters for which the color mixing doesn't work. **Exact steps for others to reproduce the error** Make a new scene with this node setup: ![image](/attachments/b8f65b3b-0040-4124-b209-4d78cd63e100) On the screenshot, the color for the box is almost white, which is fine. The B color is this: ![image](/attachments/e02ff03d-733b-47bb-a4c2-9f1ac9e5ce56) However, if I change the saturation to 0, no visible mixing of colors takes place at all. ![image](/attachments/163cd669-e53a-4732-b064-9369aefb0fd8) My intuition is that this should work with _any_ color, including monochromatic colors. A saturation of 0.0001 works, a saturation of 0 doesn't work. In this case I really wanted to mix a color with plain complete white (part of this tutorial: https://www.youtube.com/watch?v=m1PkSViBi-M), but it doesn't work with any gray color (saturation 0), either. If in this case the B color came from another computation that came out monochromatic by chance, exactly those pixels would be color-mixed wrong while their direct, subtly non-monochromatic neighborhood would be color-mixed right. Kind regards

bug-color-mix.blend

910 KiB

image.png

734 KiB

image.png

1.1 MiB

image.png

98 KiB

Mason added the

labels 2024-06-29 02:12:22 +02:00

Mason commented

2024-06-29 02:30:40 +02:00

A quick search (without really retracing the code paths) brings me to this code path:

source\blender\nodes\shader\nodes\node_shader_mix_rgb.cc -> constant MA_RAMP_COLOR

That constant is used in source\blender\compositor\nodes\COM_MixNode.cc:
convert_prog = new MixColorOperation();

The file source\blender\compositor\operations\COM_MixOperation.cc
Has: MixColorOperation::execute_pixel_sampled (called update_memory_buffer_row in toplevel)

And there, there's: if (colS != 0.0f) {
Then, colS is used in hsv_to_rgb in that branch.

The file source\blender\blenlib\intern\math_color.c has that function.
And in it, the parameter float s is used for multiplication, so it should be fine with 0.

It seems to me like the check for 0.0f could be removed.
It probably makes sense in MixHueOperation where it is also present, to use the "other hue" instead of resetting it, but not in MixColorOperation, where it causes this visible discontinuity and precludes using certain colors resulting from mixing colors.

A quick search (without really retracing the code paths) brings me to this code path: `source\blender\nodes\shader\nodes\node_shader_mix_rgb.cc` -> constant `MA_RAMP_COLOR` That constant is used in `source\blender\compositor\nodes\COM_MixNode.cc`: `convert_prog = new MixColorOperation();` The file `source\blender\compositor\operations\COM_MixOperation.cc` Has: `MixColorOperation::execute_pixel_sampled` (called `update_memory_buffer_row` in toplevel) And there, there's: `if (colS != 0.0f) {` Then, `colS` is used in `hsv_to_rgb` in that branch. The file `source\blender\blenlib\intern\math_color.c` has that function. And in it, the parameter `float s` is used for multiplication, so it should be fine with 0. It seems to me like the check for 0.0f could be removed. It probably makes sense in MixHueOperation where it is also present, to use the "other hue" instead of resetting it, but not in MixColorOperation, where it causes this visible discontinuity and precludes using certain colors resulting from mixing colors.

Mason commented

2024-06-29 11:53:36 +02:00

Looking at it again today, my choice "Color" for the mixing mode was wrong. Selecting the Data Type "Color" and Blending Mode "Mix" yields the correct results!

Closing ticket, sorry. :)

Looking at it again today, my choice "Color" for the mixing mode was wrong. Selecting the Data Type "Color" and Blending Mode "Mix" yields the correct results! Closing ticket, sorry. :)

Mason closed this issue

2024-06-29 11:53:39 +02:00

Blender Bot added

and removed

labels 2024-06-29 11:53:42 +02:00

Sign in to join this conversation.