Closed weinig closed 6 months ago
@mysteryDate @svgeesus @tiaanl @mdubet
Yeah hwb()
is even worse than hsl()
in that respect. For colors a little outside sRGB
it is lossless but it suddenly falls apart quite quickly.
Those hwb()
round-trip subtests should be deleted. The rgb()
and hsl()
ones appear correct.
Btw @weinig I strongly suggest double-checking the to-xyz and from-xyz matrices, the chromatic adaptation matrices, and the matrices to and from oklab in WebKit against the ones in the sample code. There have been several rounds of revisions and we believe the ones in the sample code are 64-bit float accurate, but it may be that WebKit is using some older ones which (while not giving visibly different colors) will be subject to small round-off errors which can accumulate to the point of failing a test if there are many color conversion stages.
Same advice for Blink and Gecko but given how WebKit was such an early adopter the chance of the matrices being older ones is greater, I suspect.
Btw @weinig I strongly suggest double-checking the to-xyz and from-xyz matrices, the chromatic adaptation matrices, and the matrices to and from oklab in WebKit against the ones in the sample code
I'm going to assume this was fixed by #45940, but feel free to reopen if that is not the case.
The test css/css-color/parsing/color-computed-relative-color.html currently assumes that conversion to hwb is lossless, which the current specification doesn't seem support. For example the fuzzy test on line 794:
(where
${colorSpace}
is eitherxyz-d65
orxyz-d50
).Using colorjs.io as a proxy, just taking the inner most part and seeing the possible values of color(xyz-d65 0.99 0.88 0.77) -> https://colorjs.io/apps/convert/?color=color(xyz-d65%200.99%200.88%200.77)&precision=4
you can see that the
hwb
representation ishwb(183.3 118.4% 15.14%)
-> https://colorjs.io/apps/convert/?color=hwb(183.3%20118.4%25%2015.14%25)&precision=4which round trips back to
xyz-d65
ascolor(xyz-d65 0.7235 0.7612 0.829)
.Totally possible I am interpreting something in the spec language incorrect here.