[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb

On Wed, Jun 15, 2016 at 12:19 PM, Mark Callow <khronos@callow.im> 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).