-
Notifications
You must be signed in to change notification settings - Fork 82
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
Add OkLrab and OkLrCh #511
Add OkLrab and OkLrCh #511
Conversation
✅ Deploy Preview for colorjs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Only lint issues related to this change were addressed. |
This will clearly need a rework now that the null changes are in. |
02d9fc8
to
1278f73
Compare
Rebase completed and is ready for review. |
@@ -430,22 +430,78 @@ const tests = { | |||
expect: [1.0, 0.0, null], | |||
}, | |||
{ | |||
name: "sRGB red (D65) to OKlab", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, one question but not a blocker
{ | ||
name: "sRGB white (D65) to OKlrab", | ||
args: "white", | ||
expect: [ 1.0000000000000002, -4.996003610813204e-16, 0 ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this actually be zero and this is cumulative error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, cumulative floating point error.
Oklab in Color.js currently yields that for white, so OkLrab will also yield that for white as OkLrab just applies a toe function to the lightness, and at white, there is no change.
> new Color('white').to('oklab').coords
[ 1.0000000000000002, -4.996003610813204e-16, 0 ]
Floating point errors can vary slightly depending on how the original matrix was generated, the exact steps and in what order. The invert matrix result can be slightly different (floating point error-wise) depending on exactly how the inversion is performed (did it use LU decomposition, some other way, what order were operations done in, etc).
This isn't too different for other Lab-like spaces, especially those that employ more complicated calculations:
> new Color('white').to('ictcp').coords
[ 0.5806888810416109, 1.1102230246251565e-16, 2.914335439641036e-16 ]
I think my library has slightly different floating point errors. It yields an exact 1 for lightness, but non-zero results for both a and b.
>>> Color('white').convert('oklab').coords()
[1.0, -4.996003610813204e-16, 1.1102230246251565e-16]
But the same things happen for various other Lab-ish spaces (Y is the lightness in XYB):
>>> Color('white').convert('hunter-lab').coords()
[100.0, 1.912989643463523e-14, -7.46260389005987e-15]
>>> Color('white').convert('xyb').coords()
[0.0, 0.8453085619621621, 2.220446049250313e-16]
Someone more familiar with ts should probably look at the lint errors |
As far as this review is concerned, none of the lint errors apply to the code changes made in this PR. I consider these all existing, separate issues. I imagine it would be useful for someone to open a separate review to address these once and for all, but I do not consider any the lint errors to be blocking this review as they are unrelated and were not introduced by these changes. |
Agreed. If |
1278f73
to
61d0f70
Compare
Rebased and fixed imports due to recent changes on main. The lint action now passes. I think this can be considered done. |
Resolves #505