Having recently started using Poser Pro, I've tried to be a really good bunny by reading up about gamma correction and linear rendering on Poserpro.net. A little light (just a little one) switched on in my head, and prompted a couple of questions which hopefully someone with a brighter light inside their head can answer:-

1. What gamma correction should we assume to be present in the texture maps for our purchased characters? Is it safe to assume that they are not gamma corrected (i.e. gamma = 1.0), since earlier versions of Poser would not have had the ability to 'uncorrect' this value before rendering? Or should we assume that vendors now generally incorporate some sort of pre-render 'linearisation' within the shaders?

If either is true, and we want to apply gamma correction to our render output, then the textures themselves will be over-compensated on input, since by default the texture manager applies the same 'uncorrection' value to the texture maps before rendering. To correct this, we would have to override this setting with a custom value of 1.0 on all the relevant texture manager screens.

1. What post-render gamma correction ought we to use for posting our renders direct to a website such as Rendo? I understand that PCs using sRGB expect 2.2, and that Macs generally use 1.8, so should we use 2.0? (Actually, the Poserpro.net write-up makes a confusing distinction between "Mac" and "Intel" machines, but I assume they really mean Mac and PC).

Of course, it's always possible that the little light inside my head is actually a lot dimmer than it seems, and I've got it all wrong....

Thanks in advance for any enlightenment you can offer.

 In general, assume everything is sRGB 2.2 unless stated otherwise. Your existing color textures are most probably gamma corrected to sRGB because a) that's what the file format standards are and b) the content creator used a monitor with a roughly 2.2 gamma curve.

With post-render gamma correction, I'd also use 2.2. That Mac vs Windows gamma is just a very vague rule of thumb; barely anyone's using a calibrated monitor anyway, so the actual gamma of the screen that it will eventually be looked at varies.

Thank you for the advice, stewer. I realise there have to be some assumptions and compromises, but that really helps.

I'm still wondering, though, if vendors have tried to 'linearise' their gamma-corrected texture maps within their shaders specifically for Firefly. If that is the case, to prevent over-compensation of the input gamma in Poser Pro we would either have to remove the attempted 'linearisation' from their shaders, or set the texture gamma values to 1.0.

I'm sort of hoping that bagginsbill will tell us how this affects his VSS skin shaders, of which I am a great fan....

Isaoshi: Thanks for posting this question.  I'd been sort of wondering about
my own monitor settings, so I found some calibration methods and checked it.
Turns out it was entirely too dark, which was causing me to make mistakes
in setting up Poser scenes.  For example, a dark sleeve was indistinguishable
from a dark wood table.  After readjusting the monitor, I realized I had put the
arm inside the table.  Other viewers would have noticed the error, but I didn't see it!

Hi David... I'm happy that some good came out of it!
:O)
Izi

In the VSS skin shader, I anti-gamma correct the incoming texture, and then I gamma correct the final output, just as Poser Pro would do.

To make VSS stop doing that, go into the shader and change the 2.2 to 1.

Thanks, bb, you're an asterisk.

Ok, let me make sure I have this clear.

If I'm going to use nodes to adjust an image,  I need to remove the gamma correction (using a color math node to raise the image to the 1/2.2 power {or is that taking the 2.2th root of the image?}), do whatever voodoo I need to do with nodes, then reapply the gamma correction to the result (using a color math node to raise the image to the 2.2 power) just prior to attaching it to the root node.

Do I need to do this to displacement/bump maps as well?

Thanks.

USMale,

You got the 2.2 versus 1/2.2 backwards, and you need Color_Math, not Math.

You take the incoming image and raise it to the 2.2 Power. (This darkens it so it is no longer compensated for your monitor.)

I know that sounds strange - raising to 2.2 darkens? But think about it. Brightness is expressed in terms of  fractions, with 1.0 being the brightest possible thing you can see in a monitor.

So what is .5 ** 2.2? Bigger (brighter) or smaller (darker)? You got it - smaller and darker.

So image/color coming in - raise to 2.2 power.

Do your lighting and other shader voodoo.

Then image out, raise to the 1/2.2 power.

I tend to put the 2.2 in its own math node. I then hook up Color_Math:Pow nodes to that value, and also to a Math:Div node to make 1 over that value (the inverse).

The question of what to do with displacement actually has some terribly complicated "what if it was made like this? what if I did that first" questions that affect the answer. But the basic answer is, no you don't gamma correct those. Such images are not images in the true sense. They are data. A displacement map is a gigantic two-dimensional array of numbers. These numbers happen to be stored in an "Image" but it isn't an image and it is very unlikely that gamma correction ever took place on that data on its way to being stored. For example, a ZBrush-generated displacement map would already be linear.

On the other hand (here's where it not only gets complicated, but also stupid) you get people making displacement/bump maps out of their color textures. In my opinion, you don't need to ask if you should gamma correct those - you should just throw those away. They are garbage.

Quote -  In general, assume everything is sRGB 2.2 unless stated otherwise. Your existing color textures are most probably gamma corrected to sRGB because a) that's what the file format standards are and b) the content creator used a monitor with a roughly 2.2 gamma curve.

With post-render gamma correction, I'd also use 2.2. That Mac vs Windows gamma is just a very vague rule of thumb; barely anyone's using a calibrated monitor anyway, so the actual gamma of the screen that it will eventually be looked at varies.

Stefan, guess what I'm finding on flickr.com? I'm finding equirectangular JPEG images that were originally HDR images. They are in linear color space, even though they are stored as JPEG, and I have to gamma correct them before rendering - otherwise they look stupid.

We can no longer talk about the JPEG as sRGB rule. People are abusing tools and techniques all over the place.

The only right answer is: Look at the image. If it is dark and oversaturated, then it is linear and you should not anti-gamma the image on the way in, even if it is a JPEG. If it looks normal, then it should be anti-gamma'd on the way in, even if it came from a .HDR or .EXR file. (I"m seeing these, too. Gamma corrected HDR images. LOL)