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

Re: [Public WebGL] gamma/color profile and sRGB



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 <pyalot@gmail.com> wrote:
On Sun, Nov 23, 2014 at 1:57 PM, Mark Callow <khronos@callow.im> 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.