[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 2:19 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On Sep 7, 2010, at 1:43 PM, Kenneth Russell wrote:
>
>> 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.
>
> So it sounds like you are advocating that all textures go into WebGL in physically linear color space. If so, we would still need your original flag to avoid conversion into that linear space so we can send pixels in unchanged. If we did that, the conversion from sRGB (which many images will be in) to linear will lose precision and cause banding in the dark areas. But if an author wanted to avoid that, he could turn off the conversion and do it using the pow() function in the shader, right?

Something -- though I am not 100% sure yet exactly what it is -- is
definitely needed for the case of uploading RGBA8 PNGs to WebGL. We
are seeing that the pixel values in the file do not come through
unchanged during the texture upload process, but do not know yet
exactly where the change occurs. See the commented-out test cases in
LayoutTests/fast/canvas/webgl/gl-teximage.html in the WebKit tree. We
probably need to isolate exactly where in WebKit the pixel values are
being affected before pushing forward the pixel storage parameter
proposal.

-Ken

> So this seems like the most reasonable compromise so far.
>
>>
>> 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.
>
> I would be satisfied if we always represented the canvas in linear space with no option to represent it any other way. In that case we would need words in the spec which requires the linear canvas to be converted to device color space on output. But we can probably just lift the words from the 2D canvas spec for this.
>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
>

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