I set out to do something very simple: let Mathematica do the transformations between RGB and XYZ. Since CIELab is defined in terms of XYZ, but my monitor (“Color LCD” on a MacBook) is RGB, I’d like to be able to convert between RGB and CIELab.

Well, I showed us how to convert between RGB and XYZ, in a previous post about the nonlinearity of my monitor.

Recall the purple disk that figured so prominently in that post. It was defined by:

and drawn by Mathematica® as:

Its original tristimulus values were

But now they are:

The percent differences are: .

Those are quite different. The smallest change is more than 16%! My monitor profile seems to have changed!

Let me say that I don’t particularly trust the new profile… I don’t know why it was changed, how often it was changed, when it will change next. I will probably have to make a habit of checking the profile after I install system updates. And just to be safe, I should probably check the XYZ values for that purple disk whenever I start playing with color.

The profile is now dated 6/24/11; but its immediate predecessor was dated earlier this year – which was still newer than the one I used for the previous measurements.

Anyway, it appears that I need to work out a new relationship between RGB and XYZ on this monitor.

Let me remark that the numbers listed for the “PCS Illuminant” are almost exactly what I measured for the white in the previous post. (Strictly speaking, divide w1 by 100.)

.

I think I know what the following does (and, yes, there are two additional identical graphs, presumably for green and blue)…

so let’s just code up their function f(x) with those parameters:

I’m a little unhappy with this function: it is not continuous at the break point. That is, the power term… evaluated at the point .0393, has the value

… while the linear term… evaluated at the point .0393, has the value

The values are not the same; the function is not continuous at .0393. I’m still mulling over whether this is a problem for inverting the function.

The function, however, does have one mandatory property: it maps 0 and 1 to 0 and 1. This means that the phosphors will not be affected by the nonlinear function. (That will make more sense very soon.)

Recall my artists’ color wheel and recall the measured RGB…

Here are the measured numbers, all in one long list (because I’m going to apply the nonlin function to each number):

Let me check the ColorSync computations. That is, I open the ColorSync Utility and I ask it to calculate tristimulus values (perceptual to perceptual) for each of the measured RGB values. Here are the answers:

Let’s compare those to the measured tristimuus values:

The two sets of numbers are pretty close. Here are the absolute errors…

… and here are the percent errors:

For the present, I’m OK with these measured and ColorSync numbers. (There’s nothing I can do about them, either.)

From the phosphor coordinates, we will need (and, once again, there are two additional identical graphs, labelled for green and blue):

… and I arrange those nine values in a 3×3 matrix M (and I define the transpose MT):

Now I’m going to do what I did before:

- apply the nonlinear function to the measured RGB
- arrange those as 3-element vectors
- apply M to each vector (actually, apply 100 times M)

The results are:

How close are they to either the measured or ColorSync-computed values? Here are the differences from the measured values, rounded to .001 .

Here are the % differences:

Hmm. Red is off by quite a bit.

But that’s silly. My pure red is supposed to match the XYZ coordinates of the red phosphor.

So, I measure red to have… divide by 100… and if I round it to 3 places, I get… and then I recall the first column of M (actually, the first row of M transpose).

which is what the profile showed. It appears that the profile should have more digits than it shows. I’m going to check green and blue, but I’m already sure that they problem is simply that the phosphor values have been rounded off too far. What I’m checking is that the measured XYZ for red, green, and blue do in fact round off to the values I used for M.

What about green? I take the measured XYZ… divide by 100… round to 3 places… and compare it to the second row of :

The same.

Blue?

Yes again. Let me define a new matrix M; call it M2. Actually, let me initialize its transpose, i.e. , and then redefine the transpose MT2 and then M2. M2 will be M with more digits.

Let’s try the new matrix M2 on the color wheel.

Here are the differences between the newly computed XYZ and the ColorSync computations:

Those are looking pretty good. You might note that precisely three rows are made up of three zeros. Guess what? Those are rows 1, 7, 9, i.e. red, green, and blue.

Here are the percent differences between the newly computed XYZ and the ColorSync computations:

Here are the differences between the newly computed XYZ and the measured XYZ:

And here are the percent differences between the newly computed XYZ and the measured XYZ:

OK, I think the more precise M2 will do just fine.

Here’s the module I wrote for RGB to XYZ.

It computes a vector (r,g,b) = ( f(R), f(G), f(B) ) from the input vector (R,G,B), and then it applies 100 M to (r,g,b). Yes, this local copy of M is actually M2.

becomes .

The nonlinear portion becomes

.

In place of (X,Y,Z) = 100 M (r,g,b), we will need

.

Thus I write

It inverts a local copy of M… applies it to the given (X,Y,Z) and divides by 100… then applies the inverse of the nonlin function to each r,g,b value… and returns (R,G,B).

Now I need to check the modules.

Start with measured RGB, and partition it now, because the modules take 3 values at a time:

use the newly defined module to get XYZ:

Compare those to the previous computations:

Call the inverse:

Did we recover what we started with?

Yes. So I have checked that the module RGBtoXYZ matches the original calculations, which in turn very nearly matched the ColorSync computations… and the inverse module XYZtoRGB recovers the original measured RGB.

One last thing. Let’s check the purple disk while we’re at it. That’s what started this whole thing!

Take the RGB… apply the module and get answers in line 2… and print the new measurements as line 3:

… so the newly computed XYZ are close to the newly measured XYZ.

So. I now have a pair of functions that will transform between RGB and XYZ on my monitor.

And the last post gave us functions that would transform between XYZ and CIELab… so now I can move between RGB on my monitor and CIELab.

And we have long been able to transform between HSB and RGB on my monitor, so I can now move between HSB and CIELab.

The one bad thing is that Mathematica cannot move between CMYK and RGB – as I keep saying, Mathematica draws the RGB given CMYK, just fine, but he can’t correctly describe the RGB coordinates of what he drew!

If I could bring myself to type in RGB coordinates of a color printed in a book, everything would be perfect… but I prefer to type in the CMYK coordinates of printed matter.

Still, we’ve come a long way.

Somewhere down the road I will look at CIECAM02, a true color appearance model… and I’ll probably look at hue in HSB and CIELab. (They’re not the same; worse, constant h in HSB is not constant h in CIELab. But HSB is still extraordinarily convenient for choosing colors on my monitor.)

February 6, 2012 at 5:08 pm

Can’t wait you write about CAM02