What are the LCh and JCh values for the sRGB blue primary?

D50 is the graphics arts standard measurement conditions.

ICC adopted it for their PCS (Profile Connection Space) because the most common workflows assume complete observer adaption to white. i.e. Almost all the time people use Relative Colorimetric, Perceptual or Saturation intents. Absolute Colorimetric intent is typically only uses in special situations, such as side by side proofing, or soft proofing.

I fully get that. ICCs were largely designed around display referred print graphic work.

With that said, having D50 in the reference doesn’t imply that the input and output achromatic points are D50, hence my original comment; it is obessive to conflate the idea that the reference white being D50 means every single instance of white needs to be considered around D50. Doubly so when discussing modern perceptually uniform colour model implementations, many of which use D65.

Lab I believe was canonized around Illuminant C if I am not mistaken.

It just seems that too much of the discussion returns to D50.

The point is that ICC device profiles data formats have to be created in such a way that they do a chromatic transformation between a devices native white point and the PCS white point (D50). So if you naively “ask” and ICC profile about a device response, you get D50 relative information. You have to ask for Absolute Colorimetric to have a chance of getting the measurement values for a device from an ICC.

And this can get complicated because the ICC has stuffed up the support of retrieving measurement values from an ICC profile. Standard CMM’s only have Absolute Colorimetric intent, which (if you implement it strictly according to the ICC spec.) only undoes the ICC device white point transform using a “wrong” Von Kries chromatic transform. But the strict ICC white point isn’t the one you might measure.

In the case of prints, you are meant to use a D50 illumination source, and for typical white paper, the white point is then not likely to be far from the illuminant. But if you happen to measure using an instrument that (say) uses a D65 illuminant, you are meant to chromatically transform the measurements into the equivalent D50 illumiunant values, stuff that transform in the ‘chad’ tag and then treat it all like it was measured with D50. That means that if you select Absolute Colormetric intent with that profile, you won’t see a white value near D65, because the CMM ignores the ‘chad’ tag, and gives you D50 transformed “absolute” values.

In the case of display profiles, the V4 approach is very similar to what I described above for print - if the display native white point was D65 say, then transform to D50 using a chromatic transform matrix, and stuff that into the ‘chad’ tag. Absolute Colorimetric will then not give you measurement values. For V2 profiles, different vendors took different approaches. Some assumed that the V4 approach is pretty nonsensical (I agree), and instead used a true Chromatic transform for the ICC White to D50, and things like the original sRGB and AdobeRGB profiles are built that way. But if the CMM uses the ICC spec “wrong” Von Kries to undo the true Chromatic transform, you get slight errors. etc.

So getting measurement values out of an ICC profile can be unreliable - you really need to understand how the profile was built, and how the CMM works.

For more background info see this.

Well versed on the stupidity of ICCs and their dreadful implementation problems.

Given the subject line though, I find the whole discussion about D50 to be a tad myopic and ends up drawing the discussion inevitably back to ICCs as though it were the singular definition of colour and colour management. It most certainly has led to the discrepancies seen in the subject of this thread.

There are numbers and there is “what does it look like on the computer screen”.

Regarding numbers, I was giving you numbers generated from ArgyllCMS xicclu, usually using absolute colorimetric intent to convert from sRGB.icm to XYZ and also to LCh. I was assuming that because the xicclu XYZ values matched D65 values when asking for absolute colorimetric intent, so would the LCh values. But this isn’t actually the case.

I did finally figure out the discrepancy in the xicclu LCh numbers for sRGB.icm’s color (0,0,1) vs Lindbloom/colour/etc. I set up a spreadsheet to do the conversions from unadapted sRGB blue to XYZ and then to LCh with the D65 reference white point. These spreadsheet values match your original colour LCh values and also Lindbloom’s LCh values, with very small discrepancies from using ASTM vs the actual D65 value used in the sRGB spec.

But my spreadsheet values don’t match ArgyllCMS xicclu values unless I change the reference white for the conversion to LCh from D65 to D50. So ArgyllCMS is still using the D50 reference white for the conversion from XYZ to LAB, even when you ask for absolute colorimetric intent. With my spreadsheet I can replicate Lindbloom values for D65 vs D50 reference white, and also ArgyllCMS values for using relative vs absolute colorimetric intent.

My apologies for taking soooo long to just sit down and write the equations into a spreadsheet, and double apologies for taking so long to figure out that xicclu might be using D50 for the conversion to Lab/LCh even when asking for absolute colorimetric intent.

Regarding “what does it look like on your monitor screen”, of course that depends on your monitor and its state of calibration and the resulting monitor color gamut.

It also depends on whether you are using a color-managed editing application. And if you are using a color-managed editing application, of course it depends on whether your monitor profile accurately reflects your monitor’s display characteristics.

Here is a screenshot showing the hugely different “colors of sRGB blue” as displayed in GIMP-2.10 on my monitor, using and not using color management, which for GIMP is ICC profile color management:


In both cases (using and not using color management) the darker surrounding colors are sRGB blue (0.0, 0.0, 1.0). The squares in the middle are sRGB blue with the chroma lowered enough to bring the resulting color into the color gamut of my monitor profile (using LCMS soft proofing to figure out how much to lower the Chroma - my monitor’s calibrated and profiled color gamut is quite weak in colors down near sRGB blue).

To me the “Color management disabled” colors on the right look considerably “more blue, less purple” than the “Color mangement enabled” colors on the left.

@briend - if you have GIMP-2.10 installed on your computer, it might be worthwhile looking to see how much different “sRGB blue” looks in GIMP when enabling and not enabling color management, and see if either case matches what you see in MyPaint, viewing on the same monitor of course.

Generally speaking, just because someone’s monitor is calibrated to D65 and has a color gamut that covers all or nearly all of sRGB, doesn’t mean that the displayed colors are accurate when not using color management. The white point and gray axis are only part of the equation. The monitor’s actual color gamut as calibrated and profiled also is important.

Sorry, I’m not familiar with any dreadful implementation problems.

If you want to use ICC profiles and ICC based systems as a means of obtaining device color response information (presumably because it is the most widely adopted color profiling system), then you are going to have to deal with the D50 white point. This is simply due to it being the reference white for the Profile Connection Space. Of course the PCS white point is not visible in a device space to device space conversion, since you do not see the PCS. But if you are looking to ICC profiles as a convenient way of capturing or obtaining the device independent behavior of a device, then you need to interpret the PCS correctly, and that means understand the role D50 plays in its definition.

That would be because the L*a*b* in question is PCS L*a*b*, which by definition has a D50 white point. (After all, it’s an ICC profile lookup tool, not a general purpose color transformation tool.)

Yes, having finally figure out what’s going on it makes perfect sense that xicclu uses D50 for the conversion to Lab - sometimes I just have to parse things out in a spreadsheet before I can put two and two together and actually get four :slight_smile:

So two mysteries solved - why xicclu LCh using absolute colorimetric didn’t match colour LCh, and also (see comment 28 above) why xicclu JCh doesn’t match colour JCh.

I don’t know what equations colour is using, but as @gwgill explained in comment 28 above, xicclu JCh has been tweaked to avoid certain deficiencies in CIECAM02. Which seriously dampens my enthusiasm for the idea of trying to figure out how to incorporate JCh into GIMP code.

Given the issues @gwgill mentions in the code notes for his JCh calculations, I wonder about the actual usefulness of plotting paint pigments on a CIECAM02 color wheel, vs a CIELAB color wheel. MacEvoy’s wonderful watercolor website uses both color wheels, and my assumption has been that CIECAM02 is better, but maybe that depends on the specific use case.

I had never even heard about CIECAM16 until @briend brought it up. Is it / in what ways is it better than CIECAM02?

Colour implements the model as per the book along some tweaks suggested by Luo et Li (2013) to correct some deficiencies.

CIECAM16 does not really exist! What exists is CAM16 by Luo et al. which brings a simplified chromatic adaptation model compared to CIECAM02 and the fixes from Luo et Li (2013). It is pretty much the same otherwise. The CIE is working on updating CIECAM02 (under Ming Ronnier Luo direction if I’m correct) and CAM16 is a step in that direction.

1 Like

OK, what is the difference between a CAM and a CIECAM? Oh, wait, is it the status of having been adopted as a standard by the CIE?

Is there an online link (that doesn’t have a subscription/fee requirement) for reading about this CAM16?

Yes the CIE prefix is because it has been blessed / adopted as standard.

I can send you my copy if you want.

Yes, thanks! That would be much appreciated - I’m trying to acquire a better understanding of color appearance, CAMS, and such so I can try to keep up with all the stuff @briend keeps tossing my way :slight_smile: .

And sent!

Thomas - got it - thanks so much!

OK, the (or a) burning question that @briend and I have is “How close to violet is sRGB blue?” Is it so violet that it can only make very desaturated green when mixed with a color that’s close to sRGB yellow? Is it so far towards violet that it can’t make green at all? Is it far enough towards blue that it can make nice saturated greens? I mean if these colors were actual paint pigments, or in the case of sRGB blue, a pigment as close as possible to sRGB blue, and putting aside issues of metamerism whereby there’s no guarantee that “same color pigments” will make “same color” when mixed.

And speaking of sRGB yellow, how far from sRGB blue is sRGB yellow in terms of degrees, on the various LCh/JCh/CAM16/etc color wheels?

In the attached image I tried really hard (not for the first time) to get a nice gradient from an obviously violet oil pastel, to an obviously blue oil pastel. It seems there is a very fast transition between “too violet to make green when mixed with yellow” and "makes a nice green when mixed with yellow:

The hue values (the magenta numbers) are in LCh and they are adapted to D50 because I used an ICC profile color-managed editing application to make the screenshot of the photograph of the oil pastel mixing.

I suspect this is likely due to the weakness of Lab / Lch hue nonlinearity, and less about the absolute position. Rather well documented that Lab / Lch is weak on the hue linearity front, where significant skew happens for blues turning violet and reds turning yellow.

The mixture of blues with yellows to greens is more spectral composition, rather than the nature of tristimulus models, which by nature, won’t mix in an analogous fashion as compared to greater-than-three channel models.

Gimp 2.10 seems to behave quite a bit differently than Gimp 2.8 or Krita 3.1.1. Gimp 2.10 does seem to desaturate my R,G,B, and push blue towards violet. Whereas with Gimp 2.8 and Krita 3.1.1 it is somewhat hard to tell the difference between CM and none-CM on this particular monitor. (my 2nd monitor is ~Adobe RGB so it’s obviously totally noticeable there).

I think this is what MacEvoy was getting at when he said Yellow pigment has no real mixing complement. Either it will swing to green or swing to tan.

My screenshot shows LCh values because I’m using GIMP and that’s what I have available. But we’ve also used xicclu to get JCh values, colour to get JCh and CAM16 hue angles. None of these agree and the range of disagreement is rather large.

So yes there might be issues with LCh, in fact there most certainly are issues with LCh, and these issues are probably greatest right at the range of hues where sRGB blue might plausibly be.

But the question isn’t “Why is LCh inferior or wrong or whatever”.

The question is, out there in the real world, if there were a pigment with the same hue (on whatever color wheel), lower chroma (of course) and reasonably close lightness, would it mix with a pigment roughly similar to sRGB yellow to make green? Or is it too violet to reasonably be expected to make green?

I was sort of thinking the same thing. Or maybe I’m just terrible at blending oil pastels :slight_smile: . But I got the same result with crayons.

I’m not at all confident that CIECAM16 overcomes the basic problems of CIECAM02, because the maths is just too similar. Personally I think a completely different mathematical approach is needed, so that the response beyond the training set data behaves more reasonably, rather than going haywire.

[ I rather like “A Neurophysiology-Inspired Steady-State Color Appearance Model” by Timo Kunkel and Erik Reinhard as a place to start, since it is mathematically simpler, and yet fits the same training data used for CIECAM02 etc. very well. ]

But the question you need to ask, is why are you interested in CAM’s ?
If it is to be able to allow for different viewing condition effects, then you are on the right track. But if all you are after is a better perceptual space than L*a*b*, especially in terms of hue linearity, then perhaps a CAM is not the right thing to look for. Most people looking for a better hue linearity space look towards an IPT based space.

[ An example of such an L*a*b* replacement space that I’ve been experimenting with, is what I’ve called “Lpt”. See the ArgyllCMS source icc/icc.c icmXYZ2Lpt() etc. But it is worth looking at other IPT based spaces too. See Dolby ICtCp for instance. ]