[css-color-hdr] Initial value of `dynamic-range-limit`

[svgeesus]

I am also not convinced that the default value for high is appropriate. constrained-high seems like a more reasonable default.

Originally posted by @smfr in WebKit/standards-positions#312 (comment)

[svgeesus]

I am also not convinced that the default value for high is appropriate. constrained-high seems like a more reasonable default.

All browsers display HDR video using high as the default, so this would be a substantial change in existing behavior, which would require coordination with every site that delivers HDR video.

There does exist some HDR content that is "just too bright", and doesn't coexist well with SDR content at all. That's a "the content is bad" problem, and solving it via a default of constrained-high has the negative effect of further-enabling bad HDR content, and penalizing good HDR content.

Originally posted by @ccameron-chromium in WebKit/standards-positions#312 (comment)

[shallawa]

There does exist some HDR content that is "just too bright", and doesn't coexist well with SDR content at all. That's a "the content is bad" problem, and solving it via a default of constrained-high has the negative effect of further-enabling bad HDR content, and penalizing good HDR content.

Should not we define what good HDR content and bad HDR content are first? I think one definition might be

1. good HDR content is the full screen HDR video/image.
2. bad HDR content is the HDR video/image when it coexists with SDR contents.

So if the page states that when the video is displayed in full screen use dynamic-range-limit: high and when it is not full screen use dynamic-range-limit: constrained-high then the user should not see that as a negative effect. In fact this will look like, the brightness of the video/image is shaded by other SDR contents in the page (or even the screen). And once the user focuses on the video and brings it to full screen, all the brightness of the video can be seen.

[ccameron-chromium]

By "good HDR content" and "bad HDR content", I don't mean the arrangement of the content on the screen, but rather the content itself (the pixel values).

Most iPhone and Pixel photos are "good HDR content" in that they coexist well even when they are the only HDR content on-screen, surrounded by SDR UI. Most professionally produced HDR videos are good by this definition (but there is a bunch of undefined behaviors there that hopefully will get pinned down).

[smfr]

See also #11558

[ccameron-chromium]

By "good HDR content" and "bad HDR content", I don't mean the arrangement of the content on the screen, but rather the content itself (the pixel values).

As an example of concrete guidance (as opposed to my "phones do pictures well" hand-waving), I really like what this article says in the "What’s next?" section.
https://blog.adobe.com/en/publish/2023/10/10/hdr-explained

[ccameron-chromium]

Should we duplicate this into #11558 or vice versa?