- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 10:56:52 +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`, and agreed to the following: * `RESOLVED: Gamut map all device independent color spaces to Rec.2020 for now, transforming from there to device gamut is undefined. Exact gamut-mapping algorithm TBD. Continue discussing in the issue.` * `RESOLVED: RGB color spaces (srgb, display-p3, rec2020, a98rgb) do not gamut map.` * `ACTION ccameron: review gamut mapping algorithms` * `ACTION lea, chris, mia to review Chrome proposal discussed today` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2162288182<br> <jarhar> miriam: i opneed this issue because theres a number fo new colro sapces that are intended to be perceptually uniform and wide gamut in fa ct unbounded gamut. and in order for a color space to be perceptually uniform, it cant be spatially uniform. they dont have nice cylindrical edges like hsl. you cant have both of those things. these color spaces<br> <jarhar> are exceiting to authors for being able to move around in color space in ways thatfeel perceptually reliable. if i add a certain amount of lightness it should be a certain amount lighter which is not possible in hsl<br> <jarhar> miriam: the problem is, because we dont have uniform edges, we end up outside of them quite easily, at that point we have to decide what to do. the spec tries to handle that by maintining lightness and sacrificing chroma with an algorithm, proposal s for preserve lightness aprpoach. in browsers, corpping rgb channels can give you strange changes in<br> <jarhar> lightness and huge, its the worst of all cases<br> <jarhar> miriam: thats the summary of the issue. browsers ship the problem and not the solution, so some of the arguments should be that we shouldn't have color spaces that allow you to do this, we shipped the way to easily make mistakes but did not guardrail, we need some sort of guardrail in these spaces, to me that is preserving lightness<br> <lea> q?<br> <jarhar> miriam: that is starting to get into other things, ok bye<br> <jarhar> fantasai: tab you have a proposal?<br> <lea> q+<br> <una> (As a non-color expert I can +1 the pain points of using modern color syntax and getting unexpected results)<br> <jarhar> TabAtkins: ok, so as miriam said if you use a color far outside your gamut its going to be mapped to your gamut. the current proposal makes that depend on your monitor which can result in different colors displayed on the screen, especially since lightness preserving tends to sacrifice chroma, when you look at your screen and see low chroma they<br> <jarhar> design your color, they use that in their design, in the better monitor they get an insanely vivid pink instead of light coral<br> <jarhar> TabAtkins: current approach isnt future compatible with monitor technology if you specify colors outside of gamut when designing the page<br> <ChrisL> The "insane pink" is due to switching into HDR mode, so the comparison is invalid<br> <ChrisL> the claim of "no perceptual mapping" in ICC profiles is invalid<br> <ChrisL> q+<br> <jarhar> TabAtkins: second thing is that ever since css2, css colors and image colors have been magical. via the introduction of - color profile stuff, you can have an ff0000 red and and ff000000 in your page look the same, and its important for having your page colors match up with images used on the page and dont want color drops<br> <lea> q-<br> <lea> q++<br> <lea> q+<br> <jarhar> TabAtkins: make sure that images and css colors work in the same way by default even if the fact that images and videos need to use cheap mapping methods rather than good mapping methods. were ok with authors opt into breaking that consistency even if the final result is not as ideal<br> <jarhar> TabAtkins: these altogether, whenever youre specifying a color with oklab or oklch functions, we eagerly map that into direct2020 gamut. somewhat arbitrary choice, we can accept others, fairly light gamut likely to encompass monitors for the future, small enough that even when you do cheap easy clipping into srgb you still get a color close to the<br> <jarhar> design intent. if designer is direct2020 and user srgb or vice versa it will still work out pretty well<br> <jarhar> TabAtkins: we dont care very much what the mapping method is to take the far out of gamut oklab color into 2020. if the spec wants to preserve lightness were ok with that<br> <jarhar> TabAtkins: do it eagerly so its future proof, once its in that gamut we want to make sure its allowed by the spec to match up with how we handle images and videos etc. because the quality mapping is fairly critical in that region. we do expect there to be an opt out method alternate function what have you that lets you specify oklab or oklch thats<br> <jarhar> not evenly mapped<br> <kbabbitt> s/direct2020/rec2020/<br> <ChrisL> s/evenly/eagerly/<br> <ChrisL> s/direct2020/rec2020/g<br> <jarhar> TabAtkins: ??? and you know its going to be played on a quality monitor, and then the other methods of specifying colors, that use arbitrary color schemes we prefer to leave those alone, as the browser sees fit video in that color profile, those arent designed for easy author useage on the page, they are sdesigned for hardware ? matching what they<br> <jarhar> might be used in an image for video we dont need to worry about authors to see a weird color unless theyre trying to match an image win which case it should match<br> <jarhar> TabAtkins: eagerly map oklab into 2020 gamut and if you need to reduce further from there provide methods for that, dont touch other colors, render as accurately as it can<br> <florian> q?<br> <florian> q+<br> <jarhar> TabAtkins: apple and mozilla folks are broadly supportive of that. simon finds it reasonable<br> <jarhar> TabAtkins: he also supports the ability to give authors choice of gamut mapping<br> <jarhar> TabAtkins: ?? from mozilla says that 2020 might be iffy, but doesn't think its a blocker and seems reasonable<br> <jarhar> TabAtkins: other thoughts?<br> <TabAtkins> s/??/Tiann Louw/<br> <jarhar> ChrisL: i want to address two inaccurate statements. first is about colors that were wildly different vivid pinks, that was done by sdr color imagery and then throwing in an hdr color<br> <jarhar> ChrisL: so yeah ok thats a very different color, the other one which is frequently stated but not demonstrated that all colros inside gamut will never change. since i just mentioned hdr, hdr has sigmoid curve you will bring the darks down and lights up which means colors in gamut will change<br> <TabAtkins> q+ ccameron<br> <jarhar> ChrisL: if you have a perceptual rendering intent then colors inside the gamut will chagne so smooth gradients continue to look smooth. the other - thats perceptual rednering intent, relative ? will guarantee colors wont change, thats not the only option<br> <jarhar> ChrisL: its depends on what the ? is<br> <jarhar> ChrisL: firstly ill point out that this proposal droped an hour before the meeting, i have not had time to play with it and see what its properties are, its an interesting proposal but it hasn't been played with<br> <jarhar> ChrisL: cheap gamut mapping methods: people have proposed 5 or 6 methods of cheap gamut mapping which haven't received comments<br> <jarhar> ChrisL: some of them are very cheap like linearized ?? and then clip or compress down, single step process no loops very efficient could probably be done in hardware, no comments<br> <miriam> q+<br> <jarhar> ChrisL: hardware can do this because games work in linear light, so could be quite efficient but no comment on that<br> <ChrisL> https://apps.colorjs.io/gamut-mapping/?<br> <jarhar> ChrisL: theres a gamut mapping playground where all o fthese have been implemented, you can put different colors in<br> <jarhar> ChrisL: theres been no comment from the chrome team about these proposals<br> <jarhar> ChrisL: some aspects are interesting, some aspects are concerning. this eager converting to 2020 gamut. if i take something out of gamut in oklch and gamut is 30 and this eager conversion, what happens when i get back the computed value? are they wildly different? has the chroma reduction happened? its saying that you specify one value and you use<br> <jarhar> a different value - how observable is that? it has changed, this seems odd to me<br> <jarhar> ChrisL: in terms of the 2020 reasonable target, id say, the reason i say that is because all the primaries are in spectral lockers, you can only get them with 100% ? but then youd have greater than 100% ?? which is why youll never have a pro monitor because ?? the triangle can cover as much of the area as possible<br> <lea> s/lockers/locus/<br> <dbaron> s/pro monitor/ProPhoto monitor/<br> <jarhar> ChrisL: was the point clear? im agreeing with the proposal there are real colors outside it but not very many, you have to look for real world examples. as a - if we have to have this as a boundary as a reasonable or unreasonable color, direct 2020 seems good ot me but im worried about the impact if this conversion is done behind the scenes, how do<br> <jarhar> authors work with this<br> <jarhar> TabAtkins: exact timing is - exactly what we want for gradients to work well is unclear, it would show up by computed value time, the conversion might happen at a point - is still a detail to be woked out. it should be good for authors<br> <jarhar> florian: i wanted to ask what do you mean by eagerly convert. is it parsing time? computing time? do you bring in direct2020 first and then do the color math? if you have functions do you convert before or after that?<br> <ChrisL> s/outside it/outside rec2020/<br> <jarhar> florian: i think im hearing you say its up in the air, but maybe youve done that already<br> <ChrisL> s/lockers/locus/<br> <jarhar> ccameron-chromium: i think the way - within the general frame we are flexible, my way that im thinkig about it is to view oklab as having th egamupt mapping be a part of the definition of the coordinate spaces<br> <ChrisL> s/100% ?/100% of one wavelength/<br> <jarhar> ccameron-chromium: it would only be observable if you round to a different color space. it would be withini that definition of srgb or xyz or whatever your connection space is. in implementation terms this is done per pixel<br> <jarhar> ccameron-chromium: does that answer the question? its in the definnition of how the coordinates are defined in the coordinate space<br> <lea> q?<br> <jarhar> florian: maybe? what im wondering about for example is as ? was saying, the boundaries are not uniform so if you tahke a color that - if youre gpoing to rotate it around, whether its in or out of gamut will depend on the view. so do you bring it into gamut first and then rotate or vice versa? would make a difference. i suspect what we want is<br> <jarhar> predictability so if its done late thats fine, that would preserve uniformity, but i havent thought deeply about this<br> <jarhar> ccameron-chromium: that sounds good if one is ?? doing this rotation, it would be that you rotate first then map, it may be that if one is doing a rotation in the context of some other operation then maybe we talk about ahaving an escape hatch to get out ?? i think thats particular case is smalll<br> <florian> q-<br> <jarhar> ccameron-chromium: rotate then map vs other is rotate then map because youre working within the coordinate system<br> <jarhar> ccameron-chromium: how to implement it, its really thinking of it as a coordinate system rather than a mapping on all colors<br> <jarhar> florian: makes sense, thanks<br> <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/12-css-minutes.html fantasai<br> <jarhar> lea: so lots of things to process. i left a comment but im going to summarize my points here. i do agree that its ok not to gamut map for rgb formats. i would rather not spec it as anything using the color funciton and scope it down to color spaces like display p3<br> <fantasai> s/Topic:/Subtopic:/<br> <fantasai> s/Topic:/Subtopic:/<br> <jarhar> lea: especially since down the line we plan to add custmo color spaces and we dont know what they would be or if they woul dbenfit from gamut mapping<br> <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/12-css-minutes.html fantasai<br> <jarhar> lea: ??? once rgb formats dont gamut map you need relative color syntax to map to relative syntax and then you dont have gamut mapping<br> <jarhar> lea: i am not a huge fan of tying down css to a color space, id rather not repeat the same mistake, i think it woudl lbe ok to do that as long as we concisder the devide and map to whatever is larger for that color, but counter to what the proposal was trying to do. what many people have not realized is that ccameron said that people can specify<br> <jarhar> imaginary colors and then monitors can do it and then you have a color thats burning through your eyes, but they are happening gradually<br> <jarhar> lea: were talking about extremely bright colors on unmaintained websites, but these websites tend to not be the ones that what most users are using<br> <jarhar> lea: and it happens so gradually that people do have time to adapt. its not like suddenly a display comes out that that can display ?<br> <TabAtkins> We do not, usually, intentionally design for slow breakage when we have a way to avoid it.<br> <jarhar> lea: worry is overprounounced compared to reality. i do think its important to let authors control<br> <jarhar> lea: different use cases prioritize different things. some cases propritize color mapping between image and videos. others abou tlightness preservation or hue or chroma<br> <jarhar> lea: having a control for this would be the best of all worlds. by default it should be lightness were preserving for ax. anything esely you preserve could have readable for developers but not readable for other peopls monitors<br> <jarhar> lea: and preserving chroma should not be the default because its not a stable stragegy.<br> <jarhar> lea: if we preserve lightness or hue then theres always a color in gamut for any gamut. for chroma theres no such garauantee because its usually chroma that gets you out of gamut. centering design aroung images and videos is wron gpriori8ty. i dont think its as common as preserving author intent all over ui, far more important use case than images<br> <jarhar> and videos, which there should be some way to get it but we shouldn't be designing entire css color sysntax around this one use case.<br> <jarhar> lea: people mentioned perceptual rendering intents that end up changing colors that are already in gamut, i dont think thats an optipn for css, we should preserve colors in gamut<br> <jarhar> lea: if we start changing colros in gamut we could be changing srgb colors that are widely employed. we are not bound to using the same gamut mapping stragety geverywhere<br> <jarhar> lea: we scould use one for gradients and use another one for background and borders or text colors or anything like that.<br> <ChrisL> Here is a chromaticity diagram for ProPhoto, showing primaries well outside the visible limits<br> <ChrisL> https://drafts.csswg.org/css-color-4/images/UCS-prophoto.svg<br> <ChrisL> q+<br> <dbaron> +1 to perceptual rendering intents that change colors in gamut not being a reasonable option for CSS<br> <florian> q+<br> <jarhar> miriam: thought overlap with lea's, like chris said i havent played with this so i dont know the results of it. i am frustreated in the proposal that all of the prioritizeds are around image and video matching whent his entire discussion started out of author requests for some other prioritizes<br> <TabAtkins> That's... not at all true? It's part, but the future-hostility is the biggest part.<br> <jarhar> miriam: feels absurd that those get dropped every time we come to it<br> <TabAtkins> It's *the first thin in my list*<br> <jarhar> miriam: yes image and video matching are important but please stop dropping all the other author use cases<br> <TabAtkins> whooops i'm out, my uber is here in two minutes<br> <lea> +infinity to what miriam just said<br> <ccameron-chromium> q+<br> <lea> 👏🏼👏🏼👏🏼<br> <jarhar> miriam: the other frustration there is when i proivde example to hue shift has problems for other cases im told thats an edge case, but then the counter example is this bright pink that required jumping into hdr rendering, and that is somehow not a strange edge case, so just frustrated about how this is presented, but maybe its fine i should go<br> <jarhar> play with it<br> <lea> q?<br> <jarhar> ccameron-chromium: playing with it, theres an experimental flag in chromium that we published a while ago called css gamut mapping. do give that a try, unfortuantely its been a while so its there in stable right now but its expired so we have to make sure its still kept alive<br> <lea> qq+ to ask ccameron-chromium if the current behavior in stable Chrome is still clipping<br> <jarhar> ccameron-chromium: that is roughly the place and time of where it would be applied. in terms of priories, its important to have prioritises - important to address use cases<br> <jarhar> ccameron-chromium: the main thing of the proposal is that it doesn't break color matching, if color matching is to be broken we want users to say this is my intention. that flag in chromium modula o the xact math it does what the proposal is proposing<br> <jarhar> lea: is clipping the default behavior in stable chrome/? i remember experiments with other behaviors without a flag<br> <jarhar> ccameron-chromium: its always been that we will clip it at a certain point, near or above the monitor. there will be some clipping<br> <jarhar> ccameron-chromium: in some circumstances the clipping is done further down the pipeline than us, it will be done either by windows or macos, and the os has the option to do something mroe but chrome does clipping of all colors specificed except for that flag, ?? will be gamut mapped with that flag<br> <jarhar> lea: so if that flag is not set then it just passes it to the os without clipping?<br> <jarhar> ccameron-chromium: yes<br> <Zakim> lea, you wanted to react to ccameron to ask ccameron-chromium if the current behavior in stable Chrome is still clipping<br> <lea> q?<br> <jarhar> florian: for a while without having thought of the eact proposal that something resembling it is likely part of the solution set that we want to look after. whether that should be dthe default behaiovri is another question. which use case tdo we prioritize? we have mu;ltiple use cases and this or something like this probably should be available.<br> <jarhar> wehther matchig videos and images is the thing we prioritize or whether we go closer to some other things that mirian was talking about and opt into this<br> <ChrisL> https://drafts.csswg.org/css-color-4/images/UCS-prophoto.svg vs https://drafts.csswg.org/css-color-4/images/UCS-rec2020.svg<br> <jarhar> ChrisL: so firstly i want to drop two links to images<br> <jarhar> ChrisL: one shows primaries are outsid ethe primaries of the shape, the 10% pure wavelength there are no colors outside that. if you compare that to direct 2020 it is exactly on the edge, you cant get bigger, it sthe largest gamma you can get if you have three primaries ant ehpeimriare s have to be real were not going to get biger than that unless<br> <jarhar> we ? primaries<br> <jarhar> ChrisL: question: when chrome does hdr mode for image and video is any tone mapping applied?<br> <astearns> s/?/use more /<br> <lea> ChrisL: These diagrams have two triangles. What's the inner one? sRGB?<br> <jarhar> ccameron-chromium: videos are passed to the os and ? mappings apply, for images tone mappi9ng apply to get you into the tone range of the monitor. there are the vast majority 99.999% of images that are hdr are done using the ? map format, with that format it is possible to specify color match with css<br> <jarhar> ccameron-chromium: you can specify that colors reamin gifxed, a specific pixel remains fixed, so you can color match wih css or with video or anything else<br> <jarhar> ChrisL: so youre saying that if you have a gain map image you have to tailer the gain map so that the pixels that you want to be unchagned remain unchanged right?<br> <Zakim> florian, you wanted to react to florian<br> <lea> q+ to ask, if we do adopt the proposal to gamut map to Rec.2020, can we change it later, as screen gamuts evolve? Or will we be stuck with Rec.2020 forever?<br> <jarhar> ccameron-chromium: ? has to specify ? so if you have an emoji that you put into your image then ? will do tone mapping, otherwise people use ? to determine what that will be, but every pixel comes with tone mapping, i think tab or someone suggested that css could have an equivalent thing where you specify theres the max of what i would want this to<br> <jarhar> be, and im supportive<br> <jarhar> ChrisL: so if i go into current builds of photoshop and export a gainmap image, heres my hdr photo i just took and i export i t out it calculates the gainmap there will be no clor match because the gainmap software will interpolable between sdr and hdr and that tone mapping operation will chagne all of the in gamut colors unless i specificaly edit<br> <jarhar> the gainmap unless i say these are the ones i dont want to chagne. im pushing on this because as mia said we are moving to a model where mapping between images and colors an ddoing perceptual manipulations is low priority and yet in the gainmap image speac eyou have to identify pixels you dont want to chagne otherwise they will change<br> <jarhar> ccameron-chromium: with the gainmap images in particular, if one exports it from photoshop, they key thing is the determinism there. is that its well defiend how - there are two points you move between. the key takeaway is to look at whats oign gon in the world of hdr video where hdr video color matching is not possible and i would characterisze<br> <jarhar> hdr video as when viewed in desktop computers and mobile devices as a sdisaseter zone. every application that tries to integrate hdr video into their app is frustrating and gives up and goes to sdr because the interaction is underdefined in there<br> <jarhar> ccameron-chromium: in terms of color matching gainmap images give a ? where that is possible. if you dont need to colo rmatch to any color of that image thn thats fine if you go into ps and export and sdr image you can ? color matchi f you want to,<br> <jarhar> ccameron-chromium: ?? color matching between images and videos it was behind every corner, the key thing is to think of it as a parameter space. better to give users parameter spaces where theyre going to bget a specific behavior. would like heres a ? preserving space, heres a hsl kind of space whereits more chroma perserving, heres something where<br> <jarhar> its more perceptual. color matchihng is the cornerstone of color management and its very hard to make a system that works twithout it<br> <jarhar> ccameron-chromium: the other different options are - im a fan of ? a different option to have them, ? from the pserspective of color matching, i like it woudl be wonderful to support css colo s that have some sort of gainmap like scheme ? and were ok with anything in between them<br> <jarhar> dbaron: repeating what tab said on irc before he left, which is that what he said is that his top motivation in response to the argument that e primary motivation was to do image and ivdeo matching, tab had said that his primary motivation was about the future compat issues and not about image<br> <jarhar> dbaron: i dont want to put words in his mouth but it soudned like it was a motivation but the biggest was future compat<br> <jarhar> ccameron-chromium: in terms of the compatability thing in 2020 vs other spaces, i would emphazie that im fine with other options as long as its well defined. there is this difficult that its hard to define whats a wide color sdr color vs hdr color, in some discussions were discussiong we can do it based on ??? sheet of paper and that kind of thing<br> <jarhar> as sdr<br> <jarhar> ccameron-chromium: srgb colors go outside of that gamut, so its very hard to find a dividing line between sdr and hdr, that will always be some boundary in place and map to that, any definition is fine, 2020 was what ??<br> <miriam> (doing only a quick comparison, I'm pretty happy with the results of the chrome algo so far)<br> <lea> q?<br> <Zakim> lea, you wanted to ask, if we do adopt the proposal to gamut map to Rec.2020, can we change it later, as screen gamuts evolve? Or will we be stuck with Rec.2020 forever?<br> <jarhar> lea: if that is the case, if we can change it alter then gtiven that tehde current situation is the worst of all words,, ,right now we have the terrible sitation the me and mia have describes and that these colors are unusuable, and given the fact that - i think there is even if we dont have consensus about everything we do have consensus baout<br> <jarhar> some things. we have consensus around rgb spaces not gamut mapping, author intent is clear there, hard to ?? without intending to, given taht the blink folks are willing to gamut mapping with 2020, and open to changingi it alter, we could resolve to do that while exploring better solutions because the longer we go without any mapping the harder it<br> <jarhar> willb eto change, not hard to go to 2020 to p3 than the current situation where verything is clipped<br> <jarhar> lea: i would be in favor of resolving for that as long as its not the end of gamut mapping and that this is just lets resolve on this because its better. once we resolve on this then foolks wil give us feedback because weve been trying to get this feedback for months or years with no response<br> <jarhar> lea: as chris described earlier<br> <jarhar> fantasai: proposal on the table to do gamut mapping by ok stuff to rec2020 and continue discussing the issue<br> <jarhar> lea: this should not be framed around spaces like oklch but device and ? color spaces. right now they are oklab oklch ? and ?<br> <jarhar> lea: should also apply to future spaces, they will have the same problem<br> <ccameron-chromium> with respect various gamut mapping algorithms, it's an issue that the gamut mapping is applied at a time that breaks color matching.<br> <jarhar> fantasai: i would like the chrome reps and peole in this issue what are the action items you want to assign to each other because we are going to assiign actin items<br> <jarhar> lea: is the proposal that we gamut map to 2020 and then its normative to clip or that they re allowed to clip<br> <jarhar> fantasai: leave it undefined and continue discussing<br> <lea> PROPOSED RESOLUTION: Gamut map all device independent color spaces to Rec.2020 for now, UAs are allowed to clip or gamut map from there to device gamut. Exact GMA TBD<br> <jarhar> ccameron-chromium: would it be ok to respond to whether ? algorithms or are we short on time?<br> <dbaron> ccameron: I agree with that [leave it undefined]. [earlier]<br> <jarhar> fserb: what about having a way to opt out of this?<br> <lea> PROPOSED RESOLUTION: RGB color spaces do not gamut map (srgb, display-p3, rec2020, a98rgb).<br> <jarhar> ccameron-chromium: chromium is ok with ok spaces, for lab and lch were a bit more afraid of that because lab is used more for ?? color matching, were a little bit uncomfortable with that but ??<br> <jarhar> lea: about escape hatch, relative color syntax to go to one of the rgb spaces<br> <jarhar> ChrisL: resolution doesn't say when it happens so we can timplement it<br> <fantasai> PROPOSED: Gamut map all device independent color spaces to Rec.2020 for now, transforming from there to device gamut is undefined. Exact gamut-mapping algorithm TBD. Continue discussing in the issue.<br> <dbaron> s/more for ??/as a canonical color space for ICC/ [??]<br> <jarhar> fantasai: continue discussing in issue<br> <fantasai> RESOLVED: Gamut map all device independent color spaces to Rec.2020 for now, transforming from there to device gamut is undefined. Exact gamut-mapping algorithm TBD. Continue discussing in the issue.<br> <jarhar> lea: im not sure about xyz ones<br> <jarhar> fantasai: does anyone want to discuss that resolution further?<br> <jarhar> dbaron: just to reword so its clear what its a list of<br> <fantasai> PROPOSED: RGB color spaces (srgb, display-p3, rec2020, a98rgb) do not gamut map.<br> <jarhar> ccameron-chromium: is the resolution oklab oklch maybe some other things question mark and then not gamut map rgb?<br> <jarhar> ccameron-chromium: sounds good<br> <jarhar> ccameron-chromium: rest is still under discussion?<br> <jarhar> fantasai: uyes<br> <fantasai> RESOLVED: RGB color spaces (srgb, display-p3, rec2020, a98rgb) do not gamut map.<br> <jarhar> fantasai: now i want to ask people what action items should be taken away from here? lea wants feedback on gamut mapping algos so we can pick a good one. action item for?<br> <jarhar> lea: ccameron<br> <jarhar> ccameron-chromium: i think the core issue ive been failing to communicate is the breaking of color matching and specifying far out of gamut colors and particular choide of algo is separate to that. its about where the algos fit but now which one it is<br> <lea> q+<br> <jarhar> ccameron-chromium: earlier i had issues with the algos perf characteristics, more the problem with the approach of where mapping is being placed<br> <jarhar> fantasai: will you review the gamut mapping algos?<br> <jarhar> lea: we need feedback from someone<br> <jarhar> ccameron-chromium: i can look at them again<br> <jarhar> fantasai: then chris lea and ? to look at chrome proposal<br> <astearns> s/?/mia/<br> <fantasai> ACTION ccameron: review gamut mapping algorithms<br> <fantasai> ACTION lea, chris, mia to review Chrome proposal discussed today<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-2162711081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 10:56:54 UTC