[Public WebGL] gamma/color profile and sRGB

Florian Bösch [email protected]
Sun Nov 23 05:31:10 PST 2014

Browsers do not composit and operate in linear space. Evidence:
http://www.4p8.com/eric.brasseur/gamma.html . Neither photoshop nor GIMP
pass this test either.

The problem with attempting to support sRGB as a drawing buffer in WebGL
arises from the sRGB texturing specification, which states that if you read
a value (as in texture2D) out from an sRGB texture, it is converted to
linear space.

texture2D is what the browsers accelerated compositor would use to read out
a texel from an sRGB texture. The texture would have been attached to a
framebuffer object, which is what stands in for a canvases drawing buffer.

Today the browser defines that as RGBA, and so no problem arises in pass
trough because the bytes just get pasted in. But once you'd have an sRGB
texture on the drawing buffer, things get tricky for the pass-trough case,
because then the compositor would have to run in linear space, which it
doesn't do, it'd output the linear component read from the sRGB texture
flat to screen, which is not what was intended. If, on the other hand, the
browser itself switches to an sRGB drawing buffer (natively this time), it
means everything is now operating in linear space, and quite a lot of the
web would start looking subtly (or dramatically) different.

On Sun, Nov 23, 2014 at 2:17 PM, Florian Bösch <[email protected]> wrote:

> On Sun, Nov 23, 2014 at 1:57 PM, Mark Callow <[email protected]> wrote:
>> The display in most cases is sRGB. It is not possible to display part of
>> the screen (or composited web page) with a different transfer function from
>> the rest. If the display is sRGB, or whatever, a linear buffer/canvas must
>> be encoded (a.k.a gamma corrected) to the display’s transfer function,
>> otherwise the result is completely wrong. You would be displaying the
>> linear data as if it were encoded in sRGB.
> Pass trough is the default. This should not be changed. Yes if you're
> doing stuff in gamma space, it's wrong. But that doesn't mean you shouldn't
> be able to do it, like I say, pass trough is an important usecase for many
> things, and necessary to avoid degradation due to back/forth transcoding if
> you don't need to account for gamma badly. Not every UI is an application
> of PBR, and not every programmer wants to deal with gamma to blit a flat
> bitmap on screen, and *NOBODY* wants any additional processing to take
> place if it can be avoided. PBR, gamma ramps, sRGB, these are things that
> should be up to the application programmer to decide to use, not for the
> browser or driver to enforce.
> Obviously, this is todays default, and this is the topic of the thread,
> because we have no way to discover what gamma ramp to use, and we have no
> way to use the default sRGB gamma ramp for output other than coding our own
> glsl function for it, which is, not user friendly.
>> Even in native land, access for apps to change the transfer function is
>> limited to full screen apps. How do you propose that a browser pass through
>> just some parts of the displayed web page? If we limit pass through to full
>> screen canvases, how do you cope with blending other page content with or
>> displaying it over the canvas?
> getGammaRamp/onGammaRamp
>> I am not saying pass through is a bad idea. I don’t see how to implement
>> it.
> Pass trough is already implemented. It's todays default. Obviously you
> cannot escape the displays curves, but that's not the meaning of pass
> trough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141123/be04eec0/attachment.html>

More information about the public_webgl mailing list