Linear workflow and How I Stumbled Ass Backwards Into It

It all started with hitting the "create physical sun and sky" button and the disappointment that followed.  You see, my colors were all washed out in the render and I did not understand why.



dramatization :)


Then I found a tutorial that said I first needed to run my textures through a gamma correct node with a gamma value of .454, it worked but I was still confused.  The number just seemed so arbitrary and I couldn't let it go.




Though, I'm partial to the "mip_gamma_gain" as you only  have to fill in one value instead of three but that node  is hidden by default .






Well, that snowballed into reading some pretty technical stuff and a few contradicting articles, it even became hard to draw the "O.K information overload" line.

What really happened?  I ended up scribbling down a list in an order that made the most sense to me, though I'm still unclear on some things.  The following is derived from that list.

- Monitors are non-linear and that is because voltage that makes the pixels on our screens light up goes through a process so it can "look right" to human eyes, this process is gamma correction and most monitors have a gamma of 2.2.

- Typical images (the images on this site and that site you just came from) have a gamma of 2.2 embedded for display on monitors, hence these images look all normal and pretty in a common image viewer, like this browser you're using :). Yes, that also means those nice jpeg/png/targa etc wood textures you're about to use and that bright blue you just chose from the Maya color picker. Because these images/color swatches have a gamma of 2.2 embedded they are not linear.

- Creating the physical sun/sky creates a few nodes and makes some connections, one of them is an exposure lens shader that it attaches to the camera, this shader has a gamma attribute and that is set to 2.2 by default.

- MR is expecting linear colors/images, hence the sky is a nice rich, bright blue but the blue on your car looks like crap :|

- Color textures and color swatches now have a gamma of 2.2 applied twice (one embedded, and another from the lens shader) so they end up looking washed out.

The gamma correct node is used to counteract the embedded gamma of 2.2.  So you need the inverse of that number, and that is 1 divided by 2.2 which equals .454545454545454 (yeah well you get the point) a value of .454.

- Floating point images don't need gamma correction nodes because they have a gamma of 1.0 and are considered linear right off the bat. (that's one way to get around all the gamma nodes providing you have enough hard drive space).

So now gamma nodes are happening, which channels need correcting?  I did some comparison tests and as suspected (had a couple surprises though), most channels that spit color into the image need correcting.

First up is the diffuse/color channel, and I found that colors at full saturation don't need correcting, nor does 100% white or black.

Diffuse/Color

 

Of course, most times colors will not be at full saturation, and those definitely need gamma correction.


And a "no correction, gamma node, linear texture comparison".


Reflection Color
 This might be too saturated, so that's a no for the gamma node


Reflection Falloff Color


Refraction Color


I think gamma correcting this one may not be a good idea.

Refraction Falloff Color


No real difference I can see.


Translucency Color


Gamma node wins this round.
And finally


AO Dark/Light Colors


The gamma node definitely has an effect, but could it possibly be too dark?  I'm on the fence about that.


6 comments:

  1. Ya know what...I stumbled upon this for the EXACT same reason as you a while back. My mind was totaly blown by all this. For the longest I avoided using sun and sky for this reason. After I started learning about it I had the same problem with information overload. There are so many different posts on the different forums on this issue. To add to the confusion, people keep going back and forth about the various 'correct' approaches for handeling this mess. I ended up settling on a method that works for me and thought all was right with the world and I had it all figured out. BUT THEN...I started working on a scene lit by candles. I thought, 'hmmmmm...wouldn't it just be so cool if I could take real-world light measurements of a candle and plug that data into my light and have that control the intensity and photon emission of my light.' Turns out...that is not so simple and I stumbled upon a post on CGTalk that took me 'even further down the rabbit hole' and almost caused me to move from using Maya to 3DSMax. Here is the link: http://forums.cgsociety.org/showthread.php?f=87&t=687373. Basically it ends up with the conclusion that physically accurate lights in maya are natively impossible. The sun and sky is a special case scenario that is more of a hack to get physically accurate lighting in maya more than anything else. The only reason it works is because the sun is so far away there is no variation in intensity of the light due to directionality and a bunch of other stuff. Zap's post about 'gnomes and basketballs' does a good job of explaining WHY physically accurate lighting is so difficult to achieve. And it turns out 3DS Max has some super complex math to do the conversions from real-world light measurments to the CG world that Maya and Softimage simply...lack. Some really cool person did write and release a really cool light shader for Maya that does allow physically accurate light in maya based on IES profiles. So that does help the issue. I'm not sure if it's 100% physically accurate though. Here's a link to that as well: http://forums.cgsociety.org/showthread.php?f=87&t=779853&highlight=release+womArchLight. All of this 'physically accurate stuff' explains why if you use the mia_exposure_photographic with the sun and sky you have to set the RGB unit conversion on the sky to .318 if you want to leave the cm2 factor set to 1 on the exposure photographic. The script djx wrote does this automatically for you and once I learned about all this I understood why. Anyways, love the post and just thought I would throw my little bit of info in there in case you or anyone else could benefit from it. It's very closely related to what you originally posted about and it's not well documented and it's nice to be aware of these things. I was totally blown away by all this when I found out about it.

    ReplyDelete
  2. Ha, you're right, it is a bit of a rabbit hole. I did comb through that CGS thread and I also remember seeing the Wom Archlight and it looks like a pretty nice contribution. Though I try not to rely on community freebie plug-ins as support can become a real issue. I crank up the cm2 factor and leave the sky as is because when I use the photographic lens, the physical sky isn't always being used anyway. And yeah, the whole "correct approach" and physical correctness thing kinda wore me down a bit lol. I'm not going to hold my breath, just keep on plugging along and eyeballing it until it looks right, getting overly technical just sucks all the joy out of the process. I've actually been meaning to do a post on this and I finally got around to it yay.

    ReplyDelete
  3. It seems, in your rake image, that the displacement/bump seems different between the two versions.

    Is this because you gamma corrected the bump/displace map or just changed something else?

    ReplyDelete
  4. Didn't gamma correct the displacement map, don't need to as it's not a color channel. I think the difference is so dramatic because the color map was being washed out so badly it looked like a blobby gray mess. I added a comparison gif to the post.

    ReplyDelete
  5. Lame, looks like blogger doesn't like gif uploads in its posts.

    gammaCorrection

    ReplyDelete
  6. Ah thanks, it's interesting there is such a big difference. Try and suggest a feature with Autodesk to try and get this done automatically somehow with Maya.

    The more people asking the more likely it is they will implement something like this because it is a bit of a pain using all the gammacorrect nodes because they change your viewport. Anyway, nice blog!

    ReplyDelete

Leave a message at the beep...wait for it...:p