How Gamma correction works?

[UPO]

Hi!

I read lately about gamma correct antialiasing (in R300) and i'm not sure if i understand it right: This technique makes sure that when averaging texels from different triangels in the pixel, color of the pixel is correct?
(because simple averaging would not give correct, natural output?)
If so,

1) Is there general formula to compute output color? (rgb)
2) Can that technique be used in other operations like resampling 2D images (in software like image editor) ?

Thanks for any links or info.

P.S If I completely misunderstand that please don't laught at me :)

[arjan de lumens]

The basic idea of gamma correction is this (assuming all color values are normalized to the [0,1] range): the relationship between the signal strength sent from the GPU's DACs to the monitor and the color intensity actually displayed on the monitor do not follow a linear relationship. Rather, the relationship is something like:

color(monitor) = color(DAC)^2.2

To compensate ("gamma correct"), you can at the GPU side modify the color as follows:

color(DAC) = color(internal)^(1/2.2)

This is sometimes not desirable - if an application/game wasn't made with the assumption that e.g. texture colors map linearly to monitor colors, you get all washed out colors. So instead, you can do as follows: whenever you add/average multiple colors together, reverse-gamma-correct them (color^2.2), add/average them, then gamma-correct (color^(1/2.2)) the result. Doing this with samples used for FSAA of a pixel results in color transitions that are linear in the Monitor color space rather than in the DAC color space, giving a smoother look to polygon edges than what is possible without Gamma correction.

This can be done with Image Resampling as well; when doing bilinear/bicubic interpolation, do as follows for each pixel: Fetch all necessary texels and compute their weights
Reverse-gamma-correct each texel
Blend together the texels according to their weights
Gamma-correct the resultOf course, this implies that it is possible to Gamma-correct standard bi/trilinear interpolation, although no GPU vendor seems to have implemented this idea. (Of course, if you are doing this on an already gamma-corrected display, you get doubled-up gamma correction, which doesn't look too good.)

[akira888]

Don't you lose precision when you transform to linear space since IIRC only around ~190 of the possible 256 color values can be mapped to by the gamma-space-to-linear-space transform? I remember reading a Blinn column around 8 years ago that dealt with that.

[arjan de lumens]

Don't you lose precision when you transform to linear space since IIRC only around ~190 of the possible 256 color values can be mapped to by the gamma-space-to-linear-space transform? I remember reading a Blinn column around 8 years ago that dealt with that.
A natural consequence of the fact that gamma-correction is a nonlinear transform, which is useful to remember. Which implies that when doing gamma-correction and reverse-gamma-correction (as well as the weighted blends in monitor/linear color space) as I described above, you should expand your color data to more bits per component than what is present in the input images - to, say, about 11 or 12 bits if the input has 8 bits per component.

[UPO]

Thanks!
I've got one question:

the relationship is something like:
color(monitor) = color(DAC)^2.2

Is gamma power (2.2) constant ? I've made test image: left side was full white- full black checkerboard and right side was filled with (127,127,127) value.Then i went to driver control and adjusted gamma settings until both sides of image become the same. And what is strange that gamma slider was at about 2.40 don't know if my testing is right :?

[X2]

Is gamma power (2.2) constant ? I've made test image: left side was full white- full black checkerboard and right side was filled with (127,127,127) value.Then i went to driver control and adjusted gamma settings until both sides of image become the same. And what is strange that gamma slider was at about 2.40 don't know if my testing is right :?
The "correct" gamma value depends on the monitor you're using.

[Geo]

[/quote]
The "correct" gamma value depends on the monitor you're using.[/quote]

Am I correct in thinking that the monitor people could help out a lot with making the gamma problem better for everybody if they'd just get together and agree on standards? Isn't there more they could do on their end to make this whole area easier to deal with?

[ehart]

Actually, gamma is even more complex then having a monitor conform to a particular spec. Since gamma is dealing with your perception of the intensities, you can get different values off the same monitor by changing the viewing environment. I would suggest trying that gamma calibration experiment again with the lights on. (I am guessing the room was dark based on your value.)

Everyone talks about a 2.2 gamma, because this is (approx) the one from the sRGB spec. 2.2 was taken as it was reasonable approximation that fits most environments pretty well. (2.2 is a lot closer to 2.4 then 1.0 is)

For more information, you should google for the gamma FAQ by Charles Poynton. (sp?) It has a lot of good information. Some of this stuff is also covered in some of Jim Blinn's books as mentioned earlier in the thread.

-Evan

[Basic]

Poyntons gamma FAQ is indeed good, it can be found here: http://www.poynton.com/GammaFAQ.html

But I thnk there's one error in it. The chart in Q14 doesn't show how computer graphics is done now. At least not realtime 3D gfx.

It says that the frame buffer is in intensity linear form. But if it was, then the gamma corrected FSAA on R300 wouldn't be nesessary. The description of video fits better to realtime 3D gfx.


Btw, what do you folks think is going to happen first?
1) Gamma corrected bilinear filtering and framebuffer output.
This means that textures and framebuffer stays in nonlinear format, and that gamma correction needs to stay in FSAA.

2) Floating point framebuffer and texture formats.
This means that everything can be done in linear format and gamma corrected FSAA can be removed. The gamma correction at screen output have to stay though. (~The gamma slider you'll find in the driver panel.) This means that computer graphics can be done as Poynton says. And a floating point frame buffer could be nice any way for HDR.

[pcchen]

Personally I prefer the second option, but for performance I think the first option is going to happen first.

[darkblu]

Personally I prefer the second option, but for performance I think the first option is going to happen first.

ditto

[UPO]

Of course, this implies that it is possible to Gamma-correct standard bi/trilinear interpolation, although no GPU vendor seems to have implemented this idea.
Can it be usefull when creating mipmaps?. I read that either developer can provide mipmaps ( he may do gamma correction in software) or hardware creates mipmaps automaticaly - does it gamma correct in that case ?

[Basic]

I expected some TBDR fans to jump in here and say that a (fat) tile could be in linear FP32, and that the end result could be stored into a nonlinear R10G10B10 frame buffer. (And I wouldn't object. :))

And that someone would say that it would be nice with a 32 bit FP texture format (as in 32 bit total). Ie R9G9B9E5, where E5 means a 5 bit block exponent.

Back on topic:

UPO:
Yes it could be useful when generating mipmaps. But if it's not there, mipmap generation can still be gamma corrected with a PS that take four point samples, and make the gamma correction explicitly. In R300 they could maybe use the FSAA circuitry that downsamples the backbuffer.
(But I don't know if the automatic mipmap generation is gammacorrected.)