Announcement

**Intuition** · 05-01-2010, 01:22 PM

LWF in Vray isn't too difficult at all. Chaosgroup have really designed Vray to be used in linear workflow.

Vray for maya is also not really different then its implementation in max in this regard besides the fact that Maya may not be able to adjust the color pickers/swatch gamma. Yet I haven't looked into it much since I have an eye for picking colors with it.

First off, LWF is generally two ideas.

One, is that you are going to look at your image rendered in a colorspace other then gamma 1.0. Which is what most render engines default to. The problem with gamma 1.0 as a default is that most computer monitors default to gamma 2.2 which is why you see this number referenced a lot in LWF discussion. This 2.2 gamma space is generally a nicer midrange tone curve compared to 1.0 gamma and feels more natural. The benefits of 2.2 gamma being that you don't run into bright overblown whites or dark zero value blacks trying to fill your scene with light because the midtone curve makes it so you need about half the amount of light to brighten up a scene then you would with 1.0 gamma.

Two, LWF can also refer to the use of rendering to "linear" image types that save floating point color values like EXR, HDR, CIN'eon, etc, VS sRGB image types like TGA, PNG, JPG etc. This is where things get tricky because if one is just concerned with fixing the midrange gamma curve of your render it would simply be a matter of post process. Add a gamma correction to your output image (tga, jppg, png) and "bam" you are finished as long as your render engine knows how to anti-alias for the target gamma space else you will see noise in your blacks when the midrange curve is added. So now we want to save this floating point color exposure data into the image so we can get really precise in color correction weather its photoshop, nuke, etc.

The problem with saving to linear image types is that they need to be rendered/saved in 1.0 gamma space so that they open properly in 2.2 gamma space and not only display correctly but have been rendered to the target gamma space properly so you don't see too much noise in the dark/bright areas due to AA values not being compensated for. You don't want to "bake in" the 2.2 gamma curve only to have another added to it when you open it up elsewhere. You want to see your render in 2.2 and have the engine AA for 2.2 but you want to save it in 1.0 so that it opens in 2.2 correctly.

Vray compensates for this with the little sRGB button on the Vray frame buffer. You can preview your work in 2.2 gamma while saving to 1.0 by using the "don't effect colors" checkbox and it even does nice AA work for the target gamma space as well.

So lets review so far..

Linear workflow is...

1. Rendering to a new target gamma space (usually 2.2) instead of 1.0

2. Rendering proper color values to the new target gamma space in linear image types that use floating point color values like hdr, exr, cin, etc.

Now the main problem that comes up when trying to achieve this goal is the use of sRGB image types for textures in your scene and also the color swatches/pickers in the 3d app either compensating or not compensating for the new target gamma space. XSi and Max have methods for changing the color swatch/picker. In Maya mental ray you can use the frame buffer method which will color correct your sRGB images for you OR you can use a mia_lens camera filter in combination with gamma corrections on each sRGB image type. Vray doesn't use the framebuffer from mental ray's setting naturally so you can use Vray's native LWF button or add gamma correction to sRGB images.

Which brings up the next topic. sRGB image types and why they get all screwed up when setting render engines to 2.2 gamma space. To understand sRGB is to understand that computer monitors display in 2.2 gamma space and as such most 8 bit / 16 bit image formats have been setup to a standard called sRGB. You can read about it here on wikipedia.

http://en.wikipedia.org/wiki/SRGB

The reason why a jpg texture looks fine rendered in the default 1.0 gamma space of most render engines is because the render engines were setup to see the sRGB value (2.2) correctly while rendering in 1.0 gamma space. Now, switch the render engine to display/render/AA in 2.2 gamma space while using an sRGB jpg that looked correct in 1.0 gamma. What do we end up with? Essentially a texture that is way blown out because the 2.2 gamma curve is being added twice essentially showing the texture at 4.4 gamma values while the render engine is displaying the scene in 2.2 gamma.

So the way people compensate for this is to "linearize" any sRGB texture/color maps used in linear worklow. Essentially returning the sRGB 2.2 gamma value to its equivalent 1.0 gamma value so that they look correct in the render engines 2.2 gamma space. In Maya Vray you can do this by adding a gamma node after an image file node that has the gamma values set to the inverse value of your target gamma space. In most cases this value is 0.4545. The way we get to this value is by dividing 1.0 (gamma) by (2.2) gamma and you end up with 0.4545. Which in Maya ends up looking like .455 because of the 3 digit integer limit in the numeric inputs.

Once you do this to your sRGB images in use in LWF they will display correctly in 2.2 gamma space.

Chaosgroup added a check box called "Linear Workflow" to Vray's options which I believe does the "linearizing" of sRGB images for you so you wouldn't need to add gamma nodes to them. I don't use it myself because I try to keep my mind in proper linear workflow but from my tests it works well and I believe even corrects the color picker result. You still need to tell Vray that the target gamma space is 2.2 but you can check "don't effect colors" so that it wont bake in the curve, ruining your floating point (exposure) color values.

Read these tuts.

First is for Vray max,

http://www.aversis.be/tutorials/vray...l_gamma_01.htm

Seconds is for mental ray but has great example pictures of photos comparing the two color spaces.

http://www.floze.org/2008/07/six-tut...de-part-i.html

I'll try and come add pics to all my descriptions later tonight. Its hard to read this and get it without good picture examples.

I did a small example on the Area for the softimage users. I'll come back annd do proper Vray examples later

But as you can see the 1.0 gamma image has blown out vales when the scene is brightly lit. The green is flat. When the proper LWF is applied the render looks more natural and the light values are about half yet the scene has brightness.

http://area.autodesk.com/forum/autod...-gamma/page-3/

**enzoenzo** · 06-01-2010, 09:03 AM

Working and sleeping better now!

Hi KC,

Thanks a million for the utmost informative reply,it is the most comprehensible explanation I've seen so far (for a non-CG-pro anyways) and indeed, my color/light problems are now gone! Everything works as intended with much better results, by setting the "Linear Workflow" checkbox and rendering to Gamma 2.2 (since I need only still images I can bypass the linear formats and just save to tga).

Highly appreciate your effort to sort out the know in my brain....

I owe you a huuuge beer!

Cheers,

Enzo

**cdavis** · 16-02-2010, 05:16 AM

So which mapping type should be used ? Gamma correction?

**albertoluceno** · 24-02-2010, 09:18 AM

Hi,

We've been looking into this issue quite a lot recently and personally I find it very frustrating to work in linear because it gets really confusing since you can never be sure what the software is actually doing internally. In fact I think that a lot of users who think they're doing it right actually aren't.

We think it is Maya who makes it very difficult to the user to do things right. Why don't they just adopt Nuke's perfect system for linear workflow? It's simple, there's only three places where you should consider gamma correction: read, write and view.

File nodes should include a gamma correction that transforms input data to linear with sensible default values depending on the image file type. This way every calculation inside Maya would be on a linear workspace. Next, all you need is two more gamma corrections: one for the render view (sRGB normally so you see stuff correctly on your monitor) and another for writing out files (normally depending on the file type). Simple!

Writing out the files would depend on the renderer, in this case VRay. And of course you could maintain your color mapping stuff for expert users who know what they're doing.

This is my conclusion after some investigation. I hope I'm not mistaken. We've already sent a feature request to Autodesk who we think it is up to to taccle this problem. Of course, why should they listen to us, we're just a small studio. But don't you think that would be the most confortable way to work?

Cheers

**vlado** · 25-02-2010, 12:44 AM

There is one more place where you might need gamma correction: color pickers.

Best regards,
Vlado

**albertoluceno** · 25-02-2010, 07:13 AM

Oh, ok, thanks!

But still, things could be kept fairly simple right? There shouldn't be too many parameters, mainly just those 3 simple corrections each in the right place.

Cheers

**albertoluceno** · 25-02-2010, 08:50 AM

Hi,

Autodesk actually answered that they will include this in future versions. Perhaps some of you if you're beta testers have seen it already? :O

Announcement

Linear Workflow for Maya (for dummies)

Linear Workflow for Maya (for dummies)

Comment

Comment

Comment

Comment

Comment

Comment

Comment