wpt
wpt copied to clipboard
[css-color] css/css-color/parsing/color-computed-relative-color.html assumes conversion to hwb is lossless
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:
fuzzy_test_computed_color(`color(from hwb(from color(${colorSpace} 0.99 0.88 0.77) h w b) ${colorSpace} x y z)`, `color(${colorSpace} 0.99 0.88 0.77)`, 0.0001);`
(where ${colorSpace}
is either xyz-d65
or xyz-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 is hwb(183.3 118.4% 15.14%)
-> https://colorjs.io/apps/convert/?color=hwb(183.3%20118.4%25%2015.14%25)&precision=4
which round trips back to xyz-d65
as color(xyz-d65 0.7235 0.7612 0.829)
.
Totally possible I am interpreting something in the spec language incorrect here.
@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
On it! https://github.com/WebKit/WebKit/pull/27824
I'm going to assume this was fixed by #45940, but feel free to reopen if that is not the case.