2011 - Color Management for LWF ?


#21

Thanks, David. Great found. I feel a lot more rest assured now as seeing your test. At least, my understanding to the settings from manual reading is correct. My settings (CM Render Setting, file texture color space, and defaultViewColorManager, monitor calibrated to sRGB) are exactly the same as yours except that I got a light and different material shaders used.

Plus, a confirmation from Dagon. I will stay with old-school gamma-correct-node based linear workflow for now for sure… :slight_smile:

later guys, be out shooting some HDRIs…
Jason


#22

Matt, David :bowdown:

Thank you soo much for clearing up some ill-informed opinions, and more importantly explaining we aren’t going mad as there appears to be a ‘hiccup’ in the CM ( :banghead: ).
You guy’s should get some kind of commission and a big stick to ensure SP1(?) addresses these issues :applause:

Not that anyone will need this now but I uploaded a cruddy scene anyway :wink:
http://www.sendspace.com/file/xpsobz

Think just for now, I’ll rely on the old way of doing things :surprised


#23

Thanks to everyone for clearing this up, so I guess back to old workflow is way to go…


#24

This is so sad…
Finally Maya has a built in color management, allows userfriendly linear workflow and then it’s buggy…

I do have a question on this buggy 2011CM workflow.

Some of you set the Image Color Profile = Linear in the viewer Color Manager. Why? Mayas Help file clearly states “select the color profile of your image source file”

In my oppinion the source file (assuming jpegs) is a 8bit file and therefore sRGB and not Linear. Am I misunderstanding something here?


#25

As it’s an attribute of the ViewColorManager, I would interpret the “image source file” mentioned in the doc. as the rendered image, not your textures. In my test, I rendered the final output as EXR in linear, so I tell Maya Render View that the input image is linear and then apply a sRGB LUT for proper viewing on monitor. My 0.02. Hope that helps.


#26

The image that you render is Linear. That’s why you tell the Render View that the source is Linear.


#27

color management and LWF work fine in Maya 2011.

  1. Enable color management in render settings (input-sRGB, output-Linear)

2. If any HDR image is used for IBL, change the color profile from “use default input profile” to “linear” in the AE of the HDR image’s file node, 'coz HDRI is linear.

  1. In the render view, choose 32bit display, and go to display > color management: image color profile - linear, display color profile - sRGB.

4. If using physical sun & sky, a mia_exposure_simple lens shader will automatically attach to the camera. Change the gamma of the mia_exposure_simple to 1 since you already gamma corrected the render view in step 3.

I’m not sure my workflow is error-free, but having tested several scenes, batch rendered out 32-bit exr files and imported into Nuke, they looked the same as the ones rendered out in the Maya Render View (by default Nuke sets all the HDRI’s input color profiles to linear and displays with sRGB).


#28

Hey, Lee,
We are using the same setting per se. Yeah, it will look the same in Nuke and Maya Render View, as I am getting that, too. But if you compare your Maya 2011 result with Maya 2010 (or before) result generated with the legacy linear workflow method in Nuke, you will see the difference as I posted in page #18.

I speculate the problem is from the internal value that Maya 2011 uses for gamma-correcting textures when the CM is enabled. The one used for Render Viewer is correct (as in Nuke). So, basically, you are sending a wrongly rendered image to two Viewers (Maya Render View and Nuke’s viewer) that have the same sRGB LUT. Again, it is just my guess.

cheers,
Jason


#29

The exposure shader does more than gamma. It compresses highlights and lowers the scene brightness by a factor of 5 which impacts all manner of other things. If you want your images to be strictly linear the easiest thing is just delete that node entirely. As I said earlier, you will need to lower your mia_sky brightness multiplier from 1 to 0.2 to compensate.


#30

Why this?
Exposure simple is designed to work with sky&sun whit RGB unit conversion to 0.000100. Your 0.2, is personal and not good and Physical correct workflow.


#31

Fair enough, but we’re not really doing a Physically correct workflow here, just a linear one. The mia_exposure_simple has a gain of 0.2. If you remove the node your scene illumination will be 5x brighter than it was before. Moving the 0.2 value onto the multiplier in the mia_sky node compensates for the missing gain reduction at the lens. This also has the effect of making incandescence maps, light intensities etc behave as the user would expect.

In my original post I did note that once a user has grasped the basics, they might find reasons to keep the mia_exposure node.


#32

Yes, I reached the same conclusion.

As a side note, I would suggest that when testing these things people should avoid using any exposure changes. Exposure is just a subjective thing you do to make the image look nice, where as gamma is (should be) a fixed configuration that depends on your intended workflow. (It should almost be “set and forget”)

David


#33

I’m totally lost now. Why in the Render View, the input is linear and output is sRGB whereas in the Render Global, input is set to sRGB and output is Linear?


#34

render global input = textures (sRGB, mostly)
render global output = your image (linear)

render view input = your image (linear)
render view output = what you wanna see (your image in sRGB)

this is the right workflow cause you can save the image in linear space (EXR,HDR) and do the tonemapping in post, or do the tonemapping in the render view and save it in sRGB

think about the render view as a simple “viewer”, your image is stored in a linear way, but it make you see the sRGB output


#35

Hi, Jason
Yes you’re right. I said it too early.
I just did another 2 tests with Maya 2010 traditional LWF and 2011 color management LWF. In comparison with the 2010 ones, 2011’s appear a bit washed out, not a huge difference but noticeable enough. Also the bumps and reflections look different too.
It’s sad.

edited:

you need to set “linear” in all the bump and displacement maps

Thanks for the reminder,Dagon. My neglect. I have corrected the settings and posted the new images. Minor changes, though. The bumps seem ok now but the textures are stills washed out a bit and the IBL still brighter with the new color management LWF.

physical sun & sky

HDR IBL (no FG)

for close comparison:
http://picasaweb.google.com/116327491633796819375/LWF#5460644616874146018


#36

you need to set “linear” in all the bump and displacement maps


#37

Linalee:
I actually prefer the 2011 images you posted :smiley:

Basically, anyone looking at this thread now - a few of us have decided to stick to your original LWF for now.


#38

Yes, I think everyone prefers the new color management workflow, it makes life much easier. But it’s probably incorrect.:curious:


#39

The lens shader is absolutely necessary, but I would agree that switching the Physical Sun & sky multiplier to .2 and the lens shader to a gain of 1 is as well. There is one other HUGE reason why you want to do this - you get correct Render Passes.

The default Physical sun & Sun relies on this gain adjustment in the lens shader to produce the right results. That relationship needs to be broken in order to get the passes working.

(on a side note, I discovered a while back when you do this any SSS passes need to be multipled by .2 as well for some reason)


#40

And that’s why I ALWAYS rebuild my prefs. Pain in the ass… but not as much as going through something like this. Glad everything works as planned. I have also moved heavily into linear workflows, but was annoyed at how we had to do it.

Ya had me worried for a second there :stuck_out_tongue: