Navigation


MYMR WIKI Tools


 

Toolbox

Article    Discussion    View source    History   

Linear color space

From Wiki

You are here: mental ray cookbook / linear color space

"why is everything washed out" by Zap Anderson

taken from http://forums.cgsociety.org/archive/index.php/t-452901.html

The answer is: it is washed out because before using a proper color space (gamma):

  • everything you ever used to do was WRONG
  • everything you ever got out of your rendered before was WRONG
  • everything you've ever put into it was WRONG


Back in the day, every shader you used worked in the wrong color space. A classic "effect" of this includes burned out lighting near lights w. decay (causing people to avoid using decay) ugly borders round highlights every place where 'clipping' occurred things looked bad adding two values gave a too high sum (a "2+2=10" effect)

Due to this, many shaders included "special tricks" to work around the problems caused by being in the wrong color space. A classic such "trick" is to blend the specular highlights and the diffuse with something other than pure "add" (something akin to a 'Screen' blend mode in photoshop, or by simply turning down the diffuse where there is a specular highlight).

All those tricks are WRONG, but made the images look "perdy" in the old, incorrect, gamma=1 color model.

The sad thing, also, is that people have - to a certain extent - gotten used to how software behaves in the old - WRONG - model.

Take the two "car" images posted earlier (one mr, one fR). While the mr seems to be pushed too hard into the 'compression' part of the tonemapper (whose JOB it is to desaturate overbright to make clipping visually pleasing), the fR one looks like a horrendous gamma=1 render.

Your error is to think the fR one is "right" or some form of reference - it ain't. You can clearly see how the reflections are far too strong, and "add" to the cars appearance in a very unrealistic fashion.

Now the problem; when you switch to a proper color space (in fR, mr, or any renderer), and you keep putting the wrong thing in, you will get error.

Do check that article linked earlier; even though it's about XSI it beautifully demonstrates the "problem".

The thing is that any time you do a gamma correction at the end, it also means that anything going in will have to take this into account.

Colors aren't "washed out" due to some "error". Colors are "washed out" because you put in "washed out" colors.... the problem is they didn't appear washed out to you because you watched them in a gamma=1 color swatch on a gamma 2.2 monitor!

I.e. everything you see in every un-corrected color swatch is WRONG. It's not the color it will have in the final image.

Same with textures; you have a texture which you viewed with gamma 1.0 on your gamma 2.2 monitor. But they looked "right"? Why? Well because every image ever made (especially 8 bit ones, like jpg) have the gamma "baked in". Which means... they are all WRONG (...in this context. There is a very good reason that they use a 'baked' gamma; this gamma matches our perception curve, making each level in the file "appear" to be the same, which makes the perfect for encoding images in, because the encoding matches the intensity-resolution of our eyes!! If you write 8 bit files in gamma=1 you lose a lot of information!)

Yes, every single nice digital photo .jpg (story is a bit different with .raw stuff) you saw online or that you ever got from any digital camera are all WRONG (in this context).

Yes. All of them.

Why did it look "right" before? Because you rendered in the wrong gamma and displayed in the wrong gamma. So while your TEXTURE looked "right", all the "light math" done inside the renderer was done wrong.

Some apps have features to correct the color swatches, and to correct incoming filetextures so they get "un-gammaed" into the proper, linear color space. This all is different between apps, and unfortunately is implemented incorrectly in some cases, or with bugs in other cases.

Therefore, the only way to be "really sure" is do do your own correction w. color conversion nodes.

mia_exposure_simple is such a node, which is a SIMPLE tonemapper. (It really is just a brightness/contrast/gamma control w. a tool to compress overbrights such that they do not clip in a ugly way. It's called "simple" for a reason ;) )

Now what one has to understand is that doing a gamma correction changes the relative weight between your red, green and blue component, and changing the relative weight is the same as changing the perceived saturation of the color.

What needs to be done is to put the right color in in the first place.


Overbrights

An important job for tonemappers is to handle the overbrights. mia_exposure_simple uses a simple compression, pushing colors above the 'threshold' down until they 'soft clip' to white at a much higher level than where they otherwise would hit "1.0" and hard-clip.

This push-to-white is desirable and is exactly what happens in film, cameras, CCD's, etc. You may not be used to it, which may throw you off.

Many shaders have been written in earlier days that have seen this effect in nature (i.e. how stuff that are more lit tends to push towards 'white') and tried to incorporate it in the shading itself, when the 'real' solution is that there is no complicated color shift going on at all in the surface shading, it's just a matter of properly letting high intensities "push towards white".

(A classic case is skin rendering where weakly lit areas tend towards the redder, and brightly lit tend towards 'white'. Even my own misss shaders include features to do this; so if you are using any form of 'real' tone mapping with the misss shaders, turn OFF the 'screen_composit' parameter!!!)

Another thing that throws people off are specular highlights.

In the "old way", specular highlights could blow out very easily, and in a very "ugly" way due to hard-clipping the channels.

This caused people to make them far to 'weak' (vs. their true "physical" intensity) because even the "weak" value ended up "looking bright". Why? Because "adding" light in this WRONG space a nonlinear add.

Think of it as "2+2" not becoming "4" but "10" !!

So if "2+2=10", and you want it to be "4" (coz your eyes says "that looks correct"), then you notice by trial and error that "2+0.5" looks like "4", so yo use 0.5 instead of 2, and you are "happy".

But when you then put this shading model through a proper tone operator (or even just use plain old gamma correctly), it will indeed look like "2.5" not "4".

This is what has caused many people to throw their hands up and say "this gamma stuff sucks, it worked much better before" and give up on it!!!

When the real error was that your specular highlight was way too low.

The mia_material handles this correctly, and you will quickly notice that if you used it with NO gamma correction or tonemapping, you will most likely perceive it's highlights as "too strong". This is because the shader is right and you are looking at it wrong.

Physical rendering is difficult, mostly due to the fact that there is such a deeply rooted incorrect workflow and software written that does it wrong.

People seem to think that renderers like Maxwell etc. are "magic" and much better than things like mental ray, when the simple fact is that the only major difference is that those renderers were written with physical rendering ONLY from day #1, and has no old baggage of 'wrong workflow' and compatibility with decades of "doing stuff wrong" to worry about.

They can make all color swatches properly corrected, and "uncorrect" any incoming textures automatically because the renreres know for sure that the output will be viewed in a physical manner, seen through a physical tone mapper, corrected properly for the screen!!

External links

Retrieved from "http://mymentalray.com/wiki/index.php/Linear_color_space"