Paper Profiles and Print Drivers

[rmazzi]

I have an Epson P600 and generally use Epson papers.  I print via Lightroom.  In the print module I set the color management with the Epson provided ICC profile and set the same paper type in the print settings of the printer driver.  What I was curious about is since everything is Epson in this work flow, would the print result be the same if I set color management to Manage By Printer and select the correct paper type in the print driver.  I have no reason to change anything with my workflow, but I am interested in understanding what the print profile does that the print driver doesn't do.

Related to this, sometimes i use a third party paper.  I have a Colormunki to do a basic ICC profile for the paper in the case where one is not available (such as Inkpress profiles for P600).  The question is what paper type should I select in the Epson driver to get a good starting point.  Certainly Matte Ink vs Photo Black would be the first thing, but there are multiple options within each group.  In evaluating the selection, is there anything to look for in the output that would give me feedback on whether I made a good choice?

Thank you in advance for educating me on some of these minute points.

[Mark D Segal]

Printer Manages Color uses bespoke algorithms that will not necessarily deliver exactly the same result as an Application-managed ICC workflow regardless that the Media Type setting is the same.

The purpose of the Media Type is mainly to control ink lay-down and head height from the paper. Your custom profile should be based on an Epson Media Type that most closely resembles the paper you are profiling. Ideally, if Inkpress provides their own profiles for the Epson SC-P600, they should indicate which Media Type they themselves used. You can use that one for your custom profile creation. If they don't, you will need to estimate the Media Type from either a verbal description of the papers or by seeing and feeling paper samples to judge which Epson Media Type most resembles the Inkpress in respect to paper thickness, coating and texture.

[digitaldog]

The question is what paper type should I select in the Epson driver to get a good starting point.

Download this test file for visually examining ink density. Used to test best media settings for 3rd party papers: http://digitaldog.net/files/InkDensity.zip

[rmazzi]

Thank you for the information and test file.  I am always grateful to have experts available to help via these forums.

[NAwlins_Contrarian]

What I was curious about is since everything is Epson in this work flow, would the print result be the same if I set color management to Manage By Printer and select the correct paper type in the print driver.

A the very least you'd lose the ability to choose between relative colorimetric and perceptual rendering intents.

But I also suspect that at least some printer drivers and/or firmware include some element of 'auto-correct' when you let them manage color.

[Mark D Segal]

But I also suspect that at least some printer drivers and/or firmware include some element of 'auto-correct' when you let them manage color.

I don't know what you mean by "auto-correct", but if you mean scaling to paper white and allowing for Black Point Compensation I would also suspect these references would be built-in, and they would reference the Media Type, but as the printer manufacturers haven't specified how these algorithms are constructed we don't know. We could probably infer it by making some test prints of targets with known values using various choices of Rendering Intent and related settings, where allowed, and comparing.

[Doug Gray]

I don't know what you mean by "auto-correct", but if you mean scaling to paper white and allowing for Black Point Compensation I would also suspect these references would be built-in, and they would reference the Media Type, but as the printer manufacturers haven't specified how these algorithms are constructed we don't know. We could probably infer it by making some test prints of targets with known values using various choices of Rendering Intent and related settings, where allowed, and comparing.

Perhaps something like Photoshop does with it's various Auto modes? I haven't run across any that do but there could be. I think they generally limit printer manages transforms to some sort of gamut expansion based on CAM assumptions and possibly testing consumers for preferences. But those are fixed transforms. Certainly see this in spades on my Canon 9500 II.

[digitaldog]

Perhaps something like Photoshop does with it's various Auto modes?

What Auto modes?

[Doug Gray]

What Auto modes?

This:
https://helpx.adobe.com/photoshop/atv/cs6-tutorials/auto-corrections.html

[digitaldog]

This:
https://helpx.adobe.com/photoshop/atv/cs6-tutorials/auto-corrections.html

And that has what to do with printing?
FWIW, as a user of Photoshop since v 1.0.9, there have been some auto features (if I can be so kind) from day one.
AFAIK (and I've been a beta for Photoshop since version 2.5; nearly 26 years), there's no "Auto" anything for printing in terms of altering the data sent to the driver. So like Mark, I'm confused by this.

[Doug Gray]

And that has what to do with printing?
FWIW, as a user of Photoshop since v 1.0.9, there have been some auto features (if I can be so kind) from day one.
AFAIK (and I've been a beta for Photoshop since version 2.5; nearly 26 years), there's no "Auto" anything for printing in terms of altering the data sent to the driver. So like Mark, I'm confused by this.

The idea, I believe was that some sort of autocorrect could be built into some printer drivers when letting the printer manage color. AFAIK, this hasn't actually been done. Used to be an option on the older film processors. No idea if it is on more current mass market printers. Quite possible Costco does something like that if you don't disable color management. Many people may like the idea of the printer "fixing" their prints for them.

However, I don't think that is something printer drivers do in Windows or iOS.  Just a guess though. The printers I have on Windows do not do it.

[digitaldog]

The idea, I believe was that some sort of autocorrect could be built into some printer drivers when letting the printer manage color.

I know of no such desktop drivers but that's possible but certainly, that's not part of Photoshop. Photoshop sends the corrected/edited numbers to the driver. As does Lightroom and every Adobe app I know of.

Used to be an option on the older film processors.

And some front end processors attached to some print systems (Indigos on down, Frontiers etc) but again, that's not Photoshop or Lightroom.

However, I don't think that is something printer drivers do in Windows or iOS.

Possible but I know of none either.
The OP is using LR and an Epson and it's print driver. There's no Auto correction like perhaps some front ends found at Costco.

[Doug Gray]

Andrew,
If you haven't run across this either, and you have way more exposure and experience with PC printer than I, it's probably not being done on in any PC/iOS driver.

[NAwlins_Contrarian]

I didn't mean to kick a beehive with my quasi-speculation about exactly what 'printer manages color' means on different printers (by which I mean driver / firmware / hardware sets). And I may be about to demonstrate my considerable ignorance. But just consider, going back to the original change: the OP chooses the desired ICC profile, and chooses the rendering intent, and in some (like PS) but not other (like LR) software back point compensation is optional. Presumably in the scenario LR or whatever is effectively doing a 'convert to profile' on the image data as the software spools out the data to the printer, right? Now you turn that off and instead choose printer manages color. In this scenario, does the software making the print tell the printer whether the transmitted image data is in sRGB, or ProPhoto RGB, or whatever? Even if the printer knows the image's color space, and the printer contains internally what is basically the equivalent of ICC profiles for Epson papers, the printer still has to choose a rendering intent, or else default to some specified one. And if the incoming data does not specify its color space, how does the printer know? And if the printer does not know the image data's color space, it can't use those profile-like data sets. Instead it has to either assume (maybe sRGB?) or else drop that approach and on the fly effectively perform an auto white balance / auto levels to make the data look what the driver's / firmware's internal logic says would be 'good'. Or at least, that's the way it seems to me--but most of you know a lot more than I do, so please correct me wherever applicable.

I'm inclined to run this test: take a couple of images that are obviously 'off'--way too dark, color balance clearly off, the like--that I think my local drugstore would mostly fix with auto-corrections. Print each once with full color management and a second time with printer manages colors. Now do the same with images that are right. My supposition is that possibly the former will show more noticeable changes between the two prints, and the latter will show smaller changes. That would tend to demonstrate that some sort of 'auto correction' is occurring.

But hey, I may be veeeeeeery wrong--feel quite free to educate me. Thanks!

[Mark D Segal]

I didn't mean to kick a beehive with my quasi-speculation about exactly what 'printer manages color' means on different printers (by which I mean driver / firmware / hardware sets). And I may be about to demonstrate my considerable ignorance. But just consider, going back to the original change: the OP chooses the desired ICC profile, and chooses the rendering intent, and in some (like PS) but not other (like LR) software back point compensation is optional. Presumably in the scenario LR or whatever is effectively doing a 'convert to profile' on the image data as the software spools out the data to the printer, right? Now you turn that off and instead choose printer manages color. In this scenario, does the software making the print tell the printer whether the transmitted image data is in sRGB, or ProPhoto RGB, or whatever? Even if the printer knows the image's color space, and the printer contains internally what is basically the equivalent of ICC profiles for Epson papers, the printer still has to choose a rendering intent, or else default to some specified one. And if the incoming data does not specify its color space, how does the printer know? And if the printer does not know the image data's color space, it can't use those profile-like data sets. Instead it has to either assume (maybe sRGB?) or else drop that approach and on the fly effectively perform an auto white balance / auto levels to make the data look what the driver's / firmware's internal logic says would be 'good'. Or at least, that's the way it seems to me--but most of you know a lot more than I do, so please correct me wherever applicable.

I'm inclined to run this test: take a couple of images that are obviously 'off'--way too dark, color balance clearly off, the like--that I think my local drugstore would mostly fix with auto-corrections. Print each once with full color management and a second time with printer manages colors. Now do the same with images that are right. My supposition is that possibly the former will show more noticeable changes between the two prints, and the latter will show smaller changes. That would tend to demonstrate that some sort of 'auto correction' is occurring.

But hey, I may be veeeeeeery wrong--feel quite free to educate me. Thanks!

Back in October 2015, Ctein said the following (on TOP website) about printer colour management, which probably hasn't changed since then:

"First, and this is really important, printer-managed color won't be a superior approach if you're running Windows. What I'm recommending only works under Mac OS, which allows you to specify the output printer color space as AdobeRGB. Under Windows you're limited to sRGB, which throws away way too much of the color gamut of the printer."

He was mentioning this in the context of his claims for using a Printer Manages Color workflow on an Epson SC-P800.

Most of the time if you are using RelCol RI, you will want to activate Black Point Compensation because it does a better job of separating shadow tones than not using it. Presumably this is why it is baked into Lr when you print with RelCol.

When you are using Application Color Management with an ICC profile, both the image's color space and the printer/paper profile determine the values of the colour data that will be printed. The colour data is converted from RGB to Lab, and from Lab to printer's CMYK inkset. The Color Space is critical to the interpretation of RGB colour values because the scale of 0-255 is fixed, but the Lab value of any particular RGB number depends on the size of the colour space gamut. For example, a value of say 100,50,200 will be more saturated in sRGB space than it will in ProPhoto space, because those same numbers will be scaling closer to the sRGB gamut boundary than to the ProPhoto gamut boundary. So the conversion process needs to be RGB-Color Space aware otherwise you will print rubbish.

Printer Manages Color does not edit your photo for you. It prints the numbers it gets according to the canned algorithms the manufacturer developed for it.

All of this is quite separate from what a drug-store photo printing process does. Back in the 1990s, machine operators were trained to look at the photos on a screen before printing and select from a range of software controls to change the photo's appearance to what they thought customers would find more pleasing. My understanding is that current machinery has internal algorithms adjusting for white balance, skin tones and overall vibrancy. But some will print exactly what you send them in specified formats.

[Wayne Fox]

Printer Manages Color does not edit your photo for you. It prints the numbers it gets according to the canned algorithms the manufacturer developed for it.

So are those algorithms trying to "enhance" or "improve" the data to render what the engineers think is a more acceptable result?  It seems the engineers should be able to know the image color space as well as have access to the output color space so printer managed color could easily yield a result identical to application managed color, but instead the process seems to be something else.

I'm not sure what they are doing, but  it sounds remarkably similar to what those other devices were trying to do that were discussed, or what a camera does when it renders a jpeg file.  Some type of auto correct/enhance logic.

Trying to duplicate the result of such a print with application managed color can indeed be an exercise in futility.

[digitaldog]

So are those algorithms trying to "enhance" or "improve" the data to render what the engineers think is a more acceptable result? 

Nope. There's a conversion to some output color space from some questionable source color space (see Mark's point about sRGB being forced into this conversion).

[Doug Gray]

So are those algorithms trying to "enhance" or "improve" the data to render what the engineers think is a more acceptable result?  It seems the engineers should be able to know the image color space as well as have access to the output color space so printer managed color could easily yield a result identical to application managed color, but instead the process seems to be something else.

Both printers I have, an Epson 9800 and Canon 9500 II, alter standard sRGB images printed using "printer manages color" differently than any of the Intents in a color managed, profiled, system with Photoshop managing colors. They both increase luminance. In areas where the intrinsic printer gamut extends beyond sRGB, colors are also printed with increased saturation.  This is especially true of the Canon which pushes L* values that are near center neutral (50) over 10 units higher. This can be explained if the engineers used a color appearance model to alter printed colors based on some assumption that differs from that of the ICC's reference of 500 Lux illumination. In fact this sort of thing is expected if using a IECCAM02 model to translate colors from viewing under 500 Lux to a lower level like 100 to 150 Lux.

I'm not sure what they are doing, but  it sounds remarkably similar to what those other devices were trying to do that were discussed, or what a camera does when it renders a jpeg file.  Some type of auto correct/enhance logic.

Trying to duplicate the result of such a print with application managed color can indeed be an exercise in futility.

I described a technique to put the "printer manages color" transforms under ICC color management so those that like the way "printer manages" can have their cake and eat it too.

http://forum.luminous-landscape.com/index.php?topic=122782.0