Why does the saturation get stronger in darker areas of a cycles render?

Question

I'm rendering a cube with a single light-source with the standard white/grey diffuse-shader and therefore getting a picture with values-only and then multiplying a color on the image, the color on the different surfaces just changes its brightness.

But when I'm giving the diffuse material the color I have multiplied on the first render, in the new image the color just doesn't change its brightness, but also its saturation.

Why? Is there just a simple difference I didn't recognize? 1st picture: Values multiplied with color. 2nd picture: Used the color as material for the diffuse-shader.

EDIT: I found out that monochromatic colors dont change their saturarion.

Answer 1

The answer for this issue is "albedo", a very important aspect to keep in mind when creating shaders.

Albedo is the reflectance of a material, which in layman terms means how much of the light received is bounced (it's a percentage) and therefore how much is absorbed.

Real world materials don't reflect all the light received nor absorb all the light received (materials you'd call "black" in real world always reflect a little light, while the brightest material you'd call "white" bounces less than a 90% of the light received).

That's the main reason why the default cube is 0.8 RGB gray and not 1.0: albedo is somewhat encoded in the RGB values you feed to shaders as base colour, so if you gave your material a 1,1,1 as base colour, it would bounce back 100% of the light received, which is physically incorrect.

So when you render your materials a part of the light is being absorbed, and the resulting pixel is the light hitting the surface scaled by that albedo (present in the base colour).

I suspect you're trying to reproduce what passes do (multiplying shading by base colour as we discussed in your other question), but it can't work that way because you're multiplying the base colour to the already rendered surface. Your rendered gray cube has an albedo of 0.8, so it reflected an 80% of the light it received. When you render the brown cube, colour affects the albedo too, and the bounced light is different than 80%, and that's the reason why you get a difference when you multiply.

In other words, your rendered gray cube isn't exactly the same as a pure shading pass, so multiplying colour to produce the same result than rendering a colored cube won't work.

Answer 2

How are you multiplying the color with the grayscale image? Odds are that you're not multiplying in linear color space but in sRGB space. Cycles in doing all of its calculations in linear space and only after a pixel is rendered is it converted to sRGB for display.

See also http://filmicgames.com/archives/299

Answer 3

To summarize things: Its all about the transformation of the value informations given by the rendered scene to the final sRGB display view.

My central question was: Why the color of surfaces desaturates in areas with higher light intensity?

And here is the thing: When transforming the scene-data to sRGB image-data, blenders ignores the fact that natural media (like films in analog cameras or the rods in our eyes) are sensitive to not only a small bandwidth of red/green/blue but more to a whole range of different wavelengths (to some degree). That means if , for example, a "red-channel-sensor/layer" is stimulated strong enough the although weak stimulation for blue/green will get so strong that the combined information will create an impression of white. In opposition to this in blender values for red will only influence the red channel, etc. - Therefore red surfaces will be displayed red, even if the light-intensity raises towards infinity.

For further information please visit this very helpful thread: Render with a wider dynamic range in cycles to produce photorealistic looking images

Answer 4

Sometimes when you get unexpected color variations it can be due to color management. It might be worth looking at the color management settings in the Scene tab.

Also, how are you "multiplying by a color" and how are you looking at the resulting image? For example, if you're saving an image from Blender and looking at it using an image viewer, you might get different visual colors than when you look at the image inside Blender, as there may be different color management settings between Blender and the image viewer. This is especially likely to produce unexpected colors if you have a monitor that's not accurately compliant to a standard colorspace such as sRGB, because if Blender or your image viewer aren't compensating for the monitor (by using a profile file), then the colors will be inaccurate.

And if you're taking the grayscale image from Blender and multiplying by a hue in, say, the GIMP, it's quite likely that the math will be different to Cycles. :) After all, it would be pixel math, rather than lighting-driven.