[css-color] Values in `relative-color-out-of-gamut.html` seem slightly wrong.

[romainmenke]

https://github.com/web-platform-tests/wpt/blob/6018167f38e7d5c98ba131b66bc75a67643b662e/css/css-color/parsing/relative-color-out-of-gamut.html#L24-L52

When verifying various tests for css-color I noticed that I get different results here.

For example:

rgb(from color(display-p3 0 1 0) r g b / alpha)

results:

• color(srgb -0.511814 1.01832 -0.310726) (wpt)
• color(srgb -0.5116 1.01827 -0.31067) (my results)
• color(srgb -0.5116 1.01827 -0.31067) (colorjs.io)

I am not sure if the recorded values in the tests are slightly wrong, or if maybe Chrome is slightly wrong.

@svgeesus Are implementations expected to have interop to this degree? If so, then there should be tests for this.

@mysteryDate I think you submitted these tests, is there anything you can think of that could explain this difference?

Maybe we should just reduce the precision of the value to match the epsilon of the fuzzy tests.

---

Note: fuzzy_test_computed_color has a default epsilon of 0.01 so these tests are checking the full values.

Note: Although these tests are related to gamut mapping, they actually test that no gamut mapping happens for specific values. So this is a general issue, not a gamut mapping bug.

[svgeesus]

@svgeesus Are implementations expected to have interop to this degree? If so, then there should be tests for this.

They could have.

There was a bunch of detailed work done over the last few years, some in CSS Color 4 and some in color.js, often in parallel, to really reduce sources of cumulative error like slightly-different white points, inverse matrices calculated from rounded-off values, and so forth.

In most but not all cases, the result of this was better precision but well below the level of a visual difference.

My suspicion is that browser implementers could usefully check their matrix values against the current ones in sample code which are now as accurate as we can make them for 64bit floats, and update as needed.

[romainmenke]

A quick glance in WebKit at least shows that they have outdated matrix values:

sample code : https://github.com/w3c/csswg-drafts/blob/ed383b552d3c977ad18116d8038c73d2c997f5a3/css-color-4/conversions.js#L159-L161

    var M = [
        [ 0.79776664490064230,  0.13518129740053308,  0.03134773412839220 ],
        [ 0.28807482881940130,  0.71183523424187300,  0.00008993693872564 ],
        [ 0.00000000000000000,  0.00000000000000000,  0.82510460251046020 ]
    ];

WebKit: https://github.com/WebKit/WebKit/blob/bf9bfb5b39381e185808dedaed839b86cd4d52ec/Source/WebCore/platform/graphics/ColorTypes.h#L430-L432

    static constexpr ColorMatrix<3, 3> linearToXYZ {
        0.7977604896723027f,  0.13518583717574031f,  0.0313493495815248f,
        0.2880711282292934f,  0.7118432178101014f,   0.00008565396060525902f,
        0.0f,                 0.0f,                  0.8251046025104601f
    };

[svgeesus]

@weinig could you take a look? The difference will not be visible to the eye (mostly, unless errors accumulate through a chain of conversions) but could cause automatic tests to fail.

It looks here as if the fuzziness of the fuzzy test is set rather high, to mask these differences. But WPT should be using the correct results here. The sample code uses rational number where possible (it isn't, for prophoto) so should be accurate to 64 bits.