Ad
Ad
Ad
Pages: [1] 2 »   Bottom of Page
Print
Author Topic: Colors expanding in LAB when converting from printer profile to ProPhotoRGB!  (Read 3145 times)
darlingm
Sr. Member
****
Offline Offline

Posts: 291


WWW
« on: October 18, 2012, 02:25:01 AM »
ReplyReply

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
Logged

Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761
Mark Paulson
Jr. Member
**
Offline Offline

Posts: 89


« Reply #1 on: October 19, 2012, 08:39:09 PM »
ReplyReply

Prophoto is a color workspace and not output profile. Your workflow in cool think is wrong.
« Last Edit: October 20, 2012, 08:35:32 AM by Mark Paulson » Logged
MarkM
Full Member
***
Offline Offline

Posts: 231



WWW
« Reply #2 on: October 20, 2012, 07:47:14 PM »
ReplyReply

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?
Logged

darlingm
Sr. Member
****
Offline Offline

Posts: 291


WWW
« Reply #3 on: October 20, 2012, 08:23:50 PM »
ReplyReply

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

Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761
MarkH2
Jr. Member
**
Offline Offline

Posts: 91


WWW
« Reply #4 on: October 20, 2012, 08:26:02 PM »
ReplyReply

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.
Logged
MarkM
Full Member
***
Offline Offline

Posts: 231



WWW
« Reply #5 on: October 20, 2012, 08:32:40 PM »
ReplyReply

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

darlingm
Sr. Member
****
Offline Offline

Posts: 291


WWW
« Reply #6 on: October 21, 2012, 03:00:10 AM »
ReplyReply

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

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

Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761
MarkH2
Jr. Member
**
Offline Offline

Posts: 91


WWW
« Reply #7 on: October 21, 2012, 11:01:04 AM »
ReplyReply

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

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
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 8073



WWW
« Reply #8 on: October 21, 2012, 12:11:07 PM »
ReplyReply

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

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
MarkH2
Jr. Member
**
Offline Offline

Posts: 91


WWW
« Reply #9 on: October 21, 2012, 12:47:52 PM »
ReplyReply

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
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 8073



WWW
« Reply #10 on: October 21, 2012, 12:49:05 PM »
ReplyReply

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

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
MarkH2
Jr. Member
**
Offline Offline

Posts: 91


WWW
« Reply #11 on: October 21, 2012, 12:53:40 PM »
ReplyReply

By illegal if you mean outside the Lab gamut of human vision, yes I understand that.
Logged
MarkH2
Jr. Member
**
Offline Offline

Posts: 91


WWW
« Reply #12 on: October 21, 2012, 01:50:12 PM »
ReplyReply

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?
Logged
MarkM
Full Member
***
Offline Offline

Posts: 231



WWW
« Reply #13 on: October 21, 2012, 02:03:48 PM »
ReplyReply

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?
Logged

mcgruenigen
Newbie
*
Offline Offline

Posts: 6


« Reply #14 on: October 30, 2012, 03:36:46 PM »
ReplyReply

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.
Logged
darlingm
Sr. Member
****
Offline Offline

Posts: 291


WWW
« Reply #15 on: September 28, 2013, 06:10:35 PM »
ReplyReply

Sorry to bump a ~ 1 year old post, but I think it's worth doing.

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

Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761
Joseph Yeung
Newbie
*
Offline Offline

Posts: 21


« Reply #16 on: September 29, 2013, 10:34:16 AM »
ReplyReply

Quote
Photoshop CS6 can't print an image through the same profile that the document is in

Wait what?  I'm doing exactly this in CS5.  Is there any way around this?  What about CC?
Logged
darlingm
Sr. Member
****
Offline Offline

Posts: 291


WWW
« Reply #17 on: September 29, 2013, 01:50:51 PM »
ReplyReply

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

Mike • Westland Printworks
Fine Art Printing • Amazing Artwork Reproduction • Photography
http://www.westlandprintworks.com • (734) 255-9761
smilem
Full Member
***
Offline Offline

Posts: 212


« Reply #18 on: September 29, 2013, 04:26:14 PM »
ReplyReply

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.

Logged
Joseph Yeung
Newbie
*
Offline Offline

Posts: 21


« Reply #19 on: September 29, 2013, 07:58:40 PM »
ReplyReply

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?  Huh
Logged
Pages: [1] 2 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad