- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Mar 2024 16:02:34 +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> <argyle> fantasai: posted a summary recently, impportant things are 1) make sure we all understand the problems, constraints, design goals<br> <ChrisL> Summary from fantasai https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2014015707<br> <argyle> fantasai: then we can talk about options for solving<br> <argyle> fantasai: key question is, what happens when authors speicfy out of gamut colors<br> <argyle> fantasai: 2 scnearios: 1) author can see it, how does it display on less capable displays 2) authors specify a color they cant see, out of gamut even on their monitor or its not real. how does it display on a more capable display<br> <argyle> fantasai: variety of out of gamut colors: adjust params in oklab and get out of gamut easily, realtive color syntax, color-mixing, interpolation<br> <argyle> fantasai: more typical, p3 being displayed on a narrow gamut display<br> <argyle> fantasai: conflicting desires for what happens when mapping<br> <argyle> fantasai: maintain luminosity, maintain colorfulness, hue matching, image matching, performance and compat<br> <dbaron> fantasai: , smooth interpolation<br> <Rossen7> q?<br> <argyle> fantasai: allow everyone to say the problems they see and their thoughts. there's a variety<br> <ChrisL> q+<br> <argyle> florian: this is useful, i suspect the competing solutions are solving a part of the problem, and observe whether or not people are trying to solve the same thing<br> <argyle> ChrisL: good summary, ty, we should agree on what to solve and what the priorities are<br> <argyle> ChrisL: what i dont want to do, have 2 solutions to a website, theres a p3 and an srgb. no one suggested it, but sometimes that has been raised as a solution<br> <Rossen7> ack ChrisL<br> <foolip> q+<br> <argyle> ChrisL: theres been a lot of gamut mapping strategies, gives good reesults, has some implementations, has been refined<br> <argyle> ChrisL: simplest is clipping, gives poor results when the gamut is larger than what you can display. more recently, different approaches (5 or 6) you can see what they do, vary in performance and capability<br> <argyle> ChrisL: another thing, whether something preserves lightness or colorfulness<br> <argyle> ChrisL: for many, you want to preserve lightness, or contrast is the aspecvt of the look you want to get<br> <lea> Links to the GMAs (gamut mapping algorithms) Chris mentioned:<br> <lea> https://colorjs.io/apps/gamut-mapping/<br> <lea> https://colorjs.io/apps/gamut-mapping/gradients?from=oklch%2890%25+.8+250%29&to=oklch%2840%25+.1+20%29<br> <argyle> ChrisL: other things, you want a jazzy color, some sort of purple or red<br> <argyle> ChrisL: gamut mapping for images, more have a perceptual intent. overalll look of the iamge must be preservecd. colors in gamut can change<br> <florian> q?<br> <argyle> ChrisL: means, shift the whole lot, so the relationship is changed between all of them. that's different than what we need to do. images are secret sauce, but ensure us a good overall result. we cant really standardize on that. each impl is hedyg about what they do<br> <florian> q+<br> <argyle> ChrisL: i do get if you want to throw a color in a div and match an image, you throw away a lot if you do that<br> <lea> q?<br> <lea> q+<br> <Rossen7> ack foolip<br> <argyle> Chris Cameron: can i take 10m to present?<br> <argyle> Rossen7: can it be less than 10?<br> <argyle> Chris Cameron: i'll do the short version and do sub topics after<br> <argyle> Chris Cameron: 1 position we agree on, provivde hue, chroma, luma parameter space for manipulatinog colors<br> <argyle> Chris Cameron: i want this too<br> <argyle> Chris Cameron: other thing, color matching CSS, images, video<br> <argyle> Chris Cameron: if you specify a color in an image and css, they should not become 2 different colors<br> <argyle> Chris Cameron: when we implemented color 4, 2 partners wanted it, one wanted CSS in p3 to match their logo (images and css)<br> <argyle> Chris Cameron: the other was a web design app, p3 webgl, wanted to use CSS for the color picker<br> <argyle> Chris Cameron: needed to match webGL canvas<br> <argyle> Chris Cameron: color matching is what the partners asked for<br> <argyle> Chris Cameron: been present in all the color managed solutions. webkit first, has a lot of text on the key features in color matching<br> <argyle> Chris Cameron: we find that useful<br> <argyle> Chris Cameron: i feel these goals can be satisfied, but the problem is the high level mechanism tthe spec takes to achieve this<br> <argyle> Chris Cameron: spec attempts to dliver an HCL safe space but oklch is not designed for that<br> <argyle> Chris Cameron: result is extremely out of gamut colors, messy space to work in<br> <argyle> Chris Cameron: this is fixed up by gamut mapping<br> <argyle> Chris Cameron: this fix up has side effects<br> <argyle> Chris Cameron: violates the meaning of color values, this imposes a specific meaning that causes problems<br> <ChrisL> You can get extreme, oog colors in any extended color space (as has been pointed out in the issue several times)<br> <argyle> Chris Cameron: breaks color matching, actually impossible<br> <argyle> Chris Cameron: encourages future dangerous content, will cause problems in the future<br> <argyle> Chris Cameron: only useful if using extremely out of gamut color content<br> <argyle> Chris Cameron: afaict, clipping delivers excellent quality going from p3 to srgb<br> <argyle> Chris Cameron: clipping is bad at tone mapping<br> <argyle> Chris Cameron: i'd like us to be finding a parameter space that works, not extermelly out of gamut colors, then we dont have to add this fix up, broken color matching, or p eople designing pages they cant see<br> <dbaron> s/tone mapping/HDR tone mapping/<br> <astearns> q?<br> <argyle> Chris Cameron: shouhld i pause here?<br> <emilio> Can the presentation be mailed to www-archive?<br> <argyle> Rossen7: i dont mind stopping, if this is good. there's a queue as well<br> <argyle> florian: 2 related comments<br> <foolip> Link to slides: https://docs.google.com/presentation/d/1iODXisjA2EJTqMpNXVG-TrU7qp9XD-uTePLuPnqs9RI/edit?usp=sharing<br> <Rossen7> ack florian<br> <argyle> florian: when talking abotu matchingd colors with iamges and css, matching a logo but on the other hand ChrisL mentioned perceptual intent. i suspect these are different cases, like perceptual for photos but logos arent that. might be unsolvable to match a photo, but matching a logo might not be<br> <argyle> ChrisL: you're correct, , relative color a metric ?? tterm help here pls<br> <lea> s/relative color a metric ?? tterm help here pls/relative colorimetric/<br> <argyle> florian: you mention images, video and canvas, but i think canvas is different, has it's own logic for out of gamut colors. might be solved by css matching canvas, or a mode for canvas to match css. am i wrong or somewhere near?<br> <foolip> Does any browser respect rendering intent for images or do they all clip?<br> <argyle> ChrisL: you're right, we could add a mode to canvas<br> <argyle> ChrisL: in canvas, the colors get matched to the 2d context when you throw them in the cnas. you lose the original<br> <argyle> ChrisL: currently canvases are 8bit, srgb or p3, can change when there's floats<br> <argyle> florian: having a mode switch is helpful here<br> <argyle> Chris Cameron: take a step back about the itents<br> <argyle> Chris Cameron: relative, perceptual , all browser deliver color matching, icnluding images and css<br> <ChrisL> This is also why the current CSS GMA describes itself as a relative colorimetric intent<br> <argyle> Chris Cameron: ICC profiles in practice, in the wild, there's few perceptual spaces, but they choose perceptual mapping<br> <Rossen7> slides at https://lists.w3.org/Archives/Public/www-archive/2024Mar/0006.html<br> <argyle> Chris Cameron: these map from xyz 50 or lab, the profile connection spaces, clear defined relations to srgb<br> <ChrisL> q+<br> <argyle> Chris Cameron: you can match with the intended matching space. that is a red herring, all images, on all browser, match CSS<br> <argyle> Chris Cameron: the differents between color profiles does not affect this<br> <dbaron> s/xyz 50/XYZ D50/<br> <ChrisL> q?<br> <ChrisL> q-<br> <argyle> ChrisL: I just wanna leap in on that because that is factually incorrect. If relative color a metric guarantees not to change the colors that are in gamut.<br> <argyle> ChrisL: Perceptual that explicitly does not make that guarantee. So, depending on what the colors are, depending on what the range of the original colors are, in Gamma colors will change or can change or do change.<br> <dbaron> s/color a metric/colorimetric/<br> <ChrisL> s/Gamma/gamut<br> <argyle> Chris Cameron: chris and i have a different interpretation of this. ICC profiles even in percpetual modes, indicate a mapping into xyz or lab. you always get the same value. there's a device link thing. for any ICC profiles, its matchable from CSS. all brwosers repsect this<br> <lea> There is one primary use case for polar color spaces (like Oklch): creating color variations dynamically (mixes, tints, etc.) from one color or a couple (key design system colors, web component CSS properties for theming, etc). They’re not generally colors you copy from a color picker, literally the vast majority of their use cases is through Relative Colors, `color-mix()`, etc. If you try to tweak an OKLCH color's coords to produce variations<br> <lea> (e.g. tweak the lightness to get tints), you will notice that it's *incredibly* easy to get *wildly* out of gamut, way outside even Rec.2020.<br> <lea> Yes, other color spaces may be better for this use case, but people were using hsl for this before oklch, which is far worse (in different ways), this is a huge pain point and we cannot defer it for another decade while we design the perfect color space for color manipulations. Also note that it is impossible to design a color space that is within gamut AND perceptually uniform.<br> <lea> That said, I would support syntax for staying within a specific gamut, e.g. oklch-p3() or oklch(L, 5% of p3, H) where chroma is a % that maxes out at the max chroma in p3 for the (L, H) pair. It's still not perceptually uniform in general, but is PU for a fixed chroma, which is still desirable.<br> <lea> WRT GMAs, we should first reach consensus that the GMA should be normative, what the constraints are (e.g. linear, fixed steps, no LUT, etc.), and what the priority is (preserving hue or L) and then we have a lot of experience at this point in designing one that balances tradeoffs well.<br> <dbaron> (GMA == Gamut Mapping Algorithm)<br> <ChrisL> Gamut Mapping Playground https://colorjs.io/apps/gamut-mapping/?<br> <lea> Wrt literature, it has proven *surprisingly* hard to find actual algorithms, most of it is about "rendering intents" (colorimetric, perceptual, etc.) which are *strategies* about what to prioritize, not algorithms.<br> <foolip> q+<br> <foolip> (on behalf of Chris Cameron)<br> <ChrisL> Useful comment from an industry partner who wants to "sometimes enable matching" on "non-photographic" images"<br> <ChrisL> https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1226073808<br> <Rossen7> ack lea<br> <lea> Color matching is important, but ultimately niche specialized use cases. It's served fine via an opt in and we can discuss what that opt in would look like separately. If we try to design the default behavior around it, we end up with suboptimal behavior for using colors within CSS, just so they match other systems.<br> <Romain> q+<br> <Rossen7> ack foolip<br> <Rossen7> ack Romain<br> <lea> q+<br> <argyle> Romain: overall in the issues, things like color matching are raised as ciritcal blockers, but i dont think this is right. we sholud focus on features possible not what mapping makes impossible. color matching would still work with in gamut colors, you can still make vibrant gradfients by picking the right stops. not helpfult o focus on things it breaks. lets focus on specfic features, like if a partner wants color matching, then design a<br> <argyle> feature for explicit matching.<br> <foolip> q+<br> <foolip> q-<br> <Rossen7> ack lea<br> <florian> q+<br> <argyle> lea: one thing, mentioned hes concerned about authors specifiying non existtant colors, but we have to display something, but not sure how clipping helps authors show colors in future screens. problem exists no matter what<br> <lea> Not having gamut mapping degrades the experience of using color in CSS without helping. If you can specify nonexistent colors, you will have this problem *no matter* how you display them, whether you clip or gamut map.<br> <Rossen7> ack florian<br> <argyle> florian: one way we can consider adressing this, in tersm of what elika said earlier, either the problem is authors specify colors they can and cant see, or users can or cant see. we could have okklch mapped to p3, so if its p3, you know determinsically, ecen for future better than p3 screens, you know it will get shrunk in the future, but not blown out in the future. you can still do math in the unbounded space, it just wont get wierd<br> <argyle> miriam: be caviat there, you dont know what you can see<br> <dbaron> s/be caviat/big caveat/<br> <dbaron> s/know/necessarily know/<br> <Rossen7> ack ccameron<br> <argyle> Chris Cameron: the gamut queries give you 3 levels. the option to limit yourself, displays may not get better, but the safe regions of p3 can only carve out this safe region<br> <argyle> Chris Cameron: romain mentioned that color matching is possible, i showed that it's not possible. unless your screen exactly matches p3 or srgb, the difference is the zone that you now cant work with. clamping displays doesnt sem viable<br> <jamessw> +q<br> <argyle> Chris Cameron: within all these patching options, tehres a guideline "theres no complexity to the wrong solution". the right solution provides parameter spaces that dont produce nonesense color values. then bad values are just bad input. garbage in garbage out<br> <ChrisL> No-one is *encouraging* wildly oog colors<br> <argyle> Chris Cameron: that's the direction i'd like to go, consideirng all the time i've spent on this, the current approach of ecnouraging wikdly out of gamut colors with patching and fixes, is the wrong way to approach the problem. its these issues that made us not implement gamut mapping<br> <argyle> Chris Cameron: i'd like us to take a different direction, redirect gamut mapping to a parameter space wher eyou can modify colors reliably, then patch and patch the current problem<br> <Romain> It did get implemented<br> <Romain> Webkit shipped it in specific scenarios<br> <ChrisL> It did get implemented. Browsers are not the only implementation<br> <smfr> q+<br> <dbaron> s/redirect gamut mapping/redirect the energy we're spending on gamut mapping/<br> <argyle> Chris Cameron: i can present more slides, that taking in bad and making it good. so rather than patch, lets move forward with a solution that has nice parameters we can use without any patching<br> <lea> q+<br> <astearns> doing reasonable things with unreasonable inputs is something we have to do in CSS<br> <argyle> i'm entusiastic about the math, but cant deliver the need in the wrong way<br> <Romain> Compare Webkit vs. Chrome : https://codepen.io/romainmenke/pen/LYvLerB<br> <Rossen7> ack jamessw<br> <argyle> jamessw: this touches ont he underlying differences, ccameron, youre looking at what is a safe space. but were looking for a perceptually uniform space. we cant do both. even in a safer space, you can still get out of gamut. is ther ea way to say, we do need a safe space, btu we also need a perceptually uniform space which brings about questions.<br> <argyle> Chris Cameron: yeah, this point, when it comes to going out fo gamut in safer spaces, going slightly out of gamut is fine, any approach will do a good job<br> <argyle> Chris Cameron: all evidence is that, for rec2020 (which none of us have), it's a dangerous error to define mapping 2020 mappings to srgb which no one can see. css gamut mapping does a lot of violence when mapping from 2020 to srgb<br> <argyle> Chris Cameron: but clipping still looks good there. bad input is bad input<br> <dbaron> s/none of us have/none of us have seen/<br> <argyle> simonf: is a parameterized space doable or going to take years?<br> <Rossen7> ack smfr<br> <argyle> cameron: bjorn has one, could be just a couple months. he has an okhsl space that's very ncie<br> <argyle> it does limit to srgb and has good mapping, it's an option. but it's not a l to of research<br> <argyle> smfr: native apis like core graphics, all ow the author to speciyf image and color painting. css may need this. let authors specify what they want, and if thwy ant images and css to match, they specify that<br> <Rossen7> ack lea<br> <lea> As I and others have said, perceptual uniformity, in-gamut, pick one, you can't have both (though you can have different points within that spectrum).<br> <lea> Also, you are saying you don't like how Oklch works and want a better color space that only goes "slightly out of gamut", but until you produce such a space, I question whether it exists.<br> <lea> As I and others have said, perceptual uniformity, in-gamut, pick one, you can't have both (though you can have different points within that spectrum). Also, you are saying you don't like how Oklch works and want a better color space that only goes "slightly out of gamut", but until you produce such a space, I question whether it exists. FWIW I actually agree that there might be a better color space for color manipulation, and even have ideas on how<br> <lea> to produce one. But until we have that perfect color space, Oklch is what we have and what authors are currently using.<br> <argyle> lea: james said many things i was goin to say. until a space that's "safer" is prpduced, we heard something about 2 months, i'm doubtful. fwiw, i agree theres'a better space for manipulation, but until we have it, oklch is what we have and what uathors are currently using (with poor results due to no mapping)<br> <lea> But we do need a space that works not just now, but also in the future, when screen technology has gone beyond the P3 screens we have today (and possibly even beyond 3 primaries).<br> <argyle> lea: we need to solve the immediate problem, which a new space might work, but needs to solve eyond p3 and eyond 3 primaries possibly<br> <Rossen7> ack fantasai<br> <Zakim> fantasai, you wanted to respond to "garbage in garbage out"<br> <argyle> fantasai: garbage in and garbage out, the web takes the garbage in and does something with it thats supposed to not break. its part of what we signe dup for. must be robust and not create problems for the user<br> <Romain> q+<br> <dbaron> (I think with what smfr mentioned about doing perceptual mapping of CSS colors -- figuring out which colors are in the "set" that you need to map together ends up being a difficult problem, I think.)<br> <lea> +1 fantasai . And btw if the logic was actually "garbage in, garbage out", we wouldn't even clip, we'd just display transparent or black<br> <lea> Clipping is an attempt to display *something* meaningful, but a very poor one<br> <argyle> smfr: willing to implemented a js version of his prpposed colorspace that can be used online, is that too much work?<br> <argyle> already in colorjs.io of bjorns space<br> <argyle> ccameron: i've worked through a few examples of it, the general approach would be something like that<br> <lea> dbaron: Regardless of impl complexity, that also means the moment you apply a different color (e.g. from JS) *everything* shifts color, which would be very jarring<br> <argyle> ccameron: i'll share a quick link<br> <Rossen7> link https://bottosson.github.io/posts/colorpicker/<br> <florian> q+<br> <argyle> ccameron: good place to start is engaging bjorn<br> <Rossen7> ack Romain<br> <argyle> Romain: wondering if any other implementor is interested in gamut mapping. webkit has a partial / older implementation. would be nice to have a parallel effort that shows how it curretnly works and breaks, wouild get us hands on and out of theory<br> <Rossen7> ack florian<br> <smfr> q+<br> <lea> +1 to this. This conversation has been dominated by the Chromium implementers. Would love to hear from Gecko and WebKit.<br> <dbaron> lea, yes, I was thinking difficult in terms of "what do we even mean by this"<br> <emilio> There is a patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1847503, not sure how up-to-date it is<br> <argyle> florian: fair amount of divergent opinoins, also conflicting views of things that are supposed to be factual, like perceptual intent<br> <argyle> florian: be good to come back to this in github, get to the bottom of the facts before theres too much debate<br> <argyle> smfr: we should have an action item for cameron and lilley with exampels so we can test one way or the other with this images thing<br> <astearns> +1 to wrangling over facts in GitHub issues<br> <argyle> ccameron: yep<br> <Rossen7> ack smfr<br> <argyle> ChrisL: i plan to reach out to the internal color consortium. cameron and i shouldnt be disasgreeing so much<br> <fantasai> <ccameron> https://www.color.org/specification/ICC.1-2022-05.pdf<br> <argyle> ChrisL: will work on pinning this down<br> <ChrisL> https://onlinelibrary.wiley.com/doi/book/10.1002/9780470758922<br> <ChrisL> Color Gamut Mapping<br> <ChrisL> Author(s):Ján Morovič<br> <dbaron> Rossen: we'll take discussion back to the issue<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-2023144024 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 March 2024 16:02:36 UTC