- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Feb 2024 18:29:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-4] Channel clipping breaks author expectations, especially when using 'perceptually uniform' spaces`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> miriam: there's been a lot of discussion on this, a bunch in the last hour<br> <TabAtkins> miriam: css colors 4 proposed a number of new color spaces, new formats.<br> <TabAtkins> miriam: in varying wider gamuts<br> <TabAtkins> miriam: so display-p3 gamut, rec.2020, some adobe gamuts<br> <TabAtkins> miriam: and there are a few color formats that give us gamut-less color<br> <TabAtkins> miriam: two interesting things about them. one is their gamutless-ness. they represent all perceptual color<br> <TabAtkins> miriam: and because math runs against biology they represent some colros that don't exist too<br> <TabAtkins> miriam: so these huge spaces are useful long term, as we get wider and wider gamut screens, they'll continue to work. no need to invent a new colro space for each new monitor<br> <TabAtkins> miriam: danger is you might request colors that no monitor can show, and you quickly get out of gamut of any monitor that's currently avaialble, certainly one that's common<br> <TabAtkins> miriam: now, the more gamuts we have the more likely that is anyway<br> <TabAtkins> miriam: even if you're using display-p3 colors there are monitors that can't hit that<br> <TabAtkins> miriam: the other interesting thing about the lch/etc spaces, is they're perceptually uniform<br> <TabAtkins> miriam: which means they should be more predictable for authors in terms of what they do<br> <TabAtkins> miriam: which is grabbing a color and adjusting the lightness up and down to make a palette<br> <TabAtkins> miriam: authors are excited about this<br> <TabAtkins> miriam: problem is right when this shipped, browsers all agreed to not do gamut mapping<br> <TabAtkins> miriam: so when you go outside the gamut, you get rgb channel clipping, which gives very unpredictable results<br> <TabAtkins> miriam: so the spaces intended to be predictable are very unpredictable, which seems untenable<br> <TabAtkins> miriam: so there's two conceptual appraoches to solve this (13+ mathematical approaches)<br> <TabAtkins> miriam: one is to say that gamutless color doesn't work, people will keep requesting colors they can't see<br> <TabAtkins> miriam: so we should stick to gamut'd spaces, and release new ones as time goes on<br> <TabAtkins> miriam: this would mean oklch()/etc get a gamut imposed on them in some way so we can reason about them<br> <TabAtkins> miriam: the other way is to say, eitehr way we'll get colors outside of a monitor's gamut, and we need some mapping algorithm that tries to preserve soemthing reasonable about the oclor<br> <TabAtkins> miriam: the css algo currently tries to preserve hue and lightness at the expense of chroma<br> <TabAtkins> miriam: which is reasonable to me<br> <lea> q+<br> <TabAtkins> miriam: there's a lot of mathematical suggestions for this, but i don't think there's a success critera for judging them<br> <TabAtkins> miriam: so that's what i'm hoping to get out of this - what is being proposed, and what are the criteria for it<br> <astearns> ack lea<br> <chris> q+<br> <TabAtkins> lea: I'm not gonna repeat what's in the thread, but to summarize<br> <TabAtkins> lea: i think the need is there. anyone who tries to use the gamut-less formats runs into this clipping<br> <TabAtkins> lea: particularly bad for lighter colors, and the hgiher the chroma the worse the result<br> <lea> https://colorjs.io/apps/gamut-mapping/<br> <TabAtkins> lea: I've made a playground so you can experiment with colors and see how mapping works, both with the css algo, with clipping, and with two new algos<br> <miriam> the problem, at especially light colors: https://codepen.io/miriamsuzanne/pen/BavZLNG<br> <TabAtkins> lea: that's a segue to - Chris and i worked on a new mapping algo based on an idea i had, which seems to be both better reuslts and perf than css algo<br> <TabAtkins> lea: it removes the problem of css's gamut algorith, iterative steps due to a binary search<br> <TabAtkins> lea: the logic is also simpler<br> <TabAtkins> lea: it's based on scaling in linear rgb space of the monitor. the playground uses p3, but that's just for an example that's close to current monitors<br> <TabAtkins> lea: it seems to preserve hue better than lightness, which seems better for color perception<br> <TabAtkins> lea: it's been pointed that it *looks* slightly worse with very light or very dark, but it's a lower delta-E so it's perceptually closer<br> <chris> https://deploy-preview-438--colorjs.netlify.app/apps/gamut-mapping/?color=oklch%2899.95%25+.8+241%29<br> <TabAtkins> lea: so, specifying colors in rgb is fundamentally basing color around hardware, not human eyes<br> <TabAtkins> lea: which is why whenever people are stuck with rgb formats they have to rely on color pickers<br> <TabAtkins> lea: the point of having good spaces is you can generate related colors algorithmically<br> <TabAtkins> lea: but that doesnt' work if clipping makes your colors unpredictable<br> <TabAtkins> lea: i'd strongly object to baking any particular gamut into color functions that are designed to be gamut independent<br> <TabAtkins> lea: we've made the mistake of baking a gamut into css before, we shouldn't make that again<br> <TabAtkins> cc: I've prepared some slides to discuss some bits here, miriam covered several of the points already<br> <TabAtkins> cc: i wanted to get into some concrete examples<br> <TabAtkins> cc: [shows presentation]<br> <TabAtkins> cc: this slide shows the bug miriam mentioned<br> <TabAtkins> cc: oklch(90% 10% 0deg) vs oklch(90% 90% 0deg)<br> <TabAtkins> cc: the issue is the format doesn't do in practice what it promises<br> <TabAtkins> cc: what oklch/etc provide is they're very good for interpolation<br> <TabAtkins> cc: the line between two lab colors feels uniform, it doesn't dip in darkness like it does in rgb<br> <TabAtkins> cc: and if a particular coordinate is constant, it will *feel* like that quality is constant in the interpolation<br> <TabAtkins> cc: so if you endpoints are in gamut you'll get good results<br> <TabAtkins> cc: but there are issues for these for color manipulation or picking<br> <chris> no, the start and end in gamut does NOT guarantee the line is in gamut, for polar forms<br> <TabAtkins> cc: the parameters have a simple enough coord range<br> <TabAtkins> cc: but there's no promise that a color you specify in those ranges will be displayable<br> <TabAtkins> cc: and when you modify them you can quickly and easily get into trouble<br> <TabAtkins> cc: so the codepen draws from 90/10/0 to 90/90/0<br> <TabAtkins> cc: firsts point is in a light spot, near white and magenta-ish<br> <TabAtkins> cc: endpoint is way outside the gamut, hyper-saturated magenta<br> <TabAtkins> cc: the css mapping algo walks the out-of-gamut colors along a constant LH line, so that would map both of these colors to essentially the same colors<br> <miriam> q?<br> <TabAtkins> cc: note that rec2020 is probably about the most color we'll ever get, so this 90/90/0 color is pathological<br> <TabAtkins> cc: you can also specify colors that don't exist<br> <chris> It isn't "undefined", just un-displayablw<br> <TabAtkins> cc: [shows a reddish color] and if you increases its brightness the result won't exist<br> <TabAtkins> cc: there's reasons, [shows a cone of physically realizable colors]<br> <lea> q+<br> <TabAtkins> cc: we shouldn't be having authors specify colors that no display can produce or can't even phyically exist<br> <TabAtkins> cc: concrete example of a bad thing that can happen<br> <TabAtkins> cc: so, what should 90/90/0 look like?<br> <TabAtkins> cc: here's a picture of a monitor with several mapped examples<br> <TabAtkins> cc: but this color does exist, i could in theory display this color, it's just a bright agenta<br> <chris> That laptop does not support rec2020, I would bet on it<br> <TabAtkins> cc: [the real color appears close to the clipped color, very far from the other mapped colors]<br> <chris> q?<br> <TabAtkins> cc: this might eventually prevent us from doing good colors in better monitors, people will expect the low-chroma variants<br> <TabAtkins> cc: this is why i feel strongly that we really need to have authors stay within physically existing colors, or at least close to their gamut<br> <TabAtkins> cc: if we let authors specify colors you can't see, how do they know they're getting what they want?<br> <TabAtkins> cc: what space is safer? okhsl stays in sRGB and is easy to manipulate<br> <TabAtkins> cc: but that's a separate issue<br> <TabAtkins> cc: my position is that css shouldn't be dictating gamut mapping<br> <TabAtkins> cc: i just think we should never specify colors outside of rec2020<br> <TabAtkins> cc: way out there is danger zone<br> <TabAtkins> cc: in terms of danger with ampping to rec2020 or whatever, there's an ecosystem for this, icc profiles<br> <chris> MDCV does not do gamut mapping!<br> <TabAtkins> cc: mdcv metadata<br> <TabAtkins> cc: kinda squishes things to look appropriate, might take lighting into account, etc<br> <TabAtkins> cc: so my position is that we just shouldn't let people specify colors way outside of the real gamut<br> <TabAtkins> cc: my position is we should have a note advising authors to just not specify colors that don't exist<br> <TabAtkins> cc: if your'e on srgb and specify p3, difference isn't huge, probably fine<br> <TabAtkins> cc: and then move gamut mapping out of the color spec, and into the definition of oklch<br> <TabAtkins> cc: that takes away the temptation of running away into poorly-defined color values<br> <chris> so on the one hand remove gamut mapping and on the other, bake in gamuts (with undefined display of colors outside display gamut)!!<br> <TabAtkins> cc: given where we are, i think that's the best way to keep those spaces doing what they're designed to do<br> <TabAtkins> cc: if we add these guardrails to oklch/etc, theyh're safe enough. not ideal, but safe enough<br> <miriam> q+<br> <fserb> q+<br> <TabAtkins> cc: so that's my ramble. my main two points is that we just can't assign a meaning to some of these colors<br> <TabAtkins> cc: and if we do try to assign a meaning, we'll end up imposing bad restrictions to the rest of the platform's colors<br> <TabAtkins> cc: so we shouldn't enocurage people to specify these colors that can't exist<br> <astearns> ack chris<br> <TabAtkins> chris: first, thanks for the clear presentation on your point<br> <TabAtkins> chris: you made a few incorrect statements<br> <TabAtkins> chris: you showed apply hardware and stated it was showing a rec2020 color<br> <TabAtkins> chris: that's physically impossible, only an adobe display with lasers can show this<br> <TabAtkins> cc: for this particular rec2020 color, it lands within the extended p3 gamut<br> <TabAtkins> cc: it doesn't work for all colors, but it does work for this one<br> <TabAtkins> chris: thank you, that's correct<br> <TabAtkins> lea: when you showed this geometry, it wasn't just extending the same geom, it changed the geom too<br> <TabAtkins> lea: I don't think we can estimate the color by naively extending like this<br> <TabAtkins> chris: The point was made that it's dangerous when authors think they've chosen a color but it's wrong in some way<br> <TabAtkins> chris: I agree with that, but the proposed solution doesn't fix that<br> <TabAtkins> chris: there will be people on an srgb screen; if we bake rec2020 they'll be on a p3 screen<br> <TabAtkins> chris: if it's gamut mapped they'll be seeing an apprxoimation of that color<br> <TabAtkins> chris: if it's clipped they'll be seeing an entirely different color<br> <TabAtkins> chris: so i don't think forcing them to not do that is the right solution<br> <TabAtkins> chris: i think your visualation about the colors that can't be physically dispalyed at all is important to show to authors in devtools<br> <TabAtkins> cc: the devtools, yes i agree, would be very helpful<br> <TabAtkins> cc: re: specifying a color outside the gamut<br> <TabAtkins> cc: in the proposal that i have that says bake rec2020 in, that's a minimally invasive position to get to a workable position<br> <TabAtkins> cc: an alternative is, oklab-rgb that maps to rgb, oklab-p3 that maps to p3, oklab-2020 that maps to 2020, and oklab aliases oklab-2020<br> <TabAtkins> cc: the other is, if you specify a color not in your monitor's display<br> <TabAtkins> cc: I made an effort in the thread to find an example where that looked particularly bad, where clipping or mapping or whatever would ruin the contrast or look bad<br> <TabAtkins> cc: in the narrow case of p3 to rgb, i wasn't able to craete a page where it mattered<br> <TabAtkins> cc: so to say again, if someone specifies a p3 color, and you naive clip to rgb, in my experience both for css and photographs that wasn't a problem for me, i could barely tell the difference<br> <TabAtkins> cc: for photos i found clipping generally better than constant luminance<br> <TabAtkins> cc: so I'm not sure it's a problem that needs to be addressed<br> <TabAtkins> cc: and if someone chosoes a color out of gamut, we should give them the tools to avoid that<br> <TabAtkins> cc: like functions with safe guardrails<br> <TabAtkins> lea: want to ask about the baking gamut and what i tmeans<br> <TabAtkins> lea: i see two ways - either you scale ranges and lose uniformity, or arbitrary endpoints and you still don't know what happens when you go past that<br> <TabAtkins> chris: I wanted toa ddress okhsl<br> <TabAtkins> chris: that's designed to give a nice rect presetantion in a color picker, you get a plane of color<br> <TabAtkins> chris: it does that by, instead of having perceptually uniform chroma, it has a non-uniform saturation<br> <lea> s/or arbitrary endpoints and you still don't know what happens when you go past that/or you have arbitrary endpoints which is totally unpredictable for authors and we still need to define what happens when you go past them/<br> <TabAtkins> chris: so you lose perceptual uniformity<br> <TabAtkins> chris: the whole idea of doing predictable manipulations in the space, that miriam mentioned, you lose that<br> <TabAtkins> chris: some dimensions are uniform and others are not<br> <TabAtkins> cc: yes you lose some uniformity, but with the gamut mapping, all of these colors (except maybe the first) are identical [they have very different coords]<br> <TabAtkins> cc: i'm sympathetic to the point, but i think compromises have to be made, and these mappings aren't uniform in practice anyway since they're unchanging as the chroma bumps<br> <astearns> ack lea<br> <TabAtkins> lea: there was some misleading language about undefined areas - they're defined, just not displayable<br> <TabAtkins> lea: And physically impossible, they can be useful in color mix and such<br> <TabAtkins> lea: i do think devtools is the way to go here, it' smuch easier to change devtools than css syntax<br> <TabAtkins> lea: there's precedent too - we didn't restrict authors to websafe colors, we just showed them in devtools when a color wasn't websafe<br> <chris> ProPhoto RGB for example has non-physical primaries, and is still useful for photographic manipulation. The primaries are certainlt not "undefined"<br> <TabAtkins> lea: similarly, reference ranges are designed to tell you a reasonable range that should be safe<br> <TabAtkins> lea: also, you're saying we should bake a gamut because it'll be a problem in the future. not sure why it's not just as good to bake it in *then* when it becomes a problem<br> <TabAtkins> lea: you said that css should not dictate gamut mapping<br> <TabAtkins> lea: the existing ecosystem curently is focused around preserving relatinoships between colors<br> <TabAtkins> lea: because mostly it's for photos, where relationships are more important than individual color characteristics<br> <TabAtkins> lea: but in CSS it's the opposite<br> <TabAtkins> lea: but you also said "just use those existing gamut mapping"<br> <TabAtkins> lea: - though many literature doesn'ta ctually describe an algo<br> <TabAtkins> lea: but *who* is using those? authors?<br> <TabAtkins> lea: I already asked my question about what you mean by baking a gamut in, i don't see a way forward on that<br> <TabAtkins> lea: we already rejected enforcing a 0-1 range<br> <TabAtkins> lea: you say you lose some perceptual uniformity if you scale the ranges to be in gamut<br> <TabAtkins> lea: you can visit oklch to see that<br> <TabAtkins> lea: for each hue the ranges vary wildly<br> <chris> we went away from enforcing [0, 1] at the request of Chrome engineers to allow round tripping through HSL in color-mix<br> <TabAtkins> lea: having these distinct ranges is important, to avoid the problems that hsl has<br> <TabAtkins> lea: color interpolation can get out of gamut, yes, but it has its use cases<br> <TabAtkins> lea: there are reasons to interpolate in a way that preserves hue as much as possible, inteprolation in other spaces preserves components other than hues<br> <astearns> ack miriam<br> <TabAtkins> miriam: it's an overwhelming convo because it goes in six directions<br> <TabAtkins> miriam: it's hard to choose where we focus<br> <TabAtkins> miriam: i have some concerns about putting it on authors to make sure they're always in-gamut in some way<br> <TabAtkins> miriam: putting even lang in the spec that authors *shouldn't* go out of gamut feels somewhat absurd to me in color sapces where i have no idea when i'm getting near the gamut edge<br> <lea> s/you can visit oklch to see that/you can visit https://oklch.com to see how irregular the gamut actually is/<br> <TabAtkins> miriam: so there might be reasonable point that these colro spaces don't do what they promise if we always have to gamut map<br> <astearns> is naively convinced of the use case for out-of-gamut colors in color mixing<br> <TabAtkins> miriam: the original demo i showed with a gradient, wasn't an unusual case for the gradient, it was to show that the gradient's lightness wasn't preserved, and that was th eoriginal point<br> <TabAtkins> miriam: I think that's a big problem<br> <TabAtkins> miriam: and that's as far as I want to go. we can't give authors a space that says it maintains lightness, and then it doesn't maintain lightness<br> <TabAtkins> miriam: allowing these spaces adn not presrving lightness is a big problem<br> <astearns> ack fserb<br> <TabAtkins> fserb: i think my point is close to what miriam is saying<br> <lea> s/for each hue the ranges vary wildly/even at the same lightness, max chroma for each hue varies WILDLY, e.g. at 70% lightness you can get up to 0.15 chroma for turquoises and 0.35 for magentas. The loss of PU you'd get by scaling these to the same 0-100% range would not be trivial, it would be as bad as HSL/<br> <TabAtkins> fserb: i think we're talking about two different problems when mentioning gamut mapping<br> <TabAtkins> fserb: one is oklab has a big parameter space, some values don't exist in human color<br> <TabAtkins> fserb: that's what cc means by undefined, not that it's undefine dmathematically, it's that no human has ever seen it<br> <TabAtkins> fserb: that's a different problem than "we have a color that doens't map to your monitor well"<br> <TabAtkins> fserb: those are, in nature, two differnet problems<br> <TabAtkins> fserb: i think oklab make this worse because the params have large volumes that don't exist<br> <TabAtkins> fserb: and we're tryin to solve them at the same time<br> <TabAtkins> fserb: even if we disagree with okhsv, the attempt is to make the parameter space friendly to humans, removing the volumes that don't physically exist<br> <chris> https://bottosson.github.io/posts/colorpicker/<br> <TabAtkins> fserb: so our issue is we're using gamut mapping to both address colors that don't exist, and mapping to monitors that are a little different<br> <TabAtkins> fserb: i think cc's point is that if you're in range of colors that are reasonable, the mapping algo doens't matter much. can be a little different but not that substantial<br> <TabAtkins> fserb: but then we're also trying to address the colors way outside of reality and trying to pull them back in<br> <chris> "The way “Saturation” is defined, it does not vary smoothly due to the uneven shape of the sRGB gamut. E.g. by keeping “Saturation” constant and changing hue, the perceived chroma can change drastically and abruptly."<br> <TabAtkins> fserb: so that's the argument for baking a gamut into oklch<br> <TabAtkins> fserb: trying to avoid a color sapce that's unfriendly to people because it has huge unrealizable colors<br> <lea> q?<br> <TabAtkins> fserb: so as long as it maps well to 2020 or whatever, it would be good even if we lose some of the uniformity<br> <lea> q+ to say one way forwards if you want to bake a specific gamut into these functions might be to define percentages that way, while numbers work as they do currently (which is the goal of the current percentages really, but they're not achieving it because they are fixed ranges)<br> <TabAtkins> fserb: i just think we shoudln't give people access to spaces with huge unusable areas and expect them to use it well<br> <nicole> q+<br> <TabAtkins> fserb: i think there's just a difference between solving these problems - giving developers a friendly space to use<br> <TabAtkins> fserb: vs the simpler problem of "ehre's a bunch of friendly colors" and bringing them into the monitor<br> <TabAtkins> cc: yes, thank you for distinguishing these two<br> <TabAtkins> cc: problem of getting friendly params, and then different problem of color just slightly out of monitor space<br> <TabAtkins> cc: I can reply about baking the gamut in, but it'll take a bit<br> <astearns> ack lea<br> <Zakim> lea, you wanted to say one way forwards if you want to bake a specific gamut into these functions might be to define percentages that way, while numbers work as they do currently<br> <Zakim> ... (which is the goal of the current percentages really, but they're not achieving it because they are fixed ranges)<br> <astearns> ack dbaron<br> <TabAtkins> lea: one way forward that might work in both worlds is let %s map to a gamut boundary range<br> <TabAtkins> lea: the current %s are meant to be friendly, but because they map to fixed ranges, they still give weird results<br> <TabAtkins> lea: so if we let %s refer to a useful range, but absolute numbers being interpreted correctly, might work<br> <TabAtkins> nsull: I think Fernando covered my comment, doing different things for perceptible colors vs just slightly off colors<br> <astearns> ack fantasai<br> <astearns> ack nicole<br> <miriam> +1 to Leas suggestion - I at least think that's an interesting approach (not having seen specifics)<br> <TabAtkins> fantasai: I think what cc was talking about for gamut was we artificially limit the output to a specific gamut, rather than a gamut your monitor happens to be<br> <lea> fwiw I don't think dealing with colors outside the spectral locus differently simplifies anything. You *still* need gamut mapping<br> <TabAtkins> fantasai: so they'll know exactly what color they'll get, regardless of monitor (if they can display that gamut in the first place)<br> <TabAtkins> fantasai: i think baking a gamut into the name of the function, we could maybe just apply that to all colors on the elements<br> <lea> @miriam Actually, that would only make sense for C, so in theory UAs could even precompute this for 100 * 360 = 36000 points<br> <TabAtkins> cc: i wanted to reply to miriam' ssuggestion, i'd like to see it fleshed out<br> <fantasai> s/i think baking/cc was suggesting baking/<br> <astearns> I think it may have been lea's suggestion<br> <TabAtkins> cc: for "baking in", i meant when you convert from oklabl to xyz space, when you make that conversion there would be a gamut-limiting step<br> <fantasai> s/could maybe just/alternatively introduce a property that would/<br> <TabAtkins> TabAtkins: okay so that is what elika described too, yes<br> <TabAtkins> astearns: i'm not seeing something we can resolve on in five minutes, so i propose we return to issue<br> <TabAtkins> astearns: and see if we can split this issue into fernando's two halves, maybe more?<br> <TabAtkins> astearns: perhaps another session on this topic and its subtopics in the next month or so<br> <TabAtkins> astearns: I can work with cc on timing<br> <TabAtkins> TabAtkins: normally he's on italy time so it's close to chris and lea, just uniquely bad right now<br> <TabAtkins> <br until=10:45><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1944377755 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 February 2024 18:29:51 UTC