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

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

Whatever the differences in opinion about the why of gamma, we can agree that it is a necessary affair.

On Mon, Nov 24, 2014 at 7:39 AM, Mark Callow <khronos@callow.im> wrote:
Apparently this pass through is what happens today, but the default render buffers are supposed to be linear. That is the expectation/understanding behind the original fixed-function lighting equations and the math for the blending operations.

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.

Because the default render buffer is supposed to be linear.

If browsers are indeed passing through the data, effectively turning the buffer into an sRGB buffer, then what you have proposed is indeed implementable.

Browsers do not operate in linear space for a couple pretty simple reasons. 
  • The first reason is that it's more work to do, as every byte they get needs to be converted into linear space, and the output needs to be converted to non linear space, so it's overhead. 
  • Another reason is, that often the colorspace of input material is effectively unknown. JPEG is proverbially sRGB, but PNG is not. PNG can set a flag indicating the gamma factor, but it's erroneous to rely on that flag, because most software doesn't read it, including GIMP and Photoshop. So in practice what color sources the browser gets to paint, are implicitly encoded in "sRGB'ish", because they where authored on an sRGB'ish system, and there they looked good to the user. 
  • Unfortunately the sRGB'ish handling continues with CSS colors, gradients, blending etc.. Because authors of stylesheets tweaked their settings to look good when mangled in gamma space, not linear space. So if you where to switch to linear space compositing, there can be substantial changes to how things look.
  • sRGB textures/rendertargets where not available
Currently we can't service the sRGB gamma curves from WebGL with any built-in functionality. But we do have sRGB textures (at least on paper) in WebGL. We do not have sRGB drawing buffers. I don't know if browsers can technically service sRGB drawing buffers correctly, because I don't know if they can read out the sRGB values (not converted to linear space) out of a texture that would serve as the drawing buffer for pass trough (because the browsers compositor isn't linear space). This is where the vendors need to speak up.
The question then is how many browsers would return something other than an sRGB curve to the getGammaRamp query? Whether it is a worthwhile addition for WebGL 2 depends on the answer. For WebGL 1 it seems like a worthwhile addition.
That's a good question, and I don't know the answer to it. Anybody?
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.
Hmm. I need to do some more research including finding a copy of “A ghost in a snowstorm”, but it is my understanding that all blending should be done in a physically linear space. NVIDIA’s recent GL_NV_blend_equation_advanced extension, which provides the blending functions specified by vector graphics standards such as PDF and SVG, does all the blending in linear space.
It's true that blending should be done in linear space. But it matters a lot more for realistic rendering applications (with lighting and whatnot) than for pasting images together in a UI. Historically, simple usecases do not blend in linear space. For realistic rendering applications/games, there's also a strong historic precedent of not operating in linear space. The reasons for that are:
  • Authors aren't sufficiently educated about the topic
  • If you operate in linear space on byte textures, you will get banding.
  • It was often not feasible to use higher precision textures for bandwidth limitations (getting more FPS was more important than getting the right shading).
  • sRGB textures/framebuffers where not supported, and although not as banding free as higher precision formats, they are a low bandwidth alternative that's better than linear byte textures.