PDA

View Full Version : Gamma correction and contrast threshold



imported_mike
August 11th, 2005, 01:01
Hi,
I have noticed that gamma correction value doesn't affect sample distribution densities. I think it's not very effective. I'll try to explain it below:

As far as i know, gamma correction is the tool that reverses pixelValue-to-pixelLuminance curve that is embedded to all modern display devices. So the only way to work with "near-to-true" luminance values is to use gamma correction at the end. That is giving most believable lighting and shading with less pain for us.
It's all working great in MR with this way. Only one thing i think was missed.
The eye is very sensitive in dark areas while not so in bright ones. (That's because gamma correction is embedded in displays actually).
Using this fact, i think it's not very effective to compare raw neighbor samples with true luminance values to get their contrast, because it would force undersampling of very important dark areas, at the same time oversampling bright areas too much. It would be much more effective to gamma-correct that samples before comparation i think.

To be more illustrative, i did some images:
http://www.cinemateka.ru/mike/image_gamma1.0.jpg
http://www.cinemateka.ru/mike/image_gamma2.2.jpg

Here we see two images. They are look almost identical. This is a simple constant surface shader with black&white ramp applied to it. First one was rendered straight-forward, without any gamma correction. The second was rendered with gamma-correction set to 0.454545 (for sRGB display with gamma curve of 2.2). To make ramps look identical, i've applied a gamma-correction node after ramp with 0.454545 gamma in it. At first glance, all is ok with both of them.
Now, let's see to their sample distributions:

http://www.cinemateka.ru/mike/samples_gamma1.0.jpg
http://www.cinemateka.ru/mike/samples_gamma2.2.jpg

It's all ok with first image, but look to the second - there are a bit too much samples were taken in bright area, but worst thing is that completely not enough samples are taken in almost black area! The only chance to correct that is to decrease contrast threshold level, and that will force MR to take even more unneded samples in bright area, and overall perfomance will be decreased alot!

This is very painful when you try to get arealight shadow to look ok in gamma corrected mode. Most of computation resources are wasted to bright areas that gives almost no difference, and at the same time there are not enough samples are taken in dark, much more sensitive to eye, areas.

So i see no other fix to that problem except to draw an attention of mental images developers to it.

Thanks,

bart
August 11th, 2005, 09:00
Remember that contrast checking is done on a per sample basis. So, if you put the gamma correction in a lens shader which is the first shader a sample triggers, then the contrast should take the gamma correction into account. If you have multiple lens shaders, probably list this one first.

Has anyone listening in tried this?

imported_mike
August 11th, 2005, 11:31
It may work as a workaround, i haven't checked it.
But it's not very correct as a solution, because when you write image to any floating point format, like OpenEXR, you don't have to apply gamma correction to pixels you write there. It should be applied later in compositing or viewing program. But contrast threshold should work with gamma corrected samples anyway in this case. It should correct "copies" of samples just to get correct contrast level, leaving original samples unchanged i think.

I know that gamma correction is not a very fast operation to put it on every sample, but i think shooting unneeded ray is much worse...

bart
August 12th, 2005, 05:33
Thats interesting. For the case you point out, one wouldn't want to apply gamma correction to the output image, yet still have it affect sample density.

To achieve this in the current version, a lens shader could apply the gamma, while the gamma setting applies the inverse.

Puppet
August 12th, 2005, 09:35
Bart, do you know when contrast check happen, before or after miSHADERSTATE_SAMPLE_EXIT?

Maybe better solution use state shaders for this purpose?

imported_mike
August 12th, 2005, 11:50
In current version of mentalray for maya for all image file texture nodes inverse gamma correction applied if precision of image file is not floating point. That is the right behavior i think.
But if you will set reverse value to gamma correction in global settings, you will have to manually insert gamma correction nodes after each file texture with reverse "doubled" value of gamma, because it would automatically apply incorrect correction and you will have to revert it first and then apply right correction.
It may work. But i still see the difference in result because of filtering would happen with already corrected samples.
But i think it would be a bit annoying for the artists to do... And almost impossible to understand why they have it to do!
That missing feature is forcing us to decrease contrast threshold values to very very low to avoid noise in dark areas as the only relatively simple but very expensive solution... =(

By the way, is adaptive sampling applied for eye rays only?

zap andersson
August 24th, 2005, 13:08
I finally had time to check this issue, and must beg to disagree; mental ray is in fact doing the correct thing.

Mental rays contrast is actually working in a perceptually linear space. This is built in, as far as I know, i.e. contrast ratios are calculated in a gamma 2.2 space always (gamma 2.2 being roughly equivalent to perceptual linearity).

Your first render is a plain ramp done in gamma 1.0, displayed on our computer screens as gamma 2.2 (i.e. in practice, incorrectly). But since you have told mental ray that it is in fact gamma 1.0 you will indeed get it treated as such.

This is why you samples_gamma_1.0 has more samples in the dark areas. Not because it is *needed* due to the way it is displayed, but because it would be needed to display it when corrected to the proper display gamma.

Your gamma 2.2 render looks identical BECAUSE, as you willingly state, you put in a gamma ramp into the shader.

Hence you do in fact NOT have a real smooth linear ramp, but a perceptually linear ramp. You have now told mental ray to display this correctly with gamma 2.2 on your gamma 2.2 screen.

Since this is a perceptually linear ramp, it is quite 100% correct that the sample pattern is almost uniform over the entire surface! If you change your shader to make a real linear ramp, you will indeed see the expected behaviour of more samples in the dark area and less in the bright. Your ramp is not real linear, it is perceptually linear.

/Z

imported_mike
August 24th, 2005, 16:17
As far as i know, most images rendered with gamma 1.0 would not be gamma corrected. If i have to gamma correct my image on post, i render it with gamma correction turned on anyway, but output goes to floating point file format.
Mental Ray handles this case just perfectly, and does not apply any gamma correction to these floating point values.
One more thing that is bad when render image with gamma set to 1.0 and correct it on post - is that image file textures are not "reverse" gamma corrected when gamma is "1.0".
So i suppose to think that image rendered with gamma correction set to 1.0, would not be gamma corrected on post.
With keeping this in mind, the perceptual contrast is the same on both images. So i expect to get exactly same sampling patterns.
Yes, i understand that values that renderer operate, are different in each case. Thats why renderer should detect each case and apply needed correction.
After your explaination I can't say exactly which sample pattern is more correct - but all i know they should be the same only because resulting images are the same to human vision. (after applying gamma correction on second, of course).
And first sample pattern gives more "perceptual" quality with relatively same sample count. This is the most important thing for the artist, don't you agree? =)

Thanks for your help!

svv3d
August 29th, 2005, 11:45
some notes about GAMMA
http://throb.net/site_main/LinearWorkflow.html

bart
September 2nd, 2005, 23:56
OK. A lot of this discussion continued on the mental ray mail list forum, but I wanted to summarize a key behavior.

mental ray, in fact, does not use a strictly linear algorithm for comparing samples. It isn't bound to any particular perceptual space, and it isn't tied to gamma. However, it is closer to perceptual space than it is to linear space.

imported_mike
September 3rd, 2005, 14:41
Yes, and in case of examples shown on top of the thread, it has correct sample distribution in case of 2.2 gamma, and not correct in gamma 1.0 if image will not be gamma corrected.

bart
September 3rd, 2005, 17:57
That seems confusing to me. I would say that the gamma 1.0 example is correct. Simply put, more samples in darker areas reflects more of a perceptual space for sample contrast detection.

If you took out the gamma correction node in your shader graph, the sample distribution would look the same regardless of what your 'global' gamma setting is.

Personally, with this new information, I would only put gamma into the post process after compositing, rendering everything with gamma 1.0, and avoiding any gamma correcting nodes.

And maybe I would use the trick of gamma correcting incoming texture maps, but only if I knew exactly their intended color space.

If I understand you correctly, both of these things will occur simultaneously in Maya, if you set gamma, use the file texture nodes for input, and put out floating point images?

Also, I noticed that the rendered image left edge of your 2.2 gamma example doesn't seem to reflect the sample distribution seen from the 2.2 example. Could you double check that image as using the exact same scene setup? Or maybe the jpg compression is misleading us on the sample positions?

imported_mike
September 3rd, 2005, 18:29
more samples in darker areas reflects more of a perceptual space for sample contrast detection.
That's right, but only if image would be gamma-corrected after rendering on post. If it wouldn't, it's not correct.

If you took out the gamma correction node in your shader graph, the sample distribution would look the same regardless of what your 'global' gamma setting is.
Yes, that's because mental ray always assumes image would be gamma corrected in some way (no matter on post or inside of it). But sometimes that doesn't happen. For example when we rendering some cartoons. And in that cases sample distribution become oversampled in dark areas and undersampled in light areas.

And maybe I would use the trick of gamma correcting incoming texture maps, but only if I knew exactly their intended color space.
That is completed automaticaly in a very smart way, guarantied with a correct result in 99% of cases if you use mentalray gamma correction. And IMHO it would be very hard to control manually if you render without gamma.

If I understand you correctly, both of these things will occur simultaneously in Maya, if you set gamma, use the file texture nodes for input, and put out floating point images?
Excuse my english, but i don't understood that question =( Can you explain in details what did you mean? What both things?

Also, I noticed that the rendered image left edge of your 2.2 gamma example doesn't seem to reflect the sample distribution seen from the 2.2 example. Could you double check that image as using the exact same scene setup? Or maybe the jpg compression is misleading us on the sample positions?
I'm sure that images are correct because it was rendered from one scene. As you can see there is a different antialiasing on the edges because of gamma correction.

bart
September 4th, 2005, 09:01
Regarding the aliased edge, the sample distribution appears just as dense, so I'm not so sure of the claim that it is due to gamma. The antialiasing will depend on the sample distribution, and both images seem to have the same distribution on the left edge, yet the antialiasing is different. So something else must be going on in this scene.

mental ray does not assume that there is gamma always applied. This is completely dependent on how the final product will be displayed.

Gamma is not part of the contrast calculation, but as I said above, it does assume that the render is linear, and applies a sample contrast calculation that is closer to a perceptual basis, assuming the samples are linear.

What I meant by 'both' was both applying a reverse gamma to incoming texture maps while not applying gamma to the output. By using floating point, gamma is not applied to the output. But it appears from your report, that there is a Maya-specific mechanism in their file texture nodes which reverses the gamma on input.

Finally, by 'cartoon' rendering, do you mean for TV/video, and does the render produce the final image? In other words, are you saying that you don't use any post for this?

imported_mike
September 5th, 2005, 13:52
Regarding the aliased edge, the sample distribution appears just as dense, so I'm not so sure of the claim that it is due to gamma. The antialiasing will depend on the sample distribution, and both images seem to have the same distribution on the left edge, yet the antialiasing is different. So something else must be going on in this scene.
You right, sample distribution is the same, the difference is only how the image is displayed. First of all, there was not enough samples taken to do a good antialiasing. There was something about -4 0 and contrast threshold was high (around 0.4), just to make differences more noticable. So all antialiasing you see there is due to box filtering and jpeg compression.
You can try to do it yourself, just create a constant white plane, and render it with and wothout gamma correction. You will see antialiasing will be different, and gamma corrected image will appear more aliased.


mental ray does not assume that there is gamma always applied. This is completely dependent on how the final product will be displayed.
Maybe i said the idea incorrectly.
Mental ray always assumes that samples it work with are in linear space, i.e. each sample is a true luminance value.
Also, it assumes the final image will be displayed somehow to human observer. Due to specific of human visual system, it should take more samples in dark areas, as human eye is more sensitive in dark areas.
This human-specific perception nonlinearity is closely matches to 2.2 gamma function. So MR always uses this function to check contrast threshold.
The problem in first image is that it displayed incorrectly, because it wasn't gamma-corrected to take display gamma-function into account.
So sample distribution is not fit well this type of images. Unfortunately that kind of images are used very often. As an example, i said about cartoons, there physic laws of lights are not so important.


What I meant by 'both' was both applying a reverse gamma to incoming texture maps while not applying gamma to the output. By using floating point, gamma is not applied to the output. But it appears from your report, that there is a Maya-specific mechanism in their file texture nodes which reverses the gamma on input.
Yes, im not sure it's maya specific or not, but i like that logic. Note that this happens only if you set gamma correction to something different then 1.0.

bart
September 5th, 2005, 18:09
OK. That wording is better. Indeed, mental ray mostly assumes a physically linear color space for rendering, in order to better take advantage of physics related calculations. I might also add that this is floating point throughout, except for i/o conversion steps.

However, it does not exactly use a 2.2 gamma function for comparing samples. As I said above, the contrast check for adaptive sampling uses a 'rough' approximation of something which is closer to perceptual space than linear space. Samples are more dense in darker areas.

Also, keep in mind that mental ray is a framework. OEMs create shaders to work within the framework. Things such as the File Texture shading node in Maya are Maya specific. It is conceivable that a set of shaders could be constructed for working in different spaces and using different assumptions.

Not also that there is a color profile mechanism provided by the mental ray framework. I would be interested to see if anyone is using it yet. Specifically, I'd like to see if anyone is knowingly defining the rendering space in which mental ray works, such as a linearized sRGB, or better, a Sharp RGB space.