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
D65 values are incorrect? #79
Comments
D65 XYZ values are derived from D65 xyY values using the standard formula (with Y being set to 1). It seems that the discrepancy comes from whether to use 4- or 5-decimal space rounding for the x and y numbers. A lot of sources use 5 decimal place rounding 1 2. Bruce Lindbloom references ASTM E308 - 01 which I assume also rounds like this. HSLuv uses 4 decimal place rounding which seems to be encoded in the sRGB standard: Even if 5 decimal place rounding is better, it's certaintly not worth making a revision of the color space for this. I added some comments about this to |
So you're saying if I used a white reference equal to If that's true than I'm confused why using the longer one |
With regards to your code, I can't really comment since I don't know what exactly you're testing. I'm urging you to think practically though. What are you trying to achieve where this difference is an issue? Numbers generated by all these algorithms are always approximations. In the case of colors, remember that the general standard is 24-bit color, which means 8 bits per channel, which means the smallest difference that can be encoded is Another thing to keep is mind is that the precision of your output numbers can only be as good as the least precise of your input numbers. (depending on the calculation.. see: https://en.wikipedia.org/wiki/Propagation_of_uncertainty) So any benefit of increasing the precision of these: ... might be lost unless you also increase the precision of these: |
If I use a D65 value of Here's all the errors for one color. Keep in mind this library scales the values from 0-1, rather than 0-255 or 0-100.
I think I'd rather keep the accuracy and those tests, and I don't think using a different white point will really cause any issues. |
@makeworld-the-better-one, I think they're talking about the rounding applied to the chromaticity coordinates, not the final XYZ value for the white point. The sRGB standard states that D65 should be considered to have the chromaticity coordinates '0.3127, 0.3290', which approximately expands to an XYZ value of
Personally, I'm confused why nobody else just defines it as '0.3127, 0.3290' and then compute the more useful parameters at compile time at maximum precision. |
The standard D65 XYZ values are
(0.95047, 1.00000, 1.08883)
. This is written in Wikipedia and by Bruce Lindbloom (see here and search forD65
).But HSLuv defines them like so:
hsluv/math/cie.mac
Line 40 in 005e50b
If I remove the
rat
and run that calculation, the output XYZ values are(0.95045592705167, 1, 1.089057750759878)
. This is quite a bit off from what I believe are the correct values, and it is throwing off my calculations that use the standard D65 as I defined at the beginning. Here's an example of the difference between what using the standard D65 will output, versus the HSLuv D65:The D65 values affect these variables:
hsluv/math/cie.mac
Lines 48 to 49 in 005e50b
Which goes on to affect everything else.
I believe this could all be fixed by manually setting the
[ref_X, ref_Y, ref_Z]
variables to(0.95047, 1.00000, 1.08883)
. I know that I am quite inexperienced with color theory though, and so I'd appreciate learning if I'm wrong here.For now I will specify a custom white reference for HSLuv calculations only.
The text was updated successfully, but these errors were encountered: