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.

Value-only-image, multiplied with color.

Cycles-render, used the color from above as material color.

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

  • $\begingroup$ Was the first one rendered 100% white? The default value for the diffuse shader is a little bit grey (E7E7E7 instead of FFFFFF). $\endgroup$ – 10 Replies Nov 26 '16 at 18:21
  • $\begingroup$ No i used the default grey. $\endgroup$ – Xernist Nov 26 '16 at 19:20
  • $\begingroup$ Use 100% white, they should end up the same $\endgroup$ – 10 Replies Nov 26 '16 at 20:15
  • $\begingroup$ Changed to white, still the same situation, just a bit brighter. Colored rendering still got more saturation in the darker areas than the post multiplied one. Maybe it has to do something the the kind of lightsource? $\endgroup$ – Xernist Nov 26 '16 at 20:59
  • $\begingroup$ Just so you know, there is no need to put "(Edited)" in the title $\endgroup$ – 10 Replies Dec 1 '16 at 13:57

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.

  • $\begingroup$ BTW, Please post the hex code for your base orange/brown colour. It's easy to tell it's albedo by looking at the maximum RGB value. I suspect that the red channel is a bit above 0.8, right? $\endgroup$ – Gez Dec 1 '16 at 15:36
  • $\begingroup$ Color: c3673e , the red channel is actually at around 0.76. $\endgroup$ – Xernist Dec 1 '16 at 16:33
  • $\begingroup$ Where are you taking that 0.76 reading? $\endgroup$ – Gez Dec 1 '16 at 17:08
  • $\begingroup$ I used the color as a texture from a plain colored canvas in photoshop ,where it says R 195 / 255 -> 195/255 = ~0,764 . $\endgroup$ – Xernist Dec 1 '16 at 17:56
  • $\begingroup$ Keep in mind that in Photoshop you're working non-linearly (most likely sRGB). Those values are gamma corrected values. The albedo is a linearized value (Blender linearizes sRGB colours entered in the colour selector) $\endgroup$ – Gez Dec 3 '16 at 3:49

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

  • $\begingroup$ Yea, thats also another thing i didn't know in the beginning that in fact, i tried to multiply color on an already gamma-corrected image. $\endgroup$ – Xernist Jan 30 '17 at 13:04

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

  • $\begingroup$ Link only answers are discouraged as if the link goes down then so does the answer (yes, this includes Stack Exchange links). Please include at least some of the steps that solve your question in the answer body itself. $\endgroup$ – Ray Mairlot Jan 30 '17 at 9:25

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.

  • $\begingroup$ Its not that the colors look different in other viewers, its more the question for me why also the saturation seems to change in darker areas, i mean in the end its moslty a light-intensity/brightness change, but the r,g,b values-ration/ the saturation should stay the same. (Given that ones using a white lightsource and a black scene to avoid global illumination,etc - like in my examle.) Sorry for maybe confusing somebody. $\endgroup$ – Xernist Dec 1 '16 at 7:43
  • 2
    $\begingroup$ Colour management has nothing to do with this. The problem here is that the OP is trying to reproduce a shading*colour result (like when you multiply the colour pass to the shading passes) using as source an image that is not a pure shading pass but a rendered composite. See my answer for more details. $\endgroup$ – Gez Dec 1 '16 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.