[css-color-hdr] Add interpolation between multiple values of dynamic-range-limit

[ccameron-chromium]

This came up when writing WPT tests for dynamic-range-limit.

The dynamic-range-limit specification allows for interpolation between two dynamic-range-limit values by the dynamic-range-limit-mix function. It was pointed out that interpolation between multiple different values may happen implicitly during animation.

The syntax chosen in the spec lends itself to fixing this issue fairly simply. The current syntax is

  dynamic-range-limit-mix() = dynamic-range-limit-mix( [ <ident> && <percentage [0,100]>? ]#{2})

The suggestion that I was given was to change this to

  dynamic-range-limit-mix() = dynamic-range-limit-mix( [ <ident> && <percentage [0,100]> ]+)

Example: Halfway between standard and high.

  dynamic-range-limit-mix(standard 50%, high 50%)

This is the same as the existing syntax.

Example: One-fifth between constrained-high and dynamic-range-limit-mix(standard 40%, high 60%):

  dynamic-range-limit-mix(constrained-high 20%,  dynamic-range-limit-mix(standard 40%, high 60%) 80%)

this simplifies to

  dynamic-range-limit-mix(standard 32%, high 48%, constrained-high 20%)

Notes

In the syntax we didn't allow percentages to be omitted (cause it can get a bit difficult to define more than one unspecified value, unlike color-mix which has natural definitions).

If the sum of the arguments' percentages is 0%, then the function fails.

The arguments' percentages are normalized so that they add to 100%.

The percent for standard, high, and constrained-high is computed as the of the weighted sum of its percents in each argument.

I'll try to put together a patch that does this.

[tabatkins]

Actually, I think it would be preferable to switch the dynamic-range-limit-mix() function's grammar to match that of the mix-*() family of functions (and ideally switch the name order as well, to mix-dynamic-range-limit()).

In other words:

mix-dynamic-range-limit( <progress>, <'dynamic-range-limit'>, <'dynamic-range-limit'> )

[sboukortt]

Actually, I think it would be preferable to switch the dynamic-range-limit-mix() function's grammar to match that of the mix-*() family of functions (and ideally switch the name order as well, to mix-dynamic-range-limit()).

In other words:

mix-dynamic-range-limit( <progress>, <'dynamic-range-limit'>, <'dynamic-range-limit'> )

Thank you for the feedback. Out of curiosity, may I ask about the name change? calc-mix, color-mix, etc. seem to have the -mix at the end – would we change those as well?

[ccameron-chromium]

I think the hard part is is defining what is the computed value for this sort of thing:

    mix-dynamic-range-limit(
        40%,
        mix-dynamic-range-limit(20%, standard, high),
        mix-dynamic-range-limit(30%, standard, constrained-high));

The math of this is: 0.6*(0.8*standard + 0.2*high) + 0.4*(0.7*standard + 0.3*constrained-high)). If we have a two-argument functional, then we need to somehow nest these together, and it starts to feel a bit messy.

The syntax that @svgeesus suggested extends well to handle this, by just allowing one to say that that evaluates to:

    mix-dynamic-range(standard 76%, high 12%, constrained-high 12%)

[gregbenz]

Is there a way this might be implemented to allow absolute HDR headroom limits which would affect the rendering, yet still keep the source site blind to the output in order to ensure anti-fingerprinting objectives are met?

For example, it may be ideal to allow up to 2 stops of headroom for HDR content alongside SDR. The other proposed mechanisms would either cause unnecessary limitations below that target, or may allow brighter results if the display has an unusually large amount of headroom (which could apply now with certain Windows SDR brightness slider settings, or with future brighter displays).

[svgeesus]

Thank you for the feedback. Out of curiosity, may I ask about the name change? calc-mix, color-mix, etc. seem to have the -mix at the end – would we change those as well?

No, color-mix() is widely implemented and changing the name would be a pointless waste of time at this stage

it would be preferable to switch the dynamic-range-limit-mix() function's grammar to match that of the mix-*() family of functions (and ideally switch the name order as well, to mix-dynamic-range-limit()).

I note that, following the link, this is still called calc-mix() so I guess we do have consistency again.

[tabatkins]

Yes, the current naming convention is indeed *-mix(). I guess I'd just misremembered when I made that comment.

[ccameron-chromium]

Returning to the issue of interpolation between more than 2 enums, is there any objection to updating the functional to support the form:

    mix-dynamic-range(standard 76%, high 12%, constrained-high 12%)

This would mean the syntax would be updated to be:

    dynamic-range-limit-mix() = dynamic-range-limit-mix( [ <ident> && <percentage [0,100]> ]+)

The changes here are that the percentage is no longer optional, and there may be more than two parameters.

Some of the options for interpolating using color-mix (in particular the use of alpha in step 7) can't quite apply to this, so we'll want to list the normalization explicitly.

• If all percentages are specified and sum to zero, then the function is invalid.
• Scale all percentages so that they add to 100%

I'll put out a patch to update this.

[ccameron-chromium]

Added PR for spec changes here: https://github.com/w3c/csswg-drafts/pull/11086 Added WPT tests for the behavior here: https://chromium-review.googlesource.com/c/chromium/src/+/5501416

[svgeesus]

I merged the PR.

We should really get a WG resolution on this, before the spec goes to FPWD.

[svgeesus]

The change can now be seen in the spec:

2.5. Computed Value for dynamic-range-limit

so the proposed resolution is "Accept these edits" or alternatively, revert the PR.

The proposed WPT tests not yet merged

[svgeesus]

The WPT tests are merged, results here

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] Add interpolation between multiple values of dynamic-range-limit, and agreed to the following:

• RESOLVED: Accept the PR

The full IRC log of that discussion

<noamr> Chris: we have this dynamic range value. but you might have more than value, e.g. in animation, need to decide what happens
<noamr> ChrisL: we have a PR, we either should merge it or revert. I think it's a good syntax
<noamr> astearns: inclined to accept the PR
<noamr> ChrisL: I prefer to review things in place
<noamr> astearns: objections?
<TabAtkins> RESOLVED: Accept the PR

[svgeesus]

PR merged, WPT added to spec.