Null Transform "trick" and Rendering Intent

[Pete Berry]

In running through the various ways of printing targets with CS5/Win. Vista on my iPF5000, I found that the the null transform method results did not quite match the identical results (scaling excepted) in printing through the ACPU, Canon's 16-bit printing plug-in which bypasses CS5, or through PSE-7 with the usual method.

Turns out that I had used my usual Perceptual intent w/BCP with the null transform, and on the Canon LFP wiki forum Scott Martin stressed that rendering intent should be Relative Colorimetric, BCP unchecked. And, yes, this gives results identical to the rest.

I've not seen this important info in the seemingly interminable ACPU thread - couldn't find it in a search - so a new thread seemed to be in order for those like me not previously familiar with the CS5 trick, or having little enough sense not to make it intuitive or even to think about rendering intent!

Here's the link to the trick in LL "Tutorials" by Mark Dubovoy reporting Eric Chan's workaround for the Mac/CS4 target printing dilemma:

http://www.luminous-landscape.com/tutorials/solving.shtml

Pete

[Scott Martin]

Kudos, again, to Eric Chan for figuring out this null transform trick and for popularizing it! I'm surprised that people talking about it aren't stressing the importance of RelCol without BPC. It's a flawless process that ensure success - highly recommended. With it, ACPU isn't needed - at least for Photoshop owners.

[MHMG]

Yes, Great! I think we've got the target generating issues well in hand now.

However, with that nice new custom profile you've just built, now try printing from a CS5  "let Photoshop manage colors"/NCA workflow and then from a "let printer manage colors"/colorsync workflow. Running under Mac Snow leopard, I can not get the same results on either my Canon 8100 or my Epson 3880 when in theory they should produce essentially the same results (assuming CMM engine and rendering intent are the same). Why does it matter to get good color managed workflow from both paths? Because almost all non Adobe apps must be color managed through the colorsync pathway. They don't have a "let application manage color" pathway.

Am I missing something?  It may well be that the printer drivers are the culprits in need of updating for Snow leopard, but the current situation is that CM appears to be fundamentally broken on the latest MACs as far as I can tell.  Only certain apps under certain conditions with certain printer drivers appear to be working correctly at the current time. It's like walking through a mine field.

[digitaldog]

I’m confused. If you select say Adobe RGB Source and Destination, there’s no perceptual table so how does this make a difference when it should be using RelCol anyway?

And has anyone tried this null profile trick to an Epson using sRGB instead? Doesn’t seem to work on this end.

[Pete Berry]

I’m confused. If you select say Adobe RGB Source and Destination, there’s no perceptual table so how does this make a difference when it should be using RelCol anyway?

And has anyone tried this null profile trick to an Epson using sRGB instead? Doesn’t seem to work on this end.

All I know is that Eric specifically stated RelCol/no BCP in the above link, that you have the choice of intents to make with CS5/A-RGB file and profile, and that with RelCol/BCP unchecked it prints targets correctly in a Windows environment. Whereas with Percept+BCP, it doesn't.

Another interesting thing is that if the target file is tagged A-RGB, it prints normally, as if untagged, in both the ACPU and Canon 16-bit printing plugin with driver CM off. But if tagged S-RGB, the results are greatly over-amped with the same settings - much as if printing an S-RGB file in A-RGB color space. This suggests to me that the "native" color space with CM off, at least in my iPF5000 is indeed A-RGB.

But in printer control/CM off in CS5, whether untagged, S- or A-RGB tagged target, the same over-amped targets as above print. Now I don't know if the CS5/driver-controlled CM glitch has been identified, but it acts as if, with driver control selected and CM "Off", that all files printed are assigned S-RGB color space somehow without ending up re-tagged.

Pete

[madmanchan]

Currently, I have no explanation as to why the "null profile" workaround is unreliable with sRGB. An additional point of confusion is that many systems have many sRGB profiles installed (including ones that get packaged with printer drivers, that come with the OS, that come with Adobe software, etc.).

There is also the possibility that some drivers may respond differently if they see the document tagged with some flavor of sRGB, compared to some other profile.

[Scott Martin]

I’m confused. If you select say Adobe RGB Source and Destination, there’s no perceptual table so how does this make a difference when it should be using RelCol anyway?

I think this is one (of many) situations where we've got to put the theory aside an let the real world results speak for themselves. I agree with your logic about the Perceptual rending tables being absent, but after testing and seeing results, RelCol w/o BPC is clearly important so I've been putting my efforts there. I'm sure an answer to your question will present itself down the line...

[digitaldog]

I think this is one (of many) situations where we've got to put the theory aside an let the real world results speak for themselves. I agree with your logic about the Perceptual rending tables being absent, but after testing and seeing results, RelCol w/o BPC is clearly important so I've been putting my efforts there. I'm sure an answer to your question will present itself down the line...

I can see how BPC could affect this but rendering intent? If the table isn’t accessible, I can’t see how the results would be different. It has to be using the colorimetric table, at least at some point where the data is sent to the rest of the print chain. The question is, when one selects Perceptual (or Saturation) vs. Colorimetric, if there is a difference, what part of the print chain is doing this and what is being sent from Photoshop telling the print chain the data isn’t Colorimetric even though it seems it has to be.