Issue 72 in gpick: CIELAB Values are not Canonical

2 views
Skip to first unread message

gp...@googlecode.com

unread,
Mar 2, 2012, 6:15:24 AM3/2/12
to gp...@googlegroups.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 72 by nihilh...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

It seems the 'a' and 'b' components of the CIELAB decomposition of the
colors are not canonical: I noticed that by trying one of the colors given
in the table at the bottom of this page:

http://ethanschoonover.com/solarized

gp...@googlecode.com

unread,
Mar 2, 2012, 8:44:27 AM3/2/12
to gp...@googlegroups.com
Updates:
Status: Started

Comment #1 on issue 72 by 00a...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

If you want to be sure of a correct basis,
Bruce Lindbloom's site http://www.brucelindbloom.com/ is the only site that
seems really rock solid. Look in the Math section for LAB<->XYZ<->RGB
conversion formulas.

As for GPick specifically, looking at xyz_to_lab, I do note the following
problems :

* Epsilon is lacking a few minorly significant digits. it should be as
close as possible to (216 / 24389) -- to be excessively
precise, '0.008856451679035630817171675755'. 0.0088564516 IMO is accurate
enough (however it's better to make it a '#define EPSILON (216.0 /
24389.0)' and let the compiler optimize out the calculation. That way, you
get as much accuracy as your platform can provide.
* Same for kappa (K), however the error is bigger; GPick's algorithym uses
903.3, which is a pretty rough estimate of 903.296296296... (ie. 24389.0 /
27.0)
Bruce Lindbloom explains the cost of these errors on his site
(http://www.brucelindbloom.com/LContinuity.html). Until I corrected these
in (
https://gitorious.org/pel-core/pel-core/blobs/master/pel/core/transform.py
), I got unreliable LAB<->RGB roundtripping.

* The rest of the code is a bit more challenging to check for correctness.
At a casual inspection it seems otherwise correct.
For now, I will fix the above inaccuracies. If you can point out a specific
way in which GPick doesn't conform to Bruce's specifications (the code is
in source/Color.cpp), I'll look into it.


gp...@googlecode.com

unread,
Mar 2, 2012, 9:08:38 AM3/2/12
to gp...@googlegroups.com

Comment #2 on issue 72 by 00a...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

I've verified the correctness of the RGB<->XYZ transforms, and confirmed
that the GPick LAB values don't match (by a large margin!) the values given
on the linked page.

I've also checked the relationship of those values on the Solarize page.
They are also incorrect (less incorrect than GPick, though :) -- eg. the
first item is 15.2, -11.0624, -11.3948, (per Bruce's calculator at
http://www.brucelindbloom.com/ColorCalculator.html ) rather than the stated
15, -12, -12.

I'll wait to commit my current changes until I can find the source of
GPick's noticable inaccuracy.

gp...@googlecode.com

unread,
Mar 2, 2012, 2:43:53 PM3/2/12
to gp...@googlegroups.com

Comment #3 on issue 72 by nihilh...@gmail.com: CIELAB Values are not
Canonical
http://code.google.com/p/gpick/issues/detail?id=72

Thanks for the references.

If you manage to fix this, maybe it would be useful to provide an option
for the illuminant?

gp...@googlecode.com

unread,
Mar 2, 2012, 3:21:19 PM3/2/12
to gp...@googlegroups.com

Comment #4 on issue 72 by thez...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

White references somehow got mixed up. Should be fixed in revision
841090ddb4ca.

gp...@googlecode.com

unread,
Mar 2, 2012, 6:03:49 PM3/2/12
to gp...@googlegroups.com

Comment #5 on issue 72 by 00a...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

And I've just committed the inaccuracy fix.

Checking some values against Bruce's calculator, I see that for instance,
we get ( 59.93, -19.56, 61.73 ) for #859900 whereas his calculator produces

(59.7213, -19.4611, 61.5394 ). So there are still some inaccuracies.

Bruce's JavaScript implementation is at
http://www.brucelindbloom.com/javascript/ColorConv.js . I'll look it over
for differences to the GPick algorithm.

gp...@googlecode.com

unread,
Mar 2, 2012, 6:37:14 PM3/2/12
to gp...@googlegroups.com

Comment #6 on issue 72 by 00a...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

Looks like the XYZ->LAB conversion was wrong (the LAB->XYZ conversion was
correct, so this would have also caused LAB<->RGB roundtripping to produce
wrong results.)
The D50 illuminant values were also wrong (Z was 82.821 but should have
been 82.521).

After fixing these, #859900 produces (59.94, -19.51, 61.72) in GPick. So,
getting closer, but not there yet. Patch attached.

Attachments:
lab-fix-wip.diff 1.1 KB

gp...@googlecode.com

unread,
Mar 3, 2012, 6:59:55 AM3/3/12
to gp...@googlegroups.com

Comment #7 on issue 72 by thez...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

D50 illuminant X value was also wrong :)
Results are now the same as in Bruce's calculator.
Patch improved and attached.

Attachments:
lab-fix-wip-2.diff 1.9 KB

gp...@googlecode.com

unread,
Mar 8, 2012, 5:10:51 PM3/8/12
to gp...@googlegroups.com

Comment #8 on issue 72 by thez...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

Patch applied in revision 95b5aee934a4. I checked all the colors from
http://ethanschoonover.com/solarized, and a couple of colors do not match.
However, Gpick output is the same as in the Bruce calculator, so it is
either a mistake in the website or they are using different observer,
adaptation method or something.

gp...@googlecode.com

unread,
Mar 17, 2012, 9:06:08 AM3/17/12
to gp...@googlegroups.com
Updates:
Status: Fixed

Comment #9 on issue 72 by thez...@gmail.com: CIELAB Values are not Canonical
http://code.google.com/p/gpick/issues/detail?id=72

This issue was closed by revision 8c017960bafd.

Reply all
Reply to author
Forward
0 new messages