Its slightly different for measurement of self-luminous sources (e.g. a display) vs. reflective samples (e.g. a print). For the display, the SPD is whatever light comes out of the screen*, there is no separate illuminant involved. For the reflective print, the SPD is the product of the reflectance spectrum of the print and the illuminant (D65, D50 etc.).
*ignoring any ambient light reflected from the surface of the display, which you usually try to minimise.
The notion of a “common ground” intermediary is replete through resilient architectures. Network byte order, for instance, helps to keep the endians straight between computers without everyone maintaining a big table of architectures’ endians.
XYZ/D50 forms that common ground in ICC profile-based color management. Cameras don’t have to know about display characteristics including white point, and vice versa. And, more fundamentally, you need both primaries and a white point to transform color image data from one color space to another.
Network byte order
Since at least the 80s computers used little endian instead, why is big endian still being used in standards…
Take that question to a networking forum. I was using network order as an example of a “connection space”, where the endpoints didn’t need to know each other’s specifics. That’s what XYZ/D50 is to ICC profile-based color management. And again, you do need both primaries and a white point to do the transform math.
Thanks all for the patient explanations by the way!
Recently, I’ve been messing with baking white balance into my camera profiles. By way of background, most tutorials about making camera profiles tells you to shoot the target, then develop it to a TIFF including white balance correction. Based on recent discussions here, I decided to try making target TIFFs without white balance correction, and let the conversion from camera space to a working space like Rec2020 also handle the chromatic adaptation from camera white to the working profile’s white point. For grins, here’s the XYZ media white point of such a camera profile:
[ICC_Profile] Media White Point : 4.89584 5.11565 4.00757
The color management library I’m using in my programs, LittleCMS, does the chromatic adaptation from that wild triplet to the destination’s white point, then it does the color transform. Sounds weird, but it does work.
Thing is, XZY/D50 as the intermediary keeps me from having to develop a different camera profile for every destination space. Not so bad for going to a working profile, but displays and printers all have their particular white points, so some common ground color space and white point is needed to keep from having to maintain a rat’s nest of device->device transforms.
It didn’t have to be D50; they could have picked D65, or some other triplet. The key point is, they picked one, and all parties know what it is…
FSVO computers. I spend my working day on current big endian computers. And many computers are now “bi-endian”. But as Glenn said, that’s just an aside, not the topic at hand.
Here are my 2cts, after having spent quite some time trying to understand the role of D50 in ICC profiles and applying the math to see if I got the concepts right.
I think that one of the main points is that one should not look at the intermediate XYZ values in an RGB -> RGB ICC conversion. Independently from ICC profiles, a conversion between two matrix-based colorspaces (i.e. defined by some primaries, like sRGB, AdobeRGB, Rec.2020, etc…) processes in the following way:
RGBin -> XYZ(WPin) using the source colorspace primaries, therefore giving XYZ values relative to the WP of the source colorspace (for ex. D65 in the sRGB case)
chromatic adaptation from source to destination WP. If the Bradford method is used, this bold down to multiplying a 3x3 matrix that I will call WPin_to_WPout
XYZ(WPout) -> RGBout using the primaries of the destination colorspace
More schematically:
XYZ(WPin) = RGBin_to_XYZ * RGBin
XYZ(WPout) = WPin_to_WPout * XYZ(WPin)
RGBout = XYZ_to_RGBout * XYZ(WPout)
Since the Bradford chromatic adaptation is a linear operation, an arbitrary number of intermediate adaptations can be inserted without changing the result (apart maybe from numerical precision considerations). Therefore, the above is equivalent to
XYZ(WPin) = RGBin_to_XYZ * RGBin
XYZ(D50) = WPin_to_D50 * XYZ(WPin)
XYZ(WPout) = D50_to_WPout * XYZ(D50)
RGBout = XYZ_to_RGBout * XYZ(WPout)
This is what an ICC conversion actually does. However, instead of explicitly doing the chromatic adaptations at each conversion, the ICC profiles store the pre-calculated D50-adapted primaries.
This becomes more clear if we re-write the above like this:
XYZ(D50) = WPin_to_D50 * RGBin_to_XYZ * RGBin
RGBout = XYZ_to_RGBout * D50_to_WPout * XYZ(D50)
The two matrix products WPin_to_D50 * RGBin_to_XYZ and XYZ_to_RGBout * D50_to_WPout are pre-computed when the ICC profile is generated, thus providing the D50-adapted primaries that are stored in the ICC profile instead of the original primaries found in the colorspace definition.
To be more precise, the ICC profile stores WPout_to_D50 * RGBin_to_XYZ for the destination profile, and the resulting matrix is then inverted to provide the XYZ->RGB conversion…
Why D50? So far I could not grab wether the choice of D50 is totally arbitrary or if it has some practical consequences. Someone told me that it has to do with the fact that D50 is the reference illuminant when viewing printed images, and that ICCs where originally developed for the print industry, but I still don’t know if replacing D50 with dome other reference illuminant would change anything…
One practical consequence is that the luminance Y that one computes from the ICC primaries is relative to D50, and so rather far from daylight conditions. I have the idea that for the B&W conversion of a daylight scene one would rather prefer to use the D65-adapted luminance, but I do not have strong arguments to support my intuition…
Hope this helps!
iccMAX is coming soon.
The specification is currently at Final Draft International Standard stage, and is being balloted by ISO TC130 member bodies. If passed, it is expected that it will be published as ISO 20677 in 2019.
What is iccMAX?
iccMAX is a new color management system that goes beyond D50 colorimetry. This new specification has been approved by the ICC Steering Committee.
iccMAX profiles show v5 in the header to distinguish them from v4 and v2. iccMAX profiles also have class, sub-class, versioning and header information that differs from v4.
Users and developers are encouraged to make comments on the specification.
Profile Connection Space
The ICC v4 PCS has fixed D50 colorimetry, considered necessary until now to ensure interoperability and prevent ambiguity in colour transforms. iccMAX allows flexibility in the selection of illuminant and color matching functions. It supports spectral communication of colour information through an optional spectral PCS, and also supports the use of color appearance processing in the PCS, with the facility to store appearance attributes in a v5 profile.
I think the choice of D50 for XYZ has no mathematical consequence, unless we care about XYZ values.
When converting from one linear RGB colorspace to another linear RGB colorspace, every pixel might be multiplied by each matrix in turn. But for performance, the CMS will multiply the matrices together, resulting in a single 3x3 matrix, and that is used to multiply each pixel.
A chromatic adaptation matrix (CAM)depends on the two white points and the CAT (Bradford or whatever). It doesn’t depend on the primaries. So a CAM from D65 to D50 is the mathematical inverse of the CAM from D50 to D65 (provided the same CAT was used).
Chromatic adapatation from WP1 to a different WP2 and then to a third WP3 is mathematically the same transformation as from WP1 directly to WP3.
This provided that the transform is linear (like the 3x3 Bradford matrices). I have no idea if more sophisticated CATs exist that are not linear…
True, I was assuming the CAT is linear. Non-linear CATs do exist, eg CIECAT94. I know nothing about those.