View Full Version : Gradient Node Bug. Color Space Conversion. Mixing Colors

09-14-2014, 07:46 AM

1 - Fix the gradient node by taking out the hardcoded output linearization based on "Picked Colors" choice in the CS Panel. It messes up linear calculations. If you think it's really needed Just have a toggle option like in this picture (http://i.imgur.com/l46yJ4c.png), but I think I still prefer a color space conversion node.

2 - Make a Color space conversion node that knows which color space is being used in the scene. Either version in the concept picture would be ok I think.


Question: What's actually the best pactice?

A: Mix linearized colors?
B: Mix colors and then linearize the result?

I guess for images A would be favourable but B sometimes works better for picked colors, no?


EDIT: The issue is really that the Gradient linearizes the output based on "Picked Colors" option in the CS panel: http://www.screencast.com/t/2D2VejXD

10-22-2014, 09:48 AM
Hello prob,

i noticed this too, and tested.. the chage occurs only when conect a color, or map, into the conections showed, it seems that the input conectors lose the color space selected.

Even if am using morphs it gets scramble or bad procesed.

i found an easy way around with the the free plugin of "db&w" , it comes with a color space node switcher, just plug it before conect to the gradient inputs, from Linear to sRGB.

Look at the example, hope this gets fixed


10-22-2014, 02:49 PM
Yup. This issue is triggered by "Picked Colors" in the Color Space panel. It's a messed up, because there's no justification for the node to behave that way. My guess is that when they introduces CS the saw that a linear black and white gradient would result in a 2.2 gamma gradient, so they decided to bolt in a .4545 multiplication on the output following "Picked Colors" CS so that the b&w gradient looked "normal". But that's terrible and as you say it breaks vector calculations. For this, I avoid using gradient for vector calcs. Though sometimes you have to use it. It's the only "Select Case" node there.

In this 3 image sequeces I made colors with vectors and input them into the gradient node. Only changing "Picked Colors" CS option, it changes the output. And it shouldn't.
Correction imho is best made after the gradient so you don't have to fix each input.

Linear "Picked Colors"

sRGB "Picked Colors"

sRGB "Picked Colors" + conversion

Imho color space correction should happen on picker level and not at node calculations level, these should be kept always linear:
1a - Pick a color If you have sRGB chosen in the CS panel for "Picked Colors" you know that when you press "Ok" your color will be multiplied by .4545 (to compensate sRGB). If you have linear in CS, or click in imaginary box saying "Ignore CS" you know when you press "Ok" you'll have that exact color in linear.
1b - Another approach would be to be always in linear and change the display of the picker to preview the CS applied. Pressing "Ok" will always set a linear color. You were just able to preview it with CS inside the picker.
2 - On top of this you should be able to set the swatch display to be affected by "Picked Colors" gamma so that you see what will be rendered out. Either global switch or an additional switch per swatch (say you right click a swatch to toggle gamma temporarily)

Anyways, given that fixing the Gradient node is the focus here, another example:
Same 0 to 1 range, used in a Mixer as opacity: http://prntscr.com/4yrkyt
An used in a Gradient with keys at 0 and 1: http://prntscr.com/4yrlcb


10-23-2014, 01:11 AM
Nothing is "multiplied by .4545" in color-space conversion....

It's powered to .4545....


Inverse of .4545 is
1/.4545 = 2.2


10-23-2014, 02:57 AM
See this.

If we connect const > color to output, switching CS is causing change:



Now, if we connect const > vector, same color as above, switching CS is not causing change:



Now, connect const > vector to gradient with exposed colors:



It must be made for purpose...

10-23-2014, 05:02 AM
Hi Sensei I meant multiplication by the gamma curve. But thank you for clearing it out.

On a side note I got different results by applying power 2.2 to each color component, and using color space conversion node:
(switch between the two tabs rapidly)

Thanks for the additional examples. I'll forward them in the report.

Yes, I believe this was made by design on the Gradient node. Hope they fix it, as it breaks linear calculations or forces you to patch it with a conversion, which creates dependencies to the scene Color Space.
Hopefully they'll fix it.


10-23-2014, 05:18 AM
On a side note I got different results by applying power 2.2 to each color component, and using color space conversion node:
(switch between the two tabs rapidly)

Color Space Convert node is using LWSDK, which is providing functions to do conversion.
I don't know how it's implemented.
Whether they execute pow(x,2.2) and pow(x,1.0/2.2) or using pre-calculated tables.
Tables could be faster, but introduce little differences.

Instead of 1.0/2.2 you might try 1.0/2.20022002200220022002200220022
it's .4545

The more repetitions of .45(45)
like 0.454545454545454545
the closer we will be to 2.2

10-23-2014, 07:03 AM
I see. Thanks for the insight.

I tried with a divide node 2200220022002200.0 / 1000000000000000.0 plugged into several options: pow tree, gamma function wrap, color correction, all look the same. But there were still visible differences to the conversion node results. Either yours or db&w's. I guess that's the tables side effect you were talking about, for speed.