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

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



On Tue, Sep 7, 2010 at 3:49 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
> We seem to be at an impasse. On the one hand a physically linear drawing buffer gives you mathematically correct results. On the other hand an sRGB drawing buffer gives you a perceptually linear space and better quality. A linear drawing buffer requires more than 8 bits per component to prevent banding in the dark areas of the image, but we can't require a drawing buffer with more than 8 bits per component. An sRGB drawing buffer will either result in incorrect math or require extra work to give correct results (depending on who you talk to).
>
> Apparently today's GL authors who really care about quality take control of the pipeline at all phases. They choose:
>
> 1) the color space of the incoming images
> 2) automatic color space conversions done on textures (using the sRGB extension)
> 3) the pixel computations done by the shaders
> 4) the number of bits per component in the drawing buffer
> 5) the color conversion done when compositing the drawing buffer to the display
>
> 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. Doing this makes for the simplest possible author experience. It won't be "correct", but I believe it will give authors the least surprising results. Rendering an unlit image will produce results that match rendering  that image as an <img> tag. Of course, the same would be true if the defaults were to have all images be linear and for the default drawing buffer to be linear. But at 8 bits per pixel you would lose precision and dark areas would be banded. That wouldn't match <img> tag rendering.
>
> In fact, I don't think there should be an option to convert images to linear space at all. The option should be to simply turn off any color space conversions (as we've been discussing all along). I believe this gives authors sufficient flexibility given our other constraints. An author can set the drawing buffer to linear to be able to do "correct" math. And images can be brought in without correction to allow the author to use any color space on the original source image. Because  of the lack of ability to define a drawing buffer with sufficient bits per component, this might result in banding. In that case an author could choose to work in sRGB color space. The math might not be right, or the shaders might have to be more complex. But the author might choose to do so to achieve the desired results.
>
> I believe adding the colorSpace flag to WebGLContextAttributes gives sufficient flexibility to satisfy the needs of WebGL authors.

I'm happy with the default behavior.  I don't think the non-default
behavior is necessary, but it doesn't hurt me as long as it's
optional.

-T

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