Forum Archive › Why shouldn’t “Normal Maps” be in “Linear Color Space”? › Reply To: Why shouldn’t “Normal Maps” be in “Linear Color Space”?
@spikeyxxx The term “gamma” is obviously used in a variety of contexts in mathematics and science as can be seen for example here (probably not a complete list and not the best source but just for demonstration purposes). Therefore a proper definition is crucial. In terms of image processing and manipulation, I understand “gamma” as the manipulation of pixel brightness (I know this term also needs proper defintion in order to dinstinguish it to “Value”, “Luminosity”, “Luminance” etc.) which not only reflects the characteristic response of early cathode ray tube (CRT) monitors to input voltages (non-linear) but also the sensitivity of the human eye to slight differences in brigthness which is better in the lower range of brightness values (compare a small candle light in a dark room and the same light in broad dayligth on a sunny day) than in the higher range. Therefore it makes sense to bring pixels with slight brightness differences in the higher range of brightness values to the same brightness value so that the image can be more compressed in that range which leaves memory space the darke pixels so that slight brightness differences can be saved in the file which our eyes are able to perceive.
The question for me in the context of saving image files with Blender’s “Color Management” is, whether the conversion for a certain output device (in most cases probably an sRGB monitor) only involves a gamma correction or more. The “Blender Manual” defines the “Color Space” in its “Glossary” here:
Color Space A coordinate system in which a vector represent a color value. By doing so, the color space defines three things:
The exact color of each of the Primaries
The White Point
A transfer function
And “sRGB” directly below this:
sRGB A color space that uses the Rec .709 Primaries and white point but, with a slightly different transfer function.
And “Primaries” are defined in the “Blender Manual” here as follows:
Primaries In color theory, primaries (often known as primary colors) are the abstract lights, using an absolute model, that make up a Color Space.
Therefore, I suppose that if you set “sRGB” as “Output Device” and don’t check “Save as Render” when saving a rendered image, Blender will only calculate the necessary “Gamma” and take care of that “White” appears as “White” on an “sRGB Device”. I don’t know what this “Transfer Function” is and in how far it’s taken into account. What Blender probably does not when converting an image for an “Output Device” is the “squeezing” of the colors of a calculated image in order to avoid clamping so that pixels with different very bright colors won’t be displayed as structureless pure white areas.
I’m especially thinking at Blender Guru’s video “The Secret Ingredient of Photrealism” here and the comparison of a rendering with “View Transform” set to “Default sRGB” and to “Filmic” in Blender 2.78 at 21:39. Also see in this video from 8:51 on what Blender Guru tells about the connection between “Color Management” and “Dynamic Range”.