Color: CIELab and Tristimulus XYZ

Let’s talk about CIELab. I’m not going to provide any background or discussion. This wiki article is an excellent introduction.

And there’s a very nice article about HSB. Furthermore, it includes an example with many more parameters than just hue, saturation, and chroma computed, which is outstanding. It also has a lot more information about HSI versus HSB; the differences seem to be more than I was led to believe from my previous reading.

CIELab is specified as a transformation from XYZ tristimulus coordinates. What motivated this post is that the only inverse transformation I’d seen published – until I read the wiki article – is incomplete. That’s a polite way of saying it doesn’t always work correctly. And that’s a polite way of saying it’s wrong.

In fact, the inverse transformation in the wiki post is perfecty straight-forward, and I’ll show it to you in more detail than they do.

So, I want to show you the standard transformation which defines CIELab… and two inverse transformations, one of which is – at best – incomplete. In addition, there is more than one way to write the numbers in the transformations, and I’ll show you what I prefer.

Here’s the definition of CIELab out of Fairchild’s “Color Appearance Models”.

Here's the code I wrote for it:

You should notice that my code computes and returns two additional results… for "chroma" and h for hue angle (and I chose to use degrees rather than radians). I'll talk about them down the road (but not today).

I should point out, however, that h and are nothing more than polar coordinates based on cartesian coordinates a,b.

Oh, properly speaking the CIELab coordinates are denoted with asterisks, L*, a*, b* – but since I’m not going to discuss any other Lab model in this post, I will use L, a, b.

Thanks to the wiki article, I know what the numbers .008856 and 7.787 "really" are: one is the cube of 6/29, and the other is one-third of the square of 29/6:

Oh, and 16/116, in lowest terms, is

As a result, I prefer to write the transformation using exact rational numbers rather than approximate decimal numbers. Here's my current code. It uses "If" to define the function f, and declares f local in addition to the internal variables.

Recall my most recent artists' color wheel…

We need the tristimulus values for a reference white. I chose to measure the values of the white background – boy, that was handy! – and got

(We'll see those numbers again in a new post about transforming between RGB and XYZ on my monitor.)

Here are the tristimulus values XYZ for those 12 colors on my monitor, measured by the DigitalColor Meter, which comes with OS X.

Let me apply the XYZtoLab function to those 12 XYZ sets. Call the result "fullLab"; in addition to the L,a,b values, it has returned and h, chroma and hue angle. It's been a while since I displayed matrices; the "TeXForm" command gives me what I need for the LaTeX.

Let me cut those results down so we just have L, a, b. The following line says "drop none of the rows, and drop the last two columns" – and then give me TeX after displaying the matrix…

Now, let me use the DigitalColor Meter to measure the Lab values directly:

Look at the differences between computed Lab values and measured Lab values:

Hmm. The differences in a and b are two orders of magnitude greater than the differences in L. I don't like that.

Here are the % differences:

Yikes! The discrepancy in the last measured versus computed b value is more than 1%.

I don't know why. (And I’ve checked the measured tristimulus and Lab values.) I'm hoping it has to do with our having only 8 bits for each of R,G,B — which is how the colors are specified physically.

In other words, I'm not going to worry about the discrepancy between computed and measured. Not until and unless I have reason to. The code is simple enough, and I've checked the numerical values used in it. My computed Lab values should be correct, given the measured tristimulus values.

(I’m confident that I’m right, and it will be embarrassing if I find I’m wrong somehow.)

Now let's look at the inverse, going from Lab to XYZ. Kang ("Computational Color Technology") offers the following – and I’ve seen that Glassner (bibliography) does, too… which was easy enough to code up:

There's just one little problem: the inversion is conditional only on the value of L. Equivalently, this inversion is conditional only on the value of Y/Yn; this inverse does not depend on X/Xn or Z/Zn.

But they affected the forward computation; how can they not affect the reverse?

Was Fairchild wrong?

I don't think so. I don't have the CIE documents which define CIELab — but Wyszecki and Stiles are quite explicit: if the value of X/Xn is less than that cutoff, use the linear form of f, rather than the cube root, to compute f(X/Xn); and if the value of Z/Zn is less than that cutoff, use the linear form of f, rather than the cube root, to compute f(Z/Zn). And ditto for Y/Yn, of course.

That's what Fairchild wrote, in different language.

Kang's inversion is correct if all three of X/Xn, Y/Yn, and Z/Zn are on the same side of the cutoff – that is, if the same form of f was used for all three ratios. But the definition of CIELab  – as far as I can tell from secondary sources – can require us to use the cube root three times, twice, once, or not at all – so Kang's inversion works if we used the cube root three times or never, but it must fail to invert correctly if we used the cube root only once or twice.

Here's an example. The first line is a set of XYZ… the second line is X/Xn, Y/Yn, Z/Zn, and we see that X/Xn is less than .008… the third line converts to CIELab and drops the last two answers (hue and chroma)… the fourth line converts the Lab coordinates back to XYZ – incorrectly: X/Xn is not right.

We did not recover the original X, which used the linear function instead of the cube root: we got .54 instead of .5 . We recovered Y and Z just fine, because the forward calculation used the cube roots for both of them — so we see that the inversion used the cube on all three, rather than just on two.

What to do? I was simply going to use the inversion, but check it. If I found that I needed to fix it up, I would.

But it turns out that the specification is almost trivial to invert correctly. Let's look at f(x), for extremely small values for x.

Here's the function from the XYZ to CIELab code… and evaluate it at the break point (6/29)^3:

That value of f should not be surprising: we're taking the cube root of (6/29)^3. Here's a picture, with the two pieces in different colors.

Oh, if you've never seen the "With" command, here's a nice example of what it does for us: the value "a" occurs in the code 5 times, but I only had to write (6/29)^3 once. In this case, I was just saving myself having to repeat – and possibly mess up – 5 identical constants. Another excellent use is for parametrizing some aspect of a plot, say something that is drawn from -a to a, when you're not sure what would be a good value of a.

Perhaps I should also remind you that I am using Dave Park's Presentations package: "Draw" a function rather than "Plot" a function; it makes it very easy to combine things.

That f(x) is defined piecewise is not a problem: we simply invert the two pieces of the function separately. if f(x) = y < 6/29, we invert the linear portion; otherwise, we invert the cube root.

Oh, I'm jumping ahead. Let's see why we only need the inverse of f.

The equation for L is

so

and then we apply to both sides,

,

which gave us Y/Yn on the LHS.

Finally,

.

The reason will suffice is that this first equation only involved one term in f.

Similarly,

but we have f(Y/Yn) from the equation for L, so we can eliminate it (this is crucial):

.

Now apply and get

.

Getting Z/Zn and then Z is just like getting X/Xn; the third equation inverts as

.

Now we just need to work out .

To invert the cube root is trivial: cube the argument. To invert the linear portion…

That is equivalent to what the wiki article has, namely

Here's my code for the inversion. I should add two optional parameters, so I can apply the code to a list that includes hue and chroma, but I'm not going to yet.

Let's run the inversion on the computed Lab values.

Are those the XYZ tristimulus values we started with? Let's compute the differences between those and the original XYZ values:

I see a lot of very small numbers… are they all small?

Yes.

So. I am comfortable with displaying color combinations from books, specified in CMYK. Unfortunately, we learned that while Mathematica can draw a CMYK spec correctly on my monitor, it cannot tell me what the RGB is… I have to measure the RGB. Many of my books also specify an RGB as well as CMYK, but I don't trust their translation; I prefer to let Mathematica use my monitor profile to get RGB for my device.

Once I have the RGB, I can convert to HSB using my code – which was written to confirm that I understood the algorithm – or I can let Mathematica do it. I am comfortable with HSB for choosing colors on my computer.

Now I've added CIELab to the mix. It moves between XYZ tristimulus values and Lab. I can always measure the tristimulus values – I did that for my artists' color wheel.

But it would be nice if I could move between RGB and XYZ. And I used to be able to do that. As I said in a recent diary post, my monitor profile has been changed… I have a copy of the original, and I can see the changes. I found them, of course, when I discovered that my current measured tristimulus XYZ do not agree with my old ones.

No problem. I know what the changes are and I can write new transformations to move between RGB and XYZ – and that in turn will let me move between RGB and CIELab, and between HSB and CIELab.