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

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

On Sep 4, 2010, at 11:09 AM, Steve Baker wrote:
> 2) Textures that are loaded into WebGL have an *optional* conversion
> from the color space of the image file into linear color space and where
> the color space of the file is ill-defined, it shall be assumed to be
> sRGB with a gamma of 2.2.
> This implies a need to reverse-gamma correct formats like JPEG and some
> careful reading of the PNG and GIF specifications to see how the color
> spaces of those files are described.  But no matter what, we allow the
> application to disable this conversion on a per-file basis.

Gamma is not a separate property -- it is part of the colour profile, when we say sRGB that colour profile is the entirety of the information necessary -- if gamma were not a feature of the colour profile it would be possible to request something like "Linear RGB with a gamma of 2.2" which is clearly not sensible :D

I recommend that we drop references to "gamma" as it only confuses things.

I also believe colour matching of textures should be the default, with an optional override.

> 3) It is essential for WebGL applications to be able to render an image
> in linear color space and to subsequently use that image as a linear
> color space texture with no additional processing steps.
> There has to be a high-efficiency, zero-messing-around-with-my-data path
> for render-to-texture.  Since we're going from linear to linear color
> spaces, that's not a tough proposition.

This is purely an implementation detail and doesn't warrant being in the spec.  Any implementation that does not do this efficiently is going to appear slower than other implementations and hopefully it's apparent that UA vendors don't like appearing to be slower than other vendors.

> 4) There is an *optional* color space conversion step when reading back
> canvas data into WebGL as a texture if the canvas is not already in a
> linear color space.
> Since WebGL canvasses and textures are always linear, this cannot (by
> definition) interfere with (3).  But it may result in sRGB to linear
> conversions when reading back other kinds of canvas images...unless the
> application disables that.

I'm not sure what you mean here.

> 5) Final color space conversion of a WebGL canvas to the *device* color
> space is a clearly specified *non-optional* requirement.  This
> processing happens in a manner that never interferes with (3) or (4).
> Gamma correction happens in the compositor - or if we're printing the
> page.  The gamma will probably be nailed at 2.2, but it could be
> something that the end user might want to adjust.  For printing, this
> color space conversion might even be into CMYK - but the point is that
> the application is oblivious of this.

This also doesn't need to be in the spec.

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: