Re: Conceptual Breakdown
Re: Conceptual Breakdown
- Subject: Re: Conceptual Breakdown
- From: Steve Upton <email@hidden>
- Date: Tue, 14 Dec 2004 13:56:22 -0800
At 12:50 AM -0500 12/13/04, email@hidden wrote:
>I need a little help... with a couple of questions.
>
>Take an untagged Granger Rainbow (*), open it in PS CS and assign to it the Adobe RGB (1998) profile and save it. So far, so good. Now, if you use ColorThink to plot the tagged file in 3D, and view the vectors with a conversion to Adobe RGB (1998) using any rendering intent, there is a shift in color. It is minimal with Abs Colorimetric and but dramatic with all other intents. Why? Isn't this essentially a null transform? What's causing the shift?
>
>If I perform the same operations using the Granger Rainbow tagged with the ProPhoto profile, then "convert" it to ProPhoto, I get a color shift only in the "hooked" part of the blues, but nowhere else, regardless of rendering intent. What's the (significant) difference between the two profiles? Media White Point? I'm confused...
Ok, I have had a chance to look this over and I have a few things I can add. Sorry for the length of this post but I wanted to be thorough and hey, you asked!
First, a bit about ColorThink:
- all graphing in ColorThink is done in D50 Lab to "simulate" the standard ICC PCS as well as make graphing of measured colors easy as they tend to be all based on D50 Lab.
- all profile volume graphing in the current version of ColorThink is absolute colorimetric. This means that profiles with non-white white points will not line up with the L axis. For print profiles this makes sense and works well as the measurements taken to build the profile are also paper-absolute and the measurement colors and profile gamut volume will line up properly (at least when it is a good profile - it's not a bad test for this). What this also means, however, is that working spaces and monitor profiles with non-D50 white points will graph off-axis. From one point of view this could be argued to be correct but I have decided that correct or not, it is not necessarily a good idea for comparison. Regardless of the white point of your monitor, you will adapt to it as you view it and so it makes sense to adjust the graphs as well. Future versions of ColorThink will graph monitor and working space profiles adjusted to D50 and the Pro version will allow changing of the intent.
- when graphing vectors created by profiles, all rendering intents except abs col can cause unexpected shifts. It's important to remember that while the desire (and expectation) of relative colorimetric is for no color shifting to occur, it actually shifts all colors relative to the new destination white point. Saturation and Perceptual also shift relative to the new white but they shift for other reasons as well so it doesn't surprise people as much when they see longer vectors with this rel col.
- matrix-based profiles such as most monitor and working space profiles have no LUT tables with which to perform saturation and perceptual mapping. As a result they do not have these intents in them and I really wish Photoshop disabled intents that were not available. I have left them enabled even when they are not available to illustrate the point. (people can try them and see it makes no difference)
- finally, an explanation of how round-tripping occurs. When a profile is applied to color data for graphing vectors, two conversions occur. First the colors are converted to device space (say, RGB) using the configured intent, then they are converted back to Lab using absolute colorimetric. This is the "lazy-man's" way of testing profiles as it simulates the conversion of test colors and the subsequent printing and measuring of the colors for comparison. This means that it relies on the accuracy of the "proofing" part of the profile (device->Lab). It also means that the only way you will see the minimum amount of color shift is to select absolute colorimetric as the Lab->device intent and the device->lab intent comes back as abs col. As mentioned above, all other intents can cause shifts as the "rendering" transform (Lab->device) maps colors relative to the destination white point.
Now, about your graphs:
- the very small vectors are indeed rounding errors. When performing a conversion from one profile to the same profile, Adobe's and Apple's CMM's will detect identical profiles and not perform any conversion. For a workflow this is a good idea as you don't want rounding errors messing with your color when no conversion is required. I chose to leave them in as an illustration. It is possible that ColorThink is creating the errors but I don't suspect it at this time as all color storage in RAM is using double-precision floating point values.
- The shifting in the corner of the ProPhoto profile is not too surprising as the extreme blues in that profile are outside of ICC Lab - outside of the range of human color vision in fact.
- The shifting on the Adobe RGB profile is a bit different. This is the path it takes: D50 colors are converted to device space using the selected rendering intent and then "proofed" back through the profile using abs col, creating D50 Lab colors. For a bit more detail I'll add the following points:
= the origin of the colors isn't too relevant to the transformations so it might help to think of the colors in this example as "organized around a bluish white point".
= user-selected abs col will convert to the closest printable color, then when "proofed back" by abs col you see a minimum of shift - no surprise there
= user-selected rel col will convert to the closest printable color *while shifting all colors relative to the bluish white point of the destination aRGB space*. So bluish colors shift to become more blue. It looks strange but that's what's going on. If you imagine that the applied profile is a printer profile it tends to make more sense "in the head".
And finally, should this be the way it occurs? Well, as I mentioned above, it is A way for it to occur AND it makes sense for the print world. It just doesn't make as much sense in the working-space and monitor world. As you can see from the above discussion, it is fairly involved and has quite a bit of thinking behind it already. After more thinking and plenty of discussions I have decided to do it differently in future versions of ColorThink.
How? you ask (those who have waded all the way through this post).
- First, the generation and plotting of colors in non-D50 working/monitor spaces will change. Like the plotting of gamut volumes mentioned above, image-generated colors will be adjusted to D50 so they will line up with the axis just as the gamut volume will. If this wasn't done then the aRGB Granger colors would appear outside of the aRGB gamut volume! plenty of confusion there.
- Second, I am considering having the colors "proofed back" using relative colorimetric for monitor/workingspace profiles. This may seem odd but if I don't do it this way then all the rel col work in the first step gets messed with by it all proofing back to a blue white point and conversions will look strange. You will choose abs col and all the colors will map over to the blue whitepoint!
I am open to feedback concerning this stuff. As you can tell, it gets involved.
Rich, I hope I was able to answer your questions to your satisfaction. Thanks for the graphs and discussion. It helps to get these issues out into the open so I can make decisions that BOTH make sense AND are correct.
Regards,
Steve
________________________________________________________________________
o Steve Upton CHROMiX www.chromix.com
o (hueman) 866.CHROMiX
o email@hidden 206.985.6837
o ColorGear ColorThink ColorValet ColorSmarts ProfileCentral
________________________________________________________________________
--
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden