Bug #121259 for PDL-Transform-Color: t_xyz2lab gives wrong results

On Thu Apr 20 18:47:23 2017, vadimr wrote: Show quoted text
Could you help by indicating what is the correct value? (I'm not an expert)

Well-known color calculator: http://www.brucelindbloom.com/index.html?ColorCalculator.html Choose "D65" as Ref.White, enter 1,1,1 as XYZ, click "XYZ", read Lab values: 100.0000 8.5385 5.5939 (L is bounded by 0..100, value above 100 immediately cries "bug"; otherwise XYZ = (1,1,1) is just easy to type and doesn't make physical sense. Maybe more practical would be trying to convert any e.g. sRGB values to Lab -- they also come out wrong) The bug in PDL/Transform/Color.pm is in lines 1539..1543, where illuminant xyY is converted to XYZ. It must be: http://www.brucelindbloom.com/index.html?Eqn_xyY_to_XYZ.html but is coded wrong. Change line 1543 to $me->{params}->{wp_xyz} *= $wp_xyy->(2) / $wp_xyy->(1); i.e. restore "lost" term. Thus it may be not mathematically elegant/efficient, but easy to see where bug is, and fix it. Guarding against y = 0, as Lindbloom advises, is not really needed here, because no illuminant has y = 0. Then Lab we get: [100 8.5841461 5.5183538] That's "good enough", if e.g. someone deals with 8 bits-per-channel images, and least which _must_ be fixed, with further comments kept. As to getting really correct results... To begin with: https://en.wikipedia.org/wiki/Illuminant_D65#Why_6504_K? The module computes xyY (prior to computing XYZ from xyY) from temperature e.g. 6500, but it must use adjusted value of 6504. To fix, line #2158 can be changed to (per link above): my $T = $D*100 * 1.4388/1.438; then Lab we get: [100 8.5859237 5.5509345] Closer, but not there yet. I'm not 100% sure why (not an expert, neither). See xy for standard D-illuminants: https://en.wikipedia.org/wiki/Standard_illuminant#White_points_of_standard_illuminants and see formula for "y", which module uses: http://www.brucelindbloom.com/index.html?Eqn_T_to_xy.html But "y" in table doesn't match "y" calculated from "x" using formula. Maybe only 3 digits after decimal point lead to such error, but I can't find more precise source. I guess all well-known tables, calculators, etc. use pre-computed XYZ (or xyY) for standard D-series, and no-one really uses formulae, to first compute x from (adjusted) T, then y from x, then XYZ from xyY, as module, in good faith, tries to do. -------------------------------------- Plus, I was wrong about supplying "white point as argument", as I see such provision already exists, please disregard that part of my 2017 report, sorry.