Closed Ogeon closed 7 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
508f644
) 80.62% compared to head (503f34c
) 81.46%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Comparing fix_issue_368
(503f34c) with master
(508f644)
⚡ 7
improvements
✅ 38
untouched benchmarks
Benchmark | master |
fix_issue_368 |
Change | |
---|---|---|---|---|
⚡ | yxy to xyz |
20 µs | 13.2 µs | +50.98% |
⚡ | matrix_inverse |
838.9 ns | 271.1 ns | ×3.1 |
⚡ | xyz to yxy |
18.4 µs | 11.2 µs | +64.26% |
⚡ | multiply_3x3 |
427.8 ns | 372.2 ns | +14.93% |
⚡ | hsv to hsl |
29 µs | 16 µs | +81.27% |
⚡ | hsl to hsv |
20.5 µs | 13.9 µs | +46.74% |
⚡ | hwb to hsv |
18.3 µs | 12.1 µs | +51.57% |
bors r+
Oh, looks like bors has finally been disabled. :disappointed:
This turned out to be an error in the reference implementation as well, as I understand it. This line in the
get_Cs
function produces NaN when the lightness is 1.0 or 0.0, by dividing 0.0 by 0.0:The reference seem to be missing the necessary safeguards for this. I looked around for other implementations to see if they had the same issue, but didn't find anything so far. Regardless, it breaks down if it gets an
Oklab
value with lightness 1 or 0. Some inaccuracies or rounding made the chroma != 0.0, which bypassed the already added check for that and let the NaNs out.Closed Issues