attention color whizes: non-typical sRGB/RGB/ProPhoto question

[digitaldog]

I must say I'm quite intrigued as to the outcome here. I'm no color scientist, far from it, but I'd like to know why, in the Apple Color Synch Utility, Adobe(1998) is depicted as entirely within ProPhotoRGB (as i'd expect) and yet if I view the same profiles in ColorThink 2.2 there is a clear difference, the Adobe(1998) blue primary is outside the ProPhotoRGB space. I don't have ColorThink V3Pro to compare with.

I think this post from the ColorSync list explains this and some of the misunderstandings below:

At 1:02 AM -0700 6/27/06, Marco Ugolini wrote:
When people refer to ProPhoto RGB as a wide-gamut space, one tends to think
that since it's purported to be "larger than AdobeRGB", it must *encompass*
it all the way around. That assumption is incorrect: there is a relatively
small but noticeable range of cyans and purples in AdobeRGB that falls
outside the gamut of ProPhoto RGB.

Marco, that's an artifact of some but not all 3D graphers. Adobe RGB is D65, ProPhoto is D50, and ColorThink, for example, shows some Adobe RGB (and even some sRGB) colors as being outside ProPhoto because the neutral axis is skewed.

In fact, ProPhoto does encompass Adobe RGB. I'm about to board a plane for foreign parts so I probably won't be able to discuss this at length, but check with reliable sources (Steve Upton, for example). I'm sure they'll tell you the same thing.

Bruce Fraser

[joofa]

Joofa, you keep trying to show that the color [0, 0, 1] in Adobe1998 clips in the ProPhoto space.

I, and others, and photoshop say it doesn't. I even showed you the math. In ProPhoto that color is [88 36 241]. It doesn't clip.

So a simple question: are we wrong?

Seriously, this issue is less complicated then it has been made out to be. Chromatic adaption is not even an issue here. You will see below.

Lets deal this issue in two stages:

(A) There is a color with XYZ=[0.188185   0.075274   0.991108]; is that representable in Adobe RGB (D65) and PropPhoto RGB (D50)?. By representable we shall mean if the tristimuls values required to match these colors are in [0,1] range.

Both matrices from Bruce Lindbloom's website below:

Adobe RGB (D65):
===========


0.5767309  0.1855540  0.1881852
0.2973769  0.6273491  0.0752741 * [0,0,1]' = [0.188185   0.075274   0.991108];
0.0270343  0.0706872  0.9911085


Since the trisimulus is [0,0,1], this color is representable in Adobe RGB (D65).

Prophoto RGB (D50):
=============

0.79767   0.13519   0.03135
0.28804   0.71187   0.00009 * [0.183388   0.031393   1.201037]' = [0.188185   0.075274   0.991108].
0.00000   0.00000   0.82521


Since tristimulus value is [0.183388   0.031393   1.201037], where the blue component 1.2 exceeds one, so the color is not representable in Prophoto RGB (D50).

That is why in tho_mas' top figure it shows Adobe RGB (D65) ripping out through Prophoto RGB (D50).

(B) Why doesn't Bruce Lindbloom and some others show Adobe RGB gamut ripping out through ProphotoRGB?

Because, after the chromatic adaption multiplication the gamut is changed from Adobe RGB (D65) to Adobe RGB (D50). In the parallelepiped  of Adobe RGB (D50), the color XYZ=[0.188185   0.075274   0.991108] is outside the gamut, so in all likelihood Bruce and others strip that and don't show it. So they only show the legal colors inside this new gamut which gets nice transformed to Prophhoto RGB (D50) gamut.

This situation is the second image of tho_mas. If you line both of them vertically you will notice that Prophoto RGB gamut volume visually looks the same but the Adobe RGB gamut has visibly shrunk in the blue area.

Regarding your calculation that XYZ=[0.188185   0.075274   0.991108] in Adobe RGB (D65) gets mapped to XYZ=[ 0.14922403  0.06321976  0.74483862] in Adobe RGB (D50) after Bradford color transformation, that has nothing to do with it. Because the color XYZ=[0.188185   0.075274   0.991108] has not ceased to exist in the universe! It is still there but it is out of Adobe RGB (50) gamut, so does not get shown in conversion of Adobe RGB (D50) to Prophoto RGB (D50) which you have done essentially.

Hope that helps.

Joofa

[joofa]

Joofa,

This can basically be illustrated in Photoshop as well:

with a Granger Rainbow in Adobe RGB, and a customized Proof setup to ProPhoto RGB while using the Absolute Colorimetric rendering intent, the Gamut Warning will indicate massive clipping of blue hues as well as of close-to-white colors. Right the way as given in 3D below. Of course, the out-of-gamut marks disappear when changing the Proof setup to RelCol rendering.

In case it doesn't work - which may depend on the Photoshop version used - go to Color Settings and change the Color Engine from Adobe ACE to Microsoft ICM [which is offered when running Photoshop on a Windows platform; no idea about Macs].

Peter

So glad to hear that Peter you are saying that blue will clip!. I was feeling very lonely here.

Thanks,

Joofa

[digitaldog]

I don't have ColorThink V3Pro to compare with.

Adobe RGB is fully contained within ProPhoto RGB in V3.

[MarkM]

Joofa, I'm not making it complicated. I asked a very simple question and you replied with a bunch of stuff that did not answer it.

So I'll ask again: I asset that  the color [0, 0, 255] in AdobeRGB correctly converts to  [88 36 241] in ProphotoRGB without clipping. So does Photoshop. Are we wrong?

It's a yes or no question.

[Nick Rains]

Adobe RGB is fully contained within ProPhoto RGB in V3.

Thanks Andrew, I thought this might be the case. V2.2 seems to have some significant flaws, maybe it's time to upgrade.

[joofa]

Joofa, I'm not making it complicated. I asked a very simple question and you replied with a bunch of stuff that did not answer it.

So I'll ask again: I asset that  the color [0, 0, 255] in AdobeRGB correctly converts to  [88 36 241] in ProphotoRGB without clipping. So does Photoshop. Are we wrong?

It's a yes or no question.

Mark, I am so surprised that you are still asking this question after multiple demonstrations. You and Photoshop are not wrong but I have said nth number of times that [0,0,255] in Adobe RGB(D65) and after conversion of this color space via bradford (essentially transferring it to Adobe RGB (D50)) are not the same colors anymore. You guys are tranferring [0,0,255] in Adobe RGB (D50) to ProPhoto RGB (D50). And, I am asking you to tranfer [0,0,255] in Adobe RGB (D65) to Prophoto RGB (D50). Whether these two different representations of [0,0,255] are related by bradford has nothing to do with it. They are two different colors, plain and simple.

Joofa

[Peter_DL]

So I'll ask again: I asset that  the color [0, 0, 255] in AdobeRGB correctly converts to  [88 36 241] in ProphotoRGB without clipping. So does Photoshop. Are we wrong?

This is RelCol right, but AbsCol wrong.

On an absolute scale Adobe RGB 0, 0, 255 = ProPhoto RGB 99, 37, 282
- which means that it is out of ProPhoto RGB's gamut.
Numbers calculated with Bruce Lindbloom's CIE Calculator with (white-point-)-Adaptation set to None.

Cheers! Peter

--

[Iliah]

On http://www.brucelindbloom.com/iPhone/ColorConv.html

Set AdobeRGB 1998, gamma=2.2, reference white D65, and enter 0-0-255

Press RGB button

Set ProPhoto RGB, gamma=1.8, reference white D50, and press XYZ button

Now you see B>255. That is where the confusion is.

[digitaldog]

This is RelCol right, but AbsCol wrong.

On an absolute scale Adobe RGB 0, 0, 255 = ProPhoto RGB 99, 37, 282
- which means that it is out of ProPhoto RGB's gamut.
Numbers calculated with Bruce Lindbloom's CIE Calculator with (white-point-)-Adaptation set to None.

I’m a bit confused by the post. Where on Bruce’s calculator do you have the ability to alter the rendering intent? Why is adoption set to none? And the RelCol and Absolute intent should produce the same results expect for mapping white.

[joofa]

On http://www.brucelindbloom.com/iPhone/ColorConv.html

Set AdobeRGB 1998, gamma=2.2, reference white D65, and enter 0-0-255

Press RGB button

Set ProPhoto RGB, gamma=1.8, reference white D50, and press XYZ button

Now you see B>255. That is where the confusion is.

Thank you Iliah so much for this calculation, which shows that Blue > 255, and so will clip. I must point out though that while Prophoto RGB gamma is 1.8, the value displayed by Bruce before conversion is linear (XYZ=[0.188185   0.075274   0.991108]). So the actual coordinates are even worse in blue, being [46.76, 8, 306.2649], which you can get by selecting gamma=1.0 in the last step. Incidently, 306/255=1.2 for linear calculation, and that is what I reported as case 1 in my note as shown below:

Joofa wrote on DPReview:

Fraction of unit stimulus blue ProPhoto RGB primary needed to match unit stimulus blue Adobe RGB primary:

(1) Adobe RGB white point=D65, PropPhoto RGB white point=D50, Fraction needed=1.2

Best regards,

Joofa

[Iliah]

Chromatic adaptation is one of the most abused things in colour management. Sometimes it is forgotten to be applied; sometimes it is applied twice. Gamma is second abused.

[MarkM]

Joofa, I understand what you are saying. But again, you need to account for the different reference white points when you go between these spaces.

This is what you are trying to do as far as I can tell:
AdobeRGB -> XYZ -> ProPhotoRGB

This is what you need to do:
AdobeRGB -> XYZ -> Account for Chromatic Adaption to D50 ->ProPhotoRGB

This is what Bruce Lindbloom is telling you to do in his implementation notes.

Since you like math, here's a good exercise to drive the point home:
Take your XYZ values [0.188185   0.075274   0.991108] and convert them to LAB space. Before you can make that calculation, you will need to have a reference white point—the calculations require it. What are you going to use as a white point? D65 or D50?

Here's another way to think about it. Take your XYZ values [0.188185   0.075274   0.991108] and imagine you are seeing that color with eyes that are adapted to a white corresponding to D65. Now imagine looking at the color created by the those XYZ numbers with eyes adapted to D50. The color will look different. If you want the color under D50 that looks like the original color (which is the point of color management), a chromatic adaptation calculation will give it to you with reasonable precession: [ 0.14922403  0.06321976  0.74483862]. These two points in XYZ represent the same color appearance under different chromatic adaptations. Adobe 1998 assumes you are looking at colors with eye adapted for D65, ProPhoto assumes you are under D50. If you want to go back and forth you need to account for that.

And yet another way to think about it. Convert White Points
Take white in AdobeRGB [1,1,1]. What should that convert to in ProPhoto RGB? Common sense should tell you: [1, 1, 1]

Use your method of conversion:

(AdobeRGB D65->XYZ Matrix) x [1, 1, 1] = [ 0.9504701  1.0000001  1.08883  ]
This is the XYZ white point of  adobeRGB in XYZ. You can convert to chromaticity  coordinates an see that is corresponds to D65: 0.3127, 0.3290

Now, using your method with no adaptation, we convert to ProPhotoRGB by directly multiplying it with the transform matrix:
(XYZ -> ProPhoto matrix) x [ 0.9504701  1.0000001  1.08883  ] = [ 0.96801929  1.01290179  1.31945808] (without gamma correction, but it doesn't help)

Think about that result for a minute: we've just used your method to show that white in adobeRGB is out of gamut in PhotoPhotoRGB. This, of course, is absurd.

If you put the chromatic adaptation calculation back in where it belongs you will get a transform that correctly takes AdobeRGB white to ProPhotoRGB white. (along with all the other colors).

[joofa]

Mark, I think Iliah has settled this question by showing that blue required > 255 and so will clip. Please see the attachment in his message done using Bruce Lindbloom's calculator.

Thanks,

Joofa

[joofa]

And yet another way to think about it. Convert White Points
Take white in AdobeRGB [1,1,1]. What should that convert to in ProPhoto RGB? Common sense should tell you: [1, 1, 1]

Use your method of conversion:

(AdobeRGB D65->XYZ Matrix) x [1, 1, 1] = [ 0.9504701  1.0000001  1.08883  ]
This is the XYZ white point of  adobeRGB in XYZ. You can convert to chromaticity  coordinates an see that is corresponds to D65: 0.3127, 0.3290

Now, using your method with no adaptation, we convert to ProPhotoRGB by directly multiplying it with the transform matrix:
(XYZ -> ProPhoto matrix) x [ 0.9504701  1.0000001  1.08883  ] = [ 0.96801929  1.01290179  1.31945808] (without gamma correction, but it doesn't help)

Think about that result for a minute: we've just used your method to show that white in adobeRGB is out of gamut in PhotoPhotoRGB. This, of course, is absurd.

Why absurd?. Didn't peter say that:

Joofa,

This can basically be illustrated in Photoshop as well:

with a Granger Rainbow in Adobe RGB, and a customized Proof setup to ProPhoto RGB while using the Absolute Colorimetric rendering intent, the Gamut Warning will indicate massive clipping of blue hues as well as of close-to-white colors. Right the way as given in 3D below. Of course, the out-of-gamut marks disappear when changing the Proof setup to RelCol rendering.

In case it doesn't work - which may depend on the Photoshop version used - go to Color Settings and change the Color Engine from Adobe ACE to Microsoft ICM [which is offered when running Photoshop on a Windows platform; no idea about Macs].

Sincerely,

Joofa

[MarkM]

Mark, I think Iliah has settled this question by showing that blue required > 255 and so will clip. Please see the attachment in his message done using Bruce Lindbloom's calculator.

Actually he didn't. Sorry Iliah. You need to keep the reference white point set to D65. That's the reference white point for those XYZ numbers.

Nope, you have used the wrong white point here for Prophoto RGB

So do this for me and I think we'll have it cleared up. Show me you math, like you did earlier, including the matrices you're using to get from AdobeRGB[1, 1, 1] to ProPhotoRGB[1, 1, 1]

[Iliah]

Read closely screenshots and my next post. Also, if chromaticity coordinates are already in XYZ, do they need to be adapted to white point?

[MarkM]

Also, if chromaticity coordinates are already in XYZ, do they need to be adapted to white point?

It depends on what you are trying to do. If you are moving between color spaces with the intent of preserving color appearance, then yes you need to be mindful of the reference white when working with XYZ numbers. For instance if you are dealing with a small D65 white light, it looks white under D65 (obviously.) If you view it adapted for tungsten, it will look blue. But it's still the same XYZ point. So if you want to preserve color appearance you need to keep in mind the reference white of the source and destination and do the transformation. (That's why I suggested that Joofa try converting to lab—it explicitly requires you keep track of white). If you do it correctly, white in one space, should still be white in the other space even though the white points will have different XYZ numbers. That's what you see when you convert between spaces in photoshop.

[Iliah]

Yes Cap. We use adaptation to preserve colour appearance, that is while converting. We do not use adaptation when we assign - to see how the numbers will look at a different colour space. Took 5 pages.

[tho_mas]

So if you want to preserve color appearance you need to keep in mind the reference white of the source and destination and do the transformation. (That's why I suggested that Joofa try converting to lab—it explicitly requires you keep track of white). If you do it correctly, white in one space, should still be white in the other space even though the white points will have different XYZ numbers. That's what you see when you convert between spaces in photoshop.

that's why I also suggested to refer to Lab some posts above.
Abscol. even parts of sRGB fall outside of ProPhoto. So what. There is no such thing as abscol when the target profile is matrix based (at least not in conjunction with current CMMs). When the target profile is matrix based the only RI available is always relcol.
So... in abscol terms the highest saturated blue of AdobeRGB falls outside of ProPhoto, sure. And of course also the white of AdobeRGB falls outside of ProPhoto.
But this is something that simply does not happen in a color managed workflow. It only happens when you look at the numbers alone.
When you convert from AdobeRGB to ProPhoto the entire gamut of AdobeRGB is shifted towards the white point of ProPhoto. The shifted color space has still the same shape and likewise the relation of the colors to each other within the gamut are still the same - AdobeRGB is simply shifted to another "location" (plus some chrom. adaption to preserve the appearance).
This is why the entire discussion is so pointless...


edit: just to reiterate the initial post...

This is AdobeRGB (white) and ProPhoto each abscol to D50 (so apples to oranges):


this is what happens in real color conversions (AdobeRGB and ProPhoto relcol to eachother):


or referring to Bruce Lindbloom:


or to iccview.de: