i1Profiler issue: Not able to print target

[Doug Gray]

I found a stock of 4x6 Epson premium gloss, that I would like to use for snapshot printing on my Pro-100. The generic Canon "other glossy" profile doesn't work very well, so I decided to crank out my own.  I have 8.5x11 Epson premium gloss, so I printed a two page i1Profiler auto generated target, untagged image in Photoshop, "Printer manages colors" in Photoshop, and an appropriate media choice in the Canon print driver with color management turned off.

The targets look ok, and they are the correct size, no shrinkage.  I'll let them dry, and will report back as to the profile performance.

Richard Southworth

Anytime you make a target for profile generation and don't use ether the ACPU or direct printing from the profiling software, you should check the process by testing the quality of the print profiles. An easy check is a set of patches from Bruce Lindbloom that are in multiples of 10 over L*, a* and b*. Print them out using Abs. Col Intent and measure them. For the ones in gamut, they should be quite close and nearly always less than 2 dE in error.
http://www.brucelindbloom.com/ProfileEvaluation.html

[Mark D Segal]

Anytime you make a target for profile generation and don't use ether the ACPU or direct printing from the profiling software, you should check the process by testing the quality of the print profiles. An easy check is a set of patches from Bruce Lindbloom that are in multiples of 10 over L*, a* and b*. Print them out using Abs. Col Intent and measure them. For the ones in gamut, they should be quite close and nearly always less than 2 dE in error.
http://www.brucelindbloom.com/ProfileEvaluation.html

No question that it's thorough, but because of that, for most purposes far too much work - that's 11 pages of printing, target scanning and measurement - yipes. Firstly, one should measure only colours that are in-gamut relative to the capabilities of the profile/paper/printer being evaluated. OOG colours screw-up the accuracy testing royally. Secondly, a much smaller sample set would tell one what needs to be known.

[digitaldog]

So here's the question - can somebody tell me why the combination of Photoshop CC set to "Printer Manages Colors" and the print driver set to color management off, is not an appropriate method for target printing, specifically for a W10 system?

Since Photoshop CS (?; can't recall exact version), you can't print without color management. Printer Manages Color isn't doing that and in fact, on Windows, everything you send out using that mode gets converted to sRGB! You need to use the process defined by the profile maker software, ACPU or some other application designed for this task to print the targets correctly. Or a very old copy of Photoshop that had either the No color management option in the Print dialog or a slightly newer one that allowed you to use the old "null profile" trick which Adobe later coded to stop working without posting a warning to download ACPU.

[Doug Gray]

No question that it's thorough, but because of that, for most purposes far too much work - that's 11 pages of printing, target scanning and measurement - yipes. Firstly, one should measure only colours that are in-gamut relative to the capabilities of the profile/paper/printer being evaluated. OOG colours screw-up the accuracy testing royally. Secondly, a much smaller sample set would tell one what needs to be known.

Indeed.  When I mentioned I use a "set of patches" it was not the complete set of images but a selection of in gamut patches from the Lab images. I have a collage of some from each of the L=10 through L=90 that Fit on a 4x6" as I've had exactly the same issue with small paper sizes that can't be realistically scanned directly and have to be spot measured and checked against a larger paper size profile. Before I made the collage I just printed the L30,50, and 70 images and checked them. The L=0 and 100 images should be ignored as they are just there for completeness.

The view proof out of gamut mask in Photoshop works well to locate suitable patches but they should be at least 20 units from a boundary because the mask only detects colors that are 6 dE or more beyond the gamut.

[Mark D Segal]

The view proof out of gamut mask in Photoshop works well to locate suitable patches but they should be at least 20 units from a boundary because the mask only detects colors that are 6 dE or more beyond the gamut.

The other thing one can do is use ColorThink Pro's Color Worksheet and 3D grapher functions to visually see ever colour that fits within a profile space by overlaying the patch data with the gamut of the paper/printer profile. I believe this should be a lot more precise than using Photoshop's gamut warning.

[Rhossydd]

Since Photoshop CS (?; can't recall exact version),

CS4 was teh last version to be able to print without colour management.
That's one reason I've never upgraded since ..... and not regretted it at all.

Nice to see you back Andrew :-)

[Doug Gray]

The other thing one can do is use ColorThink Pro's Color Worksheet and 3D grapher functions to visually see ever colour that fits within a profile space by overlaying the patch data with the gamut of the paper/printer profile. I believe this should be a lot more precise than using Photoshop's gamut warning.

I agree. Much better. However, I found that as long as you are 20 dE away from the gamut mask the colors are in the printable gamut. The advantage is there is no need to own any other software, just the measuring device.

However, that's what I did 10 years ago as a free, crude but effective quick check.

My preferred tools these days are Patchtool and, for detailed analysis, Matlab. For this purpose Patchtool has a built in patch generation for creating similar in-gamut Lab patches. It outputs both tif and CGATS with an excellent compare tool for checking the measured print results. It's also only about $100 or so. Patchtool is hard to beat for cost/value in print accuracy testing.

I've had Colorthink Pro for almost 10 years and it makes some beautiful plots/graphs but find it much too slow when working with a large image color set. Matlab runs a couple orders of magnitude faster and, being program oriented, makes it much easier to do custom "what-ifs." Most of the stuff I do/did was creating specialized test charts where Matlab can do what just isn't available with any other tools I've seen.  But it's also very pricey w/o an academic subscription.

[rasworth]

Let's forget profiling for the moment, and concentrate on Andrew's statement, i.e. PS modifies the rgb values to the printer driver even though "Printer Manages Color" is invoked.  This is in direct opposition to the description statement in the print dialog box, screenshot attached.  So has Photoshop seen the error of their ways and corrected this problem?  How do we find out for sure?  I couldn't come up with any reliable way to print to a file so I could measure the actual rgb values sent to the printer driver.

Richard Southworth

[Mark D Segal]

I agree. Much better. However, I found that as long as you are 20 dE away from the gamut mask the colors are in the printable gamut. The advantage is there is no need to own any other software, just the measuring device.

However, that's what I did 10 years ago as a free, crude but effective quick check.

My preferred tools these days are Patchtool and, for detailed analysis, Matlab. For this purpose Patchtool has a built in patch generation for creating similar in-gamut Lab patches. It outputs both tif and CGATS with an excellent compare tool for checking the measured print results. It's also only about $100 or so. Patchtool is hard to beat for cost/value in print accuracy testing.

I've had Colorthink Pro for almost 10 years and it makes some beautiful plots/graphs but find it much too slow when working with a large image color set. Matlab runs a couple orders of magnitude faster and, being program oriented, makes it much easier to do custom "what-ifs." Most of the stuff I do/did was creating specialized test charts where Matlab can do what just isn't available with any other tools I've seen.  But it's also very pricey w/o an academic subscription.

Yes, Patchtool is a go-to application, and Danny's manual is an education. Matlab - good for those with a fairly deep math background, but from what I see on their website, not terribly expensive - a "home" license is USD 149.

[Doug Gray]

Let's forget profiling for the moment, and concentrate on Andrew's statement, i.e. PS modifies the rgb values to the printer driver even though "Printer Manages Color" is invoked.  This is in direct opposition to the description statement in the print dialog box, screenshot attached.  So has Photoshop seen the error of their ways and corrected this problem?  How do we find out for sure?  I couldn't come up with any reliable way to print to a file so I could measure the actual rgb values sent to the printer driver.

Richard Southworth

I did some measurements using "Printer Manages Color" with Photoshop using a Canon 9500 II and Windows 10 x64. For the driver's default settings RGB colors were converted to sRGB. However, when using ICM in the printer driver they were not converted.

I did this experiment largely as a result of Ctien's blog comments that he preferred "Printer manages color" and was curious about the interplay with the notion that Photoshop always converts colors to sRGB in this mode. It turned out that it usually does, but not always.

As an aside, I print target charts in Photoshop using null transform. I get the warning with a link to ACPU which I ignore. It works fine on the most current Win Photoshop. However, because of the warning, I run a measurement check whenever they release an updated version. Also, I have no idea whether it works on Apples.


http://forum.luminous-landscape.com/index.php?topic=119132.msg990356#msg990356

[Doug Gray]

Yes, Patchtool is a go-to application, and Danny's manual is an education. Matlab - good for those with a fairly deep math background, but from what I see on their website, not terribly expensive - a "home" license is USD 149.

Wow! I didn't realize they had released a home (non-commercial) version. I hadn't updated mine since 2015. It's a commercial license version I used in business - mostly EE stuff but some optical and specialized print related stuff. But I no longer use it for business. I'm retired now but I print (gratis) for some local artists and non-profits. So that's great news!  I'm definitely going to update to that.

[rasworth]

Ok, I'm now a believer, PS sucks for printing profile targets.  I tried scanning the "Printer Manages Colors" targets, got to line 24 and no go, just too far removed from the reference.  I printed again using ACPU, obviously different appearance.  I'll never doubt the collective wisdom of this group again!

Richard Southworth

[digitaldog]

Let's forget profiling for the moment, and concentrate on Andrew's statement, i.e. PS modifies the rgb values to the printer driver even though "Printer Manages Color" is invoked.  This is in direct opposition to the description statement in the print dialog box, screenshot attached.  So has Photoshop seen the error of their ways and corrected this problem?  How do we find out for sure?  I couldn't come up with any reliable way to print to a file so I could measure the actual rgb values sent to the printer driver.

Richard Southworth

See Dave P's comments below the article about Printer Manages Color here:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/07/andrew-rodney-on-the-importance-of-custom-printer-profiles.html
Again, the idea is to send the numbers, as is, through the driver which Photoshop since CS4 (thanks for remanding me) can't do without some modification of the data or without some color management.

[Doug Gray]

See Dave P's comments below the article about Printer Manages Color here:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/07/andrew-rodney-on-the-importance-of-custom-printer-profiles.html
Again, the idea is to send the numbers, as is, through the driver which Photoshop since CS4 (thanks for remanding me) can't do without some modification of the data or without some color management.

Dave P:
"Picking "Printer Manages Colors" on Windows guarantees that your color data will be converted to sRGB."


The graphs I showed in my "Down the Rabbit Hole" thread are compelling evidence that Dave is wrong. While the defaults do convert to sRGB, the ICM driver selection does not using Windows 10 and PS CC.

I can provide the green tiff patches and CGATS file if anyone wishes to try it out on their setup.

Also, I've been using the null transform to print targets in Photoshop pretty much forever. The warning an redirect to ACPU still pops up and I ignore it. It has always worked and continues to work. You don't even need a profile for the paper or printer you actually use. You can assign any RGB printer profile then print making sure you use exactly the same profile. The selections, Perceptual, Rel, Abs, Sat, and even BPC have zero affect on what gets printed since the image is already in printer space so ignore them or set them arbitrarily.

The key thing is to Assign the profile (any printer profile) , then print using Photoshop manages color using exactly the same profile. When you see the warning (which shows up in Windows) hit Cancel and print.

Andrew,
The videos you provide free of charge on your website are really superb. Good job and a great help to people trying to get a handle on color management. When people ask me where to learn the "how to" of CM I send them there.

[digitaldog]

The graphs I showed in my "Down the Rabbit Hole" thread are compelling evidence that Dave is wrong.

I can provide you his email (off list) if you want to go there; way, WAY above my pay grade. 

[Mark D Segal]

If it's the Dave P I think it is, the likelihood of him being wrong about what the code does is VERY remote - unless there are new factors brought into the process between the time he said that and the time you tested it.

[digitaldog]

If it's the Dave P I think it is, the likelihood of him being wrong about what the code does is VERY remote - unless there are new factors brought into the process between the time he said that and the time you tested it.

It's indeed the same Dave P (of Adobe). He could be wrong, something new could have come up under Windows since that article he commented upon, which wasn't that long ago. But it's unlikely he's wrong about what happens in Print within Photoshop or any Adobe application. That's his baby there in terms of coding.


Dave Polaschek said:"This always happens. When using "Printer Manages Colors" on Windows, Windows ICM 2.0 assumes that any color data passed to it is in sRGB, so Photoshop converts the colors to sRGB (so users don't get wrong colors when printing). We can't know whether the user has picked ABW or not (the driver-specific print settings are a black box to us at this point), and we must provide sRGB to the OS in this case."

[Doug Gray]

I can provide you his email (off list) if you want to go there; way, WAY above my pay grade. 

I would much appreciate that Andrew.  Since most of my career was in software/firmware design (remarkably similar to Norman Koran but without the photography talent)  , I do know mistakes happen. And sometimes they are mine. But I've seen the best and smartest people make them was well. This is a pretty arcane area and I'd like to get to the bottom of it. Personally, the things I am most interested in is why I get absolutely great results using null transform and always have. But the thing about always converting to sRGB just can't be right unless I did something really brain dead. The Lab green patches increased in saturation up to around a*=70 and sRGB clips at 37.  So something is really off.

[Mark D Segal]

I'm lost. If the patch is green wouldn't the a* increase to -70 and the clipping point you're referring to be a*-37?

[Doug Gray]

I'm lost. If the patch is green wouldn't the a* increase to -70 and the clipping point you're referring to be a*-37?

The patches were created in increments of -5 *a in Lab. The image was then converted to ProPhoto, Adobe RGB , and sRGB.  The sRGB cliped at a*=-37, Adobe RGB at about -65 or so. The printer itself ran out of gamut at around *a=70 or so.

The printed tiffs were measured and plotted in the linked post.  The default printer driver settings did indeed convert (and clip) to sRGB as can be seen in the posted charts. They also boosted both the luminance and saturation over what sRGB is supposed to be with a clipped sRGB green printed around a*=-45  instead of *a=37 which is where sRGB clips. And that explains how some people rather like the printed images from sRGB space using "printer manages."  Canon just boosted both the saturation and luminance.  However, when ICM was selected in the printer driver the images in the larger colorspaces printed far above the sRGB clip point up to near where the printer gamut limits color.