Skip to content

Conversation

@197g
Copy link
Member

@197g 197g commented Jun 22, 2025

Also fixes a coefficient in the definition of ST 2084.

@197g 197g merged commit 72a8adf into master Jun 22, 2025
8 checks passed
let Y = pow(val, SMPTE2084_M1);
let nom = SMPTE2084_C1 + SMPTE2084_C2 * Y;
let denom = SMPTE2084_C3 * Y + 1.0;
let fraction = pow(val, SMPTE2084_M1);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PQ OETF and HLG don't support negative inputs, and should be tested carefully because IEEE arithmetic is not exact and pow(negative_value, any_not_an_integer) = NaN. The same applies to pure gamma, log functions and others that don't have numerical stability under some conditions ( for ex. log(zero) is singularity ).
If you want to go with ITU-R standard (table 3) it recommends to clamp all input to defined range. Only ICC allows some kind of "extended range" only when your image storage type is IEEE dyadic float because other types it may lead only to overflows or underflows.

If you don’t have an explicit plan to support an "extended mode" it makes sense to clamp all input.

Sorry for being a bit pedantic.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pedantry is fine here 😃 The reason I'm not clamping here by design: a vectorized clamping should be applied to the whole slice of color data before mapping the transfer function. The same would apply to validation (out-of-gamut Oklab->sRGB) would be applied after the color transform on the whole slice. At least, so far the plan.

Do you have some good resources on how to construct rigorous integration tests, i.e. exhaustive test vectors?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have some good resources on how to construct rigorous integration tests, i.e. exhaustive test vectors?

Not really. When I want to do rigorous testing I write fuzzer for this, that usually takes a few minutes and it works forever ( until it’s not broken 🙂 ). Writing too much tests manually is annoying and you still won’t check everything.

I made “a perfect one” gamut clipping, oklab works only for srgb, and it’s too small to work for something else, also computing cost for Oklab checks is too high.

@197g 197g deleted the matching-colour-science branch June 23, 2025 00:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants