Maya 8.5 Sun/Sky Rendering Bad


#201

Sorry for going a bit off-topic. Wasn’t sure what the general state of knowledge about this sort of stuff here is and I think it’s good to know CMM for this sort of stuff…

I disagree a bit: If you have texture with an exotic color profile attached (be it of the web, or a screengrab or whatever) it will display correctly in Photoshop, but Maya will simply dump the profile and therefore the result might look rather funky.
Also the finished render will have no profile and you will be taking it into a colormanaged environment again, so you will have to assign a profile at some point again and it does make a difference what profile you assign.

If it’s sRGB, or Adobe RGB or Colormatch RGB - the difference will not be massive of course, but there are some weird device profiles out there that you should really avoid for this sort of stuff.


#202

yeah, it is strange and I’m really envious to you and to those who can use this.
Floze or anyone who want to spend several minutes and help me, please download the attached file from this posts in that thread,
render once in Render View after removing the mia_exposure_simple and unchecking the necessary options in the Framebuffer, and then just batch render again that scene.
Open both files: the one from the temp folder, and the file rendered from the batch rendering in Photoshop, and choose Image > Adjustments > Exposure.
Then drag the exposure slider slowly all the way to the left and try the same with the both files. For me the file from the temp folder gets clipped severely around the light while the file from the batch rendering is working properly.
Your help is greatly appreciated. It my be my system or something in my set up and you will help me a lot to narrow the problem.


#203

Does anyone know how the gamma issue should be handled for a broadcast environment? We have small studio with combustion “viewing” suite and broadcast monitor (connected to TV out with Svideo). [Not really a pro setup like Flame with SDI and tie lines or anything].

Anyway once we’ve “eyeballed” eveything to look cool on the broadcast monitor we copy the targas across the network to another post facility’s CAR that transfers to DigiBeta or SP. Not sure what device they’re using but it’s an old machine running Windows NT 4 (if that’s a clue) I ussume using a black magic card or something of the sort.

Any ideas to make sure we’re getting gamm2.2 targas to look correct on Betacam?


#204

No need to be sorry dude:), it is a very interesting topic that I love but I made my note to you because I’m concerned with the size of this thread going out of proportion and leally would like to concentrate here with the problems related to the tone mapping of 32 bit to 8 bit images.

I disagree a bit: If you have texture with an exotic color profile attached (be it of the web, or a screengrab or whatever) it will display correctly in Photoshop, but Maya will simply dump the profile and therefore the result might look rather funky.

That’s exactly what will happen. If you have a profile in a image that makes difference in its appearance in Photoshop form when the profile is disabled, in Maya you will see the image the way Photoshop is displaying it with the disabled profile. As I said there is no way in Maya that you can display the effect of color profiles not to mention that most of the print files have CMYK profile data attached which is a color space that doesn’t even exist in Maya.

You can’t soft color proof an image approximating a printing result using Maya, unless you are using sRGB printer device. Maya doesn’t even have a print command. The best you can do is to keep your options wide open and render to 32 bit which will give enough range to play with it in Photoshop in order to achieve the desired result.


#205

Well, it works for me… all I did was unchecking ‘Preview Tonemap Tiles’ in the render globals, choosing a 32bit buffer and openEXR as file format.

But you can clearly see the problems occuring when doing a gamma correction using the lens shader. Instead, leave the mia_exposure’s gamma at 1.0, and set the framebuffer’s to 0.455 and you should be fine. I’ve attached the edited scene.


#206

:thumbsup:Thank you so much Floze:thumbsup: you saved me one more time.
And I’m completely embarrassed :blush::blush::blush::blush::blush: because in the rush I misread your original suggestion thinking that I have to turn off both options while you have clearly written.

I apologize for taking your time and appreciate your patience with helping me. I own you a big favor:beer:

   Thank you very much again.

#207

Cheers dude. :beer:


#208

hey floze, i had a pickle for you.
take your falloff scene and add a 100% reflective sphere in it. the highlight of the reflection from the arealight can be tone mapped if you open it in…whatever even photoshop. however, try to add a white plane with a white surface shader of 3.0 in V, disable FG cast/prim visibility. the reflection of this white card on the sphere can not be tonemapped even at a 32bit render that reflection looks like 8bits.
my question is, is there any way to tonemap reflections of objects and not just lights?
besides doing a reflection pass(which you still cant tonemap)


#209

shiny materials never seem to bright or washed out in my case, it’s only a texture related issue.


#210

excuse me for my late reply, I just got to know this thread, and its the thread I was waiting for long time :scream: With the sixbysixx scheme made it all clear. But this only applies to Mia_architectural? I mean, it doesn make any sense at all with maya shaders, right?


#211

Sure it makes sense for any shader/material, since it’s a rather global issue.


#212

by the way, I forgot to ask. If in floating point images you shouldnt apply a 2.2 gamma but Photoshop does it automatically in background, how can you work with it in PS? Maybe applying back again .455 in gamma & exposure controls? How can you NO-APPLY gamma in PS?


#213

No no no, PS is doing the right thing.

The point is you shouldn’t apply a de-gamma when inputting a HDR into your renderer, because the renderer wants linear data in.

Any linear data needs a gamma applied to be viewed properly. This is what PS does when you load a HDR file.

/Z


#214

Yeah, PS is doing the right thing - you just gotta be aware of it:D

PS only applies the gamma for viewing purposes, but not to the actual file. Only when you reduce the images down to 8 or 16 bit PS automatically applies the correct gamma of your working space, so you don’t really have to worry about it…


#215

…PS is doing the right thing.
However in a workflow when a tonemapper is used in Maya and then saving to float with x32 buffer, in order to match the display between Photoshop and Maya’s Render View result, one has to apply a gamma of 2.2 in Photoshop, and this causes a lot of confusion among users.


#216

Including myself, yes:D

Maya seems to display float and non-float renders the same, while Photoshop takes non float renders as they are and adds a Gamma to float renders for display.

I wonder why nobody ever mentioned this before:rolleyes:


#217

My guess is that unlike sRGB standard that deals only with x8 bit per channel, there is no standard for displaying float images among different applications. In fact I think Render View is not even aware of float images existence.

I agree with you that things like that should have been clearly explained in the Help files. It would have saved me a lot of time.


#218

Totally off topic

How to save out this thread (the entire thing )as PDF

If I recall correctly, someone did something similar with another topic and it was very useful

I just don’t know “how to”


#219

I’ve re-read the thread and I am looking for an answer to Sixbysixx’s question on page 11 about surface shaders. I’m using a surface shader in my background and when I apply a .454 correction to my file for the suraface shader it doesn’t behave as I expect, it’s always way too dark or too desaturated.

Any way to fix it, or did I miss something ?


#220

http://forums.cgsociety.org/showthread.php?p=4708598#post4708598