Prints Suddenly Anemic

[Mick Sang]

And no, none of this has anything to do with anemic prints

True, aside from the fact that as I "drill down" into ColorThink and Patch Tool etc. to try to determine why our anemic prints are happening on that printer, I become lost when encountering commonly used, ambiguous terms or at least terms that I don't fully understand.

Thank you, again for your patience and help.

[Doug Gray]

ProPhoto RGB is a theoretical color space based on a theoretical display. G255 isn't a color. It falls outside human vision. You see this fact when you plot the numbers; the device values. So not all device values are colors. But all colors can be device values (in Lab for example).
And no, none of this has anything to do with anemic prints.

Interestingly, Adobe RGB (1998) G255, while representable in CIELAB, is outside of ICCLAB so ICC profiles using PCS  LAB clip it to a very slightly desaturated green before the profile mapping is performed. However, no printer that actually exists can print even that slightly desaturated green so it's of theoretical interests only.

[Doug Gray]

One way to quickly check a printer/paper profile is to grab an image of a colorchecker then print it using Photoshop. It s/b printed using Abs. Col. and the profile for your printer/paper.

http://www.babelcolor.com/colorchecker-2.htm#CCP2_images

Then visually examine the print and compare to a physical colorchecker. You can go further and measure the 24 patches with Patchtool. They should be quite close to the Lab values you see in Photoshop with the info tab.

This can quickly verify a color managed workflow. While it's limited to the 24 patches on a CC it will find 99% of messed up profile workflows.

[digitaldog]

Interestingly, Adobe RGB (1998) G255, while representable in CIELAB, is outside of ICCLAB so ICC profiles using PCS  LAB clip it to a very slightly desaturated green before the profile mapping is performed.

I'm not sure I understand the comment but what I can tell you with certainty is that G255 in Adobe RGB (1998) is a visible color that falls within the spectrum locus with room to spare. What that device value maps to after a conversion to (?) is possibly clipped. CTP is mapping the G255 to Lab just to show us this:
 

[Mick Sang]

So a printer ICC profile typically contains two models/tables, one describing the native (i.e. forward, i.e device values to color, AKA A2B table) behavior of the printer, and for performance reasons an inverse table (i.e. backwards table, reverse table i.e. color to device value, AKA B2A table). In a typical printing workflow it is the inverse table (B2A) that is used to translate the color of the source (i.e. the source image device values converted to color values by using the source images color profile forward table).

So, if I insert my current understanding of "device values" into this statement [inside brackets] would the following be correct:?

So a printer ICC profile typically contains two models/tables, one describing the native (i.e. forward, i.e device values to color, [The values of each image pixel that had been sent to the printer which caused colour to be printed] AKA A2B table) and for performance reasons an inverse table (i.e. backwards table, reverse table i.e. color to device value, AKA B2A table). [The measurements from the printed colours relative back to the numbers which had been sent to the printer to print those colours.]  In a typical printing workflow it is the inverse table (B2A) that is used to translate the color of the source (i.e. the source image device values [the numbers which represent each image pixel] converted to color values by using the source images color profile forward table).

[digitaldog]

The ICC specifies the tables and the direction in which they apply their color transformations in a somewhat confusing manner. Most profile editors use the same methods to allow the user to select what portion of the table they will edit. All our output profiles are table-based. Each profile contains multiple tables. A look-up table is used for conversions between the device color space (RGB, CMYK, etc.) and the PCS (Profile Connection Space, usually LAB) for each rendering intent. A profile has two directions to account for—data coming in for conversion to the PCS and data going out from the PCS to the device color space of the profile (RGB, CMYK, etc.). These tables are referred to as the AtoB and BtoA tags. There are six tags in each printer profile. The six tables are:

• AtoB0Tag (device to PCS, perceptual)—soft proof
• AtoB1Tag (device to PCS, colorimetric)—soft proof
• AtoB2Tag (device to PCS, saturation)—soft proof
• BtoA0Tag (PCS to device, perceptual)—output
• BtoA1Tag (PCS to device, colorimetric)—output
• BtoA2Tag (PCS to device, saturation)—output

The important item to keep in mind is the direction (device color space to PCS or PCS to device color space). When the direction is from the device color space to PCS, that table ultimately affects the soft proof. This is also known as the Forward transform or AtoB table. When the direction is from the PCS to device color space, that table controls the output portion. This is also known as the Inverse transform or BtoA table. When you edit the Inverse transform (BtoA), both the soft proof and the output will be affected by the edit since both need to be updated. When you edit the Forward transform (AtoB) only the soft proof will be affected. When you edit both the Forward transform (AtoB) and Inverse transform (BtoA), just the print (output) will be affected, and the soft proof will remain unchanged.

[Mick Sang]

One way to quickly check a printer/paper profile is to grab an image of a colorchecker then print it using Photoshop. It s/b printed using Abs. Col. and the profile for your printer/paper.

Thank you. I will do this now.

Mick

[Doug Gray]

I'm not sure I understand the comment but what I can tell you with certainty is that G255 in Adobe RGB (1998) is a visible color that falls within the spectrum locus with room to spare. What that device value maps to after a conversion to (?) is possibly clipped. CTP is mapping the G255 to Lab just to show us this:

Yes, Adobe RGB G255 is a very real, and visible, color and represented in CIELAB as 83.2, -129.1, 87.2   However, when converted to PCS LAB the a* is clipped at -128. So a printer (if one actually existed) profile would have to render it slightly desaturated. It's quite small, a dE2000 well under 0.5.  so not even visible if it could be printed which it can't. No printer has a chance in hell of that being within a printer's gamut so it's mostly of academic interest. 

[digitaldog]

Yes, Adobe RGB G255 is a very real, and visible, color and represented in CIELAB as 83.2, -129.1, 87.2   However, when converted to PCS LAB the a* is clipped at -128. So a printer (if one actually existed) profile would have to render it slightly desaturated. It's quite small, a dE2000 well under 0.5.  so not even visible if it could be printed which it can't. No printer has a chance in hell of that being within a printer's gamut so it's mostly of academic interest. 

Well no printer can print all of even sRGB if you want to look at RGB Working Spaces of any gamut.

[Doug Gray]

Well no printer can print all of even sRGB if you want to look at RGB Working Spaces of any gamut.

Ain't that the truth!  It's actually surprising how much of sRGB isn't printable. This is indeed, widely not understood.

[Mick Sang]

The ICC specifies the tables and the direction in which they apply their color transformations in a somewhat confusing manner. Most profile editors use the same methods to allow the user to select what portion of the table they will edit. All our output profiles are table-based. Each profile contains multiple tables. A look-up table is used for conversions between the device color space (RGB, CMYK, etc.) and the PCS (Profile Connection Space, usually LAB) for each rendering intent. A profile has two directions to account for—data coming in for conversion to the PCS and data going out from the PCS to the device color space of the profile (RGB, CMYK, etc.). These tables are referred to as the AtoB and BtoA tags. There are six tags in each printer profile. The six tables are:

Thank you again for this clarification. I didn't make the statement, though. GWGill did. I'd just like to know if the translations that I added to his statement re his use of the term "device values"  are accurate.

[Mick Sang]

One way to quickly check a printer/paper profile is to grab an image of a colorchecker then print it using Photoshop. It s/b printed using Abs. Col. and the profile for your printer/paper.

http://www.babelcolor.com/colorchecker-2.htm#CCP2_images

Then visually examine the print and compare to a physical colorchecker. You can go further and measure the 24 patches with Patchtool. They should be quite close to the Lab values you see in Photoshop with the info tab.

This can quickly verify a color managed workflow. While it's limited to the 24 patches on a CC it will find 99% of messed up profile workflows.

We downloaded this and printed it though that printer. As before all colours are close but reds and magentas. Print is anemic. One the print of the CC chart the red is muddy and dull and the light red patch above the deep red is also muddy and weak. Back to the "drill down."

By the way, nozzles clear, profile new, Mag and Lt Mag inks are new.

[Doug Gray]

We downloaded this and printed it though that printer. As before all colours are close but reds and magentas. Print is anemic. One the print of the CC chart the red is muddy and dull and the light red patch above the deep red is also muddy and weak. Back to the "drill down."

By the way, nozzles clear, profile new, Mag and Lt Mag inks are new.

OK, good stuff.

Next step is to read the 24 patches with Patchtool and the I1Pro2. In Patchtool select "Tools" then "Patch Reader"
It should automatically hook up with the plugged in I1Pro 2. You will need to calibrate it against the I1Pro2's white tab then you can read in each color one at a time. Select Lab and it will display the Lab values read. When done save them as CGATs. You should have a 3 new text files for M0/1/2. Then zip these files together with the profile you made for the printer and specify whether you used the iSiS2 or I1Pro used to make the profile. Attach the zip file with this and we can take a look with our tools.

[Mick Sang]

Next step is to read the 24 patches with Patchtool and the I1Pro2. In Patchtool select "Tools" then "Patch Reader"
It should automatically hook up with the plugged in I1Pro 2. You will need to calibrate it against the I1Pro2's white tab then you can read in each color one at a time. Select Lab and it will display the Lab values read. When done save them as CGATs. You should have a 3 new text files for M0/1/2. Then zip these files together with the profile you made for the printer and specify whether you used the iSiS2 or I1Pro used to make the profile. Attach the zip file with this and we can take a look with our tools.

Will do. Thank you very much.

[Mick Sang]

Then zip these files together with the profile you made for the printer and specify whether you used the iSiS2 or I1Pro used to make the profile. Attach the zip file with this and we can take a look with our tools.

Files per your request attached herewith Mr. Gray. I was misinformed about the colour in the resulting print of the CC Passport. A few are off. But, reds, light reds warm tones are the primary concern at the moment.

[Doug Gray]

Great! Looking forward to checking the info out. Off to dinner. Check back in 2 hours.

[Mick Sang]

Great! Looking forward to checking the info out. Off to dinner. Check back in 2 hours.

Whoops! I neglected to tell you that the profile charts were read using an Isis-2. The profiling software was i1Profiler v. 3.2. You will see that we use large charts i.e. thousands of patches. I have read several posts, some from you, sir, which indicate that charts as large as ours may not be necessary and may in fact be more of a waste of time & materials versus the achievable gains. But, until we gain more understanding of how to determine an optimal chart size, we'll stick with the status quo. It's not like profiles are made everyday and the Isis does much of the grunt work. That said, we and especially I still have much to learn.

Thank you, again, for your time.
Mick

[GWGill]

So, if it's not critical that the values come from, go to or are related to some device, I wonder why they are referred to as "device" values.

"Device values" is short for "Device dependent values". i.e the color implied by a set of such values is defined by the behavior of a particular device.  The other sort of color space is "Device independent". That is a space defined as some sort of mathematical transform of the standard observer.

[Doug Gray]

Whoops! I neglected to tell you that the profile charts were read using an Isis-2. The profiling software was i1Profiler v. 3.2. You will see that we use large charts i.e. thousands of patches. I have read several posts, some from you, sir, which indicate that charts as large as ours may not be necessary and may in fact be more of a waste of time & materials versus the achievable gains. But, until we gain more understanding of how to determine an optimal chart size, we'll stick with the status quo. It's not like profiles are made everyday and the Isis does much of the grunt work. That said, we and especially I still have much to learn.

Thank you, again, for your time.
Mick

The ICC profile looks fine. Gamut shape is excellent. I see you are using 4066 patches.

But the CC image!
Yikes. 13 of the CC colors are between deltaE 13 and 35.

Next. Since the profile has the proper shape the next step is to see what setting you are using when printing.
Please do an image capture of the dialog box of the driver settings and sub dialogs in the driver settings you used in Photoshop.

Also, identify the CPU and OS version you use. I use Windows 10 and different printers (Epson 9800, Canon Pro1000, Canon 9500II) but can probably see what's wrong in the driver settings.

Somehow something really wrong is being set in the drivers when printing but it looks like your profile is fine.

[Mick Sang]

"Device values" is short for "Device dependent values". i.e the color implied by a set of such values is defined by the behavior of a particular device.  The other sort of color space is "Device independent". That is a space defined as some sort of mathematical transform of the standard observer.

Thank you for this. It is quite clear. It is more the use of the term "device values" which often trips me up. It's becoming clearer. But, your confirmation would be helpful.

Below, I have copied a post which you made earlier.  I have inserted, inside square brackets, my understanding of what you mean when you refer to "device values."  Would you mind telling me if I have the meaning of "device values" correct and that I understand you correctly? I would appreciate it.

So a printer ICC profile typically contains two models/tables, one describing the native (i.e. forward, i.e device values to color, [The values of each image pixel that had been sent to the printer which caused colour to be printed] AKA A2B table) and for performance reasons an inverse table (i.e. backwards table, reverse table i.e. color to device value, AKA B2A table). [The measurements from the printed colours relative back to the numbers which had been sent to the printer to print those colours.]  In a typical printing workflow it is the inverse table (B2A) that is used to translate the color of the source (i.e. the source image device values [the numbers which represent each image pixel] converted to color values by using the source images color profile forward table).