[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Florian Bösch [email protected]
Wed Jun 15 03:25:09 PDT 2016

On Wed, Jun 15, 2016 at 12:19 PM, Mark Callow <[email protected]> wrote:
> A solution is for the browser to use an sRGB default framebuffer for its
> final output. It can use linear or sRGB textures for the canvas backing
> stores and page backing store as it wishes (ignoring issues of backward
> compatibility with the current broken situation).
You cannot ignore backwards compatibility for this case. So if you want an
sRGB convention for the front framebuffer for WebGL, it has to be explicit
and opt-in. You could do that with context creation attributes.

> The GPU will convert everything to linear during compositing and back to
> sRGB again when writing the composited result.
Browsers are colorspace agnostic, if you where to define the browsers
compositor as linear space, there would be all kinds of problems with color
reproduction because people have tuned all their color values to work with
the non linear space compositing, so that's not going to happen. The most
realistic thing to happen is just that sRGB is passed trough correctly from
the frontbuffer.

But I need to point out, that exactly this "shunting" trough sRGB is part
of the problem in color reproduction. It's better than what currently
happens, sure, but it's not better than what I suggested (explicitely
defining a high precision linear space frontbuffer, also as an opt-in
mechanism). Although I'm aware that also puts the browsers compositor into
a difficult position (because now it'd need to composit everything that way
as well).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160615/991fb1a5/attachment.html>

More information about the public_webgl mailing list