Re: Next telecon agenda + review presentation

One point of reference about modern desktop and mobile operating systems
and browsers' color management.

All modern operating systems and browsers, when displaying images and
videos, perform chromatic adaptation, and clamp colors that are out of the
display's gamut (that is, they do "relative colorimetric intent" by
default). All modern operating systems also do perform tone mapping on
out-of-brightness luminance in HDR content.

On Tue, Jun 13, 2023 at 2:14 PM Pekka Paalanen <pekka.paalanen@collabora.com>
wrote:

> On Fri, 2 Jun 2023 10:51:39 -0700
> What is the "gainmap" as referred there?
>

This is a reference to gainmap based HDR images. There is a write-up by
Adobe at:
https://helpx.adobe.com/si/camera-raw/using/gain-map.html

There is also some discussion about them at WWDC 2023
https://developer.apple.com/videos/play/wwdc2023/10181/

I am a big fan of the approach, because it makes all of the difficulties in
integrating HDR into desktop operating systems  go away (everything is
relative to SDR white, all tone mapping is completely parameterized by HDR
headroom, the content author controls how the content is tone mapped to
SDR, and the content has a clear maximum).

Does this mean that
> gamut mapping is not performed, or that it is fully reversible?
>

There are WPT tests that enforce that, when rendered to non-floating-point
canvases (so, all canvases), out-of-gamut colors are clamped,
component-wise, to the canvas' gamut.


> Why the inconsistency of using tone mapping but excluding gamut mapping?
>

Clamping luminance is much more jarring than clamping chrominance.


> If on the other hand the canvas is supposed to have a consistent color
> space with a specific appearance, then you would need not only tone
> mapping but also gamut mapping and chromatic adaptation.


My goal with canvas here is for canvas to behave the same way as non-canvas
content behaves in the operating system (and the operating systems
uniformly perform chromatic adaptation, clamping out-of-gamut chromiumance,
and tone-mapping out-of-range luminance).

> E.g, sRGB➔PQ➔sRGB will be darker than the original.
>
> I suppose it is due to choosing the tone mapping algorithms such that
> they cause that darkening, but why would you choose your tone mapping
> algorithms like that?


Good point.

If this is just a strict transcoding, where the PQ signal has metadata
indicating that its content maximum luminance is equal to SDR white, then
indeed there is no darkening. But, if the sRGB content is combined with
other HDR content which has a higher content maximum luminance (and this is
what I had in mind, but I didn't write out), then, in order to not clip the
higher brightnesses, we'd need to darken the SDR content.


> I've read that ideally, the average luminance of HDR content is not
> much different from SDR content, because the point of HDR is not to
> make everything brighter.


Strongly agree with this point -- HDR should not be "just brighter".


> But if round-tripping SDR content through PQ
> system causes it to be darker, then something seems off.
>

Yes (it's actually not a strict "just round-trip SDR" that I had in mind,
but my slides didn't make that clear).