Pages: 1 2 3 [4] 5   Go Down

Author Topic: Adobe Color Printer Utility – New Problem ? (Mac OS El Capitan 10.11.6)  (Read 22879 times)

Simon J.A. Simpson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 584

I don't either, but I would image they do as you mention here for showing the monitor appearance of the target. For managing the print pipeline it must be another story. I've read somewhere that they create what is called a "null transform" so that the effect of a colour space assignment is zeroed out. But I'm not certain if that's really what happens under the hood or how it works. It would be informative for someone who knows it from the inside to provide an explanation.
Mark, I was one of those actively involved at the time in the furore about the problem of not being able to print targets without colour management on the Mac.

I don’t know how applications like ACPU, ACU, and the ColorMunki software get round the problem of printing targets without colour management.  I do know that the null transform method eschewed by Eric Chan was deprecated in later versions of Photoshop, previous to CS6 if memory serves.
Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285

... Even when colour management is turned off in Photoshop ?  Judging by the file’s appearance in Photoshop it seems to assume a ProPhoto colour space even when CM is off.


How do you turn color management totally off in photoshop versions later than PS5? I'd like to know because I don't believe it is possible. If you could do that, ACPU wouldn't be needed to print a non color managed image target.  Also, if after you believe you have successfully turned off PS color management, then why would PS assume any profile for the image. By definition that says it's still trying to color manage the image.  Any truly non color managed app (e.g. microsoft word, excel, etc) just hands off the RGB data untouched to the OS's color managed pipeline which generally defaults to using the monitor profile to post RGB values to the display.
« Last Edit: April 24, 2017, 06:42:58 pm by MHMG »
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

How do you turn color management totally off in photoshop versions later than PS5? I'd like to know because I don't believe it is possible. If you could do that, ACPU wouldn't be needed to print a non color managed image target.  Also, if after you believe you have successfully turned off PS color management, then why would PS assume any profile for the image. By definition that says it's still trying to color manage the image.  Any truly non color managed app (e.g. microsoft word, excel, etc) just hands off the RGB data untouched to the OS's color managed pipeline which generally defaults to using the monitor profile to post RGB values to the display.

Can't say about Macs but color management can be defeated in Windows PhotoShop up through the latest version.

Easiest way is to assign the target image ROMM-RGB colorspace. Then select the same as the printer profile to print. PS complains and suggests you use their target printer utility - which has few placement options and doesn't accurately retain the image dimensions. Just hit cancel and proceed.

I've carefully measured the results and they are exactly the same as if I'd used their utility. And I am very particular about checking this given the warning.

I regularly use this to position and print multiple charts across 44" media.

I suspect the warning has something to do with the way Macs handle this perhaps by embedding some sort of metadata in the printer stream that messes up the ability to print directly from Photoshop. I also think that problem was why they removed the feature. So whether it works or not on a Mac is unknown.

Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com


Easiest way is to assign the target image ROMM-RGB colorspace. Then select the same as the printer profile to print.


I believe this is what is meant by the "null transform" I mentioned above. One nullifies the other and you end up with the semblance of no colour management.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285


Easiest way is to assign the target image ROMM-RGB colorspace. Then select the same as the printer profile to print. PS complains and suggests you use their target printer utility - which has few placement options and doesn't accurately retain the image dimensions. Just hit cancel and proceed.


OK, yes, this is the "null transform" workaround that I believe was originally proposed by Eric Chan before ACPU or ACU appeared as print utility options, and it does indeed still work to this day. Perhaps we are now arguing semantics, but I don't really consider this "turning color management off" in PS. It's a clever workaround to print an image target out of PS with RGB data maintaining essentially the same values, but it still requires the color management pipeline to be functioning normally in PS to succeed.

kind regards,
Mark
http://www.aardenburg-imaging.com
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

I believe this is what is meant by the "null transform" I mentioned above. One nullifies the other and you end up with the semblance of no colour management.

It is.  And the reason I pick ROMM-RGB is because, for some reason, it's RGB and still shows up in the list of profiles that can be picked in the printer menus.

I've done limited testing using arbitrary printer profiles with the same, good results. However, I prefer the matrix colorspace because there is ambiguity as to what transform tables are used with printer profiles (Relative, Perceptual, etc.). But it turns out there is no Intent state retained so once an image is in device space, how it got there makes no difference if it is printed directly. That is, you can assign a printer profile to an image then print it and get exactly the same results whether you select Perceptual or Relative.  My fear was, that if it retained state information and the print intent was different than the conversion that put it into device space that Photoshop would do a round trip going back to PCS from the retained render state then back to device space using the printer dialog selected intent.  But it doesn't. It just ignores whatever intent you select if it is already in the device space.

One side affect of this is that I'm quite certain that not only are the output RGB values to the printer similar as if there was no color management, they are almost certainly exactly the same.

And my measurements so far confirm this.

But I use ROMM-RGB just in case somebody at Adobe decides to make Photoshop "smarter" and retains conversion state.
« Last Edit: April 24, 2017, 09:00:55 pm by Doug Gray »
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

OK, yes, this is the "null transform" workaround that I believe was originally proposed by Eric Chan before ACPU or ACU appeared as print utility options, and it does indeed still work to this day. Perhaps we are now arguing semantics, but I don't really consider this "turning color management off" in PS. It's a clever workaround to print an image target out of PS with RGB data maintaining essentially the same values, but it still requires the color management pipeline to be functioning normally in PS to succeed.

kind regards,
Mark
http://www.aardenburg-imaging.com

If it walks like a duck and quacks like a duck I'm more than willing to just use it though it makes no sense that Adobe removed the option to bypass color management.  Perhaps it was confusing people. I suspect 99% of Photoshop users had no idea what it meant or what it was intended to be used for. Maybe their CSR peeps just got tired of calls from people that were using it inappropriately.
Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285

...  My fear was, that if it retained state information and the print intent was different than the conversion that put it into device space that Photoshop would do a round trip going back to PCS from the retained render state then back to device space using the printer dialog selected intent.  But it doesn't. It just ignores whatever intent you select if it is already in the device space.

One side affect of this is that I'm quite certain that not only are the output RGB values to the printer similar as if there was no color management, they are almost certainly exactly the same.


Except that this null transform trick is always done with working colorspace profiles, ie. srGB, aRGB,  ROMM-RGB, etc. and those profiles are matrix profiles. They only support the relative colorimetric conversion intent, so there's no way that choosing perceptual rendering intent for the "destination" color space conversion can do anything with these working colorspace profiles except to use the relcol matrix conversion math. Essentially one is saying " i have assigned ROMM-RGB (or aRGB,etc) to my target file, thus leaving the RGB values alone. Now, I'm printing to a magical printer that happens to have a perfect ROMM_RGB colorspace, (or aRGB, etc)". Hence the CMM (color management module) converts the starting values to essentially the same destination values, i.e. the null transform.  There may indeed be small CMM conversion numerical rounding errors, but they are so tiny that for all practical purposes the source data values and the destination values remain the same. Hence, my assertion that PS color management is alive and well with the null transform trick. It is not turned off. Yet in practical terms the null transform trick has the desired effect of sending original, unmodified image target values all the way to the printer, so it does indeed look like duck :)

best,
Mark

« Last Edit: April 24, 2017, 09:33:10 pm by MHMG »
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

Except that this null transform trick is always done with working colorspace profiles, ie. srGB, aRGB,  ROMM-RGB, etc. and those profiles are matrix profiles. They only support the relative colorimetric conversion intent, so there's no way that choosing perceptual rendering intent for the "destination" color space conversion can do anything with these working colorspace profiles except to use the relcol matrix conversion math. Essentially one is saying " i have assigned ROMM-RGB (or aRGB,etc) to my target file, thus leaving the RGB values alone. Now, I'm printing to a magical printer that happens to have a perfect ROMM_RGB colorspace, (or aRGB, etc). Hence the CMM (color management module) converts the starting values to essentially the same destination values, i.e. the null transform.  There may indeed be small CMM conversion numerical rounding errors, but they are so tiny that for all practical purposes the source data values and the destination values remain the same. Hence, my assertion that PS color management is alive and well with the null transform trick. It is not turned off.

best,
Mark

But look at the tests I did using the null transform with regular printer profiles. Assign a profile then print it using the same profile and it makes no difference at all what intent you select. This can only mean it is printing the device space color values directly as there are pretty significant differences between Perceptual and Relative intents and any sort of round tripping, even with the same printer profile intent, would shift the colors enough to detected with a spectro.

And, as I said, the reason I chose ROMM-RGB is in the remote chance Photoshop becomes smarter and does some sort of conversion then one would possibly get rounding errors but that would be all. It is apparent that currently, Photoshop does not do conversions and just outputs the device values unchanged whether using RGB profiles or printer profiles for the null transform.
Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285

But look at the tests I did using the null transform with regular printer profiles. Assign a profile then print it using the same profile and it makes no difference at all what intent you select. This can only mean it is printing the device space color values directly as there are pretty significant differences between Perceptual and Relative intents and any sort of round tripping, even with the same printer profile intent, would shift the colors enough to detected with a spectro.


An interesting result, so let's consider what it means to assign a printer profile to the image target in order to attempt the null transform trick. The target is once again already in the final destination colorspace of the printer. You choose "perceptual render", or relcol or abscol to print to the destination space. The assigned source file thus has has all the identical Lookup tables (perceptual. relcol, absolute) as the destination profile. I wouldn't have necessarily predicted it, but your testing means the CMM is smart enough to compare AtoB and BtoA tags and choose the corresponding ones for source and destination space. Hence the null transform trick still succeeds according to your testing even when assigning printer profiles rather than working space profiles. That said, printer profiles use LUTs rather than matrix math, so the CMM has to work harder to interpolate between the values not present in the LUT.  I would therefore recommend folks using the null transform trick stick with the matrix math of working space colorprofiles. The CMM errors will be less.

best,
Mark
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

An interesting result, so let's consider what it means to assign a printer profile to the image target in order to attempt the null transform trick. The target is once again already in the final destination colorspace of the printer. You choose "perceptual render", or relcol or abscol to print to the destination space. The assigned source file thus has has all the identical Lookup tables (perceptual. relcol, absolute) as the destination profile. I wouldn't have necessarily predicted it, but your testing means the CMM is smart enough to compare AtoB and BtoA tags and choose the corresponding ones for source and destination space. Hence the null transform trick still succeeds according to your testing even when assigning printer profiles rather than working space profiles. That said, printer profiles use LUTs rather than matrix math, so the CMM has to work harder to interpolate between the values not present in the LUT.  I would therefore recommend folks using the null transform trick stick with the matrix math of working space colorprofiles. The CMM errors will be less.

best,
Mark

No, no!  Let me repeat. Assign a printer profile to an image. You can not select an intent when assigning. You are simply telling Photoshop that the image RGB values are now in device space and it has no idea what "intent" the image is now in (that is what intent caused conversion into those specific device values - assigning is intent free!). When you print the image using the same profile it does not use the AtoB or BtoA tables at all (which was my concern if it had retained some sort of assumed conversion state) and it doesn't make any difference what settings you select. Rel Col, Abs Col, Sat Col will all print exactly the same.

And, I've checked because even if it did a round trip using the very same BtoA and AtoB tables it would leave significant, and detectable, if not visible errors. It does not.
Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285

No, no!  Let me repeat. Assign a printer profile to an image. You can not select an intent when assigning. You are simply telling Photoshop that the image RGB values are now in device space and it has no idea what "intent" the image is now in (that is what intent caused conversion into those specific device values - assigning is intent free!). When you print the image using the same profile it does not use the AtoB or BtoA tables at all (which was my concern if it had retained some sort of assumed conversion state) and it doesn't make any difference what settings you select. Rel Col, Abs Col, Sat Col will all print exactly the same.

And, I've checked because even if it did a round trip using the very same BtoA and AtoB tables it would leave significant, and detectable, if not visible errors. It does not.

Interesting observations. But, setting aside the null transform trick for a moment, then how does one convert from one printer profile colorspace to another? Say you have an image file tagged with Printer/ink/media combination A. Now you want to convert to Printer/ink/media combination B?. You can assign a rendering intent to the destination space B, but I don't know how to assign a rendering intent to printer/ink/media source file A. What should the software engineers assume about this printer profile to printer profile conversion condition when making the source to destination conversion? My guess is that if you want the rendering intent of the destination space to be perceptual, for example, the CMM will compare the two perceptual tables even though you couldn't tell it to do so.  Failing an actual option for the user to assign a designated rendered state to the data in source A, I don't know what else the CMM color management pipeline could assume when looking up the colorspace values of the source image already tagged with a printer profile other than to use corresponding LUT tables between source and destination. Hence, the null transform trick should work with printer profiles as well, and if I understand you correctly, you say that it does. Not sure I"m following your argument entirely, but I think you are saying it ignores all the LUTS. but I'm saying how could it? It has to make some conversion to go from Printer A to printer B. In the unique case where printer/ink/media combination A is identical to printer/ink/media combination B, you get the null transform condition, and the LUT table usage by the CMM should be getting handled the same way as it handles the conversion when printer/ink/media combination A is not identical to printer/ink/media combination B.

best,
Mark
« Last Edit: April 24, 2017, 11:22:51 pm by MHMG »
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

Interesting observations. But, setting aside the null transform trick for a moment, then how does one convert from one printer profile colorspace to another? Say you have an image file tagged with Printer/ink/media combination A. Now you want to convert to Printer/ink/media combination B?. You can assign a rendering intent to the destination space B, but I don't know how to assign a rendering intent to printer/ink/media source file A. What should the software engineers assume about this printer profile to printer profile conversion condition when making the source to destination conversion?

That's exactly what confused me for some time. When you convert to a profile you only have the option to choose the destination intent. It seemed to me that one needed to know the source profile intent as well. Then I realized it doesn't exactly work that way. The description is misleading when you start doing things a bit out of the box. Here's what I found:

Take Andrew Rodney's test image with the highly saturated colors and balls. A good fraction of the image has imaginary colors and significant additional portions have real colors that are impossible from a reflecting surface (Mac Adam limits). How attractively these print can vary a lot even if the profiles are all high quality and accurate for in gamut, colorimetric tables.

Let's say I found a printer profile that converted Andrew Rodney's test images and produced very pleasing results when using perceptual and softproofing with Profile A. But let's say I have a slightly different glossy paper matching profile B that doesn't produce as pleasing an image in Perceptual. so I can't use the profile I softproofed with since I don't have that exact paper. What to do.

If I convert the image using Perceptual with profile A, then convert back to an RGB space using Relative Colorimetric and profile A, I will now have a file that will, when printed using Colorimetric Intent and profile B on the paper I have, print nearly exactly the same image as that soft proofed using profile A on the paper I don't have.

And the reason this actually works is because the conversion back to RGB space is done by applying the selected intent, not to the RGB space, but to how the source RGB values are interpreted. That is it re-interprets the device RGB values which came from the BtoA0 tables and runs them through the AtoB1 tables.

Quote
My guess is that if you want the rendering intent of the destination space to be perceptual, for example, the CMM will compare the two perceptual tables even though you couldn't tell it to do so.  Failing an actual option for the user to assign a designated rendered state to the data in source A, I don't know what else the CMM color management pipeline could assume when looking up the colorspace values of the source image already tagged with a printer profile other than to use corresponding LUT tables between source and destination. Hence, the null transform trick should work with printer profiles as well, and if I understand you correctly, you say that it does. Not sure I"m following your argument entirely, but I think you are saying it ignores all the LUTS. but I'm saying how could it?
Well, it can because it is aware that the selected printer profile is the exact same profile that the image's colorspace is in and therefor any conversion is unnecessary just like it would make no sense to convert sRGB to sRGB by going through the PCS math.

Quote
It has to make some conversion to go from Printer A to printer B. In the unique case where printer/ink/media combination A is identical to printer/ink/media combination B, you get the null transform condition, and the LUT table usage by the CMM should be getting handled the same way as it handles the conversion when printer/ink/media combination A is not identical to printer/ink/media combination B.
It certainly could work that way which is why I ran some tests. Round tripping the same profile/intent introduces interpolation errors and the two passes can build significant errors. Generally, AtoB tables produce less error than BtoA tables. These are detectable looking at the comparison dE stats between two prints.
Logged

Simon J.A. Simpson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 584

How do you turn color management totally off in photoshop versions later than PS5? I'd like to know because I don't believe it is possible. If you could do that, ACPU wouldn't be needed to print a non color managed image target.  Also, if after you believe you have successfully turned off PS color management, then why would PS assume any profile for the image. By definition that says it's still trying to color manage the image.  Any truly non color managed app (e.g. microsoft word, excel, etc) just hands off the RGB data untouched to the OS's color managed pipeline which generally defaults to using the monitor profile to post RGB values to the display.

Mark, you are of course right.  I didn’t really express myself clearly and accurately.

You cannot really ‘turn-off’ colour management in Photoshop; and that is the whole point.

However, take a look at the screen-shot below.  It is the Photoshop ‘Color Settings’ dialogue.  Note the Description at the bottom.  This doesn’t mean that colour management is turned-off per se but it does seem to mean that you can successfully import an untagged file into Photoshop; and this was borne out by my testing.  I found that trying to do this with the colour management policies turned-on does not work.

Of course, what I should have said is:
I have found that when the import policies are on Photoshop seems to assume that it needs to apply an sRGB profile importing an untagged image.  This is how the on-screen image looks.  When the import policies are turned-off Photoshop seems to import the image without assigning an sRGB profile but the appearance on-screen replicates the appearance of an image with a ProPhoto profile attached.

I hope this is clearer.

Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

Not sure I"m following your argument entirely, but I think you are saying it ignores all the LUTS. but I'm saying how could it? It has to make some conversion to go from Printer A to printer B. In the unique case where printer/ink/media combination A is identical to printer/ink/media combination B, you get the null transform condition, and the LUT table usage by the CMM should be getting handled the same way as it handles the conversion when printer/ink/media combination A is not identical to printer/ink/media combination B.

best,
Mark

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.
Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285

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

 
« Last Edit: April 25, 2017, 01:28:37 pm by MHMG »
Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285


However, take a look at the screen-shot below.  It is the Photoshop ‘Color Settings’ dialogue.  Note the Description at the bottom.  This doesn’t mean that colour management is turned-off per se but it does seem to mean that you can successfully import an untagged file into Photoshop; and this was borne out by my testing.  I found that trying to do this with the colour management policies turned-on does not work.

Of course, what I should have said is:
I have found that when the import policies are on Photoshop seems to assume that it needs to apply an sRGB profile importing an untagged image.  This is how the on-screen image looks.  When the import policies are turned-off Photoshop seems to import the image without assigning an sRGB profile but the appearance on-screen replicates the appearance of an image with a ProPhoto profile attached.

I hope this is clearer.

Simon, there are more than one setting in PS that determine the "policies" PS is using when opening existing files or creating new ones, so much so, that we'd all get hopelessly confused trying to list all the options. I find that the best way to gather a little piece of mind is to go to the dialogue box at the very lower bottom of the image window and set it to always show the document profile. That way, I can quickly tell what profile is or isn't embedded in the document and whether any desired new profile assignment or conversion actually took place. If that dialog box show that the image is untagged, then PS assumes the working space profile that you've set in the the color settings dialogue box in order to render the color appearance of the RGB triplets in the image to you display.

Hence, PS can turn color management "policies" on and off, but it never turns off the entire color management pipeline. The null transform trick does, however, as Doug correctly pointed out, tell PS to leave the image alone and perform no further conversion. I guess it is fair to say a specific part of the PS color managed environment does get "turned off"  when source and destination space both have been assigned the same profile, but PSCC, AFAIK, cannot be set to exactly mimic the on screen behavior of other truly non color aware apps (e.g. Microsoft Word.

Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

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.
Mark, I have had similar questions about this. Being lazy, I just avoid editing an image in device mode. I see what you have described too. What it shows and what it prints often do not match the info panel. There's actually another reason I don't edit in device mode. The tone curve varies a lot between different printer's device spaces. I don't want to have to read RGB values, curves charts, and similar things that vary with device space. Now editing in a standard RGB space (I really like ProPhoto) with view proof enabled is something that works and carries few surprises.

And because of the potential, and possibly unexpected, interaction with "Color Settings," when I convert from printer device space I do so into L*a*b*.  The selected intent options in the dialog box determine how the device RGB values are interpreted and the whole thing is well defined.

Quote
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.
While the discussion re the, "null-transform", and "no color management equivalence", is at least tangentially related to ACPU, this is drifting into less related areas of Photoshop strangeness. But I'd be happy to discuss these further in another thread. There are interesting insights and observations you have made.

I appreciate the time you took to test this. I'm sometimes wrong and it's really hard to see one's own mistakes.
« Last Edit: April 25, 2017, 04:53:09 pm by Doug Gray »
Logged

GWGill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 608
  • Author of ArgyllCMS & ArgyllPRO ColorMeter
    • ArgyllCMS

When you convert to a profile you only have the option to choose the destination intent.
That's an artifact of the CMM being used. Given that ICC type pre-computed intents are part of the device profiles, there are two intent choices in play. The CMM may expose this, or it may not, in the latter case it assumes the same intent table for both source and destination.

[ Of course if you are creating a real gamut mapping between a source and destination gamut, there is only a single intent. ]

As I understand it, the null transform recognition Apple's CMM simply looks for the same profile being used as source and destination, and skips any conversion. I would guess that it would treat two different profiles as different, even if they were notionally for the same device.
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197

That's an artifact of the CMM being used. Given that ICC type pre-computed intents are part of the device profiles, there are two intent choices in play. The CMM may expose this, or it may not, in the latter case it assumes the same intent table for both source and destination.
As Photoshop does. The workaround, if you need different intents for the source and destination profiles, is to convert using Lab as an intermediary. Then you can specify the source intent on the conversion to Lab and the destination intent on conversion to the device. Klugey but at least it is (relatively) clear what is going on.
Quote
[ Of course if you are creating a real gamut mapping between a source and destination gamut, there is only a single intent. ]

As I understand it, the null transform recognition Apple's CMM simply looks for the same profile being used as source and destination, and skips any conversion. I would guess that it would treat two different profiles as different, even if they were notionally for the same device.
Adobe's ACE does that too. It even brings up a surly warning about trying to bypass color management and points you to ACPU if the image profile and selected printer names match.

I have to wonder why Adobe is trying so hard to discourage the null-transform usage pattern.
Logged
Pages: 1 2 3 [4] 5   Go Up