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

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



On Tue, Sep 7, 2010 at 10:14 PM, Patrick Baggett
<baggett.patrick@gmail.com> wrote:
> 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?

Yes.

> 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.

It depends on your card and OS; both are possible.  Speculation: these
days it is likely that the OS runs everything through a 256-entry
lookup table before hitting the final framebuffer.  In the old days, a
card might have a hardware lookup table between the framebuffer and
the DAC.  Other implementations are possible.

> 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?

OpenGL says that (0 + 1) * 0.5 == 0.5, yes.  OpenGL doesn't specify
what that means in terms of light intensity though.  We are basically
arguing about how that 0.5 should map to light intensity from the
monitor.

> 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.

Yeah, basically we're arguing about what convention to use.  Steve
correctly points out there are a bunch of implications if you are
trying to simulate physical light (but I disagree with some of his
reasoning/math).  More in a moment.

-T

>
> 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:
>>
>
>

-----------------------------------------------------------
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: