Display P3-v4 has different whitepoint and chromatic adaptation matrix than Apple Display P3 profile

[bartzy]

Hi!

Thanks for this extremely helpful repository.

I'm trying to understand the reason for differences in values between Display P3-v4 in this repo, and the official "Display P3" ICC profile shipped with macOS by Apple (from 2017).

The WP changes:

The chromatic matrix changes:

Is this on purpose and Apple's profile is wrong in some way?

Thanks again!

[saucecontrol]

Yeah, Apple's profile is wrong there. I'm not sure I had noticed that before. The V4 profile spec says that all profiles should have a D50 media whitepoint, and the chromatic adaptation matrix should give the translation from the actual color space whitepoint to the media whitepoint listed in the profile. See slides 9-10 in this presentation for a summary if you don't want to read the spec itself: https://www.color.org/events/toronto/10-Differences_between_ICC_profile_versions.pdf

Apple has listed the D65 whitepoint in both the 2015 and 2017 versions of their profile. The chad tag is close enough that it appears it was meant to translate from D65 to D50, but they may not have used the Bradford translation matrix as defined by the spec, or they may just have some rounding errors along the way.

In reality, the media whitepoint is only supposed to be used for absolute colorimetric translation, which is not actually a supported use for RGB profiles, plus many CMSs ignore the media whitepoint because it is so frequently wrong. Consequently, it's very unlikely there would be any functional difference between my profile and Apple's.

[bartzy]

Thank you for the detailed information.

I'm not sure I completely understand, but you mean that there's very little functional difference between the profiles because CMSs actually use the chromatic adaptation matrix and not the media whitepoint anyway? Isn't the chromatic adaptation matrix different between the profiles as well though? Realistically if I'm targeting iOS only device, should I just use Apple's profile even if it's wrong?

On another note and a bit unrelated - I'm trying to understand how to best configure ffmpeg and x265 to encode a video with Display P3, and I'm having a bit of trouble understanding what are the different flags I should use. Right now I'm using: -pix_fmt yuv420p10le -colorspace bt2020nc -color_trc bt2020-10 -color_primaries smpte432 -x265-params "colorprim=smpte432:transfer=bt2020-10:colormatrix=bt2020nc:master-display=""G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"" But I'm pretty sure it's wrong. If this is completely unrelated to this repo, feel free to ignore it :)

Thanks!

[saucecontrol]

Right, the wtpt will be ignored and will be calculated from the chad by most software if it needs to perform an absolute colorimetric mapping, but even that will never actually happen as it's not a valid use for a display profile. For display purposes, the primary colorants and curve are all that matter, so you can feel safe in using the two profiles interchangeably.

I'm not yet familiar with x265's color settings, so I'm afraid you're on your own there ;)

[bartzy]

Right, the wtpt will be ignored and will be calculated from the chad by most software if it needs to perform an absolute colorimetric mapping, but even that will never actually happen as it's not a valid use for a display profile. For display purposes, the primary colorants and curve are all that matter, so you can feel safe in using the two profiles interchangeably.

Why is that? When is the wtpt needed then, and how come it’s not needed for display purposes?

[saucecontrol]

wtpt (media whitepoint) is only used for absolute colorimetric intents, like converting colors between a profile meant for printing on yellow paper to a profile meant for printing on white paper. Since "white" on yellow paper is actually yellow, it's important to state that. This value is independent from the reference white light, which would be shining on the yellow paper, still yielding a yellow "white", if that makes sense.

With display profiles, the actual whitepoint is simply the sum of the primary colorants -- all colors at their full intensity create white light. Since ICC profiles are always referenced by the standard D50 profile illuminant, the primary colors will always add up to D50 white. The Apple profile does get that part right -- they use profile illuminant D50, and their primary colorant values are correctly converted to D50, which is why they match mine.

[bartzy]

I see. So what's the point in stating the Apple chose D65 for Display P3 and not DCI-P3 white illuminant? What purposes does it serve? If all the primary colors add up to D50 white, where D65 in P3 is being "used"?

Thanks!

[saucecontrol]

D65 is the reference whitepoint of the Display P3 color space, so its colors are all officially defined in terms of D65. This is simply a design choice, which Apple likely made to keep Display P3 similar to sRGB and because D65 (~6500K) represents typical color temperature for full-intensity white on computer and device displays.

Because converting between color spaces that have different whitepoints is complicated and error-prone (there actually is no exact conversion), ICC profiles attempt to eliminate that complication by requiring that all color profiles be expressed in terms of the same (D50) whitepoint. This means that when making a profile for a color space that is not based on D50, the primary colorant values must be chromatically adapted to D50 before encoding them in the profile. It also means that when converting colors between profiles, the whitepoint can be assumed to always be the same, meaning the conversion implementation can be as simple as a single 3x3 matrix multiplication.

The chromatic adaptation matrix from D65 to D50 is actually what's captured in the chad tag in the profile, although it's not used for display profiles because the colors have already been adapted. The only valid use of the chad tag would be to reverse the profile's colorant values from their profile-referenced values back to their original values relative to their original whitepoint, which is unnecessary given the target profile will also be expressed relative to ICC D50.

Having said that, I now remember why my chad value is very slightly different from Apple's. The D50 reference white encoded in ICC profiles is an imprecise value, due to limitations in the profile format. In other words, ICC D50 is very slightly different from true D50 calculated from its defined x,y value. My chad tag represents the Bradford adaptation matrix from D65 to ICC D50 rather than the matrix from D65 to true D50, which is what Apple's profile includes. If, for some reason, someone used the chad tag to restore the profile's colors back to D65, my version of the matrix will give a very slightly better result than Apple's.

An interesting quirk of V4 ICC profiles is that the chad matrix is stored in higher precision than the colorant (rXYZ, etc) values. It turns out that when doing the forward conversion from D65 to D50, once the colorant values are rounded/quantized to their profile format, it doesn't matter which D50 you use -- the encoded values end up the same. This is not true for all color spaces, but it is for Display P3, which is how my profile and Apple's ended up with the same primaries despite using slightly different chromatic adaptation matrices.

So in summary, Apple's wtpt tag is wrong according to the ICC spec, but their chad value is fine although not as good as mine if it were ever used by anyone, which it probably won't be.

[bartzy]

Thank you for the the detailed explanation! Many things just clicked for me after reading this a couple of times.