[css-color-hdr] Add CSS property to limit dynamic range of HDR content

[ccameron-chromium]

HDR content is great, but there are times when a page may want to limit HDR content to be "not as bright", be that either "keep it all in SDR" or "just a hint of HDR, but not so much that it will look awkward next to SDR content".

A proposed solution is to add a dynamic-range-limit CSS property.

That proposal suggests three qualitative values:

• standard, which limits to standard dynamic range (this name matches the CSS dynamic range query).
• high, which means that no limit is imposed (this name matches the CSS dynamic-range query)
• constrained-high, which means "not so much that it will look awkward next to SDR content" (this matches the name used in macOS and iOS

The exact numerical meaning of values depends on many things that, for fingerprinting reasons, can't be exposed directly, including the current display device's maximum brightness, the current display's SDR brightness, the ambient brightness, etc. In order to allow animation between these qualitative values, a mix-dynamic-range-limit functional is added.

[adixon-adobe]

This is definitely something we're interested in at Adobe when displaying photo grids, where toning down bright HDR images is desired. I think it'd be reasonable if this only applied to image/video content, so long as it also applies to background images.

[ccameron-chromium]

Link to example video is at:
https://photos.app.goo.gl/pAumaUXocDaRo8B56

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] Add CSS property to limit dynamic range of HDR content, and agreed to the following:

• RESOLVED: proposal as stated goes into the draft, with the name switched to match the other mix functions

The full IRC log of that discussion

<chris> q+ to say we need this
<TabAtkins> cc: Now that all smartphoens are shooting hdr, that's well and good but maybe I want to restric tit to sdr
<TabAtkins> cc: [shows a video]
<TabAtkins> cc: you can see as i hover these images the're getting brighter, going from sdr to hdr
<TabAtkins> cc: the proposal now is that there's a property where you can say "i'm sdr, don't go brighter than white"
<TabAtkins> cc: high which goes to high, and MISSED which is on mac and goes in between
<TabAtkins> cc: exposing the actual params to do this is a privacy issue, which is why we abstract to a few values
<TabAtkins> cc: also what they map to will dpeend on os, device, ambient lighting, etc
<TabAtkins> cc: so going with enumerate values is ideal
<TabAtkins> cc: and to animate them, there's a mix() function that's added
<TabAtkins> cc: we've prototyped this, response by testers has been positive
<emilio> q+
<TabAtkins> cc: so we'd like to start discussing this as part of a path
<astearns> ack chris
<Zakim> chris, you wanted to say we need this
<TabAtkins> chris: there's def a need for this. i like that it's an enumeration
<TabAtkins> chris: trying to do it properly with a website detecting the light level in your room would have signif privacy problems
<TabAtkins> chris: and there is really a neeed, if you have a bunch of hdr all together, some will use it subtly, some will be looking directly into the sun, and that'll be very distracting
<TabAtkins> chris: but you also want to slam everything to sdr
<TabAtkins> chris: so having a slightly brighter, but still usable around other iamges, is good
<astearns> ack emilio
<TabAtkins> chris: i think this proposal is great, i'd like to accept it
<TabAtkins> emilio: does this also affect css color? or just image/video
<TabAtkins> cc: in theory all content, but right now image/video is the only thing that can invoke it. but eventually canvas and css color
<TabAtkins> cc: it's inherited, so you can spec on an element and everything in there will be the right headroom
<TabAtkins> cc: but it doesn't force - you can set a parent to standard, and one child can pull its headroom up
<TabAtkins> emilio: ok, about animation, the idea is a mix() that lets you interpolate in a non-discrete way
<chris> q+
<TabAtkins> emilio: it seems fine, but maybe too specific for this particular property. maybe something more general we could do?
<TabAtkins> emilio: but the rest of the proposal seems fine
<TabAtkins> cc: yeah i'd welcome guidacne on these things but I was going with advice. a general mix() could be nice, but i was guided to this specific one and it felt reasonable.
<TabAtkins> emilio: it's fine. colors are pretty special, i'm just a bit worried about proliferating
<bradk> would cross-fade() work?
<TabAtkins> cc: one alt we discussed is you specify animate A->B, you get mix(..., A, B)
<TabAtkins> cc: alt is the ua lies and gives a discrete answer, the closest keyword, while it's actually doing something gradual
<TabAtkins> cc: i can't imagine that would be problematic, but...
<TabAtkins> emilio: yeah that could be a bit weird - a discrete property that animates continuously but *looks* like it animates discretely
<TabAtkins> emilio: one more bit of feedback is that the "mix" part of the name should be at the end to match color-mix()
<TabAtkins> fantasai: i think instead of having a mix function the property could just take a percentage
<TabAtkins> fantasai: where 0% means sdr, 100% means high, and if you want the limited range instead of high use another keyword
<TabAtkins> fantasai: we often create percents in the property value, we use mix functions only where ther'es not appropriate
<chris> I'm on the q to respond on the mix animation btw
<TabAtkins> dbaron: note that elika's proposal doesn't handle "constrained high to high", so that would need fixing
<flackr> +1
<TabAtkins> emilio: is "constrained high" a value between 0 and 100, or something more complex?
<TabAtkins> cc: not actually a %, it's slightly different formula
<TabAtkins> cc: on my device high is 16, sdr is 1, constrained is 2
<TabAtkins> cc: so i'd be hesitant to add a value for it
<chris> q?
<TabAtkins> cc: and if you have multiple pages using this, you want constrained high to look the same everywhere
<TabAtkins> cc: if the keyword has a qualitative meaning that could be a little hacky
<TabAtkins> cc: so the underlying value behind the scenes is a headroom that goes from 0 to [undefined]. 4 is pretty standard
<TabAtkins> cc: we could map constrained high to a number but i don't want people picking numbers from a hat
<TabAtkins> emilio: yeah we could have a keyword that computes to a %, but I guess we don't want to expose that %
<TabAtkins> dbaron: going back to privacy point, we *don't* want to expose where the mid value relative to the other two
<astearns> ack chris
<TabAtkins> chris: yes i was on the queue for that. we're animating something we can't do discrete animation for
<TabAtkins> chris: suddenly switching from sdr to hdr is whiplash for your eyes
<TabAtkins> chris: if you look at apple's demo, if they get a request for hdr they gradually dim things then slowly bring up the brightness, it looks nice
<TabAtkins> chris: but as david said we don't want to expose where that midpoint is
<astearns> ack dbaron
<Zakim> dbaron, you wanted to ask about inheriting
<TabAtkins> dbaron: chris mentioned inheritance
<TabAtkins> dbaron: wanted some more details on that decision
<florian> q+
<TabAtkins> dbaron: i'm a little suspicious about inherited because - wondering if there are cases where you need to know all the data inside something to know how you're gonna map it
<florian> q-
<florian> q+ to follow up on dbaron 's point
<TabAtkins> dbaron: if it's the case that you wanna take some hdr content and map it to sdr, and you need to know everything in there to do that, you might not want this inherited
<TabAtkins> dbaron: because then you lose the ability to coherently process the idea of everything inside of this
<TabAtkins> dbaron: because it;s basically set all over the place rather than a coherent whole
<TabAtkins> cc: when it comes to each individual hdr elem - say you have two images, one goes to very bright, other to slightly bright
<TabAtkins> cc: they're tone-mapped independently
<TabAtkins> cc: my sense is that we probably don't want to do "map this whole element together"
<TabAtkins> dbaron: this is probably more relevant once it applies to CSS colors than to images/canvas, too
<TabAtkins> cc: if this is done as a group, my sense is that the semantics is everything below that element in the hierarchy would be constrained to the parent
<emilio> q+
<TabAtkins> cc: this is more a per-element effect right now
<TabAtkins> cc: my main goal here is ergonomics of the usage
<TabAtkins> cc: and if what i'm suggesting doesn't match those goals, we can change it
<TabAtkins> dbaron: that makes sense, and i'll note that both things we're describing do exist in CSS sometimes - inherited, and "inherited" but grouping
<TabAtkins> cc: i'll restate we're not doing the goruping thing here. there will need to be a larger investigation into that problem
<astearns> ack fantasai
<TabAtkins> fantasai: the name of the proeprty doesn't communicate color , and "dynamic range" is used elsewhere. can we communicate color somewhere?
<TabAtkins> cc: the name comes from (dynamic-range) MQ
<TabAtkins> fantasai: right which i also don't like
<TabAtkins> cc: I think the consistency of the two is good - they use the same enum values
<TabAtkins> cc: And while dynamic-range can apply to any stimulus, maybe best to match for now
<TabAtkins> fantasai: ugh maybe an alias to the MQ
<TabAtkins> astearns: maybe we could put the proposal as-is into the draft, and then open an issue about aliasing the MQ and change the HDR draft to match
<astearns> ack florian
<Zakim> florian, you wanted to follow up on dbaron 's point
<TabAtkins> astearns: but i do like the consistency
<TabAtkins> florian: for naming, i'm not sure i agree with elika
<emilio> q- (was going to talk about inheritance)
<emilio> q-
<TabAtkins> florian: in theory it could be other ranges but in practice css is mostly visual
<TabAtkins> fantasai: but if you don't know much about colors you won't find this when you search for "color"
<TabAtkins> chris: if you search for "dynamic range" on a search engine, this is what will come up
<TabAtkins> fantasai: but it's something about your color
<fantasai> fantasai: if you don't know color terminology you might never find it
<fantasai> s/know/know proper/
<TabAtkins> florian: next point, to david's discussion, if we get out of videos/images and go to css colors, it does get harder to reason about for an author
<emilio> q+
<TabAtkins> florian: if you have a bunch of nested elements, some are tranparent, compositing, etc, i'm sure there's an answer to that mathematically but do we really want it?
<TabAtkins> florian: a grouping mode based on inheritance could be more limiting, but if it doesn't do anything useufl it will just be extra complications
<TabAtkins> q+
<TabAtkins> emilio: if we are doing this non-inheriting thing we will need an auto value that pulls the value down
<fantasai> scribe+
<TabAtkins> emilio: what's the default?
<TabAtkins> cc: i have the default matching the current browser behavior - high
<TabAtkins> emilio: i think inheriting makes sense, maybe an auto value that's the default and we can interpolate...
<astearns> ack emilio
<TabAtkins> emilio: it gets tricky
<TabAtkins> dbaron: I think what's needed to udnerstand is whether a grouping behavior is needed. only if the answer is yes do we need to know whether the element is inherited or non-inherited
<emilio> ack emilio
<emilio> ack TabAtkins
<fantasai> TabAtkins: I thought, What are any of you talking about, you can always set a property on a subtree inherited or not?
<fantasai> TabAtkins: but if it's triggering a grouping effect, then that could make sense
<fantasai> dbaron: Not grouping behavior exactly, but if you take a bunch of HDR content and map it down
<fantasai> dbaron: does limiting A and B together when A is higher, change how B gets mapped?
<fantasai> TabAtkins: That is grouping behavior, establishing a group
<fantasai> TabAtkins: but it's not part of this proposal, so if we want to do that we can do a non-inherited property for it later
<dbaron> (I'm not sure that it would be a separate property...)
<TabAtkins> astearns: I'm seeing a lot of general agreement
<TabAtkins> astearns: I propose we add this proposal as stated to the hdr draft, adn we can raise issues as needed
<dbaron> +1
<kbabbitt> +1
<TabAtkins> cc: with the dynamic-range-mix() name switched
<fantasai> -> https://github.com//issues/9957
<TabAtkins> RESOLVED: proposal as stated goes into the draft, with the name switched to match the other mix functions

[svgeesus]

New section 2. Controlling Dynamic Range containing:

• 2.1. Introducing Headroom (non-normative)
• 2.2. The dynamic-range-limit property
• 2.3. Mixing Dynamic Range Limits: the dynamic-range-limit-mix() function

Function in particular is a bit brief, we didn't discuss much on the call.

Needs more examples