WPT css/css-color/lch-005.html fails in Firefox (with color-channel difference of 1)
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox119 | --- | fixed |
People
(Reporter: dholbert, Assigned: tlouw)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
WPT css/css-color/lch-005.html fails in Firefox.
wpt.fyi:
https://wpt.fyi/results/css/css-color/lch-005.html
It's an off-by-one issue in the red color channel. The failure is reported as "Found 18432 pixels different, maximum difference per channel 1", and the screenshot shows that it's the whole bottom area that mismatches, with the testcase having
RGB(27, 193, 169) vs. the reference case having RGB(28, 193, 169). So: 27 vs. 28 in the red color channel.
Tiaan, could you take a look here perhaps? We might have a rounding/precision bug, though I'm not sure how much to worry about it. The test seems to be expecting background-color: lch(70% 45 -180); to produce the same precise color output as rgb(10.7906% 75.5567% 66.3982%);.
(It looks like that red-color-channel percentage works out to 10.7906% * 255 = 27.51603, which is just over the round-up-to-28 threshold.)
|
Reporter | |
Updated•2 years ago
|
|
Assignee | |
Comment 1•2 years ago
|
||
Yeah looks like the test is 1 out:
https://colorjs.io/apps/convert/?color=lch(70%25%2045%20-180)&precision=4
red = 0.10750589333192043 * 255 = 27.414002799639707 = 27
I will update the test.
|
|
Reporter | |
Comment 2•2 years ago
•
|
||
Hmm yeah; if I'm reading that colorjs.io table right, it seems to be saying 10.75% would be the appropriate r component here, rather than the test's current 10.7906% value.
The test's current 10.7906% value is here:
https://github.com/web-platform-tests/wpt/blob/2ba7228309/css/css-color/lch-005.html#L10
That dates back to the original commit that added the test (though at that point, it was in a 2-decimal-places form, 10.79%):
https://github.com/web-platform-tests/wpt/commit/245ccae909f72e7112b4109a0d0174b3efd8e46e#diff-36d950e261403eeb3f8528d5b0670b54be8585b53bf7893403b7a66d47168619R11
Normally I would think it was just a typo in that original commit, but it's interesting that the test was later amended to add more precision to that value (producing the current 4-digits-after-the-decimal-point expression). That later commit was here:
https://github.com/web-platform-tests/wpt/commit/755a4a0285067505e47b516dfc7d74f4cdbb661a#diff-e9a5db8cd492903f0d844b5701722cd10d54a3585b1876cfa70420568b4ceef7R5
Chris, you're the original author here - can you confirm that 10.75% would in fact be the correct red component here, per Tiaan's link above? Or is the slightly-larger 10.7906% (the value currently in the test) correct for some reason?
(I wonder if there was some subtle change in the mapping at some point, or perhaps a change in precision in color-conversion tools, with older tools tripping over a lossy numerical conversion at some point? Something like that might explain why we would've ended up with this [hypothetically] off-by-0.04% value here.
Agree that 10.75 is the correct conversion here.
I recall that the OKLab conversion code had to be tweaked after it was added to the spec, because the white point in the original OKLab blog post was not identical the the one used for other D65 RGB spaces, so it had to be recalculated. I suspect that is the origin of this difference.
Relevant issue started here
https://github.com/w3c/csswg-drafts/issues/6642#issuecomment-943521484
Recalculated matrices added with this commit
https://github.com/w3c/csswg-drafts/commit/ba64b3f83189adc241024977f2ae7d1bb7534ad6
|
|
Reporter | |
Comment 5•2 years ago
|
||
Thanks! I wonder if WebKit and Chrome are still using the old conversion code, given that they were passing this test.
I wondered that too, it would probably be good to add more tests that specifically target this sort of rounding behavior to check for that. I guess they will notice when they start failing this one :) and the WPT commit message and rel=help could usefully reference this bug.
|
|
Assignee | |
Comment 7•2 years ago
|
||
The RGB values in the test are slightly off (possibly values calculated
with old conversion code, see the related bug for discussion).
|
||
Comment 10•2 years ago
|
||
| bugherder | ||
Description
•