Re: [csswg-drafts] [css-color-4] Missing info about Premultiplication and Undefined values (#7536)

The CSS Working Group just discussed `premultiplication and undefined values`, and agreed to the following:

* `RESOLVED: Specify how none is carried across color space conversion to a related component on the other side`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: premultiplication and undefined values<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7536<br>
&lt;TabAtkins> chris: we ahve some stuff abou thow to convert colors<br>
&lt;TabAtkins> chris: first, nones get replaced by zero, bc you need a number to convert<br>
&lt;TabAtkins> chris: we also have text to interpolate, which says if one has none it takes the value from the other<br>
&lt;lea> s/ahve/have/<br>
&lt;TabAtkins> chris: This avoids interpolating an achromatic to chromatic where it starts from an essentially random color<br>
&lt;TabAtkins> chris: These assume the space you're specified and interpolated in are the same<br>
&lt;TabAtkins> chris: If they're not, the conversion happens and you lose the info<br>
&lt;TabAtkins> chris: There's also the issue taht if you're using two different color spaces, what to do?<br>
&lt;TabAtkins> chris: If you have one in lch and one in hsl, do you copy the hue angle even if it's a different color?<br>
&lt;TabAtkins> chris: it starts not making sense unless the values you're comparing nones for are in the same color space<br>
&lt;TabAtkins> chris: then the question was, do we want this anyway?<br>
&lt;TabAtkins> chris: We started with saying tha tsometimes the channel was NaN<br>
&lt;TabAtkins> chris: and i was convinced to change it to none<br>
&lt;TabAtkins> chris: for consistency we added it everywhere, including in places no one asked for it<br>
&lt;TabAtkins> chris: that's extra testing, what's the point, etc<br>
&lt;lea> q+<br>
&lt;TabAtkins> chris: it does help i nsome cases - if you have two in the same polor color space, it helps<br>
&lt;Rossen_> ack lea<br>
&lt;TabAtkins> lea: for none to resolve, you clearly need to convert to the same color sapce<br>
&lt;TabAtkins> lea: no question<br>
&lt;TabAtkins> lea: but there's a question of how to convert if both colors can have none<br>
&lt;TabAtkins> lea: i don't think having none everywhere created new problems, they exist even if it's only present in hues<br>
&lt;TabAtkins> lea: we need to figure it out regardless of if it's allowed in rgb, etc<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> chris: i don't think that transporting nones from one color to another when they're in another color space is *useful*, it's just the only thing to do from the spec text<br>
&lt;TabAtkins> chris: but it doesn't make a lot of sense<br>
&lt;TabAtkins> florian: do you have an idea of the solution<br>
&lt;fantasai> TabAtkins: I disagree that it doesn't make sense when they're in different color spaces<br>
&lt;fantasai> TabAtkins: if you take achromatic hsl into chromatic lch<br>
&lt;fantasai> TabAtkins: it's ...<br>
&lt;lea> q+<br>
&lt;fantasai> TabAtkins: if you wanted to maintain intent of none behavior, I think answer is convert using the same rules, and remember the noneness and apply it on the other side of the conversion<br>
&lt;fantasai> miriam: that only seems possible with hue, though, right?<br>
&lt;fantasai> TabAtkins: powerlessness extends across conversions, right?<br>
&lt;fantasai> TabAtkins: if your hue is none and you convert to RGB ...<br>
&lt;fantasai> miriam: if your R, G, or B is none and you convert to hue, how do you do the conversion?<br>
&lt;fantasai> chris: to restate, you take which component names have none, then you do the conversion, and if that component name exists in the result ...<br>
&lt;fantasai> chris: if you convert hsl to lch, they both have hues<br>
&lt;fantasai> chris: but if you convert to profoto rgb, then no place to put it<br>
&lt;fantasai> TabAtkins: if you have zero chroma, should be same as ???<br>
&lt;fantasai> TabAtkins: so need to some manual mapping of what coverts to what as nones<br>
&lt;fantasai> TabAtkins: but e.g. polar to rectangular or vice versa wipes out the info<br>
&lt;fantasai> lea: even if going from hsl to lch,  ...<br>
&lt;fantasai> lea: do we really want none^2/2?<br>
&lt;Rossen_> ack lea<br>
&lt;fantasai> TabAtkins: treat none as zero, convert it over, remember that the hue was zero, and then none it<br>
&lt;fantasai> lea: so would need to rmeember that hue in hsl and lch relate<br>
&lt;fantasai> TabAtkins: chroma and saturation should also map<br>
&lt;fantasai> TabAtkins: lightness should map<br>
&lt;fantasai> TabAtkins: if we want to maximize author friendliness of original intent, we need to set up a map of which channels can carry noneness into other profiles<br>
&lt;fantasai> lea: how would that work with custom profiles?<br>
&lt;florian> q?<br>
&lt;fantasai> TabAtkins: probably can't do it with custom profiles<br>
&lt;fantasai> lea: another suggestion is to ditch none altogether and handle achromatic colors specially, same as how we handle transparent colors specially<br>
&lt;fantasai> lea: it's not as elegan<br>
&lt;fantasai> TabAtkins: only objection there is one of the uses for none is to handle things without chroma that do have a definite hue<br>
&lt;fantasai> TabAtkins: e.g. things like white and black, they have undefined chroma as well<br>
&lt;fantasai> TabAtkins: so they don't go from zero chroma into white chroma red<br>
&lt;TabAtkins> s/white/bright/<br>
&lt;Rossen_> ack dbaron<br>
&lt;fantasai> dbaron: It would probably be useful to look the mapping from basically a table that shows what components in this color influence what components in ths other color<br>
&lt;fantasai> dbaron: for example, when convering hsl to lch, which components of hsl influence l in lch, etc.<br>
&lt;fantasai> dbaron: that might be useful<br>
&lt;fantasai> dbaron: it sounds like you want to transfer noneness in some cases beyond where it's strictly ok?<br>
&lt;fantasai> TabAtkins: less probably<br>
&lt;fantasai> dbaron: my intuitino is it would strictly be okay only where the inputs to the value were the ????<br>
&lt;fantasai> dbaron: I think<br>
&lt;fantasai> TabAtkins: might be, not 100% certain<br>
&lt;fantasai> dbaron: do more than that, but look at these tables and see what you want to do<br>
&lt;fantasai> dbaron: assuming you want to go down that path<br>
&lt;fantasai> chris: in genera, prefer ...<br>
&lt;fantasai> chris: but if I have a none alpha, and I convert to zero, and then I get transparent black, then ...<br>
&lt;fantasai> TabAtkins: we only premultiply during transitions right?<br>
&lt;fantasai> TabAtkins: idk if we've specifyed more clearly<br>
&lt;fantasai> chris: we have<br>
&lt;fantasai> TabAtkins: srgb is stored premultiplied?<br>
&lt;fantasai> chris: no, but when you interpolate you premultiply<br>
&lt;una> q+<br>
&lt;fantasai> miriam: but at that point you've already done the replacement<br>
&lt;fantasai> dbaron: is it possible you want the math for none to be different for different plcaes where you can put a none?<br>
&lt;lea> q+ to answer dbaron<br>
&lt;fantasai> chris: I think good thing about Tab's proposal is you don't have to handle none through the entire calculation chain<br>
&lt;fantasai> chris: just put it back at the end<br>
&lt;fantasai> dbaron: was suggesting for alpha cases, but maybe you want to treat it as 1 rather than zero<br>
&lt;fantasai> TabAtkins: yes, when you do conversoin you turn it into a number, and that's already in the spec<br>
&lt;fantasai> dbaron: ah, I thought someone said it's always zero<br>
&lt;fantasai> chris: it is<br>
&lt;fantasai> TabAtkins: even for alpha?<br>
&lt;fantasai> lea: maybe alpha should be 1<br>
&lt;una> q-<br>
&lt;fantasai> TabAtkins: alpha isn't involved in color space conversions<br>
&lt;Rossen_> ack lea<br>
&lt;Zakim> lea, you wanted to answer dbaron<br>
&lt;fantasai> lea: for HSL and LCH, for example, I think basically all components influence all components, it's jus thtat some components influence some other components more<br>
&lt;fantasai> lea: hue and lightness still influence every component, because not 1-1 mapping<br>
&lt;fantasai> dbaron: that was my intuition, especially once you're converting between d50 and d65 then you're definitely<br>
&lt;fantasai> TabAtkins: my intention was to put a table of what components map across, only a handful to worry about<br>
&lt;fantasai> TabAtkins: all the hue-ish things, all the red-green-blue-ish things'<br>
&lt;fantasai> Rossen_: that's the action out of this issue?<br>
&lt;fantasai> TabAtkins: proposed resolution is we specify how none is carried across color space converstion to a related component on the other side<br>
&lt;fantasai> Rossen_: objections?<br>
&lt;fantasai> RESOLVED: Specify how none is carried across color space conversion to a related component on the other side<br>
&lt;TabAtkins> ScribeNick: TabAtkins<br>
&lt;dbaron> (I do wonder how the stability of this relates to stability of other features in color 4.)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7536#issuecomment-1202799109 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 2 August 2022 15:17:29 UTC