Open romainmenke opened 8 months ago
also relevant for context are some of the points made here: https://github.com/w3c/csswg-drafts/issues/7610
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.
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.
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.
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:
color-gamut
query gives an approximation of the display's gamut.These two gamuts are not necessarily the same. There are three cases to consider:
color-gamut
query
color-gamut
gamut.color-gamut
query
color-gamut
then color matching is preserved.color-gamut
.color-gamut
color-gamut
but outside of the display's gamut.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.
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?
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.
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:
color-gamut
.
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?
I have asked for help from some ICC folks to put together a wide gamut image with an ICC color profile which provides a perceptual rendering intent. My understanding is that the color of near-boundary but in-sRGB patches in that image will be shifted by the perceptual rendering.
We can then also test what browsers do with that image (I have seen assertions that they always do relative colorimetric mapping and thus, that in-gamut colors always match).
I don't think we an progress this issue without some actual data, because people have very different opinions, not just on what should happen, but also on what does currently happen.
see : https://github.com/w3c/csswg-drafts/issues/9449
@ccameron-chromium said:
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: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 : https://github.com/w3c/csswg-drafts/issues/10038
The resulting colors would be clipped values and would be objectively bad, but might be what the other wants.