[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:24 PM, Thatcher Ulrich <tu@tulrich.com> wrote:
> On Tue, Sep 7, 2010 at 10:43 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> 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.
>
> There's no requirement to use SRGB8_ALPHA8 for the format of the
> destination buffer.  Just use RGBA8; it's physically identical, and
> mathematically identical, unless and until the app calls
> glEnable(GL_FRAMEBUFFER_SRGB_EXT).  Since WebGL apps have no way of
> calling that (the enum doesn't exist), they are effectively identical.
>
> In terms of implementation, if we specify the WebGL output as sRGB,
> there is nothing to change.  Nearly all device framebuffers are sRGB
> or equivalent, so this is effectively the status quo right now.
>
> There are some details about how the browser should do compositing etc
> but they're not, strictly speaking, concerns of the WebGL spec.

I don't see how we can (a) specify that the color space is sRGB and
(b) do nothing in the WebGL implementation. My colleague Al Patrick
points out that the first sentence of the GL_EXT_framebuffer_sRGB
specification (
http://www.opengl.org/registry/specs/EXT/framebuffer_sRGB.txt ) states
"Conventionally, OpenGL assumes framebuffer color components are
stored in a linear color space.". There is a tangible difference to
the application whether or not the OpenGL framebuffer is sRGB. Current
WebGL implementations are not explicitly using sRGB framebuffers,
either via EXT_framebuffer_sRGB or EXT_texture_sRGB, so I assume they
must implicitly be using linear ones.

In WebGL we would likely expose the color space of the default drawing
buffer as a context creation attribute rather than a run-time enable
flag like in GL_EXT_framebuffer_sRGB, so if version 1.0 of the
specification is going to mention anything about it, the behavior will
have to be clearly defined, rather than leaving it up to the
application to enable correct sRGB color space handling by calling
enable(FRAMEBUFFER_SRGB_EXT) at some future date.

Note that we have already encountered color space issues related to
OpenGL and composition of web pages; see
https://bugs.webkit.org/show_bug.cgi?id=43823 . In that bug, the web
page needed to be rendered via Core Graphics using the device's
(sRGB?) color space before being uploaded to OpenGL, because OpenGL
wasn't doing any color space correction. This bug isn't directly
related to WebGL, but does indicate that the composition issue is a
concern for the WebGL specification because WebGL exposes the OpenGL
API and its semantics to the HTML compositor.

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