Monday, September 22, 2008

Linear Workflow Addition 1

pixelvapour has pointed out an error with color swatch correction that I should expand on here. Thanks for kicking me in the pants to clarify this. He says that color swatches in maya are not corrected by the framebuffer setting in renderGlobals. He seems to be correct, and it may be a reason that larger studio workflows have mentioned using gamma nodes to correct just about everything in their scenes, and not the framebuffer setting. You might choose to do this, since it does avoid confusion. However, I'm still not a fan of having more nodes than I need. That said, I'll be working on some scripts that I hope to post here, that will assist in inserting/removing gamma nodes. Unfortunately, it seems a bug in MentalRay at the moment, that it does not respect nodeState "hasNoEffect". So simply turing off a gamma node doesn't work well... something I traditionally make use of in such scripts... but I digress.

Here's some test examples to illustrate the problem. First, the defualt texture map I'll be using. It is blackAndWhite for a reason... it's just easier to visually interpret gamma differences that way.

For these tests, I've simply created a Physical Sun/Sky system... which if you'll recall, automatically creates an exposureSimple gamma correction node on my camera. I have also set my framebuffer to 32-bit float. So we are in linear space and previews are being adjusted for monitor viewing. The scene has a texture-mapped plane with the iamge above, and a procedural checker sphere. The colors applied to the checker color swatches are pure red, and medium grey (128, 128, 128). Leaving the framebuffer gamma at a defualt of 1. We get this.

The gamma is out of whack, and may look familiar to users that aren't adjusting the framebuffer gamma. To fix this, I suggested using the framebuffer gamma setting. adjust this to .455 to avoid applying gamma twice. .455 negates the textures baked-in gamma, setting it to linear-space. The texture will now work correctly, as seen below.


Now the texture is correct, however the procedurally mapped sphere has not changed. the mid-grey parts of the checker are not appearing close to 128,128,128. So we do have a problem here. Framebuffer gamma is not adjusting our color swatches, so we must do it manually.


Above, we see the graph and attribs of the gamma node. Now the procedural is corrected for linear workflow, and the desired final result is this:

Finally! Correctness! The mid-grey renders properly.

We are clearly not working with an ideal toolset here. Maya needs some modifications to accomadate this workflow for its ussers. It would be nice to have gamma adjustments in the shader, instead of piping in a color and gamma node just to pick a color... alas. Thanks for the comments!

9 comments:

Jason Huang said...

Thank you, Andrew. Great as usual!

Pixelvapour said...

It would be great to have some scripts to help automate this, even better would be for Autodesk to sort the gamma issue once and for all. This link has a quick discussion on scripting gamma.
http://forums.cgsociety.org/showthread.php?f=87&t=583570&highlight=gamma+swatch+color

Zeth said...

Thanks, Andrew.

Andrew said...

I checked out the link. Thanks. The script mentioned there is possibly useful, though I'm not totally into the way it works. I'm not really a fan of global solutions. We are working on a script (actually a few of them), to help automate the process. I'll post them when I can. I guess I'd rather have a manual insert/remove tool, and then on top of that, a tool that you can change the settings on all or selected gamma nodes. More to come. Though I suspect there may be some significant changes to how Maya handles this in the upcoming release.

geoff said...

So am I correct in balking at the required workflow for linear colour correction in Maya ;) :

Every time we create a lambert, blinn or other material and simply want to make it dark green, light blue or whatever, (not using file textures, just the swatches - which is what we do about 95% of the time), we have to be mindful to make a gamma node with the required colour first, set the gamma to 0.455 and then pipe that into the colour slot of the lambert material?

Ick.

Going to be pretty difficult to get the others in the studio to implement that wretched workflow ;) Or have I missed something?

Andrew said...

You might balk. It certainly isn't an ideal workflow, since maya just isn't setup for it. It depends on how much you value the tonal advantages of working in linear space and correct gamma. For some it's great, and others just don't like it. There are super talented lighters at our place that still light traditionally, and not linearly. That said, for me, the workflow is fine. Especially if you build some scripts to speed things along. You might also cheat (which I occasionally do)... if your color isn't critical, you can use a darker, more saturated version directly in the color swatch. It will render lighter and paler, but it is a fast cheat instead of using 2 nodes. In addition to clarify... you mentioned lambert. Perhaps just as a simplified example, but be aware that you should be using physically correct materials if possible. Mia, dielectric are best. Lambert/Phong/Blinn do not transport light in a physically correct manner. Working with them in a linear space with complex GI could result in unwanted effects.

geoff said...

Thanks for your reply - and thanks for the great blog... I've written a rough script that'll throw a gammaCorrect with the desired colour into the material if there's nothing already going in, which kind of works.

It's actually not so bad ;)

Anonymous said...

Impressive, but... Since I know from the book "Mental ray for Maya, 3ds Max, and XSI: A 3D Artist's Guide" by Boaz Livny, you have to remove build in gamma correction from your 8- and 16-bit textures, not from procedurals. And Mental ray framebuffer gamma setting actually corrects only framebuffer image when it convertes into monitor's gamma 2,2. It is necessary to produce a linear output.
And finally, if you set Data Type parameter to RGBA (Float) 4*32 bit, gamma correction does not apply at all. It applies only to 8- and 16-bit output.
Am I wrong?

Jerome said...

Is it nessecary to apply the gamma correction to the specular texture or bump textures as well?