Prints Suddenly Anemic

[Doug Gray]

I'm told that the firmware is also current. So now what?

Some have had success removing the old driver and re-installing. However, I don't use Apple computers. There have been issues reported with Apple from time to time but the problem you are seeing is pretty blatant. Perhaps someone with Apple CPUs can offer specifics.

[Mick Sang]

Some have had success removing the old driver and re-installing. However, I don't use Apple computers. There have been issues reported with Apple from time to time but the problem you are seeing is pretty blatant. Perhaps someone with Apple CPUs can offer specifics.

Thank you again. Yes, this occurred to me.... finally. Tomorrow the printer will be deleted and completely reinstalled. That's all that's left as far as I can see. Thanks very much, again. I'll report back the results. In the meanwhile, be well.

Mick

[ColourPhil]

Mick, when you re-install the printer W-A-I-T for the correct one to come along and NOT Apple Airprint!
https://www.colourphil.co.uk/printing-mac_colour_problems.shtml
Also, are you on the last version of Mojave? There were problems with the earliest versions.
As Andrew (I think) suggested, try without 16-bit checked as well. Problems with that and some versions of Mojave.
Cheers,
Phil.

[datro]

I'll admit up front I haven't read this thread in entirety so my question here may have been already covered...if so, just ignore my post.

How are you viewing all your test comparison prints?  Halogen?  LED?  Something else?
Are you consistently using the exact same lighting to review all the prints?
Did you by any chance change something about your viewing lights when the problem started, e.g. switching to LED lighting?

[Mick Sang]

Mick, when you re-install the printer W-A-I-T for the correct one to come along and NOT Apple Airprint!
https://www.colourphil.co.uk/printing-mac_colour_problems.shtml
Also, are you on the last version of Mojave? There were problems with the earliest versions.
As Andrew (I think) suggested, try without 16-bit checked as well. Problems with that and some versions of Mojave.

Thanks Phil, and thanks for the link. The Mac that runs the 4900 and P5000 is on the latest version of Mojave. We haven't and won't move to Catalina until it is clear that all the anomalies that it is responsible for have been resolved. We were aware of many of those mentioned in the article re Catalina and the early version of 10.14.6 which is why we've stayed with the Mojave. We would have stayed with High Sierra but the OS became corrupt (I think as a result of a "security update" and we were unable to fix it. So far, until January at least, Mojave has been stable for us on several MACs.

I understand what you're saying about "AirPrint". But, I wouldn't accept it anyway as we don't use it and have no need of it even for our P800. We tried it with that printer and it failed the audition.

Re 16 bit vs 8 bit, yes both Mr. Rodney and Mr. Gray advised against it and I have read Mr. Gray's past posts on the subject. After installing the new driver we printed via both bit depths. There was no difference. Henceforth, we are using 8 bit at least or until this is resolved. I will be deleting and reinstalling the printer on that Mac shortly.

Thanks again,
Mick 

[Mick Sang]

I'll admit up front I haven't read this thread in entirety so my question here may have been already covered...if so, just ignore my post.

How are you viewing all your test comparison prints?  Halogen?  LED?  Something else?
Are you consistently using the exact same lighting to review all the prints?
Did you by any chance change something about your viewing lights when the problem started, e.g. switching to LED lighting?

Thank you, no this has not been asked. We have a viewing booth in each studio. One is a large GTI 5k and the other consists of a 10 lamp Solux 5k array. I prefer the latter. That is where we have been comparing the prints. Nothing has been changed in terms of the lighting in either studio. But, let me assure you that the anemic red issue is obvious in any lighting condition. This is not a slight difference. It is significant - from copper tone warm reds to sandy browns.

Mick

[Mick Sang]

Mick, when you re-install the printer W-A-I-T for the correct one to come along and NOT Apple Airprint!
https://www.colourphil.co.uk/printing-mac_colour_problems.shtml

Thanks again for this link, Phil. I reread it before deleting and reinstalling the driver for our 4900. The instructions re saving presets saved us a heck of a lot of time and aggravation involved in resetting them all up.

So, we deleted and reinstalled the printer in the OS prefs, ran a print and got exactly the same anemic result. This GD thing really has me PO'd. I've never encountered anything like this nor do I know anyone who has.

The image was changed to 8 bit, the 16 bit checkbox in the driver was unchecked - so it was run via the 8 bit path, the firmware is up to date and the new driver is the current version - 10.35. Since the print was no better, I shut down and restarted everything as a matter of routine with stubborn issues like this. No dice.

Thanks to a suggestion by Doug Gray, we know that the printer is capable of printing the image correctly as long as there is no normal colour management involved i.e. not from PhotoShop with ICC profile.

I've attached a small version of the image to show the copper tone reds that I've been describing. On the prints the results are browns. The red is subdued.  Any suggestions are welcome. Our cupboard is now bare.

Mick

[GWGill]

Our cupboard is now bare.

Well, no it's not, but to continue you have to be prepared to do the detective work of measuring colors and
tracing what the printing and color management system is doing.

[Doug Gray]

Not having Apple CPUs I can only offer some experiments one of which might be a workaround.

1. Given the profile created by ACPU, which I will call NewProf, convert an image to NewProf with rendering intents as desired.

2. Print it in Photoshop using Photoshop Manages Color but also select NewProf. Photoshop will put up a flag that what you are trying to do is a bad thing (defeating color management) and offer to get ACPU. Ignore the warning by clicking cancel. Then print it.

This is the Null-Transform trick that has always worked well in Windows in spite of the annoying warning. It appears to have been put in when Adobe removed the option to print directly w/o color management due to some issue in Apple OS much to the annoyance of people used to printing targets that way. There is some chance it will work for you. If so you now have a workaround.

Alternately:

Consider trying out ImagePrint which was for Windows only but they have a new version for iOS. It also uses the printer driver but at a lower level. Might not work but relatively inexpensive and you can test out a trial version.

Or get a true RIP processor which bypasses the printer driver. However, these tend to be expensive.

Or use a windows computer.

Or use another Apple. There is some chance the one you are using has suffered some failure that shows up this way. Seems remote but given that it was working and suddenly stopped it may be within the realm of possibilities.

[Mick Sang]

Well, no it's not, but to continue you have to be prepared to do the detective work of measuring colors and
tracing what the printing and color management system is doing.

Honestly, sir, if I knew how to go about that I would do it. So far, using the method described by Mr. Gray we were able to show that the printer is still able to print the warm copper-tones accurately; by printing the file from the same MAC directly to our P5000 using the profile specific to our 4900 we were able to prove that the profile is working well - we got a good print; and finally, by analyzing 100 colours pulled from the image in ColourThink Pro we saw that the profile vs the image are within Delta-e2000 of around 1 to 1.5.

So, aside from what you're suggesting here which if it's other than what we've done and seen so far, I have nothing else. But, I am quite prepared to try whatever I can to get this fixed. I will not stop as long as I understand what has to be done next.

Mick

P.S. The image I uploaded previously has a red quality otherwise it's a muddy mess compared to the full res image. I forgot to convert to sRGB. Another is attached.  Geeez!

[Mick Sang]

Not having Apple CPUs I can only offer some experiments one of which might be a workaround.

1. Given the profile created by ACPU, which I will call NewProf, convert an image to NewProf with rendering intents as desired.

2. Print it in Photoshop using Photoshop Manages Color but also select NewProf. Photoshop will put up a flag that what you are trying to do is a bad thing (defeating color management) and offer to get ACPU. Ignore the warning by clicking cancel. Then print it.

This is the Null-Transform trick that has always worked well in Windows in spite of the annoying warning. It appears to have been put in when Adobe removed the option to print directly w/o color management due to some issue in Apple OS much to the annoyance of people used to printing targets that way. There is some chance it will work for you. If so you now have a workaround.

And I appreciate your taking the time to do this. Thank you. I recall the issue that was responsible for bringing ACPU into the world. I see how this might work and will try it tomorrow.

If this works, while a work-around would be helpful, I'm the sort that will not be able to rest until this is solved. We have 4 other printers and this one has been relegated to office type work until we get the answer / solution to this. So, it's more important that we get it solved. I'll report back once the test is done. In the meanwhile, Happy Easter.

Mick

[Doug Gray]

And I appreciate your taking the time to do this. Thank you. I recall the issue that was responsible for bringing ACPU into the world. I see how this might work and will try it tomorrow.

If this works, while a work-around would be helpful, I'm the sort that will not be able to rest until this is solved. We have 4 other printers and this one has been relegated to office type work until we get the answer / solution to this. So, it's more important that we get it solved. I'll report back once the test is done. In the meanwhile, Happy Easter.

Mick

I should explain further how the null transform trick works, at least in Windows.

Because Photoshop sees the profile attached to the image is the same profile as the one selected in the print menu, it skips the conversion process that is required for say converting from Adobe RGB to the printer device space. The image is already in device space so it just sends it to the driver directly.

A side effect is that the rendering intent settings have absolutely no effect on the print. You can select Perc., Relative, or Abs. and check/uncheck BPC and there is zero effect on the resulting print. These settings are only meaningful when converting from a standard colorspace. But you do get the rendering intent that was selected when the image was converted to the printer profile earlier.

However, it may not work that way on Apple.

[Mick Sang]

Because Photoshop sees the profile attached to the image is the same profile as the one selected in the print menu, it skips the conversion process that is required for say converting from Adobe RGB to the printer device space. The image is already in device space so it just sends it to the driver directly.

Thank you for this clarification. I understand. Nevertheless, I just ran several tests which turned out to be frustrating and perplexing as usual with this issue.

Through Photoshop, I printed the last test as described by you, Mr. Gray. But, the print was no good i.e. browns instead of copper tones and reds. It seemed to me that the test should have worked, since the first test whereby I converted the image to the Ultra Premium Presentation Matte / 4900 profile then saved the image without a profile attached and subsequently printed it from ACPU had worked. The print was good. But, not this time.

By the way, the ACPU warning did appear with a link to get ACPU. But, there was nothing to cancel. You just ignore it and go ahead and print the file with the profile embedded and the same one selected.

So, I ran that earlier test again through ACPU (file converted to UPPM profile, file saved without profile) and to my amazement and frustration it also failed this time. The print consisted of browns consistent with the majority of other failed prints versus the copper tones and reds in the actual image. This coincides with a test I had run earlier on the 4900 whereby I had printed to a matte roll stock which was already in the machine using the profile for the UPPM sheets and the result was good. However, a subsequent print on that paper made the same way was also brown. Admittedly, I questioned if I had done something incorrectly and fooled myself. It wouldn't be the first time. But, I have been checking everything at least twice and making meticulous notes along the way. So, this thing seems to be somewhat intermittent but more off than on.

Then, to see if things had become worse with the printer, I ran a print through "Printer Manages Colour" with no profile and AdobeRGB selected. This print matched the one I had made the first time I had run that test. It was good. So, once again it appears that the printer is capable of printing those reds as long as no colour management is employed.

Then, to check to what degree the MAC might be responsible, I replaced it with another that I took from another studio. From that MAC, I printed the image to the 4900 as per normal on UPPM with the 4900 UPPM profile. The result was the same as the majority of the others - brown. So it seems to me this takes the MAC out of the equation as having any responsibility for this issue.

With this I ask what goes on in the print "pipeline" that could cause this. Is the main board in the printer responsible for these transformations? If so why would it consistently print OK as long as "Printer Manages Colour" and no profile is involved? As I typed that I had to wonder why printing from ACPU didn't work this time? No profile was attached to that image. Isn't that similar?

Lost again.....still.

Mick

[MichaelKoerner]

Hi Mick,

have you tried changing the CMM in Photoshop (on my system, I could switch from Adobe (ACE) to Apple CMM)?. As I understand, you have already updated/tried everything except this... Just a guess.

Best regards, Michael

[Mick Sang]

Hi Mick,

have you tried changing the CMM in Photoshop (on my system, I could switch from Adobe (ACE) to Apple CMM)?. As I understand, you have already updated/tried everything except this... Just a guess.

Best regards, Michael

Will do, Michael. Thanks for the suggestion, Nothing to lose now.

Mick

[Mick Sang]

have you tried changing the CMM in Photoshop (on my system, I could switch from Adobe (ACE) to Apple CMM)?. As I understand, you have already updated/tried everything except this... Just a guess.

I just tried this by converting the image to the UPPM 4900 profile using AppleCMM instead of Adobe (ACE) CMM, saving the file without profile attached and printing via ACPU to no avail, unfortunately. Nevertheless, thank you for your suggestion.

Attached is a reasonable approximation of a comparison of the results. The one on the right is closer to the required colour.

I hope someone can suggest a solution or test or information which might lead to one. Something in the print pipeline appears to be causing the printer not to convert profiles correctly. So, it seems to me.

Mick

[MichaelKoerner]

Hi Mick,

a) did I understand you right that using "Printer Manages Colour" works always - regardless which Mac and which paper you use?

b) I wonder what driver settings you use when using "Printer Manages Colour" (and everything works fine). Could you provide screenshots of "color matching" and "printer settings" tabs?

c) Perhaps I missed the answer, but did you follow Graeme’s input in reply #3 (printing the image upside down)? And what happens when printing other, i.e. typical test images (via "photoshop manges colour") - same anemic effect?

d) If you compare
  1) actual profiles for P5000 and the P4900, and
  2) old and new profiles of the P4900
are there differences in the measured values of primaries, especially magenta? In your very first post you mentioned differences between magenta patches printed via ACPU on the two printers. I wonder whether this  behavior is / is not represented in the corresponding profiles.

e) Have you considered a technical problem on the printer (not the head, which was reportedly clean, but perhaps some tubes...)? Sounds stupid, but perhaps running some cleaning cycles could help (but the reportedly well working "Printer Manages Colour" workflow makes that very unlikely).

Regards, Michael

[Mick Sang]

a) did I understand you right that using "Printer Manages Colour" works always - regardless which Mac and which paper you use?

b) I wonder what driver settings you use when using "Printer Manages Colour" (and everything works fine). Could you provide screenshots of "color matching" and "printer settings" tabs?

c) Perhaps I missed the answer, but did you follow Graeme’s input in reply #3 (printing the image upside down)? And what happens when printing other, i.e. typical test images (via "photoshop manges colour") - same anemic effect?

d) If you compare
  1) actual profiles for P5000 and the P4900, and
  2) old and new profiles of the P4900
are there differences in the measured values of primaries, especially magenta? In your very first post you mentioned differences between magenta patches printed via ACPU on the two printers. I wonder whether this  behavior is / is not represented in the corresponding profiles.

e) Have you considered a technical problem on the printer (not the head, which was reportedly clean, but perhaps some tubes...)? Sounds stupid, but perhaps running some cleaning cycles could help (but the reportedly well working "Printer Manages Colour" workflow makes that very unlikely).

Regards, Michael

Thank you, Michael. I will answer your questions in order as follows:

a & b) Running the print using “Printer Manages Colour” without a profile is the only method that has worked repeatedly. In the driver under “Colour Matching” I selected “Epson Colour Controls” and under "Printer Settings" I selected the settings as per the attached screen capture. After this, I changed the selections to “Colorsync” and selected the appropriate Epson Profile for UPPM. The print failed. It was anemic. So the same anemic result was apparent from Epson’s profile and ours.

c) I did not print that test as I can not imagine how rotating the image to print it upside down could possibly change the rendering. I certainly get that moving a print to different positions on a viewing table can affect our perception of its appearance when evaluating fine nuance of colour and shade. But, the difference here is stark. Nevertheless, since I do not want to stand in the way of any possibility to solve this issue, I will run it and report back.

d) Yes, the measured primaries are slightly different between the 4900 and the P5000. Early on we printed a chart consisting of several large solid patches including primaries. The VM on the 4900 L:68.15, A: 60.37, B:-15.45. On the P5000: L:64.20, A:66.76, B:-13.41. The density of the VM on the 4900 is .75 and from the P5000 it’s .90. The chart was printed through ACPU with UPPM media setting.

Despite these differences, the prints which have worked, though they be few and far between, look ok. For example the prints as described in a & b above.

e) Your suggestion doesn't sound "stupid." I'll take any suggestion. But, the head is clear. Contrary to many posts I have read, it is more often clear than not. But, this was the first thing we made very certain to ensure.

Based upon the fact that two tests worked once and subsequently failed, I'm beginning to wonder about the possibility of this being hardware related. That is what prompted my recent question as to where the actual translation / decoding of the numbers which are sent to the printer takes place - the main board? Case in point is a test suggested by Mr. Doug Gray whereby he asked me to convert the image to the UPPM profile, save it without a profile and print it from ACPU. This worked. The copper tones and reds were present - for one print anyway.

However, when a subsequent test failed, I returned to that test and ran it again. This time, it also failed. I had run into a similar thing early on in this investigation when I printed to a roll paper which was already in that printer using the UPPM profile. The print was ok. A subsequent print on that paper using the same profile failed. I thought I must have screwed up. But, I had been making meticulous notes. So, I was in doubt but pretty sure I had printed it as noted. But, the failed repeat of Mr. Gray’s test seemed to indicate there may be some intermittency to this thing. But, why would files printed without embedded profiles work?

Mick   

[MichaelKoerner]

a & b) Running the print using “Printer Manages Colour” without a profile is the only method that has worked repeatedly. In the driver under “Colour Matching” I selected “Epson Colour Controls” and under "Printer Settings" I selected the settings as per the attached screen capture. After this, I changed the selections to “Colorsync” and selected the appropriate Epson Profile for UPPM. The print failed. It was anemic. So the same anemic result was apparent from Epson’s profile and ours.

So we can assume that the problem has something to do with the way ICC profiles are handled on your machine regarding this printer, as PS is affected as well as the Epson driver, but not when printing to the P5000, right?

You mentioned to have tried printing from another Mac to the 4900, getting the same anemic result. Was this machine on the same OS/driver level or did it go with the older driver? I'm not sure whether my thoughts are logical, but if the older driver/OS/ColorSync/... became "corrupted" by some OS update, the now newer printer driver could work - but with the old! (or a newly made) profile. The "new" one was somehow corrupted by this quirk, as Doug Gray showed us (if I got him right).

By the way: You can see those differences visually if you soft proof the image in PS with the old and the new profile, checking "Preserve numbers". When I use the new profile - in my interpretation - it tries to compensate for that OS/driver/whatsoever quirk.

c) I did not print that test as I can not imagine how rotating the image to print it upside down could possibly change the rendering.

According to "Real World Color Management" (quote): "The only real source of variability we find in (RGB Printers) is that the profiling target may print slightly differently depending on its orientation. Color geeks refer to this problem as anisotropy - an obfuscatory way of saying that the printer produces slightly different color when printing the same image in portrait and landscape orientations. In our experience, the effect of anisotropy is usually quite subtle, and unless you're picky, you may not even notice the effect it has on your images" (end of quote).

The simulation image you showed us tells us that the effect is in no way subtle so I think you can skip that...

Based upon the fact that two tests worked once and subsequently failed, I'm beginning to wonder about the possibility of this being hardware related.

That was my idea as well, but that "Printer manages color" thing made me rethink. So I would have a try with the old profile/new driver combination first.

And then: If you had a backup of the machine from the time it still worked (aka before end of January) this could also proof whether the hardware were alright and the problem on the software side.

Michael

[Mick Sang]

So we can assume that the problem has something to do with the way ICC profiles are handled on your machine in general, as PS is affected as well as the Epson driver (one could use another trustworthy application like PrintTool, just to be sure).

I agree. Also, a print made using Print Tool 2.1, managed by same, using same UPPM paper and profile resulted in the same anemic print per the others. In Print Tool under "Print Tool Managed" I would be using the same Epson driver would I not? I understood the only way to avoid that was to use QTR inside of Print Tool which employs the RIP vs the Epson driver.

You mentioned to have tried printing from another Mac to the 4900, getting the same anemic result. Was this machine on the same OS/driver level or did it go with the older driver? I'm not sure whether my thoughts are logical, but if the older driver/OS/ColorSync/... became "corrupted" by some OS update, the now newer printer driver could work - but with the old! (or a newly made) profile. The "new" one was somehow corrupted by this quirk, as Doug Gray showed us (if I got him right).

The other machine is on the same OS and also on the same driver 10.35. But, note that this issue was happening for quite some time with the old driver which is why we upgraded it in hopes of clearing it up.

By the way: You can see those differences visually if you soft proof the image in PS with the old and the new profile, checking "Preserve numbers". When I use the new profile - in my interpretation - it tries to compensate for that OS/driver/whatsoever quirk.

A soft proof in PS looks normal. I can not simulate the actual result through soft proofing. The copper tones and reds are good in the soft proof.

According to "Real World Color Management" (quote): "The only real source of variability we find in (RGB Printers) is that the profiling target may print slightly differently depending on its orientation. Color geeks refer to this problem as anisotropy - an obfuscatory way of saying that the printer produces slightly different color when printing the same image in portrait and landscape orientations. In our experience, the effect of anisotropy is usually quite subtle, and unless you're picky, you may not even notice the effect it has on your images" (end of quote).

Yes, I recall reading that when I studied that excellent book and I believe it to be true in terms of slight differences to targets. In fact, just printing a target twice will result in slight differences between the two. But, as you saw and stated, the differences we have here are much greater. They is quite an obvious and significant loss of red - from copper tones to browns.

That was my idea as well, but that "Printer manages color" thing made me rethink. So I would have a try with the old profile/new driver combination first.

And then: If you had a backup of the machine from the time it still worked (aka before end of January) this could also proof whether the hardware were alright and the problem on the software side.

Agreed. That leaves me wondering, searching, hoping for another possibility. But what?
Thanks for trying Michael. It's a head breaker for sure.

Mick