[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] The Newly Expanded Color Space Issue



Really dumb question, but if the actual memory of the framebuffer contains (0.5, 0.5, 0.5), doesn't the hardware perform gamma correction at display time to make it appear perceptually 50% gray without requiring the programmer/gfx hardware to otherwise compute (0.73, 0.73, 0.73) and store it into the framebuffer? It would seem like that would make the most sense -- if (0.73, 0.73, 0.73) was in the framebuffer memory itself, then reading it back (which the programmer would expect (0.5, 0.5, 0.5)) would require "gamma-uncorrection".
Similarlly, if I use a program to control the gamma on my gfx card, everything becomes immediately brighter. Does that mean that every stored framebuffer value is modified or that a function is run at display time to perform gamma correction? That seems sort of like it would be too much effort, and likely isn't how the hardware actually works.

I guess I don't understand what the argument is about...If you blend 50% of a pure white with pure black pixel, you should get (0.5, 0.5, 0.5) in the framebuffer, not (0.73, 0.73, 0.73), including when you read it back. If you did not, then (especially multipass) GPGPU which depending on the, errr, correctness of a linear interp. operation would fail magically and miserably. Doesn't that kind of automatically define how colors should be written to the framebuffer?

If all you care about is how the colors are displayed (assuming the framebuffer values are 0.5), then really what should be discussed is how to control/modify the gamma ramp and gamma function itself.

Patrick

On Tue, Sep 7, 2010 at 1:56 PM, Steve Baker <steve@sjbaker.org> wrote:
Thatcher Ulrich wrote:
> Um... 0.73 in an sRGB frame buffer is (perceptually) 73% gray.  Right?
>  I can't tell from the way you phrased the question whether 73% gray
> is the wrong or right answer.
>
Short answer: 0.73 in the final, final, ultimate output of the graphics
card is the right answer for a 50/50 mix of black/white.

A value of 0.73 in the final frame buffer causes a voltage that is 73%
of maximum to be output to (for example) an analog CRT - which will
consequently fire 73% of the maximum amount of electrons at the phosphor
which will result in only 50% of the maximum number of photons appearing
at my eye because the phosphor response follows the 'gamma' law:
output = pow ( input, 2.2 ).  Modern LCD's, DLP's and such emulate a
gamma of 2.2 for backwards-compatibility with old-fashioned CRT's.

Hence a value of 0.73 in the final frame buffer is exactly the correct
answer for a PERCEPTUALLY 50% grey.
> Are you asking for a result where the monitor emits 50% of the photons
> of pure white, or a result that looks half as bright as pure white?
>
This is a red herring.  It's the same thing.

When you have a white polygon that's being lit with two identical
uniform white light sources - and then you turn one of them off - you
get half as many photons arriving at your eye.    That's true whether
this is a real-world polygon with real world lights - or a virtual
polygon with virtual lights and with the photons coming out of the
CRT.   To get 50% of the number of photons - you need to put a value of
0.73 into the final frame buffer for the reasons I explained, above.

 -- Steve

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: