[css-color-hdr] Alternative proposal for `dynamic-range-limit` defaults

[weinig]

With the new (to me) information that Safari does not currently render HDR images as HDR, I want to propose an alternative to the status quo where the initial value of dynamic-range-limit is no-limit.

I propose we change the initial value of dynamic-range-limit to standard and suggest an update to the default user agent style sheet of:

video {
    dynamic-range-limit: no-limit;
}

This brings with it a number of benefits (and of course some tradeoffs).

The benefits are:

• Relatively easy to understand. The web has been mostly SDR for a while, and
• Limits accidental HDR usage by authors who aren't testing in the latest browsers.
• Can simplify the story for HDR CSS colors by allowing us to define that when an author specifies dynamic-range-limit: no-limit or dynamic-range-limit: constrained-high, CSS colors can also participate, allowing color(srgb 10 0 0) (or what have you) be super bright (behaving like a non-gain-map style (non ISO 21496-1? I need a better term for this kind of image) HDR image. This wouldn't preclude the use introduction of an color-hdr() function as proposed, as that would just end up being the equivalent of a gain-map / ISO 21496-1 style image.

There are two tradeoffs I can see:

• I believe Chrome does support HDR images in some capacity already, so this would be a change for them.
• CSS colors that happen to be on a video element (say, a border) that happen to require additional brightness may raise the brightness accidentally, but I expect this to be almost non-existent in practice.

[ccameron-chromium]

I'm sympathetic to the idea that if we were coming at this ex novo, having standard as the default would be reasonable. That said, we're opposed to this.

Re: simplicity

Having video and img behave differently will probably be long-term confusing. The only way to explain that behavior is to reference historical behavior.

I believe Chrome does support HDR images in some capacity already, so this would be a change for them.

Chromium has supported HDR images for >3 years, and there are partners, products (Google Photos), and now there are unrelated out on the web pages (especially in the photography area) that support this.

Re: CSS color

If we allow something like color(srgb 10 0 0) to be HDR by default, then we have to answer the question of "what is the default tone mapping for this color to SDR, to 2x headroom, etc", which I think makes things more complicated. Requiring use of color-hdr to get HDR color makes it so that adding an HDR color requires also specifying how the color should look in SDR, which avoids this problem.

It also makes implementation much more complicated. The user agent needs to "turn on HDR" based on the content that is on-screen. In particular, it needs to configure its display to have some amount of headroom (headroom isn't free in terms of memory and power). It's easy to detect HDR images or videos, because they're marked as such (and they also include metadata indicating how much headroom they need). But for individual colors, is the color color(srgb 1.2 0 0) supposed to be HDR? Maybe? But it's equivalent to color(rec2020 0.99 0.30 0.11), so maybe it's just wide-gamut SDR. The color-hdr syntax makes it clear (1) when a color is to be HDR vs not (2) the maximum HDR headroom it will use.

[svgeesus]

If we allow something like color(srgb 10 0 0) to be HDR by default, then we have to answer the question of "what is the default tone mapping for this color to SDR, to 2x headroom, etc", which I think makes things more complicated. Requiring use of color-hdr to get HDR color makes it so that adding an HDR color requires also specifying how the color should look in SDR, which avoids this problem.

I agree with this reasoning. It seems simpler and cleaner to have an explicit opt-in of CSS colors to HDR. CSS Color 4 and 5 are, explicitly, SDR.