color_space_conversion: use exact rational matrix formulations

[kainino0x]

On a few tests, the conversion result was exactly the same down to the ULP. But these make a nice reference implementation since they can be copied to other contexts with arbitrary precisions.

Unfortunately, since the results didn't change, this didn't fix relatively large deltas I saw in the G channel of these tests (not huge, 0.0007). It's unclear whether we can fix that or if we'll keep those thresholds (in #1055).

Issue: #913

---

Requirements for PR author:

• All missing test coverage is tracked with "TODO" or .unimplemented().
• New helpers are /** documented */ and new helper files are found in helper_index.txt.
• Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)

Requirements for reviewer sign-off:

• Tests are properly located in the test tree.
• Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[shaoboyan]

Recalled that the diff might also generated by the chromium implementation. It always use XYZ D50 color space as intermediate color space to calculate the conversion matrix. This might introduce D65 -> D50 conversion with Bradford chromatic adaptation(Not 100% sure uses this method).
And the reason is that ICC profiles are defined relative to a D50 reference white.

[shaoboyan]

Bradford chromatic adaptation which is also used by CSS4 spec. (More info).

function D65_to_D50(XYZ) {
	// Bradford chromatic adaptation from D65 to D50
	// The matrix below is the result of three operations:
	// - convert from XYZ to retinal cone domain
	// - scale components from one reference white to another
	// - convert back to XYZ
	// http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html

[shaoboyan]

Formulation LGTM!

[kainino0x]

Your idea about D50 makes sense! Do you think it's just due to precision loss in the D50/D65 conversions or an actual error in the computation?

[github-actions]

Previews, as seen when this build job started (326c027):
Run tests | View tsdoc

[shaoboyan]

Do you think it's just due to precision loss in the D50/D65 conversions

I think it is due to precision loss considering the big diff happens around ~0 values. And the method to convert from D65/D50 are various. We cannot control the implementation in browser and I think chromium chooses the recommended one.