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

Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D

On Sep 7, 2010, at 12:32 AM, Thatcher Ulrich wrote:

> On Tue, Sep 7, 2010 at 5:31 AM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
>>  On 07/09/2010 11:15, Cedric Vivier wrote:
>>> I'm not really fond of a WebGL-specific toggle flag, and especially an
>>> unpack toggle flag, it looks "out of place" IMHO. Also it seems that
>>> this kind of toggle parameter has been deliberately avoided when
>>> developing the OpenGL sRGB extension ([1] and [2])
>> Putting a flag in unpack state implies a conversion takes place on
>> loading. The sRGB texture extension is specifically written so an
>> implementation can apply the conversion as it is reading texels or at
>> texture load time.
> OK, I think two different things are being conflated here.
> 1) Gregg's description of
> down to "convert input images to sRGB before putting in texture
> memory".  If the image has a metadata gamma tag of ~2.2, or omits the
> metadata, it is a no-op -- the image is already in sRGB.  If the image
> has a metadata gamma tag other than ~2.2, it means the browser can do
> a conversion to gamma=2.2, and then pass the data to OpenGL.  Firefox
> evidently does this conversion on HTMLImageElement when it loads a PNG
> with the gAMA or other metadata tags present.  The WebKit browsers
> evidently ignore the image metadata and always treat the raw data as
> sRGB.
> 2) As I understand it, Steve Baker was expressing a desire for a
> PixelStore mode that would convert from sRGB (or other arbitrary
> gamma) into gamma=1.0, in order to facilitate the way he likes to
> organize his pipeline.  This is sort of the inverse of 1) -- i.e. it
> could take an sRGB image and convert it to gamma=1.0.
> The EXT_*_sRGB extensions are an alternative mechanism designed to
> achieve the goals of 2) without the drawbacks.  In their preferred
> embodiment, they do nothing to the actual texture data stored in
> texture RAM.  In an alternative non-preferred embodiment, they munge
> the texture data in a manner similar to how 2) would munge an sRGB
> input image.

I don't believe that's conflation. I believe those are some of the proposals on the table. But let me be very clear. The sRGB extensions are not on the table. WebGL 1.0 will not have any extensions defined for it. That doesn't preclude a browser from doing an experimental implementation of some number of extensions. But there will be no guarantee for consistent support.


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: