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

Re: [Public WebGL] The Newly Expanded Color Space Issue




----- Original Message -----
> It's time to bring this issue to a conclusion. We can't make WebGL
> programs correct, and we can't tell authors that we will only accept
> mathematically correct WebGL programs. What we CAN do is to give
> authors sufficient tools (given the current constraints) to give them
> the flexibility to do what they want with WebGL. As Adrienne and I
> have pointed out the only things we can do are:
> 
> 1) Manipulate the color space of images being loaded with texImage2D.
> Choices are:
> 
> a) Convert all images to sRGB always
> b) Convert all images to Linear always
> c) Give a choice of which conversion to perform
> 
> (with all choices, we also need a way to turn off all conversion and
> get raw pixels into the engine)
> 
> 2) Manipulate the color space of the drawing buffer as it is
> composited with the page. Choices are:
> 
> a) Always convert the drawing buffer as if it is sRGB into the device
> color space used by the compositor
> b) Always convert the drawing buffer as if it is Linear into the
> device color space used by the compositor
> c) Give a choice of which conversion to perform
> 
> I can live with any combination of the above. Currently my first
> choice would be 1c and 2c, with the default being sRGB for both.
> Please don't criticize those choices as wrong, just make your own
> choice.

Actually, I think a better option for WebGL 1.0 would be to do the simplest thing possible -- for choice 1, that would be to have a boolean flag that says "do whatevever gamma correction/colorspace conversion/etc. the browser normally does on images before uploading" or "don't touch the pixels at all".  Doing anything else seems extremely painful to define, and will likely require some pretty instrusive work in the engines to get the conversions right. The piece that I think that we need for WebGL 1.0 is the "off" switch, that is ensuring that you can get raw uncorrected data from images.

For choice 2, the simplest option would be to define the output canvas to always be sRGB (as with CSS) and leave it at that; no way to modify this, and to not do any conversion; just assume that the pixels that are written are sRGB.  This is what the 2D canvas does, with getImageData/putImageData (with an unfortunate alpha premultiplication step).

Future extensions could add more specific conversions/getContext parameters, but I don't think they're needed in 1.0.

    - Vlad
-----------------------------------------------------------
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: