Confused by ColorRamp input values

When I connect the overlay to colorramp as shown, it seems like all the input values to the colorramp are really close to 0. With default ramp settings, I see the following:

If I open this image in an editor and use the eye dropper on the chest, I find that the brightest parts of the wood have a brightness of around 120 (out of 256) and the darkest around 40. So I'd expect the range of input values to the colorramp to range from 40/256 = .16 to 120/256 = .47. But in fact it seems like all the input values are around 0.1 or lower. Here I've added another stop to the ramp, and observe how even with this extra stop the chest doesn't show any blue:

Only when I move the stop's position to .1 does blue start appearing, suggesting that none of the input values are much greater than .1:

Why is this? If a color value of 120/256 corresponds to a position of only about 0.1, then do all the positions above 0.25 correspond to colors "brighter than pure white"?

  • spikeyxxx replied

    Hey good question!

    The thing is, what comes out of the color output and goes in to the Fac of the Colorramp is the RGB values and not the Value (from the HSV). What you were looking at in the external image editor was the Value.

    You could also do this in Blender:

    Just left click and hold and move the mouse pointer over any image in the Image Editor

    If that isn't enough, you can press N and go to Scopes.

    Now look at the default Colorramp :

    and look at where 'middle grey' is; quite close to the left; right?

    Grey with a Value of .5 looks like middle grey to us humans, but our eyes are not linear and a RGB of (0.5, 0.5, 0.5) looks more white than middle grey to us.

    If you take the Value to the power of 2.2  (normal Gamma correction value, if I'm not mistaken), you get the RGB values (when R=G=B).

    Man, I am horrible at explaining this. Let's ask Bartek Skorupa: https://www.youtube.com/watch?v=kVKnhJN-BrQ

  • tarrosion replied

    Thanks! This was enough to point me in the right direction. The nonlinear intensity encoding of sRGB was the key. Blender's own color correction on renders (seems like Filmic by default on 2.82) also contributed a little bit.

    Turns out the bright parts of the chest in the first picture above have a raw intensity of around .18, which is encoded as .47 via sRGB. But that's with Filmic color management, with standard the resulting image's bright have respective intensities of .14 raw / .41 sRGB.

    Is it okay to multiply the grayscale colors by a constant via a math node before passing into the colorramp node, just to make the colorramp easier to manage?

  • spikeyxxx replied

    Sure! 

    Or you could use the Converter >  Map Range Node, if you have values from 0 to 0.18, you can have them go from 0 to 1 like this:

    With a Math Node that would be multiplying by 1/ 0.18...