[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 5:31 AM, Mark Callow <firstname.lastname@example.org> 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 ( and )
> 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
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
>> >From an API perspective, would it be reasonable to rather support
>> EXT_texture_sRGB - or at least a subset of it - and allow to just
>> specify GL_SRGB8 as tex*Image2D format arguments when one wants the
>> input image data color-corrected ?
> There is the issue of how the application finds out the color space of
> the input img tag so it can correctly specify the format when calling
> But I think this a much better approach than a parameter to unpack.
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: