[Public WebGL] gamma/color profile and sRGB

Mark Callow [email protected]
Sat Nov 22 23:14:58 PST 2014

> On Nov 22, 2014, at 3:17 PM, Florian Bösch <[email protected]> wrote:
> I should perhaps better explain the problem.
> Support sRGB well. Don't make sRGB mandatory. Support unmodified output. Support getGammaRamp/onGammaRamp.

Supporting unmodified output for canvases being composited with other web page content will, I think, be difficult, if not impossible. As Hardware generally only supports 1 transfer function per display, it is only reasonable to do when if the canvas is full screen. Even then, if other page content is being blended with the canvas, the compositor will need to convert everything into a single color space.

> deficiencies and history of sRGB, and why it should be supported well, but not be made mandatory.
> sRGB was created at a time when most displays where crap. By that I mean, they where dim, had poor contrast and a miserable gamut. Consequently it represents a colorspace that's attempting to make things look good on the population of miserable displays that existed at the time, and accepting that better displays where getting the worse end of the deal. This was nearly 20 years ago. Meanwhile displays did get a bunch better, and it starts to show. sRGB isn't a bad choice for an output colorspace, but it's by no means a terribly good one either.
> A particularly problematic area for sRGB is that its prime motivation was consumer grade CRTs from 20 years ago. The assumptions it made about the inevitable gamma ramp of these displays does not hold true anymore for most displays in use (because they're LCDs or OLEDs). In many of these cases, the "gamma ramp" of a display is purely emulated by the display driver (and by that I mean a piece of hardware embedded in the display that does the conversion).

The transfer functions (commonly and mistakenly, referred to as gamma ramps) used in the various color spaces are related not to the displays but to human visual perception. They are designed to give a perceptually uniform response given the expected viewing conditions. That is, each change in input signal gives a uniform change in brightness perceived by a human observer. This means the entire bandwidth is used for information useful to the human eye. Encoding to one of these transfer functions is a form of lossy compression.

sRGB’s transfer function was designed for the expected viewing conditions of a computer monitor. BT709’s is designed for the average living room. Those used in digital cinema are designed for the darkened viewing environment of a cinema. Since they are related to human vision, these transfer functions remain valid despite improvements in displays.

The fact that the response of a CRT’s electron gun is almost the inverse of the human visual response, therefore making the CRT a perfect decoder for the desired signal compression was a happy accident for (or as Charles Poynton calls it “God’s gift to”) television engineers. If it hadn’t been that way, they would have had to invent something that was.

This usefulness, as well as the legacy content, is why displays continue to have transfer functions.

It should be noted that there is a lot more to a color space definition than the transfer function but that is focus of this discussion.

Let’s base our decisions on the proper science.

> A common way to deal with this problem is to offer a user some adjustment parameters inside the application.

I think having to adjust parameters for each application would be a pain. Adjusting them for the display systemwide is the right approach. Of course not all systems provide such controls.

> So if you would make sRGB mandatory,

If the alternatives are useful, I would not object to having them. What you are proposing is something in addition to linear and sRGB back-buffers. Let’s call it custom. How would browsers deal with it? I noted some of the difficulties in my introduction.

BTW, I hope current browsers are converting the current linear back-buffers to their compositing color space. I wonder because such conversion has considerable overhead.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141123/cf492e33/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141123/cf492e33/attachment.asc>

More information about the public_webgl mailing list