I created an untagged TIFF file containing 442 RGB values, mostly evenly distributed except with additional focus on shadow, highlight, and gray areas. In Photoshop CS6, I assigned one of my printer profiles to this image. I expected this to turn the image into 442 colors, all within my printer's profile gamut. (Graphing the printer profile and this TIFF file assigned to the printer profile confirms my expectation.)

However, since my workflow involves printing ProPhoto RGB documents, and Photoshop CS6 can't print an image through the same profile that the document is in, I assumed I could then convert that TIFF file to ProPhoto RGB, and since the conversion occurs around LAB, the LAB colors should remain roughly the same, so I should wind up with a ProPhoto RGB document that contains 442 colors that are all within my printer's profile gamut -- or at least darn close.

To my surprise, I now see if I graph this ProPhoto RGB image in ColorThink, the colors have severely leaked out of the printer profile space.

In Photoshop, when I make the ProPhoto RGB conversion, a few of the colors on my monitor change ever so slightly. This is odd because when I check the LAB values of the patch before and after the conversion, they're the same. Perhaps this is some type of rounding error in converting to my monitor.

I also tried converting to ProPhoto RGB without black point compensation and also absolute colorimetric, and they still have large differences. Absolute is a little better, but not by a lot.

Prophoto is a color workspace and not output profile. Your workflow in cool think is wrong.

Mark, it would be nice if you would elaborate. Regardless of the type of profile, both contain instructions for getting from profiles space to PCS and from PCS to profile. (AtoB and BtoA). Either type should allow you to plot color values in LAB coordinates. Maybe you could add some details to spell out why this shouldn't work.

darlingm, your charts are a bit of a mystery to me. The second chart looks like you have applied the ProPhoto profile rather than converted, but I'm guessing you would have discovered that yourself at some point. It's truly odd that you are reporting similar LAB values on paper, but when plotted on a LAB plot they end up all over the place. It's well known that LUT based profiles don't invert very well, but but the changes on roundtrips are generally much closer than this.

Have you tried plotting into a different model like xyY or LUV just to see if there's something funky going on in ColorThink?

Also confused about why color workspace vs output profile would invalidate the workflow.

ProPhoto definitely isn't being assigned. The points would explode a lot more, and many would be at the ProPhoto shell boundaries.

Confirmed unexpected behavior by

CHROMiX (ColorThink) technical support confirmed unexpected behavior in their independent testing, seeing the same strange results. That doesn't for sure mean a ColorThink bug (could be Photoshop) but they're looking into it.

I think it is possible that you have specified RGB colors that are outside the gamut of your printer profile. You created the RGB values and then assigned the profile, so the file may contain values out of gamut. There was no opportunity to bring these “illegal” values into gamut via a conversion.

The out of gamut values represent Lab values that are outside the printer gamut. When you convert to ProPhoto they correctly show there. That's why the Lab values are the same before and after conversion.

When ColorThink plotted the file it likely did a conversion to bring them all in-gamut. Looks like an awful lot of points on the surface (see the edges) of that first plot – as if they were brought into gamut.

MarkH2 (there's a lot of Marks in this thread), you can't create out of gamut colors by assigning a profile. They are by definition defined within the profile you assign.

darlingm, have you tried focusing on just one patch to try and drill down what's going on? You might try exploring argyllCMS, which has a utility for converting tifs files, to see if you get the same LAB values in the conversion.

MarkH2, as MarkM mentioned, when you assign a profile, everything is in gamut for that profile. The method I used to choose the RGB values by ensured a lot of them would wind up on the outer surface of the profile, pushing the maximums of what the profile should be able to display. RGB values don't really mean anything by themselves (without a profile), and just specify what level between 0 and 255 (or larger ranges for 16+ bit) that the value is at. Level 255 just means the full strength available within that profile, and the profile itself defines what that maximum translates to in LAB. This is why when you assign a profile, the RGB numbers don't change (but the appearance of the colors and the corresponding LAB values do.) You aren't doing any mathematical conversion - you're just saying to change what the definition of the maximum r/g/or b actually means. It's a bit more complicated than that since we're talking an odd shaped 3D object representing a profile gamut, but that's the jist of it. You can't have an out of gamut color that's actually in a profile, because by its definition out of gamut would effectively be level 256 or higher, which can't mathematically be stored (again, unless higher bit depth.) That's why when you're converting to a profile and there are out of gamut colors, there has to be a decision made on how to map those invalid values into the profile - and that's where rendering intents come in.

MarkM, I haven't been able to spend more time on it after ColorThink confirmed the issue. I'll probably spend a bit more time on it out of curiosity, but I realized I had quite a few jobs stacking up with just enough time to finish them before they were due. I haven't directly used Argyll, but I've been meaning to - specifically to test their scanner ICC profile generation vs BasICColor's.

Thank you, I understand. I got thrown off by this experiment: Create a new document in ProPhoto RGB 16-bit, fill it with fully saturated yellow, RGB 255, 255, 0, Lab 100, -5, 128. Now assign printer profile Epson Velvet Fine Art, the result is RGB 255, 255, 0, Lab 95, -1, 117. This point is actually outside the printer gamut, as seen in the plot.

If instead, I assign profile sRGB the resulting Lab is 98, -16, 93, which plots right at the vertex of sRGB space, as you would expect.

So I wondered if somehow printer profiles were different. But you are right, RGB spaces by definition are defined by their three primaries and white point.

I have since tried other saturated colors, such as cyan, and they plot within gamut, both for the Velvet Fine Art profile, and the Hahnemuhle Fine Art Baryta profile. So the yellow point I started with is probably ok; it shows outside the PerfX gamut display, but that may be due to their calculations.

So I barked up the wrong tree.

I was curious about your statement that the Lab values are the same before and after conversion. If this is true for the patches that plot outside the printer gamut in ColorThink, then the problem most likely is with ColorThink, no? If they are different, most likely PS. Since ColorThink is looking into it, you should get the answer. Hope you can let us know.

But you are right, RGB spaces by definition are defined by their three primaries and white point.

And I think it might illustrate the first issue, that you created 442 RGB values but didn't define the color space. When you did, some of those values could be illegal (not actual 'colors'). Colorthink can't report any lab values from RGB until it knows the scale (color space).

But I don't think that's what going on here. As I recall, the ProPhoto values outside human vision are clustered around the blue point, which is itself an "illegal" color. There are many yellows and cyans, etc. outside the printer gamut in the op's plots.

If by analogy, you mean that there are RGB values within the printer gamut that are not printable, I don't think that's the case, since the gamut by definition contains only printable colors.

We begin with untagged RGB numbers and immediately assign a printer profile. It's very unlikely that an output profile will have imaginary colors in gamut. That would be a very strange LUT and it would imply that your output profile had colors the device can't reproduce.

Even if it did, they shouldn't move like this when converted to a larger space like ProPhoto.

The real question is why are two patches showing very similar LAB measurements in photoshop, but plotting in very different places on a LAB plot in colorthink?

I noticed the same behaviour, not only when converting to ProPhoto, but also to AdobeRGB or sRGB.But if I convert the result of the conversion *printer profile* --> *ProPhoto* to LAB, the graph displays the values as expected (within the boundaries of the printer's gamut). Could really be a bug in Colorthink.

We were seeing unexpected behavior and never came up with a reason. Wanted to let contributors & viewers of this post know what caused it.

It's caused by ColorThink resampling an image greater than 500px using a resampling method such as bicubic or bilinear instead of nearest neighbor. If you do this, those resampling methods try to sharpen the image - and the way to do that is to increase contrast between adjoining pixels - therefore expanding the image's gamut.

The graphing I was doing was from a 956x752 pixel TIFF, the one to be printed, not a TIFF that had 1 pixel per patch.

Wait what? I'm doing exactly this in CS5. Is there any way around this? What about CC?

Most people aren't going to fall into the situation that I referred to. If what you're currently doing works, then this isn't affecting you at all. People will typically only run into this frustration when they're trying to print color targets to be measured for ICC profiling.

Typically you will have your document in a standard working space, such as sRGB, AdobeRGB, or ProPhoto RGB. You'll do soft proofing with a printer profile, and in the print dialog window tell Photoshop you want to use that ICC profile and a rendering intent of your choice.

Photoshop can handle that standard workflow just fine.

What it can't do in CS5/CS6/CC is if you take a document and either convert (or more rarely, assign) to a printer profile, having the ICC profile already applied, so when you print you want to tell Photoshop not to use any color management at all - because it's already been done. Photoshop CS4 and lower had a "No Color Management" option in the print dialog next to "Printer Manages Colors" and "Photoshop Manages Colors", and they removed "No Color Management" in CS5.

Ways around this are:

* Use Adobe's Color Printer Utility (ACPU) that they released that prints files as is without color management - downloadable at http://helpx.adobe.com/photoshop/kb/no-color-management-option-missing.html* Keep Photoshop CS4 around, installed side by side.* Use another program that can handle no color management. I use QImage for this. QImage, of course, supports color management - however you can also specify to turn it off.

When adobe decided to remove "No color management" for Photoshop on MAC that's OSX problem they forced this to happen, however when 90% of users work on Windows this means they could have kept the "No color managment" at least on windows.

Now I understand when professional software gives you choice over non professional. In this case it means Photoshop and other Adobe application are leaving the Pro market, because in no doubt if you're into color management you keep CS4, Qimage etc. To do the same you did in Photoshop - Print your targets.

If the ACPU would at least work on windows with proper margins, print positioning, etc. This would look like alternative. But now it's more like a dead end.

Most people aren't going to fall into the situation that I referred to. If what you're currently doing works, then this isn't affecting you at all. People will typically only run into this frustration when they're trying to print color targets to be measured for ICC profiling.

Typically you will have your document in a standard working space, such as sRGB, AdobeRGB, or ProPhoto RGB. You'll do soft proofing with a printer profile, and in the print dialog window tell Photoshop you want to use that ICC profile and a rendering intent of your choice.

Photoshop can handle that standard workflow just fine.

What it can't do in CS5/CS6/CC is if you take a document and either convert (or more rarely, assign) to a printer profile, having the ICC profile already applied, so when you print you want to tell Photoshop not to use any color management at all - because it's already been done. Photoshop CS4 and lower had a "No Color Management" option in the print dialog next to "Printer Manages Colors" and "Photoshop Manages Colors", and they removed "No Color Management" in CS5.

Ways around this are:

* Use Adobe's Color Printer Utility (ACPU) that they released that prints files as is without color management - downloadable at http://helpx.adobe.com/photoshop/kb/no-color-management-option-missing.html* Keep Photoshop CS4 around, installed side by side.* Use another program that can handle no color management. I use QImage for this. QImage, of course, supports color management - however you can also specify to turn it off.

Oh, I've found my way around this in CS5 just fine--just print to the same profile that the document has been assigned to. This way you get a 1:1 mapping just like no color management. But the OP was saying that this isn't possible in CS6?