[css-color-hdr] CSS syntax for HDR colors parameterized by headroom

[svgeesus]

@ccameron-chromium suggested a mechanism for allowing CSS colors to be displayed in HDR, which copes with displays having different amounts of HDR headroom.

It also establishes, in a backwards-and-forwards compatible way, the convention that CSS colors are to be gamut mapped to the SDR gamut of the display, unless they explicitly opt-in to a potentially-higher-headroom gamut via the new syntax.

[svgeesus]

Agenda+ to see if we can resolve to adopt the proposal.

[weinig]

Really glad to see this being discussed!

One thing I can't figure out from the proposal on first reading is if this allows matching the colors of an HDR image or HDR video. (Partially, this is likely a problem of me not knowing enough about how HDR images / videos are represented/ encoded).

That is, if a user has an HDR image, and for the sake of simplicity, it is all one color, is there a way to create CSS Color values that match that color in all headrooms?

[ccameron-chromium]

That is, if a user has an HDR image, and for the sake of simplicity, it is all one color, is there a way to create CSS Color values that match that color in all headrooms?

Yes, that's the goal -- to be able to create a CSS Color that will match an HDR image color in all headrooms.

In order to handle all possible ISO 21496-1 images, the "it may be worth adding those as parameters to be able to color match with gain map images" would need some elaboration.

If there's consensus around this general approach, then I can flesh out those details.

[weinig]

Great. Ok, after reading a bit more about ISO 21496-1 images I think I understand the idea (I do wish those ISO specs were not behind paywalls, but I digress and should just fork over some cash).

Generally, and for matching images that use ISO 21496-1 gain map, this seems like a great way forward to me.

One thing that might make sense in addition to adding parameterization (primaries of the space, esp value, etc.) of the interpolation space would be a way to explicitly use an image's metadata. For example:

  color-hdr(matching url(myImage.png),
      color(rec2100-linear 0.9 1.0 0.8) 1,
      color(rec2100-linear 1.8 2.0 1.5) 2);

What about HDR images that don't use ISO 21496-1 gain maps? (I think one can make an HDR image that has no gain map, presumably getting some default tone-mapping from the system?)

Any thoughts on HDR video?

[ccameron-chromium]

What about HDR images that don't use ISO 21496-1 gain maps?

There is a similar proposal in ICC that defines this mapping as a global tone map. I don't think it's share-able yet, unfortunately. It is also representable by this scheme.

Also if there is no ICC global tone map, and no other metadata, then ISO 22028-5 is working to define how this would be tone mapped "by default".

(BTW, I'd like for us to eventually have WPT tests for all 3 of these cases: gain map tone mapping, global profile tone mapping, and default tone mapping ... hopefully by the end of the year?).

color-hdr(matching url(myImage.png)

I suspect that we'll want to provide something like the ICC global tone map as metadata also for canvases. And so I think something more like that metadata would be a better "match". There are also some parameters in the image metadata to account for the fact that image data is in [0,1] (the min/max/gamma parameters), which don't apply to CSS colors that can specify any value.

Any thoughts on HDR video?

There is a proposal for gainmap support in AV1 video. I would like for there to be a uniform approach on global tone mapping between ICC and video as well.

[svgeesus]

(BTW, I'd like for us to eventually have WPT tests for all 3 of these cases: gain map tone mapping, global profile tone mapping, and default tone mapping ... hopefully by the end of the year?).

Yes, definitely!

Great. Ok, after reading a bit more about ISO 21496-1 images I think I understand the idea (I do wish those ISO specs were not behind paywalls, but I digress and should just fork over some cash).

I agree that these paywalled specs do hinder development. In your case @weinig I suggest an email to Nicolas Bonnier at Apple would be helpful.