[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 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.

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