I think there is a core tension here between (what I'll call here) high-luma (brightness) and high-chroma (hue).

Say a user is try to output (on a sufficiently good display) color(rec2020 1.0 0.5 0.5). Well, they might try to trying to lean on a promise of unclamped chrominance and write rgb(1.19 0.446 0.533)¹. Because we cap luminance, we can choose to interpret this as "redder than red", or "go to 119% of the distance in the direction of the red primary". If we also uncap luminance/brightness though, suddenly it's ambiguous whether srgb(red=1.19) goes out past srgb-primary-red by ~20% (roughly towards rec2020-primary-red), or represents 20% brighter (more photons) of (less-saturated-red) srgb-primary-red.

If you clamp chroma to the display colorspace and also leave luma uncapped, then an display with a gamut between srgb and rec2020 here would go out past the srgb gamut, and then "climb the gamut wall" and add brightness. For a display-p3 monitor/display, that same color above is now color(display-p3 1.1 0.5 0.55). Do we spill then into hdr for this 110% output for the display-p3-red-primary? This will give us not just three different colors, but three different brightnesses as well.

I'm not 100% sure about this, but my understanding is that there isn't actually an ambiguity there. For example,
color(rec2020-linear 1 0 0) = color(srgb-linear 1.66 -0.1 0).
The negative blue value counterbalances the brighter R value, so you still get a luminance of 1.0.

To look at the color space visually we can look for example at the xY slice of the xyY color space - again, according to my understanding:

While I think that the "luminance vs chrominance clamping" idea is useful conceptually, it does fall apart in terms of actual implementation. (Also, I'm going to live in srgb-linear, p3-linear, and rec2020-linear just to make the math easier here).

All monitors ultimately have 3 primaries (red, green, and blue) that have some maximum range. Historically (pre-HDR), we would think of these having a range of [0, 1], with (1,1,1) being white.

In an HDR world, we can think of these as all being in [0, H] for some HDR headroom H>=1. The value (1,1,1) is still white, and now the value (H,H,H) is the maximum producible brightness. (Deep in the guts of the display device, everything is still normalized to [0, 1], and it's actually the case that [1/H, 1/H, 1/H] is white ... but that's a very-not-fun space to work in, and often only exists ephemerally in a display controller's color management pipeline anyway).

The WebGPU spec currently says

During presentation, the chrominance of color values outside of the [0, 1] range is not to be clamped to that range; extended values may be used to display colors outside of the gamut defined by the canvas' color space’s primaries, when permitted by the configured format and the user’s display capabilities. This is in contrast with luminance, which is to be clamped to the maximum standard dynamic range luminance.

What we are clamping to is the "standard dynamic range" of the device. In practice, the "standard dynamic range" of the device is the color space with the device's primaries and with each color component being able to take values in the range [0, 1].

This per-component clamping is the same behavior that we have for handling out-of-gamut colors when drawing to a canvas and when uploading to a texture (and there are a bunch of WPT tests for that). It is also the only behavior that ensures color matching between extended and non-extended modes. If one wants more fancy handling of out-of-range colors, then that's where more fancy tonemapping algorithms (and metadata, etc) come in.

Example:

Suppose you have a canvas that has the solid color color(rec2020 1.0 0.5 0.5).

Case 1: You have a very fancy HDR monitor with P3 primaries and an HDR headroom of H=2. You do not specify that you want extended range.

• First, you convert to the color space of the display. Our fancy monitor has exactly P3 primaries, so this means we now have color(p3-linear 1.25 0.21 0.26).
• Next, because you didn't specify extended range, this is clamped to the "standard dynamic range" of the device, which means clamping each component to [0, 1], so you get color(p3-linear 1.00 0.21 0.26).

Case 2: You have a very fancy HDR monitor with P3 primaries and an HDR headroom of H=2. You do specify that you want extended range.

• First, like last time, you get color(p3-linear 1.25 0.21 0.26).
• And that's it. You don't do anything else. This is the color you show.

Case 3: You have an sRGB monitor, no extended range.

• First, convert to your monitor's (sRGB) primaries to get color(srgb-linear 1.49 0.17 0.25)
• Next, clamp to the "standard dynamic range" of the device, so you get color(srgb-linear 1.00 0.17 0.25).

While I think that the "luminance vs chrominance clamping" idea is useful conceptually, it does fall apart in terms of actual implementation.

What we are clamping to is the "standard dynamic range" of the device. In practice, the "standard dynamic range" of the device is the color space with the device's primaries and with each color component being able to take values in the range [0, 1].

This is good to know. I had a misunderstanding when I was writing this spec text (without really knowing how HDR works) and we should update it. I'll file a new issue as V1.0: #4263

I should clarify - the chrominance-luminance diagram I drew above is not good as a clamping model. But I think it still correctly visualizes why there's no ambiguity between "redder red" and "brighter red".

A few disjointed thoughts:

Suppose you have a canvas that has the solid color color(rec2020 1.0 0.5 0.5). ... First, you convert to the color space of the display. ... Next, because you didn't specify extended range, this is clamped to the "standard dynamic range" of the device

All these color conversions are handled for us in the window server. The programming model is "applications give some colors to the window server in whatever color space they feel like; it's the window server's responsibility to show them well on the display." Of course, it's possible for content to deliver a color to the window server that is outside of the gamut (or headroom) of the display, in which case the window server will use a tonemapping algorithm to show those colors as well as it can. That tone mapping algorithm isn't a simple clamping operation like you've described here.

But that's fine, because the result of that operation isn't observable by the webpage. It's only observable to the user, via their eyeballs*. So, if the WebGPU spec says "clamp this and don't clamp that" there's no way it's enforceable. The requirement here isn't that some algorithm outputs correct numbers; the only requirement is that different representations of the same color end up visually identical to the user (aka "color-matching").

So I kind of don't really understand why much of the above discussion needs to happen. All that's necessary is a single flag that says "stop clipping when you throw the colors over the wall to the system compositor; act as if the colors in my canvas have an infinite gamut with infinite headroom; the compositor will do something complicated and arbitrary with them, and that's okay."

(*And potentially observable via reftests, depending on your testing infrastructure - but not necessarily; it's totally possible to set up your testing infrastructure such that the page snapshots it generates are in infinite-gamut-infinite-brightness XYZ color space. Hell, every pixel in your snapshot could be an arbitrary precision mpfr float.)

(Also, much of what I say here is specific to the Mac. iOS works slightly differently, but not in ways that are material to the discussion.)

(Not a reply to Myles)

I talked with Chris today and figured out that my diagram is not accurate, so I've hidden it. The conclusion is correct but the diagram doesn't provide the right intuition, in particular because 1.0 red doesn't have a luminance of 1.0. We'll have a better diagram soon.

Meanwhile I found these diagrams useful:
https://fujiwaratko.sakura.ne.jp/infosci/xyz_e.html
https://fujiwaratko.sakura.ne.jp/infosci/gam_srgb.png
https://fujiwaratko.sakura.ne.jp/infosci/gam_p3d65.png

I've put together this page which might help visualize the exact behavior:
https://ccameron-chromium.github.io/webgl-examples/gamut.html

Hopefully I can give a walk-though of this at an upcoming meeting.

As an employee at Adobe, we are developing an upcoming product that will provide web-hosted video editing and compositing features. Modern video supports a wide gamut of colors and HDR is supported in almost all modern televisions and computer screens. Phones and DSLR camera are capable of capturing HDR content and users that produce video content require the ability to preview and edit those video with the color fidelity intact. Within our WebCodec and WebGPU dependencies, we expect HDR pixels to flow through our processing pipeline. As we build web-hosted video applications, it is imperative that the user can visualize these colors, especially when performing color correction.

I can preview stunningly beautiful HDR videos on youtube on my macbook pro in both Chrome and Safari : https://www.youtube.com/watch?v=tO01J-M3g0U

From Apple: Devices that combine wide-gamut color with 10-bit HDR capability can produce vibrant hues with nuanced shading, lending more realism and immediacy to an image, revealing more detail, and reducing artifacts like gradient “banding” (often seen in images of the sky as it transitions from lighter to darker areas.)

Speaking as a lead at Adobe, HDR support in WebGPU is going to be crucial for Photoshop on the web and next-gen web apps. Unclipped sRGB linear works great for us and we're in full support of the proposed HDR APIs.

This will help us close the gap to native apps in color, which is highly desired.

I'm a lead on Lightroom Web at Adobe. What @ounterecker mentioned for Photoshop is also true for Lightroom. We need exactly the same support.