Yes, the above example images could be generated by just not doing Chromatic Adaptation while changing illuminant.
Made a quick Colab notebook to poke at Argyll a bit, got the same values on all the tests I did: Google Colab
Cheers,
Thomas
Yes, the above example images could be generated by just not doing Chromatic Adaptation while changing illuminant.
Made a quick Colab notebook to poke at Argyll a bit, got the same values on all the tests I did: Google Colab
Cheers,
Thomas
Before I read the rest of your post, I want to clarify some terminology:
Let’s say you chromatically adapt the sRGB color space with its D65 white point, to D50, to make a new color space which is the sRGB ICC profile. Now you have two different color spaces.
If you plot the XYZ values for the red, green, and blue primaries for each of these two color spaces on the xy chromaticity plane, you get two different triangeles, largely overlapping, but around the edges there are xy colors in each color space that aren’t in the other color space.
If you plot the volume for each color space in XYZ space, both have the same black point, X=Y=Z=0, but they have different gray axes and different white points. Again, there are colors in each color space that aren’t in the other color space.
Now please note these points because they are important:
Chromatic adaptation is not gamut mapping.
No colors get squished or clipped or gamut mapped when the sRGB color space is chromatically adapted from D65 to D50 to make the sRGB ICC profile color space.
When chromatically adapting all the colors in the sRGB color space with its D65 white point, from D65 to D50, no color is lost or squished or mushed or nudged or any such thing. Every single color in the original sRGB color space gets chromatically adapted to a new color. Except black of course.
You can call the process of chromatically adapting colors from D65 to D50 “mapping” if it makes you happy, because indeed it is a type of mathematical mapping. But it’s not “gamut mapping”. It’s chromatic adaptation.
Asking xicclu to give you the conversion from the sRGB.icm ICC profile color space to XYZ using absolute colorimetric intent is not gamut mapping. It’s chromatic adaptation. Nothing is clipped or nudged to make the resulting color fit inside the (infinitely large) XYZ color space. It’s not gamut mapping at all. It’s just chromatic adaptation.
In light of the above comments, this statement needs to be rewritten to avoid collapsing concepts that really do need to be kept separate:
It will only cause confusion to talk about “nudging” or “gamut mapping” when you are really talking about chromatic adaptation.
It’s not clear from the above quote whether “sRGB Blue” is the blue XYZ value for the original sRGB color space with its D65 white point, or the blue XYZ value that’s in the sRGB ICC profile, that’s been chromatically adapted from D65 to D50. Though given the person who’s making the statement, I’m guessing you mean "sRGB blue in the sRGB color space and not the sRGB ICC profile color space.
“push it out of gamut” requires specifying “which gamut is it pushed out of”. There is the infinite XYZ color gamut, the color gamut of the sRGB color space, and the color gamut of the sRGB ICC profile.
In a very real sense it doesn’t make any sense at all to talk about “pushed out of gamut” as a result of a chromatic adaptation of an entire set of colors from one white point to another white point, because you haven’t “lost” any colors doing the chromatic adaptation. You’ve chromatically adapted all of them.
It will take me some time to work through the rest of your post.
Yes, there are speadsheet functions for doing min, max, median, etc. But I wasn’t referring to doing min or max or median operators available in any spreadsheet application.
I used a spreadsheet to do a chromatic adapation from D65 to D50.
Min, max, median etc are not operations that are used when doing chromatic adaptations from one white point to another white point.
You can download my spreadsheet and check for yourself if you aren’t sure whether I might have somehow “nudged” something by using min, max, median etc in the process of doing the chromatic adaptation:
https://ninedegreesbelow.com/files/spreadsheets/sRGB_specifications_to_ICC_profile.ods
Gamut mapping is not chromatic adaptation, and trying to conflate the two terms into one will only lead to confusion. Yes, chromatic adaptation can also be done in the course of an ICC profile conversion from one color space to another (for example to a printer profile with LUTs) and that might result in additional colors being out of gamut and clipped. But it’s important to keep the “chromatic adaptation” part separate from the “gamut mapping” part when you talk about color space conversions:
“Gamut mapping” refers to how one deals with colors that are in gamut with respect to one color space and out of gamut with respect to another color space, when the goal is to convert the colors from the first space to the second space.
“Chromatic adaptation” refers to chromatically adapting colors from one white point to another white point.
These are two very different concepts accomplished in very different ways for very differnt purposes.
Yes, there are colors in the sRGB D65 color space that are out of gamut with respect to the sRGB ICC profile that’s made by chromatically adapting from D65 to D50 and vice versa. But no colors are clipped, minned, maxed, or medianed in the process of doing the chromatic adaptation. One might say they are “nudged” but that doesn’t say much about the type of nudging, in fact “nudged” totally buries the difference between gamut mapping and chromatic adaptation.
Thank you for the detailed explanations, they did help. I still don’t understand the possible benefit of adapting to D50 when talking about the appearance of colors on a computer. It wasn’t clear from the start that the LCh and JCh values you were using were D50 adapted. When discussing appearance, why would it be important to know the JCh values of a color after it has been adapted to D50 versus the native D65?
I think it is because ICC uses D50, so to get back to your screen, the adaptation must go in reverse. I supposed that might be too simplistic an explanation. I am not as deep into colour as you all are.
Actually if you check you’ll see that I gave you both “adapted to D50” (relative, “-ir”) and “using D65” (absolute, “-ia”). I tried to indicate every step of the way which I was using, but I guess I didn’t try hard enough
Hmm, see these two posts over from another thread:
Also see this article, in particular sections A3 and A4:
sRGB luminance: technology, standards, and color science which talks about “why D50”.
and this article, section D1:
Programmer's Guide to XYZ, RGB which has what I hope is an easy to understand “imagine this” that demonstrates what “adapting to the color of the light” actually means.
There is a common thread running through all of this, which is “What color of light are your eyes actually adapted to?”
In ICC profile color management, the assumption is not that your eyes are adapted to D50. The assumption is that your eyes are adapted to the color of white on your monitor in its current state of calibration.
ICC profile color management does indeed send “D50” values from the image to the monitor profile. The monitor profile in turn sends RGB values to the screen that are appropriate to your monitor’s actual state of calibration, if indeed you are using an appropriate monitor ICC profile that actually describes your monitor’s display characteristics in its current state of calibration.
@briend and @KelSolaar - Hopefully tomorrow I’ll have time to go through all of your calculations, which look really interesting. I’d very much like to add colour-science to my current list of “tools for exploring color spaces” and the provided examples are helping quite a lot.
I understand perfectly the difference and I’m not trying to conflate the two terms together.
I was merely referring to the fact that you can do gamut mapping in a spreadsheet, and might have to do if you are doing colourspace conversions.
Same than above, thanks!
I’m border going nuclear here, seriously
Glad to see we are getting somewhere here!
I think you mis-quoted me out of context, if you re-read my sentence correctly the first word is Clipping, nothing more, nothing less.
Now to make things clear, the only thing I wanted to understand was what conversion path Argyll is taking under the Relative Colorimetric Intent, which I managed to find out as per my Colab Notebook.
Is there a reason for the obsession with ICC D50?
D50 is protocol driven in the ICC PCS system. Everyone understands that under the ICC system, some white point was chosen as the anchor reference. This doesn’t mean there is some magical element to D50. Most displays these days are pretty damn good at delivering proper D65 sRGB / REC.709 primaries and achromatic value.
So again, why the obsession with D50 other than the fact that some CMS system (ICC in this case) chose to rally around it as their reference space “glue” colour? The colours you would be staring at on a decent display in 2018 would be D65 under a V2 system.
It’s a protocol question under the hood. V4 notwithstanding with their awful decisions…
using the code that @KelSolaar posted, both of these (coincidentally) resolve sRGB blue to LCh hue 301:
LChab_D65 = Lab_to_LCHab(XYZ_to_Lab(XYZ_D65, D50))
LChab_D50 = Lab_to_LCHab(XYZ_to_Lab(XYZ_D50, D50))
print(LChab_D65)
[32.302587 148.413874 301.622547]
print(LChab_D50)
[28.459261 135.117122 301.838168]
So, does that mean that xicclu is in fact assuming my eyes are adapted to D50? Whereas with D65 the hue angle is ~306
Here’s an attempt to do reflectance recovery and mixing and compare to normal RGB mixing, so we might consider how blue and yellow might create green, which is the background topic of this entire thread
https://gist.github.com/briend/194cd595201f581d6acb2e9280c70fe3
The four gradients are: spectral weighted geometric mean, spectral arithmetic mean, normal RGB weighted geometric mean, and normal RGB arithmetic mean.
I think the top two bars looks so odd because the reflectances have many values > 1.0, and also probably because I’m not normalizing the illuminant properly. I would like to tweak the Meng recovery method to constrain to 1.0 as an option, and also allow illuminants besides E. I got a worse result if I adapted my target colors to E before generating the curves for some reason, so you can tell I can’t even reach my original target yellow and blue…
As an example, here’s the gradients I get using Scott Burns’ recovery method, which I much prefer even though @anon11264400 says it’s a horrible hack ;-). The first row is a weighted geometric mean, and the next two blend in increasing amounts of the results of a plain multiply operation. I don’t know if that’s coherent but I was trying to mimic a glazing or layering effect.
I don’t understand why you “border going nuclear”. This is a discussion via a forum. I can’t see your face, I can’t stop you in mid sentence and ask you what you really mean. All I can do is try to interpret what you are saying and answer as best i can.
Please look at your post #23 above:
And then at your post #41 above
I’m not the one who brought the term “gamut mapping” into this conversation. I have only been talking about using xicclu to convert from the ArgyllCMS sRGB.icm ICC profile to XYZ. In this conversion there is no “gamut mapping” as is discussed in your provided link in your post #41. There is only a conversion from sRGB.icm to XYZ, either using relative colorimetric intent in which case you get XYZ values for sRGB adapted from D65 to D50, or else using absolute colorimetric intent, in which case you get the XYZ values that you’d get if there hadn’t been a chromatic adaptation from D65 to D50.
Then I referred to using a spreadsheet to do a chromatic adaptation (What are the LCh and JCh values for the sRGB blue primary? - #43 by Elle) and again you brouht up “gamut mapping”:
So my apologies for upsetting you, that wasn’t my intent. But when one person is talking about a chromatic adaptation and and another person repeatedly brings gamut mapping into the conversation, well, it seems like a good time to very carefully lay out the differences between gamut mapping and chromatic adaptation.
Of course you are absolutely correct to say that clipping when using a colorimetric intent to convert from one ICC profile to another, if the converted color falls outside the color gamut of the destination ICC profile, is indeed a form of gamut mapping. But that’s not what happens when using xicclu to convert from sRGB.icm to XYZ. I’m sure you understand all this, and I’m still very confused as to how gamut mapping got dragged into the discussion in the first place.
Unless maybe you were speculating that perhaps for some reason ArgyllCMS was doing some totally unnecessary rearrangement of the XYZ values? As per your following statement?
In which case my apologies for not figuring out why you were talking about gamut mapping. It would never in a million years cross my mind to wonder whether xicclu conversions were somehow tossing in totally pointless “gamut mappings” to distort results from plain and simple chromatic adaptation when asking for relative vs absolute colorimetric intent when doing a conversion from sRGB.icm to XYZ.
I think I stated clearly that I did not know what Argyll was doing under the hood and thus that gamut mapping could be a cause for the discrepancies between Argyll and Colour.
Why? Well…
You should not assume that everybody has the same knowledge about ICC than you. As an example, I did not assume you know about Python or Colour.
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:
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
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?