[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D
On Tue, Sep 7, 2010 at 11:51 AM, Mark Callow <email@example.com> wrote:
> On 07/09/2010 16:58, Thatcher Ulrich wrote:
>> On Tue, Sep 7, 2010 at 4:21 AM, Mark Callow <firstname.lastname@example.org> wrote:
>>> On 06/09/2010 18:54, Thatcher Ulrich wrote:
>>>> Actually, an app author can do this directly in their fragment shader.
>>>> Just do "gl_FragColor = pow(linear_rgb, 1.0 / 2.2);" at the end of
>>>> the shader. When/if WebGL exposes EXT_framebuffer_sRGB, the hardware
>>>> can do this more cheaply (and perhaps more exactly) using a lookup
>>> Subsequent blending and anti-aliasing will then be mathematically and
>>> visually incorrect. Blending and especially anti-aliasing must be done
>>> in a physically linear space.
>> You say they "must" be done in a physically linear space, and yet in
>> practice no system works this way unless EXT_*_sRGB are enabled, or
>> unless the shaders are written to work around this.
> I repeat. All the math. in the OpenGL spec. including blending is
> predicated on using a physically linear space. If you do it in a
> perceptually linear space the results are wrong. Doing the conversion in
> the fragment shader means the renderbuffer contents are converted before
> blending and anti-aliasing, ergo the results are incorrect.
> You are incorrect in stating that in practice no system works this way
> (in linear space). All SGI systems had gamma correctors so computations
> could be done in linear space and the results converted on output to the
> display. This is because as authors of IRIS GL and later OpenGL, we
> understood that the math is only correct in a linear space.
OK, I exaggerated slightly when I said *all* systems behave that way.
I'll take your word for it that SGI systems did something different.
I'm curious what exactly they did, but in any case I don't think it
affects WebGL which will be implemented on consumer hardware built
within the last 10 years. Practically all of that hardware will, by
default, and "incorrectly", do linear operations on non-linear data.
> A good
> number of desktop video cards in modern PCs have gamma correctors,
> although it is not immediately clear how many GL or D3D drivers turn
> them on.
If I understand correctly, "gamma correctors" == the hardware to
implement EXT_*_SRGB. I don't think any drivers will (or should) turn
them on unless the app asks for them.
>>> Doing what you suggest is only correct if
>>> blending is disabled or is blend equation and func are set such that the
>>> destination is replaced by the source color.
>> Yes -- sorry to be the bearer of bad news. EXT_*_sRGB are designed to
>> correct this.
> If you are using an SRGB8_ALPHA8 renderbuffer then there is no need to
> do conversion in the fragment shader and my comment becomes irrelevant.
> That is hardly bad news.
The bad news is that SRGB8_ALPHA8 is not in ES 2.0 (it was introduced
into OpenGL via EXT_texture_SRGB), so it's not in WebGL yet. It does
appear in base OpenGL 2.1, and the equivalent states
(D3DSAMP_SRGBTEXTURE and D3DRS_SRGBWRITEENABLE) appear in D3D 9 so it
should be pretty mainstream in terms of hardware support.
I'm 100% in favor of getting these into WebGL as soon as possible.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: