Increase test result precision

[ntkme]

Currently the js-api-spec runs at very low precision at epsilon = (10 ** -2), so things are passing now.

sass-spec/js-api-spec/setup.ts

Lines 358 to 363 in 3bb39e6

	// The max distance two Sass numbers can be from each another before they're
	// considered different (2 decimals).
	//
	// Uses ** instead of Math.pow() for constant folding.
	// TODO: Ideally this should be more precise, but ColorJS does not always match.
	const epsilon = 10 ** -2;

However, when I change the epsilon to 10 ** -11 (the value sass uses internally), I got 6 test failures because the "expected" result does not have enough precision.

[nex3]

The primary reason for this comparison being so low, as the comment indicates, is that the Color.js API which the embedded host uses tends to accumulate more errors than the Dart color API (I think mostly because the Dart API uses more precise transformation matrices). Have you verified that that's no longer the case?

[ntkme]

Have you verified that that's no longer the case?

It is still not consistent. Thus in this PR I'm not trying to really increase the actual the precision used for testing.

I noticed some matrices in w3 draft examples and color.js got updated and have different values than dart-sass: For example https://github.com/color-js/color.js/blob/40e7a059c639bafde14504627e62791588c63100/src/spaces/oklab.js#L10-L24

@nex3 Probably worth cross checking all matrices and see if they are accurate.

[ntkme]

BTW, w3c/csswg-drafts#6642 (comment) might explain what's happening with the precision issue here:

sass-spec/js-api-spec/value/color/color-4-conversions.test.ts

Lines 164 to 168 in 83bd499

	// Certain channel values cause equality issues on 1-3 of 16*16*3
	// cases. 0.45 is a magic number that works around this until the
	// root cause is determined.
	const scale = 0.45;
	const channelValue = destinationSpace.ranges[index][1] * scale;

[nex3]

Increasing precision here sounds good, given that all the tests pass. However, it's probably worth merging the changes for below and making sure that the high-precision values are still correct, given that OK* space conversions are now subtly different than they were before.

I noticed some matrices in w3 draft examples and color.js got updated and have different values than dart-sass: For example https://github.com/color-js/color.js/blob/40e7a059c639bafde14504627e62791588c63100/src/spaces/oklab.js#L10-L24

Oh, thanks for the tip. I'm updating our matrices in sass/dart-sass#2374.

BTW, w3c/csswg-drafts#6642 (comment) might explain what's happening with the precision issue here:

sass-spec/js-api-spec/value/color/color-4-conversions.test.ts

Lines 164 to 168 in 83bd499

	// Certain channel values cause equality issues on 1-3 of 16*16*3
	// cases. 0.45 is a magic number that works around this until the
	// root cause is determined.
	const scale = 0.45;
	const channelValue = destinationSpace.ranges[index][1] * scale;

I doubt we can fix this until Color.js is also using all the latest matrices (if it ever does).

[ntkme]

I doubt we can fix this until Color.js is also using all the latest matrices (if it ever does).

If I read the comment from the linked color.js code correctly I think they are already using updated matrices, and dart-sass being outdated might be why the results were off between the two, but maybe there will be other differences. Hard to know as the way color conversion path works is quite different.

[nex3]

Hmm... the matrices added in color-js/color.js#357 match the CSS spec, but they're different from those described in w3c/csswg-drafts#6642 (comment), which the comments on that issue seem to indicate are the best currently available. I've asked for clarification in w3c/csswg-drafts#6642 (comment).

[ntkme]

One good-ish news is that after I updated the matrices in ruby implementation (a port of dart implementation) now I can reproduce the issue where the color conversion tests pass at precision of 4 digits, but fails at precision of 5 digits. So the LMS matrices might have been the root cause of the precision difference. Next thing to try is re-baseline all color conversion tests, and validate them against dart-sass vs color.js and see if they pass at higher precision.

[ntkme]

@nex3 I spent sometime re-baselining all the outputs with embedded-host-node implementation on color.js 0.5.2 - and now when running at epsilon = 10 ** -11 on dart-sass, we still see failed tests and all of them involves oklch and oklab - might be something we want to take a look.

[nex3]

It's generally expected that we differ slightly from Color.js, because we're generally using more precise color transform inputs (especially for oklch and oklab, where we computed many steps losslessly).

[ntkme]

Never mind, I forgot to update my dart-sass build.

[ntkme]

Tests are now passing at epsilon = 10 ** -11.