mental ray gamma workflow while having 32bit exr textures

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  05 May 2008
mental ray gamma workflow while having 32bit exr textures

Hi, everyone,

I have been researching this over the long weekend. I read couple threads mentioning gamma workflow in this forum and sorta have a acceptable workflow, which is setting frame buffer to 0.455 or 0.555 and test render in 8-bit. Under this setting, I don't have to put a gamma node (0.455) for LDR color textures (say, I am not dealing with bump, displacement, and what not) and in final render, just render as 32-bit EXR and do the rest in compositing.

Now, I want to integrate 32-bit tiles EXR texture into pipeline, but I found that, if I stick with aforementioned workflow, I have to do put a gamma node (0.455) for the 32-bit EXR textures to get not washed-out renders.



Both jpg and tiled exr texture files, and the scene files can be downloaded below.
textures and scene (rapidshare)

So, if I have all textures (color, bump, specular, displacment..) converted as 32-bit tiled EXR (linear) for mental ray, what would be the best gamma correct workflow?

Thanks!
__________________
Showreel: http://reel.jchvfx.com
spec:
Windows 7 x64, i7-920, GTX 480, 32 GB RAM
 
  05 May 2008
In the documentation it says that 32 bit float file are considered as linear so there is no conversion done.

So you have 2 options :
add an gamma correction node in your shading network
or burn directly the correction in your texture
__________________
http://www.harrybardak.co.uk
 
  05 May 2008
Thanks, Saturn.
It seems using 32bit float textures is slowing me down on this gamma workflow.
If wanting to integrate 32bit float textures into pipeline, one has to put gamma nodes for all textures. That really wasn't something I expected at the first place when spending time converting 8 bit textures into 32 bit tiled exr.

I am not a coder. I use a script provided by the company to convert LDR textures into tiled exr. Any idea to use imf_copy and some command to make tiled exr with burn-in gamma correction?

Thanks!
__________________
Showreel: http://reel.jchvfx.com
spec:
Windows 7 x64, i7-920, GTX 480, 32 GB RAM
 
  05 May 2008
I really dont know the advantage of using a 32 bit as texture . Could you give some example to see it could help enhance the render quality. I really dont get the idea of using it . The texture will be burn out or darken in render, so a 32 bit final render could be understood, but how an input texture affect the rendering
 
  05 May 2008
ghostlake114, I myself am not sure if it will be beneficial if using tiled exr as textures. The reason I want to use it is because A. it's linear and I am hoping it will help me on linear workflow. B. a friend of mine working in a MR pipeline company told me they got better looking renders when using tiled exr with mib_texture_lookup in Maya 8.5. Maybe it's better filtering or something that I have to experiment later.

I did some more test this afternoon and here is what I got. Seems I still need a gamma correct node for each 32 bit texture when working at home. Please correct if I am wrong.
In company, there is MR standalone and in-house EXR viewer with adjustable gamma, so it's easier to do linear workflow. Now at home, the workflow becomes:
1. For preview of test-render in Maya, I set framebuffer to 4x8 Bit, gamma 0.455 and put a gamma correct node (0.455) for my converted 32 bit texture.


2. When it comes to final render, set framebuffer to 4x16 Bit Half (or whatever that is float) and render (MR won't modify my 32 bit texture since it's a float texture).

3. Load the render in Nuke. When the viewer gamma is set to 1.0, it looks exactly the same as the preview render done in step 1. I can start post compositing now.
__________________
Showreel: http://reel.jchvfx.com
spec:
Windows 7 x64, i7-920, GTX 480, 32 GB RAM
 
  05 May 2008
Hi Jason, it seems you are trying to achieve a completely linear workflow. In which case you should not apply gamma correction to your float 32bit textures as they are gamma1.0. Also your frame buffer should be Gamma 1.0, because it seems you are carrying your linear workflow to your compositor. Now with this set up, your preview renders will appear dark, but in your compositor, you should view them at gamma 2.2 , which is the typical monitor gamma. If your compositor is the last stage in your pipeline, you will also want to convert to gamma 2.2 ( as apposed to just viewing) so the end user has the correct viewing.

You will only need to put gamma correction on 8bit or 16bit file textures that you use when rendering ( typically 0.455 to linearise 2.2 input).

Dave.
 
  05 May 2008
Thanks davegreenwook for the input.

One thing I don't quite understand. In final render, I did set my framebuffer to float format and gamma back to 1.0, and even though I leave the gamma correction node connected with 32 bit texture, it shouldn't matter under this setting. But, if I view the image in Nuke with viewer gamma set to 2.2, it will look totally washed-out.
In my understanding, gamma correction node for 8 bit and 16 bit (LDR) textures should be applied when you are using lens shader (like simple_exposure) with gamma set to 2.2 for the render camera in Maya.

Originally Posted by davegreenwood: Hi Jason, it seems you are trying to achieve a completely linear workflow. In which case you should not apply gamma correction to your float 32bit textures as they are gamma1.0. Also your frame buffer should be Gamma 1.0, because it seems you are carrying your linear workflow to your compositor. Now with this set up, your preview renders will appear dark, but in your compositor, you should view them at gamma 2.2 , which is the typical monitor gamma. If your compositor is the last stage in your pipeline, you will also want to convert to gamma 2.2 ( as apposed to just viewing) so the end user has the correct viewing.

You will only need to put gamma correction on 8bit or 16bit file textures that you use when rendering ( typically 0.455 to linearise 2.2 input).

Dave.
__________________
Showreel: http://reel.jchvfx.com
spec:
Windows 7 x64, i7-920, GTX 480, 32 GB RAM
 
  05 May 2008
Jason try this, first just view your float texture in your compositor as you would expect to view a float render. Does it look how it should? If not maybe your float images have some in built tone mapping or are not gamma 1.0 for some reason...

Suppose it does look as expected...
then map the texture to a simple object, a plane perhaps, using a surface shader, no gamma correction, no tone mapping lens shaders, and with frame buffer at 1.0.
Batch render, then view the result in your compositor in the same way as you did in the first step.
It should appear the same, exactly the same in fact...

now provided you are going to tonemap your float images in your compositor that should be your workflow for your gamma1.0 textures, if you mix in LDR images, these should be gamma corrected at the reciprocal (eg 1/2.2 =0.455 or 1/1.8 =0.555) of their original gamma.
Dave.
 
  05 May 2008
Thanks, Dave. You are totally right. I just realize I am wrong at the first place. The tiled exr texture didn't get "de-gamma" when it is converted from jpg. So I changed the workflow to: (one question at the step 5)
1. put gamma node (0.455) for 32 bit exr textures.
2. framebuffer data type: 3x32 bit, gamma=1.0
3. for preview, a lens shader with gamma set to 2.2 for render camera.
4. for final render, get rid of lens shader.
5. load the rendered exr into Nuke as "Raw" data. Here I have to leave the Nuke Viewer gamma correction to 1 (default), so that the image look as in Maya Render Viewer of step 3 (preview). Does it mean I am viewing the image at gamma 2.2 like you said in your first post?

Thanks.
__________________
Showreel: http://reel.jchvfx.com
spec:
Windows 7 x64, i7-920, GTX 480, 32 GB RAM
 
  05 May 2008
Jason, glad it's starting to come clear.
Sorry I can't help with the Nuke settings, I don't know that program.

But anyway, I am still a little suspicious of how you are viewing your float images, can you get hold of some known float images, maybe the HDR probes on the Debevec site? Just try something like that with the surface shader check I described.
If your converted images really do need gamma correction, then you really might as well not use them, and stick with your original jpgs (and gamma correct them).

You're correct to use the lens shader at 2.2 to preview, and then disconnect to output raw. If your Nuke settings make your raw output look like the Maya preview, then I guess that is correct.

Dave.
 
  05 May 2008
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 04:01 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.