Colors expand converting from printer profile to ProPhotoRGB

CHROMiX ColorThink
1

I created a set of 442 RGB values, mostly evenly distributed but with additional focus on shadow, highlight, and gray. I used BabelColor’s PatchTool to create a 16 bit untagged TIFF image using those values.

In Photoshop CS6, I assigned this untagged TIFF image one of my printer profiles. I expected this to turn the image into 442 different colors, all within my printer profile’s gamut. I wanted to print the patch, measure it with i1Profiler, and see how accurate it was.

I’ve found that if I graph the printer profile and the TIFF image with the printer profile assigned to it, as I expected, all the colors are in gamut.

However, Photoshop CS6 can’t print an image through the same profile that the document is in. (It considers this no color management, which is no longer supported.) Rather than using the Adobe print tool for such a case, I figured I could convert this TIFF to ProPhoto RGB, and the LAB colors should remain approximately the same, so all the colors should remain in gamut – or if they drifted outside, they wouldn’t by much.

Much to my surprise, if I then graph this TIFF image in ColorThink, the colors have severely leaked out of the printer profile space.

I’m not sure if this is a Photoshop or ColorThink issue, but I’m probably missing something. The measurements are giving me deltaE values averaging 4 overall and 8.8 for the worst 10% when printing using relative colorimetric, and 2.75 and 9 using absolute colorimetric. In Photoshop, when I make the ProPhoto RGB conversion, I see a slight change in a few of the colors - which is odd to me because the patch has the same LAB values in Photoshop before and after the conversion, so I would have thought they would display on the screen the same.

I also tried without black point compensation and absolute colorimetric, and still have large differences.

P.S. My workflow always involves printing a document that’s in ProPhoto RGB, hence my desire to convert it to that rather than use Adobe’s standalone print tool.

Untagged RGB values, assigned a printer profile

Untagged RGB values, assigned a printer profile, converted to ProPhoto RGB using Adobe (ACE) Relative Colorimetric with Black Point Compensation
[/img]

Untagged RGB values, assigned a printer profile, converted to ProPhoto RGB using Adobe (ACE) Absolute Colorimetric

2

You have me stumped!

I have followed your workflow and get the same results you do.

If I assign an image to a printer profile in PS, convert that image to ProPhotoRGB, then save it out - that saved image will import into the Grapher with a larger gamut than one would expect. You’d expect it to be contained by the gamut of the printer profile, but it’s not.

I’ve seen this happen using printer profiles. Interestingly enough the image stays contained when using working space profiles.

I don’t have an explanation for this yet, but I’ll try a few things and get back to you.

3

Glad I’m not doing it wrong. :smiley: Looking forward to hearing from you.

Could you elaborate on “I’ve seen this happen using printer profiles”? I’d love to know any other known situations to watch out for.

4

Any update?

5

I’ve been working on this from several different angles this week and I still don’t have any answers. I have duplicated your workflow with a simpler set of saturated colors, assigned them a printer profile in Photoshop, converted them to Prophoto, and then compared the two using the Worksheet in CTP. I basically get the same results as we see in the Grapher. The converted image has a larger gamut, moves outward from beyond the printer gamut by several delta E’s.

Next I’m going to try to break it down to this much detail in Photoshop, if I can figure out how. It might have something to do with how PS assumes Lab values from the working space.

“I’ve seen this happen using printer profiles”
I just mean that this phenomenon we’re witnessing only happens with printer profiles. If you are assigning a working space profile (sRGB, AdobeRGB, etc) to your image in PS before converting to ProPhoto, then your image will stay contained within the original working space. Generally people assign a working space profile to an image before sending it onto someone else. That’s the more common use of the assign profile function.


6

IF you’re making any color space conversions using Photoshop, did you turn OFF Dither in the color preferences?

7

Okay, I think I’ve figured it out.

If you make the PS conversion into ProPhoto using RelCol you will necessarily get an expansion of the gamut because the conversion is dragging the whole image up to the 100 L white point of ProPhoto. (Your printer profile probably has a lower white point like 95 or something.) When I did the conversion with AbsCol I found that there was very little change. This actually makes sense. All things being equal, if you increase the lightness of a printing process, you will tend to get a broader gamut. But if you want to convert with no change, then you’d want AbsCol.

You said that you tried AbsCol and got similar large dE’s, but try it again and see if you get the same results. Use AbsCol to do the conversion from your embedded printer profile to ProPhoto and be sure that dithering is unchecked as Andrew suggests.

8

Finally back to this. I just beat a year.

My original post showed graph 2 (RelCol conversion) and graph 3 (AbsCol conversion.)

RelCol definitely does (and should) convert the printer profile’s whitepoint to ProPhoto’s L* 100, and in doing so also expands a* and b*, therefore increasing saturation.

The AbsCol conversion I was doing leaves the printer profile’s whitepoint where it is, and doesn’t expand a* and b* at all.

I wasn’t using a manually generated color list like you were, so although I knew the situation got better using AbsCol instead of RelCol, I was still getting the same results as in graph 3 after double checking.

Got frustrated and back-burnered the project.

Solved this bug while diagnosing a different symptom. My post today, “BUG: Wrong values extracted from images with dim > 50” is what caused this bug.

I was using the 956x752 pixel TIFF generated by i1 Profiler that is the actual test target, including the patches, the whitespace, the text labels X-Rite puts on it.

All that’s fine - all of that would still be converted to in-gamut values - of course adding black and white pixels, but still in gamut.

It’s the downsampling method of images over 500 pixels that is causing all those pixels in graph 3 to be displayed out of gamut.