Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Simon J.A. Simpson on April 18, 2017, 01:50:07 pm
-
After updating to El Capitan, and trying some experiments with the Adobe Color Printer Utility (ACPU), I noticed that the printed targets for profiling exhibited very different colours that those printed under Lion (10.7.5). I tried a variety of checks and ALL files without a profile attached (untagged) exhibit the same shift – darkening of the image and a loss of saturation. Some files below show the effect. The ones labelled “PS” are as displayed in Photoshop and replicated how they were printed in Lion. The ones labelled “ACPU” are as displayed in ACPU and print much as shown.
Has anyone else noticed this problem ? Is it the same in Sierra ?
-
Maybe I'm dense today, but I read this three times over and I don't understand what this comparison is. Did you do everything (underline everything) exactly the same except for the difference of OS version, or are there any (repeat any) other settings or printing arrangements that may have differed in what you did between OS 10.7 and OS 10.11? It seems strange because over the past several years I've upgraded my OS from 10.6.8 to 10.11.x and except for that incident we had with PS 2015.5, all my colour management has been working consistently.
-
Sorry, Mark, I may not have explained myself very clearly.
Printing the untagged targets from ACPU under Lion produced the correct results from which an accurate profile could be generated. Printing the same targets with everything the same, but under El Capitan, produced targets which were degraded (as shown). The images in my original post are for illustrative purposes to show the differences except that the screen shots of the targets in ACPU show fairly accurately how the targets actually print. This is irrespective of the target and is replicated with every untagged image (I even tried some other untagged images to check it wasn't just the targets).
I can create accurate and usable profiles using targets printed directly from the ColorMunki software, but ACPU will not print the targets correctly. My colour management is working fine and I can produce excellent prints using the profiles created from the ColorMunki software.
The only differences here are the operating system and that ACPU will not display or print untagged images correctly.
Have you recently tried printing targets from ACPU under El Capitan 10.11.6; and do they match targets printed under earlier Mac operating systems ? A quick test is to make an image containing maximum saturation CYM and RGB, and compare it in Photoshop and ACPU (in my illustrations the differences are somewhat obscured by the complex second target).
It would be good to know if this is a problem with ACPU and more recent iterations of the Mac operating system, or whether it is something particular to my system. It would also be good to know whether this is replicated under Sierra.
-
You *may* want to try printing via the Colorsync Utility and see how that output compares to ACPU under the different OS's. There is a pulldown that lets you 'print as target'
-
Sorry, Mark, I may not have explained myself very clearly.
Printing the untagged targets from ACPU under Lion produced the correct results from which an accurate profile could be generated. Printing the same targets with everything the same, but under El Capitan, produced targets which were degraded (as shown). The images in my original post are for illustrative purposes to show the differences except that the screen shots of the targets in ACPU show fairly accurately how the targets actually print. This is irrespective of the target and is replicated with every untagged image (I even tried some other untagged images to check it wasn't just the targets).
I can create accurate and usable profiles using targets printed directly from the ColorMunki software, but ACPU will not print the targets correctly. My colour management is working fine and I can produce excellent prints using the profiles created from the ColorMunki software.
The only differences here are the operating system and that ACPU will not display or print untagged images correctly.
Have you recently tried printing targets from ACPU under El Capitan 10.11.6; and do they match targets printed under earlier Mac operating systems ? A quick test is to make an image containing maximum saturation CYM and RGB, and compare it in Photoshop and ACPU (in my illustrations the differences are somewhat obscured by the complex second target).
It would be good to know if this is a problem with ACPU and more recent iterations of the Mac operating system, or whether it is something particular to my system. It would also be good to know whether this is replicated under Sierra.
OK, that's all very clear, and no - I have no problems printing fine targets from ACPU and El Capitan from which I generate highly accurate profiles for Epson printers; but not for Canon printers, for which latter it is recommended to use Canon's Print Studio Pro.
So this would suggest there is something going on at your end which isn't at mine.
-
Mark. Well one difference here is that I am using Canon printers whilst you are using an Epson. Hmmm, thinking… ?
-
Mark. I have attached a file which is an untagged TIFF. Would you mind opening this in ACPU and the ColorSync utility to see what you get ? You should see fully saturated CYM and RGB.
Thank you.
-
It should look like this.
-
Mark. Well one difference here is that I am using Canon printers whilst you are using an Epson. Hmmm, thinking… ?
OK, we can stop right there - I know the problem, as I use both Canon and Epson. You didn't say you are on Canon. Right. You cannot use ACPU with current Canon printers on recent Mac OSX versions; and I can't find out why. Anyhow, you should print the targets from Canon's Print Studio Pro with Color Management (or Color Correction) turned OFF in that application. This is why you are having a problem. Try printing your targets through the Canon utility and see what happens.
-
You *may* want to try printing via the Colorsync Utility and see how that output compares to ACPU under the different OS's. There is a pulldown that lets you 'print as target'
Howard. Well I did reply to this, and posted it, but it seems to have been eaten by the system !
I'll try to remember what I said. So…
I just tried this and, nope, the result is the same.
Interestingly, using the ColorSync Utility, I tried assigning a ‘display’ profile of ProPhoto RGB and this improved matters considerably. But assigning Adobe RGB degraded the image; and assigning sRGB degraded it even more.
If memory serves, the symptoms of darkened and desaturated targets occurred under the last ‘printing with no colour management’ debacle when it appeared that the OS was trying to insert an sRGB profile into the printing pipeline. I wonder… ?
-
OK, we can stop right there - I know the problem, as I use both Canon and Epson. You didn't say you are on Canon. Right. You cannot use ACPU with current Canon printers on recent Mac OSX versions; and I can't find out why. Anyhow, you should print the targets from Canon's Print Studio Pro with Color Management (or Color Correction) turned OFF in that application. This is why you are having a problem. Try printing your targets through the Canon utility and see what happens.
Mark. I tried to do this but couldn’t find this option in Print Studio Pro. I wondered if it is only available for some Canon printers from the Pro1000 up (I have a Pro 1 and and A4 office printer). I’ll have another root around and see if I can find it.
-
Mark. I tried to do this but couldn’t find this option in Print Studio Pro. I wondered if it is only available for some Canon printers from the Pro1000 up (I have a Pro 1 and and A4 office printer). I’ll have another root around and see if I can find it.
Let's leave the office printer out of this loop. The Pro 1, however should allow this through PSP, though I can't be sure because I never tested a Pro-1. This would be a question to put to Canon if you can't find out from the PSP manual. The version of PSP that ships with the Pro-1000 definitely allows you to turn off colour management toward the bottom of the panels you can scroll down the right side of the interface.
-
OK, we can stop right there - I know the problem, as I use both Canon and Epson. You didn't say you are on Canon. Right. You cannot use ACPU with current Canon printers on recent Mac OSX versions; and I can't find out why. Anyhow, you should print the targets from Canon's Print Studio Pro with Color Management (or Color Correction) turned OFF in that application. This is why you are having a problem. Try printing your targets through the Canon utility and see what happens.
OK. I've just had a root around and there doesn't seem to be any way of truing-off colour management. Having tried all the options available I assume this is to be found under the “Color Matching Method:” which remains stubbornly greyed-out and displays “OS Standard CMM”. I have the most up-to-date version 2.1.1.
There is this menu (see below). “Linear Tone” ? Could that be without colour management ?
Also, of course, this doesn’t explain the display variations as the printer driver will have nothing to do with this. Are you using the same version of El Capitan as me ?
-
Is your printer driver fully up-to-date.
According to this, you should have full functionality of PSP with Canon Pro-1 provided the driver is up to date:
PSP Manual CUSA (https://support.usa.canon.com/kb/index?page=content&id=ART165367&actp=LIST_POPULAR)
And yes, it should be under color matching method, but not greyed-out. I'm not sure "Linear tone" is the same thing as "No color management" in Canonese - somehow I doubt it.
-
Let's leave the office printer out of this loop. The Pro 1, however should allow this through PSP, though I can't be sure because I never tested a Pro-1. This would be a question to put to Canon if you can't find out from the PSP manual. The version of PSP that ships with the Pro-1000 definitely allows you to turn off colour management toward the bottom of the panels you can scroll down the right side of the interface.
A little internet research. You have to use the Color Management Tool Pro for the Pro 1.
-
Is your printer driver fully up-to-date.
According to this, you should have full functionality of PSP with Canon Pro-1 provided the driver is up to date:
PSP Manual CUSA (https://support.usa.canon.com/kb/index?page=content&id=ART165367&actp=LIST_POPULAR)
And yes, it should be under color matching method, but not greyed-out. I'm not sure "Linear tone" is the same thing as "No color management" in Canonese - somehow I doubt it.
Yes, latest versions of PSP and driver.
-
Mark (or anyone).
Have you had a chance to open the TIFF file I posted and see if it displays and prints correctly from ACPU (or the ColorSync Utility) – in either El Capitan or Sierra ?
I will try making a profile using Canon's utility. Previous attempts under Lion produced a profile that was complete rubbish (you had to have seen the 3D projection of the colour space to believe it !) but perhaps the newer version works correctly. I'll see; and report back.
-
Mark (or anyone).
Have you had a chance to open the TIFF file I posted and see if it displays and prints correctly from ACPU (or the ColorSync Utility) – in either El Capitan or Sierra ?
I will try making a profile using Canon's utility. Previous attempts under Lion produced a profile that was complete rubbish (you had to have seen the 3D projection of the colour space to believe it !) but perhaps the newer version works correctly. I'll see; and report back.
Yes, I have opened with ACPU the TIFF you posted and no, it does not look like the image you said it should look like. The reason is that ACPU is using sRGB as the preview colour space, which clips colours that are out of sRGB gamut, while Photoshop, when set to ProPhoto space shows the colours as you say they should be. I have provided two comparisons between ACPU and Photoshop, one where the latter's working colour space is set to sRGB (matches the ACPU view) and another where the working colour space is set to ProPhoto (does not match the ACPU view). None of this has anything to do with the real problem you are facing of printing profiling targets with the most recent OSX versions and Canon Printers: ACPU is not usable in this context for reasons that remain to be explained by anyone who knows this from the inside and is willing to respond.
-
Mark. Thank you very much for trying this. And, yes, I agree with diagnosis.
I will report back on using Canon's Color Management Tool Pro. I hope this works otherwise anyone with a Canon Pro 1, a Mac, and El Capitan (and perhaps Sierra) will be unable to print targets for profiling ! Not good. Unless you have a ColorMunki in which case you can print direct from the software (I assume this doesn't apply with the i1 Profiler and its ilk ?).
Much obliged for your patient advice.
-
I've spoken to Canon European Support and the Color Management Tool Pro is not supported beyond Mac OS 10.10.X.
They are investigating to see how targets can be printed without colour management to the Canon Pro 1 printer.
-
Interesting - one wonders how a "Pro" printer, could be left unable to support the printing of profiling targets. It's not as if this is a new issue, so I'm thinking perhaps they've had very, very little traffic from users of this printer model for that capability. It is, however, good to learn that they are investigating what they can do about it - which doesn't help you much in the short term, but may in the coming weeks or so.
-
I should have added - you did say above that you can print acceptable targets from the Color Munki software, so perhaps that's your best option for now.
-
I should have added - you did say above that you can print acceptable targets from the Color Munki software, so perhaps that's your best option for now.
Yes, I can; thankfully. But I was also thinking about other folk who may not yet realise that there is a problem. Be nice to get a fix. I'm really not sure why the Pro 1 cannot use Print Studio Pro, but perhaps my contact at Canon can help. He certainly seemed very willing.
-
In the service of further testing I tried creating a profile using the Canon Color Management Tool Pro.
It's complete rubbish (see the 3D projection from the ColorSync utility below). Exactly the same as with Lion. Bizarre.
-
Oh my goodness, and once in a blue moon I thought I generated the odd crappy profile whenever I saw little bits of unevenness on the edges. No, clearly that's a non-starter. Probably not worth wasting further time with. Best to use the profiling software until Canon produces a fix.
-
They are investigating to see how targets can be printed without colour management to the Canon Pro 1 printer.
Doess anyone know if this problem is confined to the Pro 1 or are other canon printers affected too ?
-
This appears to be only confined to the Pro 1.
First serving from Canon's technical support not helpful. Waiting for more.
I have confirmed that the option to be able to turn-off colour management in Print Studio Pro is not available for the Pro 1.
As things currently stand there is no way of printing targets remotely supplied (i.e. not printed from within proprietary profiling software), without colour management, for a Pro 1.
-
Doess anyone know if this problem is confined to the Pro 1 or are other canon printers affected too ?
I should add that Mark’s recommendation is that from El Capitan and later Canon Print Studio Pro should be used to print targets for all Canon printers with which it is compatible. ACPU and the ColorSync Utility will no longer print accurate targets.
Pro 1 users languish ignored in Canon's backwaters of sloth.
-
Pro 1 users languish ignored in Canon's backwaters of sloth.
From that table image it looks like Pro 10 & 100 series printers are also affected ?
-
Pro 1 users languish ignored in Canon's backwaters of sloth.
I would like to be clear that the above statement is yours, not mine. From my experience dealing with them, there are no "backwaters of sloth" in Canon's printing departments. Every decision they make has a background of supporting considerations that go through several levels of management internally. You or I may not necessarily agree with those considerations, but that is a different matter from "sloth". My sense is, on this particular one, that they probably didn't expect customers for certain models to want the capability to print profiling targets. What they provide depends heavily on their assessment of what the market asks for. I also know from first-hand experience that Canon is really serious about the printer market and they are very open to receiving customer suggestions - doesn't mean they will implement all of them, but at the very least, and as they can manage it, they will be carefully assessed. I believe you have already seen that in their response to you.
-
Mark. I think that the problem for Pro 1 users is that even though it is called a ‘professional’ printer it comes under their consumer rather their their commercial division (I read this in a review – was it on the Northlight website ?).
Thus, in your dealings with Canon in relation to your excellent reviews of the Pro1000 etc., no doubt you got good responses from their commercial team. Also, you are on a different continent. I'm here in the UK, shortly to excise itself from Europe. It is also clear that Canon have spent a great deal of time and effort ensuring their new professional printers are well supported with software etc.. Well done to them. Doesn’t really help us Pro 1 users though.
BTW, “Pro 1 users languish ignored in Canon's backwaters of sloth” = unsubtle attempt at humour. Apologies.
-
Latest…
Canon support have escalated the issue to the product specialist team.
-
Latest…
Canon support have escalated the issue to the product specialist team.
Nice; they DO listen. Thanks for the info.
-
Try using Apple's Colorsync Utility app. It's a free utility on the Mac. Open an untagged tif file of the profiling target. Select the "print as color target" option in the main menu located near the bottom when the submenu on that page is set to "colorsync utility" (this is the default page when you begin to print the image. Then adjust all your other settings like media choice you will navigate to by selecting the other submenu items.
One quirk is that the print as target option is not sticky. If you go back out of the printer driver, and than back in, you will need to reset that choice. I'd also check your submenu items to be sure, but I seem to recall them as sticky. Another quirk is if you use a 16 bit tif file, the preview will look weird in ACU, but it prints fine. I have successfully printed profiling targets using ACU for a Pro-1 and Pro-1000 and I'm currently on El Capitan as well. Once I figured out how to use ACU's print as color target feature, I rarely if ever use ACPU.
good luck,
Mark
http://www.aardenburg-imaging.com
-
Try using Apple's Colorsync Utility app.
Reply #9 on the first page says that doesn't work either.
-
Reply #9 on the first page says that doesn't work either.
I did read the whole thread quickly. Sorry I missed the fact you had tried ACU already. Yet it's a strange result... I build good ICC profiles using this utility, for both Canon Pro-1 and Pro-1000. No double profiling, no dull colors as if sRGB profile had gotten injected into the mix. I'm using Mac OS10.11.6. Not sure what else might be going on in your situation.
kind regards,
Mark
-
I did read the whole thread quickly. Sorry I missed the fact you had tried ACU already. Yet it's a strange result... I build good ICC profiles using this utility, for both Canon Pro-1 and Pro-1000. No double profiling, no dull colors as if sRGB profile had gotten injected into the mix. I'm using Mac OS10.11.6. Not sure what else might be going on in your situation.
kind regards,
Mark
I believe we have established fairly conclusively that there is indeed a problem printing accurate targets using ACPU under mac OS X El Capitan (and perhaps Sierra). See post #8. Mark Segal has undertaken detailed and exhaustive printer testing and I would trust his conclusions. If you have made any profiles recently under El Capitan you might want to review and check them.
-
I believe we have established fairly conclusively that there is indeed a problem printing accurate targets using ACPU under mac OS X El Capitan (and perhaps Sierra). See post #8. Mark Segal has undertaken detailed and exhaustive printer testing and I would trust his conclusions. If you have made any profiles recently under El Capitan you might want to review and check them.
I was taking about Apple Colorsync Utility (ACU) not ACPU, but just to make sure ACU is still able to print correctly to the Pro-1 driver in "print as color target" mode, I just performed the following steps.
1) Checked my Pro-1 Firmware. It is up to date.
2). Checked my Pro-1 driver version. It was 13.7.1.0, which was not the latest, so I just updated today. It is now latest version 16.11.0.0
3) Sent untagged TC918 color target to printer, using "print as color target" in ACU and made sure all other media settings were correct and sticky (i.e. not defaulting to something else).
4). I just looked at the print which finished a few minutes ago. It is a correctly printed untagged, non color managed output! What more can I say, other than the fact that I've been making ICC profiles for 25 years, and over that time I have learned to recognize instantly whether the chosen color target has printed with color management truly turned off.
Only advice I can give at this point is to make sure printer driver and firmware are up to date. Also, even if up to date, uninstall the driver in Mac system preferences "printers and scanners" menu, restart computer then reinstall the driver. This step alone can sometimes fix Mac printing problems. Also take your target image into PS and recheck to make sure it is truly an untagged file. If not, PS can unembed any embedded profile. Then give ACU "print as color target" feature another try.
good wishes,
Mark
http://www.aardenburg-imaging.com
-
I was taking about Apple Colorsync Utility (ACU) not ACPU, but just to make sure ACU is still able to print correctly to the Pro-1 driver in "print as color target" mode, I just performed the following steps.
1) Checked my Pro-1 Firmware. It is up to date.
2). Checked my Pro-1 driver version. It was 13.7.1.0, which was not the latest, so I just updated today. It is now latest version 16.11.0.0
3) Sent untagged TC918 color target to printer, using "print as color target" in ACU and made sure all other media settings were correct and sticky (i.e. not defaulting to something else).
4). I just looked at the print which finished a few minutes ago. It is a correctly printed untagged, non color managed output! What more can I say, other than the fact that I've been making ICC profiles for 25 years, and over that time I have learned to recognize instantly whether the chosen color target has printed with color management truly turned off.
Only advice I can give at this point is to make sure printer driver and firmware are up to date. Also, even if up to date, uninstall the driver in Mac system preferences "printers and scanners" menu, restart computer then reinstall the driver. This step alone can sometimes fix Mac printing problems. Also take your target image into PS and recheck to make sure it is truly an untagged file. If not, PS can unembed any embedded profile. Then give ACU "print as color target" feature another try.
good wishes,
Mark
http://www.aardenburg-imaging.com
Hi Mark H M-G. Thank you for your test and advice.
I tried another test.
Mac OSX 10.11.6
Untagged TIFF – double checked with PS and Preview.
Canon Pro 1 Firmware Version 2.110 (as per test page).
Canon CUPS driver 16.11.0.0.
I have made two prints following your instructions to the letter; one from my iMac and one from my MacBook Pro.
Both prints are not correct (expected symptoms); and are identical. I double checked the all my settings. All OK.
This is very puzzling.
Just out of interest, how does my test image print for you (posted earlier) ? See #6 and #7.
-
I'm not puzzled. Unless one has highly unusual visual accuity and memory relative to normal human visual perception, we cannot confidently predict from simply looking at a profiling target, regardless of how many we have made and looked at, whether the profile made from such target will perform accurately. I've made and looked at enough of them, then tested their accuracy on all kinds of paper to be quite convinced of this. It would be interesting if Mark MCG could use his target that he says looks good for making a test print with known reference values that he can then measure with a spectrophotometer and tell us what the dE(76) readings are.
-
I'm not puzzled. Unless one has highly unusual visual accuity and memory relative to normal human visual perception, we cannot confidently predict from simply looking at a profiling target, regardless of how many we have made and looked at, whether the profile made from such target will perform accurately. I've made and looked at enough of them, then tested their accuracy on all kinds of paper to be quite convinced of this. It would be interesting if Mark MCG could use his target that he says looks good for making a test print with known reference values that he can then measure with a spectrophotometer and tell us what the dE(76) readings are.
I firmly disagree with Mark S., but with one caveat. Mark S. is correct that visual assessment of the printed test target is very difficult if not a fool's game when one is using scrambled patch ICC test targets, or the "striped pattern" ones like i1Profiler makes as standard. However, the TC918 pattern as supplied in Profilemaker 5.1 software has a beautiful visually ordered arrangement of colors and tones as originally designed by Bill Atkinson. It does indeed allow one to inspect it visually and know in advance whether the non managed color target path is working right. I never said one could tell final profile accuracy by looking at the test target any more than one can judge the output from a well-built 1000 patch ICC profile compared to the output from a well built 5000 patch profile without going through more analytics. But you sure can tell whether the non color managed printer path got broken!
I will be happy to turn that target print into a full blown ICC profile tomorrow, just as proof of principle (yet again like I've done hundreds and hundreds of times before). Will let you know the results from printing with said profile tomorrow. The media I used to run the test target test today was Canon Photo Pro Plus Semigloss.
I stand by my earlier statements, and will further confirm tomorrow. Mac OS El Capitan with latest Canon Pro-1 firmware and driver software is not breaking Mac's Colorsync Utility "print as color target" feature on my Mac computer. I don't dispute that something isn't working right for the OP, but to argue that OP's outcome overrides my outcome on my system, implies I don't understand the ICC profiling process, and thus is, frankly, a bit condescending.
best,
Mark
http://www.aardenburg-imaging.com
-
.............but to argue that OP's outcome overrides my outcome on my system, implies I don't understand the ICC profiling process, and thus is, frankly, a bit condescending.
best,
Mark
http://www.aardenburg-imaging.com
Who ever implied you don't understand the profiling process? You saw one thing, Simon thought you were talking about ACPU but you clarified it was ACU and saw something else and I questioned whether one can come to reliable conclusions just by looking at the target (I doubted it, but you say you can because you have a particular version that facilitates this; fine). So? The idea is to help the OP get the issue sorted out with facts, tests, numbers and - for him - workable procedures. Throwing around descriptors like "condescending" when there is no apparent intent doesn't help anyone or anything. I appreciate your experience, interest and effort even while I can question this or that idea, and I have no doubt the same applies to the OP, whose main interest is to solve a problem. There's a straightforward technical path for both of you to come to a common understanding on all of this and I too have an interest in seeing the outcomes. So full throttle forward.......
-
... You saw one thing, Simon thought you were talking about ACPU but you clarified it was ACU and saw something else and I questioned whether one can come to reliable conclusions just by looking at the target
So that we are not going around in circles here, did or did not Simon follow up his ACPU test with a test of the "print as color target" feature in ACU?
If not, the ball is in Simon's court. I say ACU works fine using the "print as color target" feature with El Capitan and latest Pro-1 firmware and driver to produce non color managed output. If I'm wrong, we can all have a good laugh later. If I'm right, but it doesn't work for Simon, then the mystery of our discrepancy remains unsolved at this point in time
best,
Mark
http://www.aardenburg-imaging.com
-
I think we're waiting for Simon to try what you suggested. If it works, we're done. If it doesn't, then its most likely some difference in settings and *shouldn't* be hard to sleuth it. I'm using those ** because in this business wonders never cease. :-)
-
I think we're waiting for Simon to try what you suggested. If it works, we're done. If it doesn't, then its most likely some difference in settings and *shouldn't* be hard to sleuth it. I'm using those ** because in this business wonders never cease. :-)
Tracking back to reply #9, it does appear Simon tried ACU, but did not have success. However, that post further describes attempts to assign source profiles to the target while using ACU, which, with all due respect, was a total waste of time, ink, and media. The "print as color target" feature has to be invoked correctly in ACU. When that step is done correctly, all other ICC profile options are greyed out. And if further attempting to use the "Color matching" submenu item in the printer driver, ACU greys that option out as well when "print as color target" feature has been properly invoked. The greyed out nature of the "Color matching" menu items is a very good way to check on the Mac if color management has indeed been turned off. If the Canon driver further imposes an RGB transformation of the incoming unmodified data from ACU, then it is indeed a bug in the Canon driver, and I have seen that with some Canon drivers before. However, I used the ACU "print as color target" feature today to print to my Pro-1 and am entirely confident I produced non color managed output notwithstanding Mark S.'s doubts about my claim.
I also confirmed that I could still use ACU successfully with latest firmware and software by updating my older Pro-1 driver version. I also just now checked to find that Canon's Print Studio Pro software does indeed support "no color correction" for my Pro-1000, but not for my Pro-1, or Pro-100, thus confirming what the Canon-provided table posted earlier appears to document, i.e., that the "no color correction" menu item is apparently a feature of imageprograf models Pro-1000, 2000, and 4000 only. This leaves Colormunki sofware, i1profiler software, and ACU as best bets for non color managed target output to Pro-1, Pro-10, and Pro-100 models, and i1profiler and ACU both work for me in this regard on my system. I don't own a Colormunki, but I have not reason to believe Xrite isn't using essentially the same code for both Colormunki and i1Profiler to overide the normally enforced color management pathway on the Mac.
Simon, may I suggest you give ACU another go? If you still can't make it work, then I suspect it will be challenging in an open forum setting to try to figure out why it works for me and not you given that we both seem to be using the same printer firmware and software on same Mac OS El Capitan version.
later,
Mark
-
Mark S and Mark HMG. I tried using the Apple ColorSync Utility, the results of which were posted at #38.
in conclusion, I cannot print accurate targets using either the ‘Adobe Color Print Utility’ nor the ‘Apple ColorSync UtilityÆ, nor ‘Canon Print Studio Pro’. In the former two because the targets prints are not accurate (and I am using a reference print to compare them to) and in the latter because the option to print without colour management is not available.
I am awaiting the results of Canon's technical support’s escalation. They have been very responsive and are taking the issue seriously.
Let's see what they have to say.
I am happy to undertake more tests as suggested.
-
Somehow or other, my response to post 44 last night didn't "take" - anyhow it was mainly to agree with Mark MC-G that the targets need to be printed without assigning ANY profiles ANYWHERE in the imaging pipeline. So Simon, if you did assign profiles in the print process, it was an incorrect procedure and you can't tell from that whether printing from ACU will or will not work correctly for you. As you are willing to do another test, may I suggest that you replicate exactly the steps that Mark MC-G listed in his previous posts, making sure that there are no profiles assigned anywhere in your print pipeline (it all needs to be profile-free, un-managed), and then see whether you have an acceptable outcome. Do let us know.
-
Somehow or other, my response to post 44 last night didn't "take" - anyhow it was mainly to agree with Mark MC-G that the targets need to be printed without assigning ANY profiles ANYWHERE in the imaging pipeline. So Simon, if you did assign profiles in the print process, it was an incorrect procedure and you can't tell from that whether printing from ACU will or will not work correctly for you. As you are willing to do another test, may I suggest that you replicate exactly the steps that Mark MC-G listed in his previous posts, making sure that there are no profiles assigned anywhere in your print pipeline (it all needs to be profile-free, un-managed), and then see whether you have an acceptable outcome. Do let us know.
My apologies, my post #9 may have added to the confusion.
In my latest test at #38 I can assure both Marks that no colour management was used, no profiles assigned; and I double checked the printer dialogue just to be sure (all possibilities for colour management were greyed-out). And I did actually say that I had followed Mark HMG’s instructions to the letter ! I promise you I did too ! :)
I am open to the possibility of user error here; but as yet we have not been able to discover what that might be ?
It will be interesting to see what Canon come back with. This might shed some light.
-
OK Simon, thanks for clarifying. So now I need to put the same issue to you that I addressed to the other Mark yesterday: how do you know the real quality of your target prints? What exactly did you compare them against? Have you tried making and testing a profile with them?
-
I followed through with Mark S.'s request by building a custom ICC profile from the ACU printed test target using i1Profiler set to it "Colorful" default setting. The TC918 target has a 9x9x9 grid of RGB color patches that gets used to build the profile. I'm not sure whether i1profiler uses all 918 patches or just the 729 patches of the grid, but very decent profiles get built with the TC918 target if the printer is running properly and the target was successfully printed with color management turned off.
I have attached two screenshot views comparing the color gamut volume of Canon's generic supplied Pro-1 printer profile for the Canon PPPSG paper to the gamut volume created by the custom i1Profiler/TC918 profile I built with the ACU printed color target. The red color in the graphs is for the generic profile. The Blue color shows the gamut volume of my custom made profile. As can be seen in the two views, the custom profile produced a slightly larger gamut volume than the generic Canon profile on my Pro-1 printer. However, this is probably not of practical significance. The more important fact is that the overall gamut volume shape of the two profiles are totally consistent with each other which would not occur if ACU had failed to produce a non color managed target outcome.
That said, gamut volumes only address the potential of the system to make colors not the accuracy of the colors produced on the print by the profile. So, I did a quick and dirty test to verify and compare the printed output accuracy of both profiles. I made two color prints using a digital image of a Macbeth ColorChecker Chart with colorimetrically perfect embedded lab values of all the colors and using perceptual rendering intent for both prints. One print was made with the Canon supplied Pro-1 generic profile for the PPPSG paper, the other with the custom i1Profiler-built profile. Both prints showed the merits of color managed output, but to my eye under controlled lighting the generic profile produced a noticeably darker print than the custom profile yet with hue and chroma accuracy being in close agreement between both prints. I preferred the lighter version created by my custom profile and when placing both prints side by side an actual ColorChecker chart, the lighter version of the print was the better overall match, IMHO. I then spot checked a few of the color patches with an i1Pro2 spectrophotometer to confirm my visual impression of both prints. Here are a few measured values. I could have measured all 24 patches, but these three pretty much tell the story. Note the L* values in particular. The generic proflle was printing patches 4-6 L* units darker than the custom profile throughout most of the midtone tonal range, while a* and b* values are very close for both prints. The custom profiled print is the colorimetrically better match to the actual ColorChecker reference target owing to the significantly better agreement on L*. Most viewers would prefer the lighter print if they saw it side by side the actual ColorChecker, although without a direct comparison many amateur printmakers would probably be satisfied with either print.
Actual Colorchecker value Printed value Generic ICC, Printed value Custom ICC
mid tone gray LAB = 51, 0. 0 LAB = 42, -1, -1 LAB = 48, 0, -1
Black patch LAB = 20, 0, -1 LAB = 14, 0, -2 LAB = 18, 0, -2
Skin tone LAB = 66, 18, 18, LAB = 58, 18, 19 LAB = 64,16,16
So, to summarize: I was able to use ACU running under Mac OS El Capitan, and also with the latest Pro-1 firmware, and the latest Pro-1 printer driver to successfully print a non color managed ICC profiling target. The 918 color patches were then measured and used to make a properly performing custom ICC profile, one that essentially exceeds the quality of the generic Canon supplied profile on my Pro-1 print unit by virtue of better tonal fidelity while maintaining comparable hue and chroma accuracy.
My conclusion is that Simon's issue is unlikely to be a bug in the Canon driver (although I've seen Canon drivers with real bugs before :) ) nor in ACU, otherwise I should have duplicated Simon's results and concurred that ACU wasn't giving proper output. That leaves the million dollar question. Why is Simon unable to duplicate my results given that we appear to have exactly the same OS, same printer model, same printer driver, and same ACU software to "print as color target"? Simon, if you haven't already done so, try deleting your printer driver in the Mac System preferences pane, rebooting your computer from full off mode (not just a restart), and then re-add the driver back into the Mac's printer cue. This trick goes a long way to curing many strange printer woes on a MAC, but I'm stumped to suggest anything else if that doesn't work. Hopefully, Canon can give you some other ideas.
best,
Mark
http://www.aardenburg-imaging.com
-
This is very interesting Mark in that it provides reasonable evidence that the ACU is a workable approach for printing profiling targets. Useful contribution, thanks for doing it.
I was going to try something similar this morning, but every time I tried to open Colorsync Utility all I got was a non-stop spinning beach ball, so I Forced Quit it, sent a report to Apple and moved on to other things (that do work).
Anyhow, the remainder of this story is to understand why Simon isn't doing as well as you did, so let's see what he comes up with next.
-
I was going to try something similar this morning, but every time I tried to open Colorsync Utility all I got was a non-stop spinning beach ball, so I Forced Quit it, sent a report to Apple and moved on to other things (that do work).
Yes, if there's an achilles heel to ACU it's that its performance is very MAC OS version sensitive because Apple treats it a little bit like a step child. So, it performs poorly on some older versions of Mac OS, fairly but not perfectly in the latest update to Mac EL Captan, and I have no idea how it does in MAC Sierra because I'm not yet willing to make the upgrade. I'm worried about my HPZ3200 printer driver's performance on Sierra, so will probably freeze my current machine on El Capitan, eventually move to Sierra when I buy my next Mac.
Because Simon and I are both on the same Mac OS version, we should be experiencing similar ACU performance.
-
I'm on El Capitan and am not upgrading to Sierra until I can have confidence in its reliability. So ACU is not functioning properly even on "recent" versions of OSX. Not surprising. Apart from the operating system (once they debug the updates) I find Apple software in general underwhelming, so I'm not surprised about this. "It just works" was a 20th century concept. But that's a whole other talk-show.
-
I'm on El Capitan and am not upgrading to Sierra until I can have confidence in its reliability. So ACU is not functioning properly even on "recent" versions of OSX. Not surprising. Apart from the operating system (once they debug the updates) I find Apple software in general underwhelming, so I'm not surprised about this. "It just works" was a 20th century concept. But that's a whole other talk-show.
Well, I do hope I'm not the outlier, but based on other responses in this thread, it seems like maybe I am. ACU works reliably for me on Mac OS 10.11.6, and so does ACU's "print as color target" feature when printing to the same printer, firmware, and driver software that apparently is not working well for Simon. And it works reliably for me with any number of other printers I presently have in my studio (Canon Pro-1000, Canon Pro-100, Epson P600, Epson P400, Epson 3880, and more). That said, I do tend to agree that, "it just works" is a quaint reminder of the "good ole" days on Mac computers.
-
Marks both…
First, my thanks to you both; particularly to Mark HMG for all the trouble you have taken on my behalf.
I have undertaken some extensive testing and believe I have gotten to the bottom of this.
The issue has, for me, been clouded by a couple of factors.
Deprecated Test File
I was using my simple test file, posted earlier, as a quick check as to whether ACPU and ACU were printing untagged targets correctly. It transpires that the file had been deprecated at some point in the past (I have my suspicions here) and that the values printed were not 100% RGB and CYM. The file has now been rectified.
New Tests
I printed the new file with ACPU and ACU and both now appear to be printing correctly in that fully saturated patches of ink are being laid down. I measured patches of prints from both pieces of software and they correlate to each other to within 1–2%. I would take this to be good enough for confirmation of a correlation. Marks both, you will have to forgive me as I do not have the sophisticated measuring instruments and software at your disposal and have to rely on my ColorMunki to make measurements.
I then re-did the test with some untagged targets, which correlated with each other. Some measurements of a few patches confirmed this.
I visually compared the prints of targets and my test file with earlier historical prints and this confirms that ACPU and ACU are printing untagged targets correctly.
I believe I can now confirm that ACU and ACPU are indeed working correctly under El Capitan, as Mark HMG says, and that I was being misled by the deprecated test file.
However.
Display of Untagged Images
I noticed that untagged images (targets) are displayed differently in Photoshop, ACPU and ACU (quick off-screen measurements confirm this). The differences between ACPU and ACU are very small and (with limited testing) do not seem to be reproduced in printing. The difference between Photoshop (CC 2017) and the other two is marked. It looks to me as if Photoshop is clipping colours at the saturated end whereas ACPU and ACU are not. ACPU and ACU displays are retaining a fair representation of the differences between patches in the file whereas Photoshop is not. The Photoshop images look much brighter and well saturated which is why I did not immediately recognise that my test file was deprecated (and the visual difference is almost zero between the old and rectified files). I tried turning-off colour management in Photoshop but this made no difference to the display of both files. Just to be absolutely clear I did not make prints of untagged images from Photoshop – for obvious reasons !
Creating Untagged Files for Printing in ACPU/ACU
This issue arose when I was trying to use ACPU to print targets from the ColorMunki software (there is an earlier posting of mine on how to do this). Whilst my earlier method worked well and produced good profiles (under Lion) when I updated to El Capitan and the later versions of Photoshop I was unable to create accurate target files (they were badly deprecated having appeared to have been tagged with sRGB somewhere in the process). Long story short. It transpires that in order to retain the file without some element of colour management being introduced you have to ensure that Photoshop’s colour management is turned-off before importing the file from ColorMunki. This then gives correct untagged target files for printing from ACPU/ACU.
Thank You
So, Mark S and Mark HMG, a big thank you for your efforts and advice on my behalf. This really demonstrates the value of forums such as LuLa where being able to discuss and explore issues with others (particularly the more experienced and knowledgeable) helps to diagnose a complicated problem and in the end benefits all of us.
-
I spoke with Canon this morning and passed-on the news that printing untagged targets through ACPU and ACU is working satisfactorily; as well as offering my grovelling apologies. They were just pleased that the issue had been satisfactorily resolved.
I did leave with them the suggestion to allow, in a future update, Canon's Print Studio Pro to print targets without colour management as it can for the Pro 1000 and Pro 2000 printers.
-
Glad you got to the bottom of it, and good feedback to Canon.
-
Display of Untagged Images
I noticed that untagged images (targets) are displayed differently in Photoshop, ACPU and ACU (quick off-screen measurements confirm this). The differences between ACPU and ACU are very small and (with limited testing) do not seem to be reproduced in printing. The difference between Photoshop (CC 2017) and the other two is marked. It looks to me as if Photoshop is clipping colours at the saturated end whereas ACPU and ACU are not. ACPU and ACU displays are retaining a fair representation of the differences between patches in the file whereas Photoshop is not. The Photoshop images look much brighter and well saturated which is why I did not immediately recognise that my test file was deprecated (and the visual difference is almost zero between the old and rectified files). I tried turning-off colour management in Photoshop but this made no difference to the display of both files. Just to be absolutely clear I did not make prints of untagged images from Photoshop – for obvious reasons !
Somewhere around PSCS6 photoshop became a fully color managed environment with no way around, partly in response to some of the operating changes Apple was making to its OS. Hence, Adobe had to create the separate ACPU software to deal with target printing. Apple later stepped up and added the "print as color target feature" to ACU as well.
Thus, when you bring in an untagged image into PS, photoshop will color manage it anyway, by assuming it has the same colorspace as your chosen working space setting found in the "color settings" menu. So if you have sRGB set in your color settings menu, then untagged image will look quite different than if you set your working space to aRGB or prophoto, and of course prophoto will show many clipped colors on an ICC profiling target which inevitably has RGB triplets that would specify a color way beyond your monitor's gamut. I really don't know what ACU and ACPU do, but my guess is they just use your monitor's display profile and leave it at that. So, the moral of the story is don't worry about what the target looks like in PS, or ACU, or ACPU, Just worry that the print is truly non color managed, and as I noted in earlier discussion, if you are using an ordered target with a nice visual progression of colors (not scrambled colors) then judging whether color management got turned off correctly is just a matter of getting some visual experience looking at the printed target. I print the Bill Atkinson designed TC918 test target so often that I know what it should and shouldn't look like in my sleep :).
Creating Untagged Files for Printing in ACPU/ACU
This issue arose when I was trying to use ACPU to print targets from the ColorMunki software (there is an earlier posting of mine on how to do this). Whilst my earlier method worked well and produced good profiles (under Lion) when I updated to El Capitan and the later versions of Photoshop I was unable to create accurate target files (they were badly deprecated having appeared to have been tagged with sRGB somewhere in the process). Long story short. It transpires that in order to retain the file without some element of colour management being introduced you have to ensure that Photoshop’s colour management is turned-off before importing the file from ColorMunki. This then gives correct untagged target files for printing from ACPU/ACU
PS offers various way of dealing with untagged targets when they open. One choice is that it will immediately assign your working space profile. Another is "ask me what to do", and another is "don't color manage the document" which assigns no tag but display the untagged file as per the discussion above. My guess is your PS version is currently set to immediately assign the working space profile to any untagged target, and BTW PS does allow you to unembed profiles, You want to be aware of these PS behaviors any time you open a colormunki target (or any other profiling target file for that matter) in PS.
Glad you got things sorted.
best,
Mark
http://www.aardenburg-imaging.com
-
..............I really don't know what ACU and ACPU do, but my guess is they just use your monitor's display profile and leave it at that. ...........
best,
Mark
http://www.aardenburg-imaging.com
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.
-
Somewhere around PSCS6 photoshop became a fully color managed environment with no way around, partly in response to some of the operating changes Apple was making to its OS. Hence, Adobe had to create the separate ACPU software to deal with target printing. Apple later stepped up and added the "print as color target feature" to ACU as well.
I know, I was actively involved in this.
Thus, when you bring in an untagged image into PS, photoshop will color manage it anyway by assuming it has the same colorspace as your chosen working space setting found in the "color settings" menu.
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.
judging whether color management got turned off correctly is just a matter of getting some visual experience looking at the printed target
I have this experience. :) :) :)
PS offers various way of dealing with untagged targets when they open. One choice is that it will immediately assign your working space profile. Another is "ask me what to do", and another is "don't color manage the document" which assigns no tag but display the untagged file as per the discussion above. My guess is your PS version is currently set to immediately assign the working space profile to any untagged target, and BTW PS does allow you to unembed profiles, You want to be aware of these PS behaviors any time you open a colormunki target (or any other profiling target file for that matter) in PS.
I always use “Ask When Opening”. I don't then assign a profile and Photoshop opens it untagged.
-
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.
-
... 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.
-
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.
-
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.
-
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
-
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.
-
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.
-
... 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
-
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.
-
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
-
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.
-
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
-
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.
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.
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.
-
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.
-
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.
-
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
-
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.
-
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.
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.
-
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.
-
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.
[ 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.
-
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 am confused. Where are all these other options other than in the Color Settings dialogue ?
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.
I have this set as default. Have for a very long time.
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…
This is interesting, as it was well documented some years back that the null transform method stopped working on the Mac after a update to the OS or PS (not sure which now). I confirmed this for myself and so stopped using it, substituting ACPU to print targets instead. Doug and you seem to be saying this is working again. Can one, or both of you, confirm whether this has been tested on a Mac ? And, if so, which version of OS and Photoshop it you have confirmed this with ? Thank you.
-
This is interesting, as it was well documented some years back that the null transform method stopped working on the Mac after a update to the OS or PS (not sure which now). I confirmed this for myself and so stopped using it, substituting ACPU to print targets instead. Doug and you seem to be saying this is working again. Can one, or both of you, confirm whether this has been tested on a Mac ? And, if so, which version of OS and Photoshop it you have confirmed this with ? Thank you.
This was my understanding as well. But, as I stated earlier in the thread, I'm a Windows Photoshop user. After Adobe removed the no color management option I have made a point of checking the null-transform on subsequent updates from Adobe and Microsoft and so far it works flawlessly.
What exactly happened that caused Adobe to do this I don't know. I suspect some sort of metadata in the printer data path that was interfering with the null-transform. What goes on in Mac OS's data path is quite opaque. Not that Windows isn't opaque too but it hasn't had these peculiar, unasked for, transforms. At least as of today.
-
What exactly happened that caused Adobe to do this I don't know.
It was Apple that forced the issue...it was Adobe who basically figured out the null transform work-around but that didn't fit into Apple's ecosystem view so Adobe undid the work-around :~(
-
Thanks for clarifying that Jeff.
-
This is interesting, as it was well documented some years back that the null transform method stopped working on the Mac after a update to the OS or PS (not sure which now).
As far as I am aware, programmatically the null transform "trick" is the only method available for displaying non-color managed color on secondary displays with OS X >= 10.6, while it doesn't work on OS X < 10.6 where using an explicit Device Color call is sufficient.
[ As a programmer, this seems like a straight up bug on Apples part. ]