On Tue, Sep 7, 2010 at 6:49 AM, 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 believe there is a fundamental reason why WebGL can not use an sRGB
color space by default, which is that OpenGL ES 2.0 does not have any
sRGB support, not even in the form of an extension. (EXT_texture_sRGB
exists on desktop hardware.) As I understand it, the way that most
WebGL implementations would support an sRGB color space for the back
buffer would be to use an sRGB texture as the color attachment for the
FBO they use behind the scenes. If this is correct, then it will be
impossible to make WebGL use an sRGB color space on mobile hardware.
Since a major motivating factor of the WebGL specification has been to
provide a uniform API and behavior between desktop and mobile
hardware, I do not think this is a viable option at the present time.
An sRGB color space might be a good option to have in the
WebGLContextAttributes, so long as the specification allows an
implementation to only support a linear color space, and requires
applications to call getContextAttributes() to confirm which color
space is in use.
For the same reason, I do not think it is viable to specify that
uploaded textures are in an sRGB color space. sRGB texture formats
would first need to be supported on mobile hardware.
Corrections to my understanding, or lack thereof, welcome.
-Ken
-----------------------------------------------------------
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: