Corona Renderer for 3ds Max > [Max] Tutorials & Guides

OFFICIAL Q/A: sRGB, gamma, color pickers, linear workflow, ...

(1/5) > >>

There is a lot of confusion about the sRGB checkbox in color picker lately and why the same numbers can represent different colors. I will try to explain it.

General intro

Q1: Why is 127 gray sometimes darker and sometimes brighter? Why is 0 240 0 green sometimes greener?
A: Because there are different color spaces, terms such as "red 240 120 50" can mean different actual colors in different color spaces - Adobe RGB, Wide RGB, XYZ, CIERGB, sRGB, ... The reason why we can usually get around by just using numbers without specifying color space is that the sRGB color space is widely adopted and was set as the default for web graphics, leading to wide adoption.

Q2: Why not just always use sRGB then?
A: Because sRGB is "narrow" and can express only a relatively small subset of all colors without using negative values. It is also non-linear - there is gamma curve involved - you cannot add two sRGB colors in rendering (i.e. from 2 lights in the scene) and expect correct result. You need a linear space for that - this is what the linear workflow is about.

Q3: Why even complicate things with gamma?
A: Because human vision is highly non-linear - roughly logarithmic. By applying a gamma, sRGB is roughly perceptually uniform - adding 1 to a dark or bright color results in roughly the same increase in brightness. Linear gradient from 0 to 255 in sRGB looks roughly uniform. In '90s nobody was doing rendering (which needs linear color space as opposed to 2D graphics), converting between color spaces would be too expensive, and memory was scarce, so the 8bit gamma-baked sRGB modelled to match '90s CRT monitors was created to give good visual resuls for 2D graphics. 8bit non-gamma format would produce bad results because all of its 255steps precision would be wasted in blacks, with no precision left for whites. Also appylying the gamma before sending the image to monitors would be too expensive.

Q4: Why is this a problem in 3ds Max?
A: Because 3ds Max is not color managed, and does not have the concept of color spaces. It internally uses just "RGB" with no information about which space it is - which is problem because that number can represent different colors, and renderers cannot just use sRGB, as explained previously. The biggest problem is that certain map slots need linear data (such as diffuse color) to work properly (linear workflow), while other slots need sRGB data (normal, bump, and displacement) to preserve what user intended in photoshop when he created the map and saved it as sRGB. 3ds Max has no way to specify which space is the input texmap in, or what space it returns results in, which puts the burden of checking this on user. We try to make it easier for users by showing warnings in normal maps, but that is not an ideal solution.

Q5: Why do different textures need to be in different color spaces?
A: I will give an example: diffuse color vs. normal/displace map:
- Diffuse color is just a captured surface reflectance (assuming no reflections). The renderer internally has to multiply the diffuse color with incident radiance to produce bounced radiance when calculating GI/direct light. This multiplication will not work if done in sRGB color space, because it is not linear. When you created a photo of the wood/gravel/leaf, your camera added the gamma curve to the image when it was saved as .jpg - because that is what the standard requires. Renderer needs to remove the same gamma curve to get the true linear values.
- Normal map cannot be photographed in reality. It is drawn in photoshop, and the standard here (created in realtime graphics before linear workflow era) is that 127 127 255 saved in jpeg is "no change to normal". If we would remove the same gamma curve as from diffuse texture, then "no change to normal" color would become "huge change in normal", which would screw up look of the model because all normals would be way off. This is really easy to reproduce and I bet it happened to everyone at least once ;)
- When you draw a displacement map in photoshop and use linear gradient from black to white, you expect this to translate to linear slope on the surface. You save this gradient into JPG as linear progression from 0 to 255. If renderer would remove gamma from this and interpret the numbers as height then, the slope would no longer be linear, but gamma-curve shaped.
We would happily do these decisions for you on background, but that is not possible in 3ds Max - textures work as black boxes there, so we cannot determine how should each texture behave, when for example the same texture is instanced in different slots, reused in shader tree, ... Plus there is the issue of legacy workflows - people expect to load normal maps with gamma override - by not requiring gamma override we would break workflows people have because then overriding normal maps to 1.0 gamma would actually produce incorrect result.

Color pickers

Q6: Why is this an issue in color pickers?
A: Because there are exactly the same problems when picking color as when inputting a texture - you can think about color pickers as small 1*1 px textures ;) - you need to specify their color space the same way as for textures.

Q7: How does 3ds Max color picker work?
A: When gamma is set up properly in 3ds max, the color picker will show linear (no-gamma) sRGB numbers, show gradient which is linear in linear space, BUT show sRGB (color-mapped) colors on the monitor.

Q8: What is the problem with this?
A: We identified these problems:
- The color gradient on sliders progresses uniformly in the linear space, so it progresses non-linearly in sRGB, so it is perceptually non-uniform. You can see this - all blacks are cramped at the very top, half of the slider looks completely white.
- You cannot do direct input from photoshop/webpage/... Photoshop uses sRGB values. When you put them in the 3dsmax inputs, they get interpreted as linear values, resulting in brighter color. This leads to absurd situations where you would open a texture in photoshop, pick one if its pixels, write that color in 3dsmax, and get completely different results. Or putting 127 in color picker gives different result from putting 127 gray jpeg texture in the texture slot.
- Same goes the other way - if you pick color for material under white lighting, say 255 127 0, render, and copy the image to photoshop, the material will have much different green color value.

Q9: How does Corona color picker work?
A: With sRGB checkbox off, it works exactly like 3ds Max picker, with one exception: we made the sliders perceptually uniform - roughly half of the scale is dark colors, and half is light colors. When you enable the sRGB checkbox, then nothing changes (displayed color, sliders, ...) except for the numerical values - those are now in sRGB. This means that with sRGB checked, you can copy colors directly from photoshop/web/... with no brightness change.

Q10: Should the sRGB checkbox be on or off then?
A: There is no "correct" solution. Picking the colors visually works exactly the same in both cases. Only thing that changes are the numerical values. What is better depends on situation. Use sRGB=off for consistency with 3dsmax, sRGB=on when you need to match photoshop or web values.

Q11: This is confusing, but I want to use the new color picker because of temperature!
A: No problem, just leave sRGB=off to have the same behavior as 3ds Max color picker

"I cannot be bothered with technical details" version
When using Corona Color Picker, leave sRGB off. It will behave exactly the same as 3ds max color picker. When you copy RGB values between photoshop and 3ds Max and notice the result is not matching, turn sRGB on first, then copy the values. You can mentally rename the checkbox to "match numbers to photoshop instead of 3dsmax"

Thanks so much! Very useful.
If we look the gradient, in 3ds max Color Picker we have less black part.
So, 3ds Max color gradients are displayed in sRGB, right? Because we have, in the Preferences, Enabled Gamma correction.
Corona gradient is always Linear and it isn't affected by the 3ds Max Gamma correction (Preferences)

For this reason, the 128 (that in 3ds Max is in the middle) in Corona has a different position.

PS: you should put this thread as a sticky thread

There are 3 different qualities for the slider:

a) Is the slider progression uniform in sRGB or linearRGB?
In corona it is in sRGB, in max it is in linearRGB

b) Are the displayed colors in sRGB or linearRGB?
Both in max and Corona they are in sRGB

c) Are the numbers displayed in sRGB or linearRGB?
In max it is linearRGB, in Corona it depends on the sRGB checkbox

as you can see, 3dsmax progresses the slider in linearRGB but displays it in sRGB, leading to its non-uniformity (there is almost no black displayed). Corona both progresses and displays it in sRGB, leading to uniform gradient


--- Quote ---The biggest problem is that certain map slots need linear data (such as diffuse color) to work properly (linear workflow), while other slots need sRGB data (normal, bump, and displacement)
--- End quote ---

--- Quote ---* Diffuse and Translucency are loaded with Gamma 2.2, the rest are loaded with Gamma 1.0.
--- End quote ---
from here:,12945.0.html

I'm sorry but I finally confused with all this terms. In simple words, we have a texture after photoshop. Means sRGB. Means gamma 2.2?  Do we need to load this texture with gamma override  1.0 for this linear workflow? Or do we load it automatically and Corona knows what to do?

The color values you observe and edit in photoshop are saved "as is" into the jpeg - the values do not change, and sRGB color space is assumed. So when you edit values in photoshop, you edit the 2.2g values - so 50% gray will not mean "50% of energy is reflected". 3dsmax removes the gamma from jpeg upon loading, so the 50% grey will become 21% grey in linear color space. If you use 127 127 127 jpeg saved from photoshop in 3dsmax as diffuse texture, it will mean the surface reflectance will be 21%


[0] Message Index

[#] Next page

Go to full version