Colors expanding in LAB when converting from printer profile to ProPhotoRGB!

[darlingm]

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.

Untagged RGB values, assigned a printer profile - all nicely within gamut


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


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

[Mark Paulson]

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

[MarkM]

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?

[darlingm]

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.

[MarkH2]

darlingm,

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.

[MarkM]

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.

[darlingm]

Mark, Mark, and Mark, thank you for your replies.   

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.

[MarkH2]

Darling Mark (that must be what the m is for  )

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.

Mark

[digitaldog]

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).

[MarkH2]

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')...

Andrew,

Not sure I follow.  When he assigned the printer profile, all possible RGB values are in-gamut, right?  None of them can be illegal, or not actual 'colors,' right?

At least that must be true for a working space, such as sRGB or ProPhoto RGB.  Is it not true for a physical device, such as a printer?

Mark

[digitaldog]

There are a number of illegal colors that can be numerically specified in ProPhoto RGB.

[MarkH2]

By illegal if you mean outside the Lab gamut of human vision, yes I understand that.

[MarkH2]

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.

What am I missing?

[MarkM]

Andrew, I don't think this is what's going on here.

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?

[mcgruenigen]

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.