[css-color-4] matching displayed colors between CSS colors and images when those colors are outside the displayable gamut

[romainmenke]

see : #9449

@ccameron-chromium said:

This #7610 (comment) the ability to color match between CSS colors and images. Why is it okay to break this functionality? Is there a way that we can avoid breaking this?

I think there is a lot of nuance missing from this statement.
In particular that all colors inside the displayable gamut would still match between CSS and images.

But I agree that having the ability to color match between various features is important to at least some users.

---

Do users have the needed knobs and dials today to effectively color match between images and CSS colors?

I think they already do with the color-gamut media query:

• can be used to pick specific CSS colors
• can be used to load specific images

It is an involved process, not something that just works.
But it is possible.

---

An even smaller group of users might want to match colors that are outside the displayable gamut. (e.g. matching midpoints of interpolations in oklch to an image)

Maybe there should be an opt-out for gamut mapping in CSS?
This could be a keyword on a property that would otherwise limit to a specific gamut, see : #10038

The resulting colors would be clipped values and would be objectively bad, but might be what the other wants.

[romainmenke]

also relevant for context are some of the points made here: #7610

[ccameron-chromium]

Thank you for filing this issue!

I believe that color matching between CSS, image, video, and canvas is a very important feature. I also have a general uneasiness about any color management system that does not deliver color matching across different input sources.

The first two major partners that requested CSS Level 4 from us explicitly wanted color matching between CSS and images (for one) and WebGL canvas (for the other). I have a bit more detail about their exact use cases in this comment, which was an elaboration on this comment. Also of note is the prominence of color matching with images as the motivation in this post.

In the current CSS gamut mapping specification, it is impossible for a content author to achieve the same color across CSS, images, video, and canvas. The impossibility of color matching, when it was requested by all partners who had interest in the features of CSS Color Level 4, was the strongest reason for me to be cautious about implementing the current CSS gamut mapping solution.

[foolip]

Do users have the needed knobs and dials today to effectively color match between images and CSS colors?

I believe it's as simple as specifying the same color using color(display-p3 ...) as is used in an image or a canvas, and it will match, since browsers currently treat colors the same in all of these contexts.

I tried this with two images from https://webkit.org/blog-files/color-gamut/comparison.html, matching the bright yellow and red colors in the images with a background color like color(display-p3 1 0 0). Try it at https://codepen.io/foolip/pen/WNWpZxM. Screenshot:

The background will be a yellow similar to the flower, and the red will match border of the image.

Color matching in this way is a longstanding feature already.

[romainmenke]

In the current CSS gamut mapping specification, it is impossible for a content author to achieve the same color across CSS, images, video, and canvas.

I think it is extremely important that we always say this with the complete context.

It is absolutely possible to color match even when following the specification.
But only for colors that fit within the displayable color gamut.

Shipping the css-color-4 gamut mapping algorithm does not take away a feature from authors.

Authors can also use @media (color-gamut: ...) to conditionally apply other colors, images, ... So even wider gamut images and css colors can be color matched without causing issues for users on narrower gamut screens.

Also of note is the prominence of color matching with images as the motivation in this post.

Even this post mentions the various ways to use (color-gamut: p3) as a critical part to color matching :) This is why the features exists.

---

I believe it's as simple as specifying the same color using color(display-p3 ...) as is used in an image or a canvas, and it will match, since browsers currently treat colors the same in all of these contexts.

Yes, that is what currently shipped, not what was specified.
Clipping colors on narrow gamut screens is also very undesirable behavior.

---

Let me try and restate the question.

Imagine that implementers actually followed the specification and implemented gamut mapping :)

How large is the real world issue of color matching between css colors and images/canvas?
Keeping in mind that all colors that do fit within the displayable gamut would always match.

Is @media (color-gamut: ...) sufficient for those authors that do need to match colors?

If this is not sufficient, what is missing?

---

I don't want this to become another thread where we debate the validity of the gamut mapping algorithm :) We already have enough of those.

I would like to keep this focused on trying to find ways to make progress.

[ccameron-chromium]

In the current CSS gamut mapping specification, it is impossible for a content author to achieve the same color across CSS, images, video, and canvas.

It is absolutely possible to color match even when following the specification. But only for colors that fit within the displayable color gamut.

Shipping the css-color-4 gamut mapping algorithm does not take away a feature from authors.

Authors can also use @media (color-gamut: ...) to conditionally apply other colors, images, ... So even wider gamut images and css colors can be color matched without causing issues for users on narrower gamut screens.

Is @media (color-gamut: ...) sufficient for those authors that do need to match colors?

No, it is still impossible to ever ensure color matching if CSS gamut mapping is enabled, even with the color-gamut query. The important distinction is that:

• The color-gamut query gives an approximation of the display's gamut.
• The CSS gamut mapping maps to the display's true gamut.

These two gamuts are not necessarily the same. There are three cases to consider:

• The display's true gamut exactly matches the color-gamut query
  • In this case you are correct, it is possible to ensure color matching by staying within the color-gamut gamut.
  • An exact match happens like this almost never.
• The display's true gamut is larger than the one reported by the color-gamut query
  • If the author stays within the gamut reported by color-gamut then color matching is preserved.
  • But there exist colors that the display is capable of producing but are not in the gamut reported by color-gamut.
  • The author cannot use these colors, because there is no way to know if they will match.
• The display's true gamut is smaller than the one reported by color-gamut
  • In this case, there are colors that are within color-gamut but outside of the display's gamut.
  • Color matching will not be preserved for these colors.

If this is not sufficient, what is missing?

One needs to know the exact gamut that CSS colors are being mapped to. That is a very potent fingerprinting vector. It's also very hard to provide accurately (e.g, print, E-ink displays, and non-3-primary displays don't even have the usual gamut shape).

One could try to update the spec to make CSS map to the gamut reported by color-gamut, but that also breaks down.

Also of note is the prominence of color matching with images as the motivation in this post.

Even this post mentions the various ways to use (color-gamut: p3) as a critical part to color matching :) This is why the features exists.

The post says the exact opposite. It says: "If you serve wide-gamut images to users not on a wide-gamut display, WebKit will color-match the images and show them in the sRGB space."

And then continues: "However, this conversion into sRGB can be done a few ways and isn’t guaranteed to happen identically on other browsers or platforms. As a discerning Web developer or designer you will want to convert your images offline to better control what the end user will see. Also, embedding the color profile adds a little to the file size, so you might not want to send that extra data if it isn’t necessary."

That is why the color-gamut feature exists.

[romainmenke]

I am not sure how we are misunderstanding each other here :)

I’ve explained above why you should prefer to serve wide-gamut images to users on a wide-gamut display. If you serve wide-gamut images to users not on a wide-gamut display, WebKit will color-match the images and show them in the sRGB space. However, this conversion into sRGB can be done a few ways and isn’t guaranteed to happen identically on other browsers or platforms. As a discerning Web developer or designer you will want to convert your images offline to better control what the end user will see. Also, embedding the color profile adds a little to the file size, so you might not want to send that extra data if it isn’t necessary.

The best solution is to serve a wide-gamut image when the user is on a wide-gamut display, and an sRGB image when the user is not on a wide-gamut display. This is just another case of responsive images, and is exactly what the element and media queries were designed to handle.

I am reading :

If you care about color accuracy then you should create tailored assets and use the media query to conditionally load the correct asset. Do not leave it up to automatic color matching as it isn't guaranteed to be identical across platforms, hardware, ...

Is this an incorrect interpretation, if so, how?

[romainmenke]

The display's true gamut is smaller than the one reported by color-gamut

Can we quantify this?

Combined with those authors and users that actually care about exactly matching colors between css, images, ... ?

This will help us make a more informed decision about which compromise is better.

[ccameron-chromium]

I am not sure how we are misunderstanding each other here :)

I am reading :

If you care about color accuracy then you should create tailored assets and use the media query to conditionally load the correct asset. Do not leave it up to automatic color matching as it isn't guaranteed to be identical across platforms, hardware, ...

Is this an incorrect interpretation, if so, how?

I think I agree, but I want to make sure I'm being as precise as possible.

My understanding of what is being written is:

• If one wants an exact and known appearance, then keep all color values (in CSS, images, videos, canvas) near the gamut reported by color-gamut.
  • That's because the rendition of color values outside color gamut of the screen are affected by the browser implementation, operating system, hardware, and other things.
• Each color value, regardless of how it is specified (CSS, image, video, canvas), and regardless of whether it is in the gamut of the display or not, will always map to exactly one color on the screen.
  • Therefore it is not the case that a color value will map to one color on the screen when specified as CSS and a different color on the screen when specified in an image.
  • This what I mean by "color matching will always be respected"

[romainmenke]

I agree with your reading :)

---

What I meant with previous statements is that the (color-gamut) queries carve out relatively safe spaces where colors should match because no mapping is done at all. That there are edge cases where this isn't true is unfortunate, but I don't think it fully invalidates the concept.

So even if CSS and other API's handle out of gamut colors differently it is still possible to have matching in-gamut colors. Even for wider gamut spaces like p3, rec2020.

Is there a need for out of gamut color matching?

How can we give this as a feature to authors?