I think these proposals together are workable.
(a) a flag in WebGLContextAttributes that specifies the color space of
the drawing buffer.
Doing as Chris suggests and converting all incoming images to sRGB would
be a mistake because the images would then not match the drawing buffer
color space.
so, as Adrienne says, we also need
(b) a way for the application to say 'please convert my input image to
the drawing buffer color space' or 'leave my image alone'.
Later when sRGB texture support is available everywhere we'll need a way
for the application to query the color space of an HTMLImage so it can
say 'leave my image alone' and then specify the SRGB8 format when
loading the texture, if the source image is sRGB. Of course this is only
of interest to applications using a linear color space in their drawing
buffer.
Regards
-Mark
On 08/09/2010 07:20, Adrienne Walker wrote:
> El día 7 de septiembre de 2010 11:36, Chris Marrin <cmarrin@apple.com> escribió:
>> We can't control (2) or (4) in WebGL 1.0, and authors can do anything they want in (3). We can only control (1) and (5). So I propose we add one flag to our discussion, a flag in WebGLContextAttributes which specifies the color space of the WebGL drawing buffer. This is similar to the 'premultipliedAlpha' flag, which tells the HTML compositor about the format of the drawing buffer so it can be properly composited. This flag would be:
>>
>> DOMString colorSpace // 'linear', 'sRGB'
>>
>> I propose the default be 'sRGB'. While I'm sure that's controversial, let me explain why. I further propose that all incoming images be converted to sRGB space.
>
>
> ...
>
> If we want to enable this trade-off, we'd need _both_ a packing flag
> to turn non-linear input textures into linear ones as well as a
> context creation flag to convert the linear framebuffer back into sRGB
> before the compositor uses it. Without the latter option to change
> compositor behavior (i.e. the option to consider the canvas to be in
> sRGB color space) then there'd be no way to pass an sRGB texture
> through WebGL unchanged without a loss of precision.
>
> Both of these ideas have been proposed before separately upthread, but
> I think we need both.
>