Maya 8.5 Sun/Sky Rendering Bad

#181

I dont quite get the whole confusion. Why dont you stick with the framebuffer gamma setting and leave all the lens shaders linear (i.e. at gamma 1.0)? Also, I dont get Emil3d’s quote regarding the ‘special case’.

When rendering to a floating point framebuffer, the resulting image is always, per definiton, in linear space, and needs to be corrected in the viewer (automatically, in photoshop in your case). The framebuffer gamma setting does have no effect if the framebuffer is in floating point. You might have forgot to set the ‘Preview Convert Tiles’ to ON, which enables rendering floating point framebuffers from within the GUI. Thus, when solely using a lens shader for correction, it must be set to gamma 1.0 when rendering to floating point.

Also, I dont quite understand why everyone is being confused with the gamma (or rather: color profile) in the image, and the gamma correction of the monitor. Unless you dont know better, always render to sRGB, i.e. a sRGB closely approximating gamma curve of 2.2. After all you dont apply a correction manually to any picture you see on the internet as well - as they’re sRGB (or ~gamma 2.2 quantized) too and that’s fine for everyone. You shouldnt have to care about anything else than the color profile in the image itself.

#182

In my test I batch rendered everything, so the ‘Preview Convert Tiles’ shouldn’t have any effect.
But the Framebuffer Gamma clearly has an effect if you compare the two right renders: both in float, one with FBgamma 0.45, one with FBgamma 1 - the center ball looks different, so something is happening…

hmnn - nyess - unless you know that you’ll be converting the gamma in PShop to 2.2 anyway - might as well save that step and set the mia to 2.2.
Of course you’re right if somebody else will have to handle these files - naturally people will assume that 32bit float files are linear.

#183

Aah, sorry. Yes, the framebuffer gamma applies the inverse gamma value to your (non-floating point) textures regardless. However, there is no quantization happening on the framebuffer itself, which is important to know.

Hence you should not ‘bake’ the gamma correction into a floating point image. This is wrong, as (for mathematical reason) the quantization happens between the 0.0 and 1.0 RGB values - this draws the higher dynamic range pretty much useless.

Imagine the whole dynamic range of your rendering extends from 0.0 to 3.0 RGB (everything >1.0 being displayed as ‘white’), if you apply a gamma correction with the lens shader on a floating point framebuffer, you only gamma correct (quantize) values between 0.0 and 1.0 - all colors greater than 1.0 will not be implied, and this makes any afterward tonemapping or whatever high dynamic range operation wrong.

And besides, such ‘wrongly’ quantized floating point images will be displayed ‘wrongly’ by the most HDRI viewers. Because there is no non-linear floating point, and gamma correction is expected to happen on the HDRI viewer.

#184

Hence you should not ‘bake’ the gamma correction into a floating point image. This is wrong, as (for mathematical reason) the quantization happens between the 0.0 and 1.0 RGB values - this draws the higher dynamic range pretty much useless.

Was that in response to this?

hmnn - nyess - unless you know that you’ll be converting the gamma in PShop to 2.2 anyway - might as well save that step and set the mia to 2.2.
Of course you’re right if somebody else will have to handle these files - naturally people will assume that 32bit float files are linear.

I read the whole thread again and it confused me more. I thought I had it when my renders started looking good and now I’m not so sure I have all of it anymore.

Aren’t you guys saying that if I render to .exr or .hdr then gamma on tonemapper stays at one? Why would you render to an OpenEXR anyways? Am I correct in saying these two image formats are what is called 32 bit float non linear? Should I be using sun/sky if I am not rendering to .exr or .hdr?

Emil, I still don’t understand why you are saying that the slider doesn’t stay around 2.2 when all the math is based around 1/2.2 and everyone in the earlier threads including master zap is saying to use the mia_exposure_simple at a value of 2.2?

What I think Emil is saying is that 2.2 only fits a few models of physically correct lighting and that the gamma slider will need adjusting once using indoor scenes that are poorly lit and all that 2.2 number for is something that looks good. So therefore it can be used as a tool to get the desired image you want by dragging the slider in a desired way. Yet I feel like this is a poor way to do image correction, no? Especially if you are animating?

Sorry, I know everyone hates repeating. Believe me, this is just as frustrating for me as the people reading my posts…watching me turn in circles chasing my own tail.

scott

#185

:twisted::scream::rolleyes:
Hahaha - I’m going through exactly the same thing here - always when I think I’ve got it - it turns out that I don’t understand a thing… I spent the whole day trying to understand what’s going on, realizing that many things I’m testing just don’t match with the theories here in the thread…

The insane thing is that I get the best results now with this setup:
-Framebuffer Gamma 1
-No Gamma Nodes
-mia_exposure Gamma 1

keeping everything at one!
Input: sRGB Textures
Output: 8bit TIFF or 32bit float .exr, for the latter I have to apply a Gamma of 0.45 in Photoshop.
Tried it with a Physical Light Setup and with a Physical Sky Setup - looks pretty exactly how I would expect it to look like - the only thing: IT DOESN’T MAKE SENSE!

Is it just that my brain is fried by now or that my eyes are screwed?
This looks correct to me - no?

#186

I’m afraid it’s incorrect; you compensated everything for a true linear color space. Why dont you try:

  • framebuffer gamma 0.455
  • no gamma nodes
  • mia_exposure gamma 1.0

Trust me. That’s the way it works. If switched to a floating point framebuffer this will yield the correct result as well. The only drawback is that color swatches would need some care.

#187

In my post # 155earlier I was trying to answer in a very basic way questions exactly like yours. Please read the middle part of it again, I just edited it to make it a little bit clearer. The new edits are with a italic font so you don’t need to read the whole thing if you already did.

He he:). We have a misunderstanding again. I didn’t say that the slider shouldn’t stay at 2.2. Ideally you should not touch it. Ideally you should not touch any slider in any controls when your image comes perfect out of the renderer.

What I was trying to say is that in reality renderings most of the time are not created perfectly and you have to use all possible controls including the gamma slider if that makes your images better or gives easier results. What defines a poor way to do image correction is the way that makes the correction difficult and gives poor results. You should use the gamma slider when all other controls don’t give you what you want or if they are harder to use. As I already said before, I’m not aware of any complications, incompatibilities, reduced possibilities, etc. associated with using the gamma slider freely. If anybody knows, please let me know.

#188

@ sixbysixx and floze

regarding my mentioning of the special case with the Framebuffer Gamma, I was trying to point to what was already establish clearer here from your follow ups. That is Framebuffer Gamma affects only 8 bit textures from the input and 8 bit output. Well it also affects 16 bit [short] but for simplicity here let’s pretend it doesn’t exist:).

#189

Sweet lord, thanks guys. I thought all that tweeking to get vibrant colours was normal.
I will never render the same again. Thank You Thank You!

#190

I would like to comment on this hoping that we can clarify better our understanding about gamma although I’m realizing the risk of actually complicating the ideas we already have by trying to clarify them:).

Correct me if I’m wrong but as far as I know sRGB is not a profile that must exist in an image file. sRGB is a standard “imposed” from Microsoft to monitor and device manufacturers, and software companies to create their products compliant to the sRGB standard so that when a user creates an image using these products the colors of the image will be displayed the same on all other systems that use the same products. This means that the user doesn’t need to be aware of or use color management including gamma in order to produce image files with sRGB standard.

AFAIK color profiles embedded in files traditionally came from Apple as their color management solution and are used from programs like Adobe products. This color management system didn’t have the luxury to “impose” to most of the device and software manufacturers one standard like sRGB but instead assumes that all devices and programs can handle color differently and tried to solve the problem by attaching a profile to an image file that tells how the colors of this image were created so that the next device or program used can interpret how to deal with the colors.

Both color managements have advantages and disadvantages and currently can be mixed and exist together on PCs and Macs. For example on a PC you can create a file with Adobe Photoshop and embed a sRGB profile that can be useful if you are sending it to a printer that by default doesn’t assume sRGB but after reading the profile of the file will interpret and print it correctly.

Also such devices that are not by default sRGB can have or use device color profiles to be set with sRGB. In Windows XP for example, you can access and assign such profiles if you go to Display Properties > Settings tab > Advanced button > Color Management tab and click Add
to assign a color profile to your non sRGB device.

#191

Hi Emil,

here is a very good explanation about color profiles - Bruce Frazer has a few more good articles, well worth reading on this site as well: http://www.creativepro.com/story/feature/13605.html

A few points from a Photographers point of view (some of which you already made):
-sRGB was developed for monitors and is a bit of the least common denominator when it comes to color profiles. But it is the most compatible with monitors and the web, because it is made for screen devices and has a gamma of 2.2 (which is the typical response curve of CRT screens). It has a fairly small gamut though and for print and compositing you might be better off using something like Adobe1998 or ProPhotoRGB which is becoming Adobe’s new HighGamut standard workspace and has a very big gamut. Only professional HighEnd monitors are capable of displaying the whole AdobeRGB gamut.
-A colorprofile is a bit like a dictionary: it translates the RGB values into LAB.
RGB is a device dependend model and doesn’t tell you the absolute color values as opposed to LAB. Meaning without converting an image to the device’s profile, it will not be displayed/printed correctly.
-when you ASSIGN a profile you don’t change the RBG values of an image, but the way it will be displayed in colormanaged applications/devices
-When you CONVERT to a different profile you change the RGB values, but the image will be displayed identically in colormanaged applications/devices, therefor you should be very careful about assigning a profile to an image - never do it to an image that already has a profile assigned (unless you know what you’re doing), but always CONVERT into a different color space in order to keep the color appearance.
-make sure that all textures you put into Maya have the same colorprofile and be aware which profile this is and what Gamma this profile has (not all profiles have a gamma of 2.2:D)Colormatch RGB for example has a gamma of 1.8 and LStar-RGB and LinearsRGB are - well - linear.
-When opening your finished render in Photoshop, make sure you ASSIGN the profile that your input textures had in order to follow a correct workflow.
-if you have screenshot textures the might have your monitor profile embedded, which is usually not gray-neutral, meaning an RGB value of 118-134-110 can be neutral gray for example. So make sure that you work with Profiles that are gray balanced. These are usually called working spaces. The most common ones are: sRGB, AdobeRGB1998, ColormatchRGB, ProphotoRGB, ECI RGB, LStarRGB (identical to ECI RGBv2)…

Usually if you get this wrong and mix up profiles it doesn’t have a devastating effect, unless you use some exotic printer or monitor profile.

This whole colormanaging thing was mainly developed for repro processes: You scan a transparency and want it to look exactly the same on your monitor and when you print it.
When rendering you are creating images from scratch, so you use your eyes and make it look the way you want it anyway. The one point where it comes in very handy, is when you use textures and want them to look in your render the same as before.

If anybody finds any errors in what I wrote - please let me know. Don’t wanna confuse things more than necessary…

#192

hey all, i’m the original person who started this thread, i just want to say thanks for all who contributed and sacraficed their time to help me and others. As I stated in my title though, this is kinda ridiculous, it’s been 13 pages of threads later, and people are still trying to figure out how to render in mental ray with this gamma problem… i’ve tryed all ways and found that every way didn’t work that good…you either got the textures to look right and shiny materials where to bright and washed out, or textures wrong but now your shiny materials look good… I went to final render 2 for maya along time ago, and i must say, all these weeks or months that this thread has been going on and people trying to figure out why mr isn’t rendering right, i just hit render in fr2 everytime and it renders perfect, I do wish MR could do what fr2, or maxwell, or vray can do because of the fact that mr supports just about everything maya can throw at it and more, but without timeless hours of tweaking and reworking mr can’t just hit render and get what you want. All other renders have sky/sun systems and lighting, and you just hit render and get a great pic, MR needs to catch up, hopefully in 3.6 they have sovled and fixed all of these problems…but i can say looking at their history, don’t expect it…

Once again, thanks to all for your input, this is just mine if it’s worth anything…

#193

actually there is one correct and safe way:
-leave the render globals frame buffer default settings (gamma 1).
-leave the mia_exposure gamma default value (ganmma 2.2).
-plug a gamma corerct node to every color texture with this values ( 0.45 0.45 0.45).

#194

I’ve done that, and chrome, glass, mirrors, still always comes out washed out and way to bright

#195

Hey Doody, I understand what you’re saying, believe me, but I’m still in quite a good love/hate relationship with MR. It is capable of amazing things and very flexible.
I think its main flaw is the documentation and the Maya implementation - it is not self explanatory at all. Also I don’t care if it’s Mental Images or Autodesk’s fault. They seem to realize that with the newer materials like the mia, and started to have a halfway decent documentation of things, but I really hope that they also start to make a proper documentation of the Mental Ray for Maya package.

Anyway: as a result of all this I also learned a lot and I hope that this little chart of possible and correct gamma workflows in Maya helps to wrap this problem up for everybody. I hope all of this is correct now - seems to work fine for me anyway:-)
Big Credits to Floze who helped me a lot with his comments and to Sphere | for his mia_material_rg

Please let me know if anything here seems wrong to you…

#196

could you post a visual exemple with degamma texture looking good and your chrome, glass, mirrors,… looking washy.

because if what you are saying is true than i don’t see what’s the purpose of using the ungamma node or a mia_material_rg.mi material if anyaways your reflective surfaces are going to look washy .

#197

Consider final render, vray etc. giving you the fish, but handling mental ray (or any more or less complex renderer) is learning fishing. Although many people blame ‘knowledge’ being a barrier between themselves and ‘art’, you end up being able to help yourself.

And afaik fr2 does not render in the right gamma by default as well.

#198

Hey sixbysixx, thanks for the link, it is informative and I’m pretty much aware about all of this since I’m coming from 2d design printing background, but we are going too much off topic here. The article from your link covers mainly digital images to print color management concerns and this is totally out of the scope of 3D programs including Maya which doesn’t have, and does not deal with, any color management/matching tools and tasks.

Files with embedded color matching profiles has no effect in Maya at all because Maya doesn’t know anything about them and that part of the file is completely ignored. So you are wasting your time if you are preparing textures with color profiles thinking that this will do any good in Maya. The same counts when you render images from Maya intended for print since Maya doesn’t deal with color profiles. All you have to take care is to prepare and produce an image that can go without any destruction to a printing program like Photoshop and then care about color profiles. By the way, only a handful of file formats like jpeg, psd, and tiff supports embedding of a color matching profiles.

#199

Regarding to the text in red from the above quite:

Unfortunately this didn’t work for me:sad:. I use to use the exr file from the temporary folder for quite a time and wondering why I can’t do anything out of them with tone mapping and color correction which was a reason to start this thread until I realized that those files are good for nothing and don’t use them anymore. The suggested workaround did not work for me as I mentioned it in the first part of my post #24 in that thread and didn’t get any help with that nor I was able to solve this. Since then I stay away from the files in the temp folder.

#200

That’s quite strange, I’m using them every day and it works the way described… :shrug: