It is clear that when you use the same printer profile and the image is in that profile's colorspace, Photoshop realizes the profiles are identical and simply does not do any transforms. When the profiles differ, then it does do LUT conversions. For rel col it uses AtoB1 with the image's profile, then BtoA1 using the target printer profile. Thus, when you use the same profile, ie: the null-transform, it is identical to the way Adobe's ACPU works. The RGB values go directly to the printer unaltered.
I just verified this by the following experiment. I created a profile (TINY) with the smallest (least accurate) LUTs I1Profiler allows then printed directly the cyan using RGB(0,255,255) which happened, on my set of 64 colors, to be the color that exhibited the greatest change roundtripping AtoB1->BtoA1. The measured dE between ACPU and the null-transform was 0.14. The dE from roundtripping was 6.8.
This confirms Adobe does not roundtrip, and introduce errors, using the null-transform. It clearly recognizes the profiles as identical and skips a process that would, of course, be necessary when the profiles differ.
First, let me apologize to everyone that we seem to have gotten so far OT.. But this wandering has made me really curious about the null transform method and what the implcations are for PSCC's color management behavior when a file has been tagged with a printer profile and not a typical working space profile. So, Doug, experimental minds think alike
In the clarity of the morning light, I played some games in PSCC. Here's what I observed:
1) Doug is absolutely correct. I was wrong to assume PS still attempts to follow a standard conversion pathway when the source and destination space are set to the same profile. Adobe engineers did indeed put some code in PS to totally override the user's conversion request in this rather unique null transform situation, and that code affects all profiles, even printer profiles. RGB numbers remain totally identical. No CMM errors occur. I guess in this special case, we can say PS color management is indeed turned off as far as the forward conversion from source space to destination space is concerned whenever the user chooses the same profile for both source and destination.
2) Perhaps as a consequence of this null transform code, PSCC makes some other very confusing color management choices when viewing a printer-profile tagged image. I'm still not sure I have figured it out, but here's what I'm seeing. The Proof Setup menu is now irrelevant. No way to use its rendering intents to soft proof how those rendering intents will affect the final printed image other than the fact that [command Y] does toggle an apparent softproof view on your display on and off. However, the color settings menu now appears to override the Proof setup menu.
3) When an image file is converted to or assigned a printer profile, the color conversion options chosen in the color setting dialogue dictate what colorimetric values will be associated with the RGB triplets in the image file.
4) Now here's what I don't quite get. By changing the color conversion options in the color setting dialog box (e.g. from perceptual to abscol) in PS even on the fly, i.e. even after the image has been converted to or assigned a printer profile, the info tool shows that the colorimetric values associated with each RGB triplet have changed, but the image colors posted to the display are not changing. That seems weird to me because it suggests we can't really trust the the colors posted to our display (even when they are all totally in gamut) when looking at an image tagged with a printer profile. Are they being properly color managed in terms of how the colors appear on the display? Again, the rendering intents in the Proof setup dialogue box have also been rendered (pardon the pun) useless. The color settings dialogue has taken over what the info tool reads out on the fly for the LAB values associated with each RGB triplet based on what conversion option you choose in that dialogue box, but the display doesn't update to reflect any changes.
I'm puzzled by what's going on in item 4. If it's a bug, or if I just don't understand the Adobe color management logic here, this odd and confusing PSCC color management behavior when printer profiles are embedded in an image does reinforce the fact that editing images in a printer colorspace rather than a standardized working color space, is probably never a good practice.
cheers,
Mark
http://www.aardenburg-imaging.com