[Public WebGL] gamma/color profile and sRGB

Florian Bösch [email protected]
Sun Nov 23 22:58:10 PST 2014

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 <[email protected]> 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
> <https://www.opengl.org/registry/specs/NV/blend_equation_advanced.txt> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141124/3183c6aa/attachment.html>

More information about the public_webgl mailing list