Maya 8.5 Sun/Sky Rendering Bad

[MasterZap]

So to me it looks as if the FB gamma is applied before sampling and the mia_simple_exposure gamma is applied after sampling.

Might that be true? Or what else might be the reason?

It’s the other way around, but yes.

Sampling is defined by “whatever is returned by the lens shader”. So when using mia_exposure_* or any other lens-shader-that-does-gamma, the gamma correction occurs prior to the samplers measurements. This yeilds a different result to havinga linear lens shader, and applying the gamma before storing the final pixel in the framebuffer.

Which is “better” is debatable and may depend on a lot of factors.

/Z

[Throbberwocky]

Sorry to bring this up again but I still didn’t get it completely.

I am trying to develop a linear workflow with HDR lighting in MentalRay for Maya. This is what is bugging me:

[ul]
[li]The “correct” way of viewing an HDR in Photshop is to check if the exposure value is set to 0 and the gamma to 1 in the 32Bit Preview Options in the View menu? Now the HDR is shown in Photoshop exactly how mentalray will “see” it. Is that right?[/li] When this is set correctly I can adjust the exposure of the HDR (in Image > Adjustments > Exposure …) while having a proper representation of the light situation later in Maya.
[/ul]
[ul]
[li]What exactly needs to be gamma corrected in Maya??[/li][list]
[li]Either you set the FB gamme to 0.455 or you set the gamma value in the mia_exposure_simple to 2.2[/li][li]Every file node needs to be gamma corrected with 0.455 as long as it is not a 32bit texture.[/li][li]Since somebody said that 32bit images ALWAYS are in linear space, I assume that the HDR does NOT need to be gamma corrected in Maya.[/li][li]Do I also need to gamma correct ALL color swatches in Maya?? i.e. diffuse color, light color, photon color, specular color, etc[/li]Since I tested the mia_material with a gamma corrected diffuse color and without correction and the corrected one looked right.
[/ul]
[li]When rendering in 32bit the image shown in the RenderView differs drastically from the one that I command line render and view in Photoshop. Why? Is there an option that makes RenderView look that same as Photoshop?[/li][/list]Thanks in advance for any help!
tom 8)

[sixbysixx]

[ul]
[li]The “correct” way of viewing an HDR in Photshop is to check if the exposure value is set to 0 and the gamma to 1 in the 32Bit Preview Options in the View menu? Now the HDR is shown in Photoshop exactly how mentalray will “see” it. Is that right?[/li]

When this is set correctly I can adjust the exposure of the HDR (in Image > Adjustments > Exposure ...) while having a proper representation of the light situation later in Maya.

[/ul]Yeah, kind of. The exposure value doesn’t need to be at 0 - do whatever you want with it - it does the same as if you tweak it in Maya - if it is a .hdr file.

Photoshop at the moment only seems to handle half float for .exr files.

(It opens 32bit exr files alright but I get the feeling it only uses 16bit of it, while it uses the full range from .hdr images - maybe somebody can confirm this?)

What has maybe more influence than the gamma of your IBL Sphere is how the renderer samples it…

[quote=“Throbberwocky”]

[ul]
[li]What exactly needs to be gamma corrected in Maya??[/li][list]
[li]Either you set the FB gamme to 0.455 or you set the gamma value in the mia_exposure_simple to 2.2[/li][li]Every file node needs to be gamma corrected with 0.455 as long as it is not a 32bit texture.[/li][li]Since somebody said that 32bit images ALWAYS are in linear space, I assume that the HDR does NOT need to be gamma corrected in Maya.[/li][/quote]

[/ul]Yes
[/list]

[ul]
[li]When rendering in 32bit the image shown in the RenderView differs drastically from the one that I command line render and view in Photoshop. Why? Is there an option that makes RenderView look that same as Photoshop?[/li][/ul]

I think I kind of explained that issue here:

http://farmhousepost.com/weblinks/GammaWorkflow.jpg

Don’t worry if this whole issue seems a bloody mess to you - it is!

Cheers - Christoph

[wizlon]

“If you use the mia Gamma, the swatches will be correct”

No, that’s not correct, you still have to un-gamma your colour swatches.

[sixbysixx]

“If you use the mia Gamma, the swatches will be correct”

No, that’s not correct, you still have to un-gamma your colour swatches.

Ooops - sorry, yes, you’re right, I confused it with something else…

Christoph

[Throbberwocky]

Thanks for your answers!

Ok … so to speak, it is not possible to see a proper representation of the 32bit image in the RenderView. So it also does not make sense to go into 32bit mode before the final render.

BUT …

as long as I am tweaking and test rendering every 10 seconds, it would be handsome to have a gamme correct RenderView instead of saving and going to command line each time.

In (my) theory this is achieved by going to 8bit or 16bit and setting your FB gamma to 0.455.

But if I compare the 8bit render in RenderView with the 32bit render in Photoshop for some reason there is a difference. It’s not a BIG difference but there is. Why? In theory they should be exactly the same, don’t they?

It’s definitely a big mess … and a not too straight forward workflow …

No, that’s not correct, you still have to un-gamma your colour swatches.

Uhm … again confused. So I do indeed have to un-gamma each and every single color swatch when I use the standard materials like mia_material, mib_phong, mib_blinn, etc??
This … is … wicked …

[leif3d]

I read this whole thread…yes it took me a while…but it was well worth it.

After a lot of confusion, I pretty much understood that if you are to do your gamma in post you should render everything normally except put 0.454 in the gamma value of the framebuffer and output your image in a 32bit float image like EXR.

I did this and my results look like they are correct. All I did was take down the gain to .2 from a value of 1.0 in a color corrector node inside Digital Fusion and the image looks fine.

By the way, the exact parameters in this image are: Batch rendered with No gamma lens Shader and a value of .454 in framebuffer in 32bit EXR format.

Am I doing this correctly?

[wizlon]

But if I compare the 8bit render in RenderView with the 32bit render in Photoshop for some reason there is a difference. It’s not a BIG difference but there is. Why? In theory they should be exactly the same, don’t they?

Turn off Preview Convert Tiles in Render Settings - Preview tab.

[Emil3d]

I read this whole thread…yes it took me a while…but it was well worth it.

 After a lot of confusion, I pretty much understood that if you are to do your gamma in post you should render everything normally except put 0.454 in the gamma value of the framebuffer and output your image in a 32bit float image like EXR.
 
 I did this and my results look like they are correct. All I did was take down the gain to .2 from a value of 1.0 in a color corrector node inside Digital Fusion and the image looks fine.

By the way, the exact parameters in this image are: Batch rendered with No gamma lens Shader and a value of .454 in framebuffer in 32bit EXR format.

Am I doing this correctly?

There is nothing wrong in your setup. In your case the framebuffer gamma of 0.454 corrects the gamma of 8 and 16 bit textures. It will not have any affect if you don’t have these kind of textures in your scene. Another thing to be aware with this setup is that the color swatches do not mach the output. The colors will render lighter.

[Emil3d]

“But if I compare the 8bit render in RenderView with the 32bit render in Photoshop for some reason there is a difference. It’s not a BIG difference but there is. Why? In theory they should be exactly the same, don’t they?”

No, on theory they should not be the same.

[dagon1978]

There is nothing wrong in your setup. In your case the framebuffer gamma of 0.454 corrects the gamma of 8 and 16 bit textures. It will not have any affect if you don’t have these kind of textures in your scene. Another thing to be aware with this setup is that the color swatches do not mach the output. The colors will render lighter.

yep, and the displacement/bump maps are linearized too, so they works in the wrong way

[leif3d]

yep, and the displacement/bump maps are linearized too, so they works in the wrong way

So emil3d says the setup if fine, but dragon says that this setup will also linearize my displacement or bump which may work in the wrong way?

Was he referring to the swatches only?

Should I just stick to de-gammaing my color textures and not my value textures with gamma nodes and just keeping my framebuffer at 1?

I just want to have 32bit float control in post in the most color accurate way possible.

…I’m confused again…

[Emil3d]

leif3d, in other words, your setup is OK if everything in your scene is textured and you don’t have 8 & 16 bit textures that drive values like bump and displacement maps.

As I said, the color swatches will render wrongly. You can fix that, as you already know, by creating gamma nodes with correct color and 0.45 gamma and then plug them into the color input of the materials.

If you have 8 & 16 bit textures that drive values like bump and displacement maps, as Dagon noted, they will render wrongly too, since they don't need to be gamma corrected. In such case you shouldn’t use the Framebuffer gamma. You have to put it back to 1, and as an alternative, you have to attach gamma nodes to all 8 & 16 bit textures ([i]except value textures[/i]) in addition to the color swatches. 

I hope I’m not confusing you more, since I’m not very good at explaining things:)

[sixbysixx]

yep, and the displacement/bump maps are linearized too, so they works in the wrong way

No, I don’t think this is true.

As far as I know (and experienced it myself), setting the framebuffer gamma only affects color textures, but not parameter/value driving textures like bump or displacement.

Christoph

[Emil3d]

Christoph, honestly I haven’t tested this exclusively and I haven’t seen the effect of wrong displacement and bump, since all my displacement and bump textures are 32 bit created in Mudbox and this bypasses the problem. However what Dagon noted makes sense unless Mentalray is intelligent enough to see which texture is used for what. Are you sure that in your tests you displacement and bump were 8 bit textures?

Will this thread ever reach some unanimously accepted conclusion?

[dagon1978]

No, I don’t think this is true.

As far as I know (and experienced it myself), setting the framebuffer gamma only affects color textures, but not parameter/value driving textures like bump or displacement.

Christoph

I’m going to add my two cents here.

In case textures are involved, note that mental ray applies gamma correction to all output images that are not floating-point, and applies reverse gamma to all non-fp input textures.

AFAIK there is (at least in 8.5) currently no way to block the reverse gamma of non-fp input textures from within mrfM except by disabling gamma correction at all in mental ray.

p

…which is exactly what you want a good 99% of the time. Except for bump maps and displacement. So while this is a good try at “automatic under the hood”, it’s not 100% automatic under the hood.

The problem is that the color swatches in Maya aren’t gamma corrected, so the colors you “see” aren’t correct.

[…]

/Z

but you can see it by yourself, take a render with bump/displace and a lens shader with gamma 2.2 (so the textures are not linearized at all) and take it with fb gamma .45, you’ll get a different render

[sixbysixx]

but you can see it by yourself, take a render with bump/displace and a lens shader with gamma 2.2 (so the textures are not linearized at all) and take it with fb gamma .45, you’ll get a different render

Bloody Hell - I was sure I had figured this out. :rolleyes:

I did some testing again - this time with Displacement and Bump (in the past I tested only displacement)

Setup 1: a torus with a 16bit black to white gradient as a bump texture.
Result: there is indeed a big difference between rendering FB 0.45 Lens Gamma 1
and FB 1 Lens Gamma 2.2 - wow.

Setup 2: a torus with a 16bit black to white gradient as a displacement texture.
Result: there is a tiny shading difference between rendering FB 0.45 Lens Gamma 1
and FB 1 Lens Gamma 2.2, but I fail to register any difference in displacement between the two and that was also my conclusion from the past.

Did anybody else test this? Do you really see a difference in displacement between different frambuffer settings?

Cheers and sorry if I added to the confusion!

Christoph

[dagon1978]

Bloody Hell - I was sure I had figured this out. :rolleyes:

I did some testing again - this time with Displacement and Bump (in the past I tested only displacement)

Setup 1: a torus with a 16bit black to white gradient as a bump texture.
Result: there is indeed a big difference between rendering FB 0.45 Lens Gamma 1
and FB 1 Lens Gamma 2.2 - wow.

Setup 2: a torus with a 16bit black to white gradient as a displacement texture.
Result: there is a tiny shading difference between rendering FB 0.45 Lens Gamma 1
and FB 1 Lens Gamma 2.2, but I fail to register any difference in displacement between the two and that was also my conclusion from the past.

Did anybody else test this? Do you really see a difference in displacement between different frambuffer settings?

Cheers and sorry if I added to the confusion!

Christoph

i’ll investigate a little more on this subject tonight

[leif3d]

Thanks for the help everyone.

I’ll try and keep my value textures a 32bit float and my framebuffer at .454, because I don’t really care about my swatches. As long as it renders fine I’m ok.

The only crappy thing with that workflow is that I can’t use procedutal textures, because I would have to de-gamma everything and keep the framebuffer at 1…which is what I’m trying to avoid with really heavy textured scenes.

But oh well…you can’t have everything you want…

[JayHoo]

Hi,
how can I improve my renderings with regard to the contrast? Is the mia_exposure_simple node the thing to play with? With area lights I get good results but I need the physical sun in this still.

Thanks for your advices.