[Public WebGL] gamma/color profile and sRGB

Florian Bösch [email protected]
Sat Nov 22 23:34:39 PST 2014


On Sun, Nov 23, 2014 at 8:14 AM, Mark Callow <[email protected]> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141123/4372dd35/attachment.html>


More information about the public_webgl mailing list