Pages: [1]   Go Down

Author Topic: Proof Printer Manages Color does not *always* convert to sRGB in Windows  (Read 596 times)

Doug Gray

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

I've been otherwise engaged after getting an Isis 2 XL learning its capabilities and limits but it's time to address this internet color management myth. The myth goes back to an article at "The Online Photographer" where, at the end of the comment section Dave Polaschek, and Adobe color guru, makes the following statement:

http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

Quote
Printer Manages Colors guarantees a conversion to sRGB IF you are printing with a color profile attached to your image data. This is how StretchDIBits (which is the bottleneck routine used on Windows operates) works. ICM2, when designed by Microsoft back in the 90s, chose to use sRGB as their interchange space, so any image data with an attached profile, and with ICM enabled fed into StretchDIBits will be converted to sRGB.

In the case of the Epson 9800, using Printer Manages Color with ICM the option exists to assign the input to a colorspace which can be any in your profile directory. This experiment shows that assigning the input profile to ProPhoto RGB precludes conversion to sRGB in Windows and the full range of ProPhoto RGB will be used together with the selected printer profile and Colorimetric Intent.

A test was run comparing 478 patches in ProPhoto RGB containing printable Lab colors in 10 unit separations. The printer profile used was a custom 4k patch made with I1Profiler. This profile was used for "Printer manages" as well as Photoshop manages."  Additionally, the "Basic ICM" was selected for the "printer manages" and "ProPhoto RGB was selected as the input colorspace. The usual (none) settings were used for Photoshop Manages.

This is the result for Photoshop Manages Color:

Mean DeltaE2000: 0.54, Max DeltaE2000:  1.90
Mean DeltaE1976: 0.90, Max DeltaE1976:  3.17
Best 90%,  Mean DeltaE2000: 0.47, Max DeltaE2000:  0.92
Best 90%,  Mean DeltaE1976: 0.77, Max DeltaE1976:  1.65

This is the result for Printer Manages Color:

Mean DeltaE2000: 0.53, Max DeltaE2000:  2.11
Mean DeltaE1976: 0.90, Max DeltaE1976:  3.44
Best 90%,  Mean DeltaE2000: 0.46, Max DeltaE2000:  0.88
Best 90%,  Mean DeltaE1976: 0.78, Max DeltaE1976:  1.49


Provided here are the results of printing 478 patches in Lab distributed around 10 units from L*=10 to 90 and a* and b* ranging within a printable gamut that exceeds Adobe RGB in places. Each patch is on boundaries of units of + or -10 to make it easy to visually scan for color error since the reference colors are fixed. To enable any others wishing to verify this I have provided a tif file of an Isis scannable image in ProPhoto, high bit RGB format. I have also included a reference patch file that includes the ProPhoto RGB values for each of the Lab 10 unit delta patches. Additionally, I have included captures of the Epson 9800 printer settings for "Printer Manages Color" that show what ICM settings were used in the driver. An included Zip file contains these so anyone interested that has an Epson 9800, and likely other similar printers, can verify this for themselves.

Zip File:
Epson 9800 Printer Manages Colors Settings.jpg - Screen capture of Epson 9800  settings
Histograms.jpg - Histograms of dE2k error distributions
LAB10 478 Patches.tif - CGATS LAB file of patches
LAB10 in ProPhoto .txt - CGATS RGB file of patches, the end is padded with RGB 255,255,255 for default Isis formatting
LAB10 Photoshop Manages.txt - CGATS file from I1 Profiler patch measurement
LAB10 Printer Manages.txt - CGATS file from I1 Profiler patch measurement


« Last Edit: September 14, 2017, 11:12:40 AM by Doug Gray »
Logged

Ethan Hansen

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 73
    • Dry Creek Photo
Re: Proof Printer Manages Color does not *always* convert to sRGB in Windows
« Reply #1 on: September 14, 2017, 07:58:15 PM »

Many thanks Doug for delving into this issue. Dave's original post did not make much sense. If Adobe uses StretchDIBits for printing (and there are a number of performance reasons for not doing so), using Windows WCS color management in no way requires use of sRGB.

Now it is always possible that Adobe hard-coded the LCS_sRGB flag into the bitmap structure used by WCS routines rather than the actual profile used. That forces sRGB rather than a specified profile. I'm guessing that if this was the case before, Adobe corrected their dumb mistake. I see no evidence of phantom sRGB conversion with printer ICM either with CC 2017.

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 725
Re: Proof Printer Manages Color does not *always* convert to sRGB in Windows
« Reply #2 on: September 15, 2017, 09:57:52 PM »

Out of curiosity, thought I'd do a null transform using Printer Manages Color. I set the input profile and the output profile to the same profile. Worked with no warnings.

But wait, there's more and it wasn't good.

It does what I've sometimes feared Photoshop might do given their obnoxious warning to get ACPU. It converts from device space into PCS (Lab) then back to device space using the same profile. In ICC terms this is AtoB1->PCS->BtoA1. While ideally this would produce no change at all it introduces LUT interpolation errors most of which are in the BtoA1 transform near the outer gamut edges. The dE2k comparing the target printed w/o color management (no round tripping errors) against the round tripped print increased to about 2.5 times that of 2, identically printed targets. I also, just for grins, did a manual roundtrip by converting, in Photoshop, the image in device space to Lab then back to device space then printing w/o color management. The differences between the manually roundtripped and device driver roundtripped values dropped to normal. Strong evidence the device driver simply assumes incoming RGB values are in the input colorspace of the profile assigned in the device driver. It fails to recognize both input and output profiles are identical and so it converts to PCS (Lab), then converts back to the output profile. The interpolation errors introduced by the two roundtrips are the same within normal print to print resolution.
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 725
Re: Proof Printer Manages Color does not *always* convert to sRGB in Windows
« Reply #3 on: September 27, 2017, 06:03:08 PM »

BTW, while you can, in Windows, use "Printer Manages Color" in Photoshop and get the same results as you would get with Photoshop Manages Colors if your printer driver lets you select the image and printer profiles like Epson does on their pro printers, You cannot do this with Lightroom.

Why, you ask? How can that be?

Simple. Photoshop sends the image in whatever colorspace it is in, Adobe, ProPhoto, or sRGB to the driver. Lightroom internally converts everything to ProPhoto primaries. OK, so then you just select ProPhoto RGB as the input colorspace in the device driver, right?

Wrong. While Lightroom sends the image in ProPhoto primaries, it also sends it with a Gamma==1. True ProPhoto is, of course, Gamma==1.8. You can select ProPhoto in the printer driver's ICM submenu but there is no option for adjusting the Gamma. Most people don't see this. They use the defaults, not ICM, which converts whatever the driver is given to sRGB in Windows.

The printer driver will happily interpret the RGB values as ProPhoto gamma=1.8 and darken the print. A LOT!

Here's an example. I created a color patch (16 bit) in Photoshop of LAB=(50,-70,-20) in 16bit ProPhoto RGB. I then printed it on glossy paper using my most accurate I1Profiler profile and selected Perceptual Intent. 4 Prints were made using Lightroom and Photoshop with both Application manages Color and Printer Manages Color.

Roundtripping, the profile reported the printer colors are expected to be LAB=(46 ,-66,-20). The darkening and decrease in saturation are typical of the I1Profiler Perceptual tables.

The actual measured (with a different instrument than generated the profile) colors are:

Photoshop, Photoshop Manages:    46,-66,-21
Photoshop, Printer Manages:         46,-66,-21
Lightroom, Lightroom Manages:    46,-66,-22
Lightroom, Printer Manages:          28,-52,-23!!!!

And, guess what? The last values are exactly what one expects if the "ProPhoto" RGB values coming from Lightroom were in Gamma==1 but interpreted as standard ProPhoto RGB Gamma==1.8. Still highly saturated far beyond sRGB but very dark.

To summarize, use Application Manages Color. Then you don't have to wonder what colorspace is actually being sent to the printer driver.


« Last Edit: September 27, 2017, 07:36:11 PM by Doug Gray »
Logged

GWGill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 384
  • Author of ArgyllCMS & ArgyllPRO ColorMeter
    • ArgyllCMS
Re: Proof Printer Manages Color does not *always* convert to sRGB in Windows
« Reply #4 on: September 27, 2017, 09:49:20 PM »

It fails to recognize both input and output profiles are identical and so it converts to PCS (Lab), then converts back to the output profile. The interpolation errors introduced by the two roundtrips are the same within normal print to print resolution.
This is the reason I strongly dislike the idea of using a "null profile combination" over an explicit "no color management" UI/API. The former relies on a special case, which is ill specified. For instance, is it a null transform if the two conversions have different intents ? How are profiles for a device identified as being the same ? What if a user needs such a conversion, to change the black inking behavior for instance ? etc.


Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 725
Re: Proof Printer Manages Color does not *always* convert to sRGB in Windows
« Reply #5 on: September 27, 2017, 11:02:24 PM »

This is the reason I strongly dislike the idea of using a "null profile combination" over an explicit "no color management" UI/API.
Yes, the additional error introduced by roundtripping through mutually inverting profiles would just add to intrinsic, system error. Good thing Photoshop, in spite of dire warnings, recognizes they match and just bypasses both resulting in no color management conversions. At least in Windows. I have a bad feeling that Adobe wants to get rid of Application Manages Color and put all the color profile processing on the driver. Phone calls go to the printer manufacturer. I'm sure color management calls are a major source of customer confusion that often goes unresolved. This would require a separate utility like ACPU to print w/o color management.
Quote
The former relies on a special case, which is ill specified. For instance, is it a null transform if the two conversions have different intents ?
They don't. Only one intent is specified and presumably it would apply to both input and output profiles. This comes up in Photoshop if you are converting from one device space to another, ie: a R2400 to a 9900. You can only select one intent. For instance, if Perceptual is selected it will apply the AtoB0(R2400)->PCS->BtoA0(9900).
Quote
How are profiles for a device identified as being the same ?
They aren't in the device driver even though they easily could be. The selection boxes for input and output profiles are populated by the embedded description field and if two or more share the same description field only one is displayed for selection.  Photoshop, OTOH, does check to see if the profiles have the same description (the same one was selected as the one attached to the image). If so it pops up the warning but does the right thing if you cancel the warning dialog.

Quote
What if a user needs such a conversion, to change the black inking behavior for instance ? etc.

I can't imagine someone doing that in the printer driver dialog but it's certainly done in Photoshop in two steps. First to Lab from device space, then back to device space. The intent settings including BPC, are selected sequentially from the source (step 1) to destination (step 2).
Logged
Pages: [1]   Go Up