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

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

On Sun, Nov 23, 2014 at 8:14 AM, Mark Callow <khronos@callow.im> wrote:
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.
The human eye has a spectral response for primaries, that roughly align to CIE-1931 (or later improved revisions). This roughly corresponds to the spectral primaries of RGB of today. The curves are there to account for the fact that you only have 255 states per primary, and that depending on the energy, the eye is more likely to notice banding. So you compress one range, and expand another to hide banding issues.

The real world doesn't work in gamma curves, and the 8-bit per channel "display standard" is rocking at its base already. Taken together with the lessons from PBR, whereby to produce consistent renderings, you operate in linear space, not in gamma space, this means that in the not so distant future, the holy trinitry of gamma ramp, 8-bit per channel and sRGB will probably disintegrate completely as:
  • Wide Gamut displays get commonplace
  • 12, 16 and 32 bit per channel displays get commonplace
  • DisplayPort/HDMI get updated to handle expanded bit per channel formats
  • Image formats abandon 8 bit per channel in favor of various floating point formats (various camera raws to cite just one example)
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.
They only remain valid insofar as you're talking about a need to compress contrast to avoid banding.
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.
But mainly legacy really.
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.
It is a pain, but it's also common practice. Precisely because discovering, or adjusting a system wide setting has been botched beyond recoginition by popular OS and device vendors. If the industry is failing you, you aren't going to fail your users, as a rule of thumb.

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.
What I'm proposing is 3 things:
  • Proper pass trough handling
  • Proper sRGB handling
  • Proper gamma ramp handling
Each of those is currently being questionable or unhandled, which creates problems on various fronts.
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.
I hope that is exactly not the case, because that would be quite the wrong thing to do, without the application programmer having indicated his willingness for this to happen.