Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert utility claims to have gamut mapped an in-gamut ACEScc color #377

Open
svgeesus opened this issue Dec 15, 2023 · 2 comments
Open
Labels
bug Something isn't working Topic: demos

Comments

@svgeesus
Copy link
Member

Converting oklab(0 0 0) to ACEScc returns color(acescc -0.3584 -0.3584 -0.3584) which it says has been gamut mapped. The un-gamut-mapped converted value is not listed.

@svgeesus svgeesus added bug Something isn't working Topic: demos labels Dec 15, 2023
@svgeesus
Copy link
Member Author

Raw coords are -0.35844748858447484, -0.35844748858447484, -0.35844748858447484

In the source we have

// the smallest value which, in the 32bit IEEE 754 float encoding,
// decodes as a non-negative value
const ACES_min_nonzero = -0.35828683;

but there is no specification link for that value, or why it was copied at that precision.

@facelessuser
Copy link
Collaborator

This is stated as non-zero values, oklab(0 0 0) would be a zero value return. This is also comparing 32 bit values, but JS is using 64 bit values.

Considering that 32 bit has ~7 decimal places of precision, that is probably correct as seen below.

>>> Color('acescc', [-0.35828683] * 3).convert('aces2065-1').coords()
[5.959876951435854e-08, 5.9598769514358546e-08, 5.9598769514358546e-08]
>>> Color('acescc', [-0.35844748858447484] * 3).convert('aces2065-1').coords()
[0.0, 0.0, 0.0]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Topic: demos
Projects
None yet
Development

No branches or pull requests

2 participants