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
Inaccurate xyz to lab. #100
Comments
Do you have some reference for the If this is truly the case, happy to accept a PR that constructs the constant at boot time and uses that instead of the hardcoded value. |
Ah actually that's pretty well documented. Neat, thanks for the heads up. Will fix. |
c1576fe should fix it; as for the other constants, I'm not sure they can be adjusted based on some cursory research. Further, some of the more specific ones are hitting limits of the IEEE standard anyway. Let me know if that's adequate or if any others should be calculated like that. If not, I'll cut a release for you. Thanks again! |
Wow, thanks for the quick fix! Could you also change 7.787 to 1/3*(4/29)^(-2) (ref: lab wiki) ? One other thing is that any reason there are no tests broken? |
The tests are using the default (rounded) versions of calls. Probably best, anyway, given IEEE inaccuracies, especially at such a fine-grained level. |
The change you requested gives me a drastically different result (
Am I misunderstanding the formula? I would have expected it to be mostly the same, if not a bit more precise. |
Sorry. Typo. 1/3*(6/29)^(-2) |
Too lazy to figure out what's wrong with rgb to xyz. Feel free to close this once 1/3*(6/29)^(-2) is fixed. Things I used for manual testing the convertion: To document my findings for rgb to xyz conversion: For I don't think it's too fine grained though. My library converts rgb to lab color space, do some basic arithmetic and then convert back to 0-255 integer version of rgb. And some rgb components is off by 2. Too lazy to write a minimum example though. If you are worried about IEEE inaccuracy, maybe set a difference threshold when asserting. Threshold of 1 is not justified just to account for IEEE inaccuracy. But not a high priority though. |
The constants used in xyz to lab conversions are not accurate...
As an example, places where we use 0.008856 are actually supposed to be (6/29)^3. There are a lot more constants that are not accurate. I didn't go through all of them.
This has caused problems for me because I'm building a color-related library that's implemented in multiple languages. It converts rgb to lab color space, do some basic arithmetic and then convert back to rgb. (Yes, I used the
xyz.lab.raw
version) For javascript, I used color-convert as a dependency. And this has produced inconsistent results for different implementations.The text was updated successfully, but these errors were encountered: