Gamma correction - do you care?

#102

Screen layer2 over layer1, and you get this:

result = 1 - (1 - layer1) * (1 - layer2)

So, basically, it inverts both layers, multiplies them together, and then inverts the result.

#103

anyone knows what i have to edit to remove gamma adjustment at windows startup?

I have my screen (TFT, sony SDM-HS95P /R) set to sRGB pretty good, but i have to set gamma +22% in my nvidia drivers to get correct sRGB output (2.2 gamma) because something seems to darken my output at windows startup.
1st sec. of startup it is correct but when my windows desktop is loaded for like 1sec. it gets suddenly darkened (to a gamma of 1.8).

Even if i have my screen set to the built in sRGB preset (which seems good with some minor tweaks) and use the sRGB colorprofile in my windows display settings dialog.

I’ve been experimenting with EVIL tools like ‘quickgamma’ and ‘adobe gamma’ (curse them) during a quest for correct sRGB output in the past (doh!), so it could be (i presume) it is caused by some incorrect setting these tools left behind in some config file?! But i cant find none of both in my running services or startup folder. Scanned my system registry for ‘gamma’ but that didnt bring up any suspicious entries either…

Any1 any ideas how to fix this?

#104

Hi,
CHRiTTeR, are you tryng to put all your system (windows interface and all apps) to gamma 1.0 ?

from what i understood it’s a bad idea… windows interface and monitor should be -anyway- at 2.2gamma (srgb).

Or better: windows interface is made to be viewed on 2.2gamma (srgb)

So, should be better and easier to manage gamma for each application …

edit:
Or are you trying to restore it to srgb? after problems with gamma tools?

#105

My screen is setup for 2.2 (sRGB) but something in my windows is wrong.

At startup i get correct gamma of 2.2, but then quickly (approx 1 second) after my desktop is loaded at startup my desktop gets darkened to a gamma of 1.8 (so something gets loaded that causes this).
So to counter this i have to sett my gamma settings in my nvidia control panel to +22% (1.8 + 22% = 2.2).

So now it displays ok, but i hate the idea that its unnessecary gamma corrected twice (from 2.2 to 1.8 and then back to 2.2) and i fear that this may cause some loss of colorinformation and stuff.

And i dont know whats causing it to get a gamma of 1.8 at startup. :curious:

#106

RIP maps are a generalization of MIP maps:
given a 1024x1024 texture, MIP maps will have 512x512, 256x256, 128x128, etc versions of it. RIP maps would be 1024x512, 1024x256, …, 512x1024, 512x512, 512x256, etc.
Summed Area Tables are a smart way of getting arbitrary rectangular area lookups from a single texture representation, but are not too popular because they use more memory and require random access.

His point is that it probably pays off to de-gamma your textures in Photoshop first before bringing them into Maya, because in some cases you might get artifacts in high detail areas if you leave it up to the renderer (via the gammaCorrect node). I can’t say I’ve noticed this in my work but I have no reason to doubt him as he obviously understands it well!

It’s subtle, so ignoring it won’t kill you. Like many things, it might be a little more prominent when animated. I wanted to point it out mostly for completeness.

Basically, it’s the exact same problem as here:
http://www.4p8.com/eric.brasseur/gamma.html

#107

Oh I see, thanks!

By the way this has been about Mental Ray for the most part but the same concepts apply to most renderers. You can fix the gamma in the Maya Software Renderer, 3Delight, all the Max renderers etc.

I think Maxwell is one of the only renderers that does it all for you automatically, but it’s also one of the newest so that makes sense. iDisplay (3Delight’s image viewer) has a LUT feature which is really handy, so when you render it shows the image in 2.2 gamma when really it’s still linear.

#108

That iDisplay feature slipped my mind, thanks for pointing that out :slight_smile:

#109

Nice topic.
Well I tried to reproduce the render from the XSIBlog with Maya and MR.
http://www.xsi-blog.com/archives/133

My result differs especially the wood texture. Is the gamma of my texture correctly remapped? It still looks too washed out.
See the attachment:
First render is my test.
Second render is taken from the blog.

#110

Err, don’t you want to plug the texture into the value attribute then set gamma to 0.4545,0.4545,0.4545?

#111

Oh my. That was stupid indeed. Thanks man.
So this step is just necessary if you are using a texture. If I’m using a standard shader with a simple color, I don’t have to regamma this color right?

#112

You do if you want it to look the same when rendered with no shading of any kind – think no lights and 100 % white ambient – as it does in the color picker.

#113

Actually you kinda do. :scream:

Not with a gamma node, just by darkening it yourself. The colour you see in the Maya Colour Picker UI is at gamma 2.2 already just as your textures are.

Does that suck? Yes it does.

EDIT: Oh it seems the good captain beat me to it. In that case I get to say…

Noooooooooooooooo! Curse you Captain Obvious! :applause:

#114

Ok I’ve read through blazelets great summary and your following post Jozvex.
Thanks for your explanation. I understand the topic pretty much now.
Just one last question to make it sure :slight_smile:
Let’s say I’m going to save my image as a HDRI as a .exr to retouch it in the post. Then of course I don’t have to aply the lens shader to correct the gamma. But no matter if I save it as a HDR or a LDR I have to degamma my file textures before?

#115

Yes, if at some point later you will add the gamma back onto the image, you need to degamma the textures. :thumbsup:

This thread has actually been quite fun (scary, I know!) because it reassures me that I’m doing it properly!

#116

On a side note: PRMan doesn’t support RIP maps in the new TIFF texture format (now default since several years).
Only when txmake is asked to produced an old Pixar TEX format the RIP map option is supported (-pattern diagonal requires -format pixar).

.mm

#117

Yes, you do indeed.

#118

At that you want to degamma every texture that has an impact on color, not just the main color or diffuse node.

Other than the value problems, your gamma correction connections look spot on! Thanks for posting a picture of that, it will make it easier for others to understand.

Data Nodes such as bump wouldn’t need gamma correction though.

#119

As has already been stated, that depends on how you generated them. If they’re painted, then you do need to gamma-correct them. If they’re extracted from geo using zbrush etc then you don’t.

#120

As has already been stated, that depends on how you generated them. If they’re painted, then you do need to gamma-correct them. If they’re extracted from geo using zbrush etc then you don’t

Thanks for the clarification :slight_smile: I hadn’t thought about this pertaining to bumps - but it makes sense.

#121

On the other hand, the effect on bump maps and such does not change based on your output gamma. The bump map will change the surface normal by the same amount when you’re rendering to gamma 2.2 as when you’re rendering to 1.0.

This is not really the case with color maps, though. Applying gamma correction to a scene where the color maps are also gamma corrected (ie, as most people do it), you get very washed out-looking images. Applying gamma correction of 2.2 on a scene with no color maps but a lot of bump maps does not dramatically screw up anything at all – it just makes it lighter. It’s not like it’ll magically change the shading normals or anything. :wink:

Of course, if you’re extracting a bump map from a photo, you’d probably want to remove the gamma correction first.