Prints Suddenly Anemic

[Mick Sang]

Hello All:
I hope someone has a suggestion that may help with another “stumper” we have encountered this time with our 4900. Suddenly we see a clear colour shift in the prints primarily in the reds which results in awn overall anemic look. We run nozzle checks prior to every print run and they are all firing. We made a new custom profile for the paper involved. But, the reds are still anemic. We have a P5000 running side by side with the 4900. So, we reprofiled the same paper on the P5000 as well and ran a print through it for comparison. It was perfect as compared against the on-screen soft-proof.
 
In ColorThink each profile looks good. Although the P5000 has a larger gamut, the overall shape looks good and the LAB values of each RGB patch are very close. Also, very importantly, the on-screen soft-proof through each custom profile looks good - virtually the same between the 2 printers. So, both profiles appear to be fine. We also printed a simple colour patch chart through each printer via ACPU (no profile) to compare the solid colour patches. The density of the solid red from the 4900 reads slightly lighter than that from the P5000. The Magenta patch from the 4900 reads .65 and is .80 from the P5000. Visually,the result from the 4900 doesn't appear to be so much lighter as to be the cause of this obvious reduction that we see in the oranges, skin tones and reds throughout images. The ICC profiles were made with the same inks in each machine, as they are, and the soft-proof through the 4900 profile doesn't indicate the anemic result in print. So, the problem appear to be with the printer Right?
 
This started last month. Prior to this, the 4900 was printing fine. Any thoughts would be greatly appreciated.
 
Paul

[Pat Herold]

You have covered all the troubleshooting basics.  Congratulations - that's impressive!  Here are a few more ideas:

- You might double check that your profiling target did not have color management going on when printed.  (You said the gamut shape looks good, so maybe you have already confirmed this?)

- Have you changed an ink cartridge recently?  It very rarely happens that you get a bad (or old) batch of ink, but I have to ask...

- Have you inadvertently changed your working space profile?  Read this article for more info regarding reds turning to orange:
http://www.colorwiki.com/wiki/Color_Management_Myths_11-15

- Once in a blue moon, I hear about a mysterious color problem being solved by deleting and reinstalling the printer driver (probably more relevant to a Windows user.)

Good luck!

[Mick Sang]

- Have you changed an ink cartridge recently?  It very rarely happens that you get a bad (or old) batch of ink, but I have to ask...

Thanks very much, Pat.

Yes, in fact the Magenta was changed not too long prior to this issue coming about. As I noted, the density of s solid magenta patch on the colour charts that I printed does read .15 lighter than the magenta patch from our P5000 from which prints match the on-screen soft proof. But, I have been disregarding that because the soft proof of the 4900 profile shows very little (almost no) difference between it and the P5000 profiling of the same paper (viewed on Eizo CG319x) not to mention that ColorThink shows the 2 profiles to be very similar. Also, visually the patches don't appear much different. Based upon the resulting photo print from the 4900 profile, I would have expected the solid Magenta patch on the test to be very washed out - much lighter.

The only difference between the two profiles appears when the image that started this is printed - skin colour and rust tones. It's a close up of a woman's face on a copper colour background. How can this be? Of course, I doubted myself, as I can certainly be prone to screwing up. But, repeated prints have shown the same result.

One of the things I love most about fine inkjet printing is there is always something to learn. I have never seen anything like this nor have I heard of it. So, I'm unfortunately at a loss. All I can do now is to try a different magenta ink cartridge. But, even if that worked, it would not explain why both profiles soft proof so similarly and the results in ColorThink don't show any anomalies.

- Have you inadvertently changed your working space profile?  Read this article for more info regarding reds turning to orange:
http://www.colorwiki.com/wiki/Color_Management_Myths_11-15

I wish I had. That's rather what the final print looks like. But, everything was set properly.

- You might double check that your profiling target did not have color management going on when printed.

All targets for both profiles (4900 and P5000) were printed through ACPU.

- Once in a blue moon, I hear about a mysterious color problem being solved by deleting and reinstalling the printer driver (probably more relevant to a Windows user.)

If all else fails, I will try this.

[GWGill]

The only difference between the two profiles appears when the image that started this is printed - skin colour and rust tones. It's a close up of a woman's face on a copper colour background. How can this be? Of course, I doubted myself, as I can certainly be prone to screwing up. But, repeated prints have shown the same result.

Another thing to investigate is whether it is a spatial issue. This can lead to a mismatch between chart and print. i.e. try printing the image upside down and see if it looks the same.

Failing that, if it were me, I'd simply drill down. Figure out the L*a*b* of the problem color. Look that up in the profile to get the device values. Print test patches of that device color and measure them. Do the forward lookup of that device color and check the L*a*b*. Lookup that L*a*b*'s device value in the source profile. Convert that through the linked source and destination profile and check the resulting printer device value. etc.

[Mick Sang]

Print test patches of that device color and measure them. Do the forward lookup of that device color and check the L*a*b*. Lookup that L*a*b*'s device value in the source profile. Convert that through the linked source and destination profile and check the resulting printer device value. etc.

I'm sorry, I don't understand all of this. You have suggested that I identify the L*A*B* values of the relevant range of colours get, record the corresponding device values, create a test target with that range, print and measure it. I think I understand so far. Please correct me if I'm wrong. But, after that, I'm lost. What is meant by "do the forward lookup etc?"

This process sounds very interesting and seems that it might lead me to an answer as to what is the cause of the anemic prints. I would certainly try it if I understood it fully.

[GWGill]

This process sounds very interesting and seems that it might lead me to an answer as to what is the cause of the anemic prints. I would certainly try it if I understood it fully.

A profile is meant to be a model of the device (i.e. printer) behavior. You describe a problem that appears to be related to the model or the workflow that is using the model not describing the device behavior. So drilling down means figuring out if or where or how the device behavior and model or workflow deviate. 

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 it were me (of course), I'd use xicclu to interrogate the ICC profile. You need to be cognizant of the encoding/ranges used, and the direction and the intent you are using. If you are checking against measurement values, you probably want to use absolute colorimetric intent.

To check the forward table, you might want to use:

    xicclu -ff -ia -pl profile.icc

To check the backward table, you might want to use:

    xicclu -fb -ia -pl profile.icc

If you suspect that the problem may be a disagreement between the forward and
backward tables, you may want to check the reverse lookup using the inverse
of the forward table:

    xicclu -fif -ia -pl profile.icc

Note that by default, the device ranges are 0.0 .. 1.0, and that using -pl that the color/CIE/Profile Connection Space values will be in L*a*b*.

Of course if you are not familiar with running command line software, you may have to look for other tools to interrogate the ICC profiles.

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

Thank you for taking the time to provide all of this. The above has helped to clarify some things about printer profiles for me.

Of course if you are not familiar with running command line software, you may have to look for other tools to interrogate the ICC profiles.

Alas, sadly I am not. But, I suspect ColorThink may be of some help in this analysis. I will explore this with that if possible.

Thanks again,
Mick

[digitaldog]

ColorThink Pro can absolutely provide such analysis. Do you have the Pro version?

[JRSmit]

Mick, the orange cartridge in the 4900, is that one not way over date? Just asking.

[Pat Herold]

Mick, I have not heard whether you have access to ColorThink Pro or not?  There are several ways to use the Worksheet to emulate a workflow.  You can follow a color through the different profile transforms you're using in your printing workflow and see if this matches up with what you're seeing on the press.  As Gil says, you'd want to start with the Lab value of your problem color and see what happens to it as it goes through the profiles in your system.

http://www.colorwiki.com/wiki/Quantify_Out_Of_Gamut_Colors

http://www.colorwiki.com/wiki/Save_As_Lab_list

[Mick Sang]

Mick, the orange cartridge in the 4900, is that one not way over date? Just asking.

Sorry for the delayed reply. We just installed a 9570 and have been profiling etc. The orange and all inks in the 4900 are nowhere near the expiration dates and have been in the machine for a couple of months.

Mick, I have not heard whether you have access to ColorThink Pro or not?  There are several ways to use the Worksheet to emulate a workflow.  You can follow a color through the different profile transforms you're using in your printing workflow and see if this matches up with what you're seeing on the press.  As Gil says, you'd want to start with the Lab value of your problem color and see what happens to it as it goes through the profiles in your system.

Yes, we have ColorThink Pro. But, we are not familiar with the technique required to to explore the reason for our anemic reds. I will see if I can figure out how to "follow a colour through the different profile transforms." Right now, we have stopped using that printer until we can find and fix the reason for this.

Thank you for the links.

[Doug Gray]

Mick,

If you have a spectrophotometer you can print a selection of LAB colors in increments of 10 L*,a* and b* from BruceLindbloom's site using Abs. Col. and check accuracy around the colors on interest with the spectro. I used to use those before I got PatchTool which automates it. It's under the Info tab and called "Profile Evaluation images"

[Mick Sang]

Mick,

If you have a spectrophotometer you can print a selection of LAB colors in increments of 10 L*,a* and b* from BruceLindbloom's site using Abs. Col. and check accuracy around the colors on interest with the spectro. I used to use those before I got PatchTool which automates it. It's under the Info tab and called "Profile Evaluation images"

Thanks Doug, I will pursue this. We do have an i1Pro-1 and 2 as well as an Isis-2.  We also have patch Tool. But, I have never used it. I appreciate this information and help very much. Thanks to all. I'll report back the results.

Mick

[Mick Sang]

OK, to be brutally honest, there are certain terms used often in colour management speak which are not entirely clear to me. For example, I need to ask for clarification on a basic term so that I can get on with the tests required to determine what is going on with our 4900 and its anemic prints. Im going to ask what many if not most of you might find a very rudimentary question. Nevertheless, without clarification I can't proceed with any real understanding. Here goes: What are device values? Are they values (sets of numbers) sent to the printer or the values read from the printed output a.k.a. the results?

[digitaldog]

When a device (a printer, a display etc) produce a pixel/dot(s), that pixel/dot(s) has a set of numbers (triplets) for RGB; those are device values. As the name implies. The values might be in a Working Space (not really a device but based on a theoretical 'device') and those values are sent to a printer after conversion to a value intended to be converted to that device. So an example could be: Adobe RGB (1998)  to Epson 3880 Luster paper. There's quite a bit more to that (it's not a direct RGB to RGB conversion) but that's not necessary to understand at this point. When you measure that one color from the 3880 on luster paper, that Lab value measured is a device value. 

[Mick Sang]

When a device (a printer, a display etc) produce a pixel/dot(s), that pixel/dot(s) has a set of numbers (triplets) for RGB; those are device values. As the name implies. The values might be in a Working Space (not really a device but based on a theoretical 'device') and those values are sent to a printer after conversion to a value intended to be converted to that device. So an example could be: Adobe RGB (1998)  to Epson 3880 Luster paper. There's quite a bit more to that (it's not a direct RGB to RGB conversion) but that's not necessary to understand at this point. When you measure that one color from the 3880 on luster paper, that Lab value measured is a device value.

Thank you. So, if I understand you correctly, device values are simply those which are produced by a device - not those which are sent to the device. I hope that is correct. I have heard and read statements from people such as the following:  " ColorThink comes up with these device values and sends them through a profile and proofs them saying if I were to send these device values to the printer what colours would I get?"  Hence my confusion. I think I see what is being said there. But, I have to keep the correct definition of the term "device values" in mind as we go through some of this stuff.

[Doug Gray]

Thank you. So, if I understand you correctly, device values are simply those which are produced by a device - not those which are sent to the device. I hope that is correct. I have heard and read statements from people such as the following:  " ColorThink comes up with these device values and sends them through a profile and proofs them saying if I were to send these device values to the printer what colours would I get?"  Hence my confusion. I think I see what is being said there. But, I have to keep the correct definition of the term "device values" in mind as we go through some of this stuff.

It can be confusing. Printer profiles provide tables for converting colors between a standard colorspace such as Lab (sRGB, ProPhoto RGB, etc. are converted first to Lab), and a printer's native RGB. Since the same printer RGB value will produce different colors on different papers, especially matte or glossy, one has to have a profile for each printer/paper/driver setting combination.

A profile contains 3 dim tables that allow conversion both ways so a printer's RGB value can be converted to the corresponding Lab color.  Of course normal printing converts Lab values to the corresponding printer's device RGB values. This happens behind the scenes when you print with Photoshop or LR.

As an example, my Pro1000 converts the Lab skin color (70,20,20) to the device RGB values 220,138,148 on a glossy paper. If I were to create a patch with these values and print it out with a program that directly prints device RGB values such as Adobe's ACPU utility (normally used for printing profile charts) and measure it with the I1 Spectro I would get readings that were quite close. Within 1 dE or so.

Alternately, I could just make a patch in Photoshop using Lab colorspace with the skin Lab values of (70,20,20) and print it to the printer after selecting Abs. Col. and choosing the paper's profile. The results are the same.

A note about Abs. Col. This prints exactly the color requested or the closest (in some sense) color that the printer is capable of printing. If it can, it's in gamut. If it can't, the color is out of gamut. Rel. Col. is very similar to Abs. Col. except that values are scaled so that Lab(100,0,0) corresponds to the paper's actual unprinted white.

This describes how profiles work in more detail and the site generally covers profiles quite well.
http://www.color.org/ICC_white_paper_7_role_of_ICC_profiles.pdf

[digitaldog]

Thank you. So, if I understand you correctly, device values are simply those which are produced by a device - not those which are sent to the device. I hope that is correct. I have heard and read statements from people such as the following:  " ColorThink comes up with these device values and sends them through a profile and proofs them saying if I were to send these device values to the printer what colours would I get?"  Hence my confusion. I think I see what is being said there. But, I have to keep the correct definition of the term "device values" in mind as we go through some of this stuff.

It a strict sense, device values could be said to be from some device but it's not critical. CTP calls RGB and CMYK numbers device values and that's fine. Pixels have values and no matter where they come from or go, it's fine to call them 'device values'. RGB color spaces can have device values that are not actual colors (G255 in ProPhoto RGB) and while no device made that value, there is nothing wrong calling it a device value (cause it ain't a color).
See:
http://digitaldog.net/files/ColorNumbersColorGamut.pdf

[Mick Sang]

In a strict sense, device values could be said to be from some device but it's not critical........no matter where they come from or go.

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.
 
So, they are values that are perhaps relative to some device, conceptual or real, but not necessarily so. They can come from device output and / or be sent to an actual device. Is that a fair understanding?

The thing is, I realise they are sets of numbers which refer to colours real or imaginary. But I'm trying to understand why they are referred to as "device" values.

At this stage, I would not be surprised if one were to ask what the heck has this got to do with his anemic prints issue? The answer is that I am "drilling down" into this thing as was said by GWGill. But, I ain't the brightest light on the tree. So, if I'm not 100% clear on a relevant term, I can't proceed with real clarity and confidence. This one has been irking me for some time.

As an example, my Pro1000 converts the Lab skin color (70,20,20) to the device RGB values 220,138,148 on a glossy paper.

This portion of Doug Gray's post makes perfect sense to me as long as I think of "device values" as being values which had been read from output by or relative to the output of some device - a printer in this case.

If I were to create a patch with these values and print it out with a program that directly prints device RGB values such as Adobe's ACPU utility

However, it is when the term is used as though it's synonymous with the word "values" whether going in or coming out, that I become muddled. So, if ACPU prints "device" values, then this means we are sending those values to the printer. So, if they go both ways, as it were are they referred to as device values because they are only used in concert with some device?

[digitaldog]

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.

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.