[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?

[svgeesus]

Noting here that the spec has been updated to change high to no-limit in accordance with the CSSWG resolution and that the proposal is tho make the other two values be constrained and standard.

Just making sure that when we reach consensus on this, we resolve it using the correct values for the property :)

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] Initial value of `dynamic-range-limit` .

The full IRC log of that discussion

<fantasai> ccameron: should it be auto or no-limit?
<fantasai> ccameron: I'm sympathetic to idea that if we're doing this ex-novo, make HDR opt in and whatever for the default
<fantasai> ccameron: but given every browser is shipping HDR on video by default
<fantasai> ccameron: and HDR images is not implemented yet only due to technical complexity
<fantasai> ccameron: I think UA should pull down everything together, and e.g. UA limits to 2x and you have to hint that you want HDR to get it
<fantasai> ccameron: or have mode where try to be smart in that property
<weinig> q+
<fantasai> ccameron: right now UA can do anything
<fantasai> ccameron: But I think everything should be limited on a page together
<fantasai> ccameron: if global limit, then adjust
<fantasai> ccameron: if there's behavior we want to care about
<fantasai> ccameron: better to let HDR images shine out, if too bright, that's just bad content
<fantasai> ccameron: clear signal that your HDR content is not authored in a good way
<fantasai> ccameron: we want people to integrate in a good way
<fantasai> ccameron: encourage people to create good content
<fantasai> ChrisL: I tend to agree with that
<fantasai> ChrisL: e.g. you could create lime green with flashing gif
<ccameron> I haven't been to Geocities that recently....
<fantasai> ChrisL: we don't limit that
<astearns> ack weinig
<fantasai> weinig: piece we're missing is, what's the goal of this property?
<fantasai> weinig: establish goal, then we can figure out our values
<fantasai> weinig: but without that, it's hard for us to make smart decisions
<fantasai> weinig: general premise of protecting people from poorly designed website is not our battle
<fantasai> weinig: But author may not know the source of images, so having author's abilitiy to limit
<fantasai> weinig: in this index, we're going to constrain HDR, because we dont' know what they contain
<fantasai> weinig: let's not waste that power
<fantasai> weinig: but default should be no limit, no use case for auto
<weinig> fantasai: believes that WebKit's position was that the initial value should be constrained
<weinig> fantasai: and things on a case by case basis should be marked unconstrained by authors
<weinig> fantasai: unfortunately not sure of the details, smfr would know more
<weinig> fantasai: authors do have the issue of things like 3rd party content, ads,
<ccameron> q+
<weinig> fantasai: if the default is no-limit, those ads might do bad things, and they would not know, because things works fine now
<astearns> ack fantasai
<fantasai> ads or user-generated content
<astearns> ack ccameron
<weinig> ccameron: would it be better to have a global hint?
<weinig> ccameron: we have to deal with the fact that video is already not constrained today
<weinig> ccameron: lots of people count on that
<weinig> fantasai: webkit/apple thinks a ua style sheet for video would help
<fantasai> ccameron: some browsers are shipping HDR images already, would break that behavior
<weinig> ccameron: for chrome, this would break things for images and webgpu canvas, which have already shipped
<fantasai> ccameron: hard to explain why we have this default a few years from now
<fantasai> ccameron: why not have a global signal
<fantasai> ccameron: whole page, if you want to keep the old behaviors, you need to opt into it
<fantasai> ccameron: roll that out slowly later
<fantasai> weinig: 2 weeks ago, position was that webkit/apple really wanted images also to be HDR unconstrained
<fantasai> weinig: in addition to video
<fantasai> fantasai: I can't remember which elements were proposed to except. ^_^;;
<fantasai> weinig: What if we split property in two, and have one limit apply to things like video/image/canvas -- replaced content
<fantasai> weinig: and separate one that applies to CSS colors etc.
<fantasai> weinig: then you could decide... is bg one or the other
<Said> q+
<astearns> ack Said
<fantasai> Said: I've been working with HDR for awhile now, and I feel it is really distracting to see HDR and SDR together in the same page
<fantasai> Said: I tried to get high quality HDR, but still same experience
<fantasai> Said: So it makes sense to me, to always have mixed content always be constrained
<ccameron> q+
<astearns> q+
<fantasai> Said: and only allow no-limit for fullscreen(?)
<astearns> ack ccameron
<fantasai> Said: This is my experience with SDR and HDR in the same page
<fantasai> ccameron: Right now the UA is free to do that, to limit all the HDR in the page to nothing for e.g. background windows (like Preview does on MacOS)
<fantasai> ccameron: and they can also limit the range heuristically, based on outlines
<fantasai> ccameron: Key thing is that the limit is imposed by UA on all content, so that page is affected all together, not element by element
<fantasai> ccameron: dynamic-range-limit property is author saying what they wayt
<fantasai> ccameron: if UA wants to do something beyond that, is compatible
<Said> q+
<fantasai> ccameron: Sympathetic to opt-in idea, but given where we are, disagree.
<fantasai> astearns: Wrt separate properties idea, aside from images and video, you can define a bg color as HDR color
<fantasai> astearns: if we decide initial value of dynamic-range-limit is constrained, then it's double-opt-in for that color? You'd have to specify the color and also raise the limit
<fantasai> ChrisL: You'd still get the color, just a more subdued color
<fantasai> astearns: That's a fair argument for not having a constraint, since we tend to avoid double opt in
<ChrisL> s/the color/an HDR color
<fantasai> weinig: We would re-imagine existing CSS colors as all being HDR capable, as long as their components were large enough
<astearns> ack fantasai
<fantasai> weinig: it wouldn't be a double opt in, you just need a color bright enough to warrant using some headroom
<astearns> ack astearns
<weinig> fantasai: the idea that the UA can do anything it wants
<weinig> fantasai: works well in cases where the UA has the final say, like background window
<weinig> fantasai: but it doesn't work well when the author overriding things
<weinig> fantasai: in that case, a property makes sense
<weinig> fantasai: element by element makes sense
<weinig> fantasai: but a different default for fullscreen or loaded alone might make sense
<weinig> fantasai: but allowing a page to have a mix of HDR and non-HDR might make sense too
<weinig> fantasai: like YouTube, where there is video, but also other content
<weinig> fantasai: but only the main video should be HDR
<weinig> fantasai: magic limits later seems worse
<weinig> fantasai: should figure this out now, and make it work with the cascade
<weinig> fantasai: weird huerstics are worse, viewport metatag is awful
<astearns> q+
<astearns> ack Said
<fantasai> Said: We should take consideration the default, any possible auto values, take into consideration the transition
<fantasai> Said: At this time [missed]
<fantasai> Said: For example eBay, suppose someone decided "well, now all browsers support HDR, let's use this ability"
<fantasai> Said: [missed2]
<fantasai> astearns: I'm not sure I understand the story of having a constrained default be useful if we are also specifying that videos and images are not constrained for compat reasons
<fantasai> astearns: story of page with a lot of videos, if videos have their headroom expanded in UA stylesheet, that default is doing nothing for that case
<astearns> ack astearns
<fantasai> weinig: We have to figure out and agree on our goal
<fantasai> weinig: sounds like we dont' quite agree on it
<ccameron> q+
<fantasai> weinig: is the goal that videos, images are constrained or unconstrained? constrained in some circumstances? browsers can have different goals?
<fantasai> weinig: I see different goals here. We need to converge on the goal.
<fantasai> weinig: Another issue is that chrome has shipped this, so we also potentially have a compat problem here
<fantasai> weinig: Maybe Apple can give a concerete proposal
<fantasai> s/concerete/concrete/
<fantasai> Said: My understanding is that we like to provide the nicest experience for the user even during the transition period
<fantasai> Said: Having HDR without constraint doesn't seem nice
<fantasai> Said: so we want the default to be constrained-high for images
<astearns> ack ccameron
<fantasai> ccameron: One of my goals is to not lull people into the idea that they have good content because it looks good by default
<fantasai> ccameron: I want to show exactly what was specified up to capabilities of the machine
<fantasai> ccameron: and hope this will inform people to make good choices about how they use HDR
<Said> q+
<fantasai> ccameron: if specify too much, and end up getting 2x as bright because ...
<fantasai> ccameron: There is concern that I'm authoring to 10, but not knowing it
<fantasai> ccameron: HDR video authored with PQ is usually quite good.
<fantasai> ccameron: HDR images on iPhone, Pixel, etc are also good. They don't blow your eyes out.
<fantasai> ccameron: But ?? video shot at iPhone and Pixel is way too bright, looks bad, ruins people's eyes
<fantasai> ccameron: problem with that is, people were allowed to create the content without seeing what they're specifying
<fantasai> ccameron: I think it's better to show what was specified, and hope they are not making it unpleasant to view
<fantasai> ccameron: Should it turn out that we're wrong, and ppl can't do this right even when seeing what they're producing, then maybe ratchet down the defaults or global switch or something
<fantasai> ccameron: If we limit things by default, they will create bad content because won't see what they're specifying
<fantasai> ccameron: I want to give ecosystem a chance to get it right
<fantasai> ccameron: otherwise will be bad forever
<astearns> ack Said
<fantasai> Said: I disagree with ccameron
<fantasai> Said: Here's an example
<fantasai> Said: In WebKit, we limit animation to 60fps. But in Chrome, it uses device frame rate
<fantasai> Said: Chrome has already hit a problem where the frame rate can be 200 or 500, some device has this kind of speed
<fantasai> Said: and Chrome can't cope with this speed, and begins to limit it
<fantasai> Said: So I think unlimited would give you a bad experience
<astearns> ack fantasai
<fantasai> Said: We want to give the normal user the best experience.
<weinig> fantasai: Chris is making the argument we should give the author the opportunity to get it right
<weinig> fantasai: I am making the argument that there is a bunch of content out there where the author is not going to know, and user will get annoyed
<weinig> fantasai: not just about the transition period
<weinig> fantasai: constrained is a better default for the web
<weinig> fantasai: sophisticated authors will get it right
<weinig> fantasai: but many won't know how to make things right
<weinig> fantasai: better to make things opt in
<weinig> fantasai: you should not need to learn everything to use CSS
<ccameron> q+
<weinig> fantasai: shouldn't have to learn to turn down the headroom
<weinig> astearns: could be argued in either way
<astearns> ack ccameron
<weinig> astearns: could be hard to figure out how to make your photos look right
<fantasai> fantasai: If you want extra brightness you're expecting but not getting, then you can go looking for how to do it.
<fantasai> fantasai: but if your page is tacky and uncomfortable, as someone who isn't a designer, you might not even know why or that it's fixable
<fantasai> ccameron: I'm sympathetic to that argument, but in that case I would suggest a default of SDR
<fantasai> ccameron: since constrained high is [missed3]
<fantasai> ccameron: I could go for that. And maybe there's a bridge to that somehow.
<fantasai> ccameron: Keep going back to global thing.
<weinig> q+
<fantasai> ccameron: (something about gainmaps)
<astearns> ack weinig
<fantasai> ccameron: even if you have a very small headroom
<fantasai> weinig: I do think that the ideal default would be SDR
<fantasai> weinig: I would ask the browser vendors if that is a possibility, even though it would make some content that currently works not do what is expected
<fantasai> weinig: majority of content that wants to benefit from HDR values will learn about these properties
<fantasai> weinig: and in time get those properties set on them
<ccameron> q+
<fantasai> weinig: whereas if we start with unconstrained or a middle ground, it will always be fighting one battle or the other
<fantasai> weinig: both argument fantasai made and astearns made, that each group won't get behavior that makes sense
<fantasai> weinig: it would take video that's already HDR and make it not
<fantasai> weinig: but maybe that's OK
<fantasai> weinig: maybe there aren't enough websites that having this blip of compatibility isn't doable
<astearns> ack ccameron
<fantasai> ccameron: In terms of video, one difficulty is that right now tone-mapping videos to SDR is to do terrible and undefined things to the video
<fantasai> ccameron: One of the nice things about images is that, from the moment they were defined in terms of SDR and in HDR, its' all parameterized in terms of headroom and it's great
<fantasai> ccameron: but for video, don't have that
<fantasai> ccameron: in many cases no ability to even tell the OS to render under constraints
<fantasai> ccameron: so that limits what we can do for video. Even if we want to, in some OSes it is technically impossible
<fantasai> ccameron: I do horrible things to make it "work" in Chrome
<fantasai> ccameron: We're working on standards to improve the situation
<fantasai> ccameron: There's work going on in standards to improve video, to have double-graded content
<fantasai> ccameron: but for right now.... it would be a big amount of work
<fantasai> ccameron: and it yes, there are pages that serve HDR content, usually professional stuff and they are paying for the bandwidth
<fantasai> ccameron: I think there's a chance we could push in a different direction in the future, but really built in right now
<fantasai> ccameron: Can we switch topic to names?
<fantasai> ChrisL: +1
<fantasai> astearns: I wonder if we can decide on an sdr default with video override in the UA stylesheet
<fantasai> weinig: I think we really need Simon for that
<fantasai> weinig: since I proposed that last time, and he had objected
<fantasai> astearns: OK, we'll take that back to the issue for now
<ChrisL> q+

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] Initial value of `dynamic-range-limit` .

The full IRC log of that discussion

<annevk> scribe: annevk
<annevk> smfr: We'd like HDR to be constrained by default, including images, but excluding videos as they have been the exception for a long time. Web developers get to opt-in to no-limit through CSS.
<annevk> smfr: We only want to give video content no-limit access by default, not video element border colors and such.
<annevk> smfr: We'd also want to limit cross-origin documents by default, excluding videos again. And we'd use a sandbox flag [editor: Permissions Policy] to let the embedder enable that after all.
<annevk> weinig: I think this makes it hard-if-not-impossible for content producers to match colors.
<annevk> ccameron: As a moral position, there are good arguments for any of the defaults. I'll agree with everything at some level. Do we consider it acceptable for different element types to have different default behaviors? I would not want that to be in the specification.
<annevk> ccameron: In another collaboration we very much try to make images and videos to behave the same.
<annevk> ccameron: Does constrained-high work with CoreAnimation? I think I have to use a shader.
<annevk> smfr: I don't think we can change the HDR behavior of YouTube. And I don't think we can ship no-limit by default as it'll look weird.
<annevk> weinig: There are not that many websites. Can we get the websites fixed?
<annevk> smfr: It's the embedding pages that would have to set the Permissions Policy.
<annevk> weinig: What's the goal of doing that?
<annevk> smfr: To prevent abuse essentially.
<annevk> weinig: I suspect ads will just abuse video.
<annevk> smfr: Seems harder to deploy.
<annevk> weinig/ccameron: People will do it if they want it.
<annevk> ccameron: I don't think images need to be constrained. Most of the photos look fine on a white background. HDR video content also seems mostly reasonable and is written to co-exist.
<annevk> ccameron: Also, even with constrained there can be bad content.
<annevk> ccameron: The path I thought might be reasonable: the unset default value is implementation-defined, ideally the same across all types. And then we regroup in a year and agree on a default.
<annevk> smfr: I'm sympathetic to the argument that "valid" HDR will get better. I'm worried about antagonistic HDR.
<annevk> ccameron: That's why I have thought about making standard the default and you'd have to opt-in.
<annevk> weinig: And then you'd require Permissions Policy for cross-origin documents too.
<annevk> ccameron: antagonistic HDR already exists, I've been assigned bugs.
<annevk> ccameron: for instance, a green screen background that hides content between sRGB and P3 green so only end users with a P3 screen see it (and it might circumvent certain tools).
<annevk> ccameron: because of that a no-HDR default is reasonable.
<annevk> weinig: I think any kind of sandboxing flag that we do should be absolute.
<annevk> ccameron: this would break YouTube embeds.
<annevk> weinig: that seems really easy to work around. It could be a quirk for a while that we work on phasing out.
<annevk> weinig: there's just not enough video websites for this to be a real problem.
<annevk> weinig: I'm also not sure it's such a big concern to break it as it's still early HDR days
<smfr> q+
<annevk> ccameron: I'm trying to give no-limit a go, gathering feedback as I go, but am prepared to switch to SDR. But for now we have quite a few partners that expect no-limit...
<astearns> ack smfr
<annevk> smfr: 1) I'm doubtful about great resets. Much less concerned about starting with less HDR and going towards more. 2) Who are the people that really want great HDR?
<annevk> ccameron: for 2) name any website that does a gallery of photos and they have opted in.
<annevk> smfr: Do they care about HDR in CSS images, SVG images, etc? Or primary content only?
<annevk> ccameron: mainly the primary content, but I've had people complain about it not being present in the gallery view (server-side downscaled images, say 6 in a row)
<annevk> ccameron: next steps?
<annevk> smfr: We have to check internally on some things.
<annevk> annevk: Do these websites rely on no-limit or specify the CSS property?
<smfr> q+
<annevk> ccameron: They rely on no-limit. Some enforce lower limits server-side.
<astearns> ack smfr
<annevk> smfr: Would it be possible for Google-controlled ad networks to control the amount of HDR?
<annevk> ccameron: I can ask, not sure I can answer.
<annevk> astearns: Okay, so smfr is going to be checking if the default for video could be constrained. ccameron is going to check on ad networks (but might not be able to answer).
<annevk> astearns: I'm against not specifying a default.
<annevk> astearns: If we specify constrained and Safari ships that, we can maybe change it. But if we go with no-limit we can't change it.
<annevk> ccameron: Keep in mind, it'd be pretty hard for us to change it at this point.
<annevk> ccameron: It seems unlikely that if the standard ends up on something other than no-limit, Chrome would be able to align...
<annevk> weinig: I don't agree with the idea that HDR will make things worse. It's really easy to make shitty web content without HDR. I don't think this will make it significantly worse.
<annevk> ccameron: I also think there's a possibility that enshrining SDR will make the web look shittier as people end up expecting their images to look bad.
<annevk> smfr: I think HDR can be a real problem for people.
<annevk> weinig: I think we can impose limits, but I don't think any of it will deter people from writing bad HDR.
<annevk> ccameron: I think a limit on cross-origin documents seems far more reasonable and might be doable.
<annevk> smfr: Question about iframe elements. If you apply the property on the element, does it impact the nested document?
<annevk> weinig: CSS logic says no.
<annevk> smfr: Fair, I just want it to be clear as it might go against expectations.