Prints Suddenly Anemic

[MichaelKoerner]

In Print Tool under "Print Tool Managed" I would be using the same Epson driver would I not?

Yes you would. So printing application is definitively unblamable.

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.

So, just to be sure that I understand you exactly: Have you printed with the new driver 10.35, but using the old profile "CSI 4900 1440 RGB Epson UltraPremPres Matte.icc" from 2017?

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.

Sorry, I was not clear on that. What I meant: You can see a difference between soft proofing in PS using the old profile from 01/2017 and the new profile 02/2020 when checking "Preserve numbers".

Soft proofing with the new profile ("Preserve numbers" checked) shows a huge shift towards magenta/red compared to soft proofing with the old profile ("Preserve numbers" checked). In my understanding (which may be wrong, I'm a newbie to this!) this means that the new profile tells the printer to use much more mangenta ink when printing the same LAB values as the old profile did. My guess is, that the profiling software (i1Profiler, I assume) tries to "compensate a lack of magenta coming from the printer" (all very dilettantish spoken).

Luckily, you found out that this "lack of magenta" always happens, excluding printing via "Printer manages colour" without ICC-profiles.

Now, assuming there is some strange OS/driver/... thing happening: When you printed the targets for the new profile this February, you did not use "printer manages colour", am I right? ACPU should print without any color management, but we don't know what that specific OS/driver/.../ situation on your machine did. So there is a (little) chance that this situation could also have "corrupted" the newly printed target. I am not sure whether I understood Doug Grays interpretation of comparing old and new profile correctly, but he mentioned differences:

Profiles are indeed internally quite different.

Now, my suggestion is to either produce a new profile, now with the fresh driver 10.35 installed. Or at least try to print (with the new driver) using the old profile that worked so well for the last years.

I hope, this was clearer now (English not being my first language )

Regards, Michael

[Mick Sang]

I hope, this was clearer now (English not being my first language )

English is my first language, Michael. But, trust me, one would never know sometimes, in view of my frequent failure to communicate effectively.

Now, my suggestion is to either produce a new profile, now with the fresh driver 10.35 installed. Or at least try to print (with the new driver) using the old profile that worked so well for the last years.

I want to thank you, most sincerely, for this suggestion Michael. After over 2 months of labouring over this anomaly, your suggestion helped us to get closer to the bottom of it - finally!

After reading your post, I realised that despite changing the inks and all of the analysis we've done of old & new profiles, printing umpteen tests from 3 MACs, old and new, with various configurations and drivers, updating the driver and using canned and custom profiles your suggestion awoke me to the fact that I had NOT actually printed a test using the oldest (Jan 2017) custom profile that I still had for that printer / paper combo.

Upon printing through that profile, the print was a visual match to the copper tones and reds in the image file. Just like that. I was shocked. So, in disbelief, I reprinted through the newest of the 4 profiles in question which failed as usual and then again through 2 more recent profiles which also failed. But, subsequent prints through the oldest 2017 profile continued to work. In apprehension from having had such results on two other occasions which subsequently failed, I ran it again this morning. Again the print is good.

It is now clear that there is nothing wrong with our 4900. Neither is there any indication through ColorThink Pro that there is anything wrong with the profiles - oldest or newest - in terms of gamut shape, Delta-e, volume, etc. BUT, there is indeed something wrong with the newest profile. The question is what is it? What the heck is it?

The oldest (2017) profile was generated from charts printed using the old driver (9.65) in combination with OS 10.12.6 High Sierra. New profiles which were made using that same driver in combination with OS 10.14.6 Mojave produce bad / anemic prints on the 4900 - but not on our P5000.

We have always stayed behind the upgrades and never allowed automatic updates. We try to wait for the dust to settle. Nevertheless, clearly, one can never be too careful.

Fortunately, we have a 2010 MAC with both High Sierra and the old driver. But, prints from that MAC using the new profile also failed. So, must we make all new profiles for the 4900 through that machine? Can we trust the true accuracy of any profiles made on any machine with OS Mojave in combo with the new driver going forward? Must we now check every one of our custom profiles?

Again, thank you for that valuable suggestion, Michael. But, now what? This new driver seems to work for all of our printers except for the 4900. We will now make a new profile using the new driver and see what happens. I'll report back.

Mick

[GWGill]

It is now clear that there is nothing wrong with our 4900. Neither is there any indication through ColorThink Pro that there is anything wrong with the profiles - oldest or newest - in terms of gamut shape, Delta-e, volume, etc. BUT, there is indeed something wrong with the newest profile. The question is what is it? What the heck is it?

Care to share links to your old/good & new/bad profiles ?

[MichaelKoerner]

I am very glad it worked out - since it was just a guess :-)

This new driver seems to work for all of our printers except for the 4900. We will now make a new profile using the new driver and see what happens. I'll report back.

Very curious about the result - if it was just the combination Mojave+old driver+4990 that knocked you out, it should work now with the new driver - also when making a new profile.

Keeping my fingers crossed,
Michael

[Mick Sang]

Care to share links to your old/good & new/bad profiles ?

Be happy to. New profile will be ready tomorrow. I'll upload both.

Thank you, also, for your earlier input. I am still learning from it.

Mick

[Mick Sang]

I am very glad it worked out - since it was just a guess :-)

Got any "guesses" re the upcoming lottery? 

Mick

[Mick Sang]

Care to share links to your old/good & new/bad profiles ?

The following DropBox Link is to a folder containing the oldest profile from Jan 2017 made from charts printed from ACPU on a MAC running OS 10.12.6 High Sierra and using the Epson driver 9.65 and a new profile made with charts printed from ACPU on a MAC running OS 10.14.6. Mojave with the same Epson driver.: https://www.dropbox.com/sh/7ow76rko3sglpdt/AACbn5HVYdjFZLbBCgKkERFVa?dl=0

A new profile to be made from charts printed using the new Epson driver 10.35 in combination with Mojave. I'll report back.

Mick

[MichaelKoerner]

Got any "guesses" re the upcoming lottery? 

Yes, of course!

Based on serious scientific research and extrapolated from longstanding personal experience I can not only guess, but predict with more than 99,9999% degree of probability:

You and I won't win this time.

Next question?

[Simon J.A. Simpson]

It is now clear that there is nothing wrong with our 4900. Neither is there any indication through ColorThink Pro that there is anything wrong with the profiles - oldest or newest - in terms of gamut shape, Delta-e, volume, etc. BUT, there is indeed something wrong with the newest profile. The question is what is it? What the heck is it?

If you still have the original (2017) target prints it would be interesting to take sample measurements of some relevant patches and compare them with measurements from the same patches on the new target prints.

If there is a difference this would suggest that printing from ACPU is where the problem lies and would be where to look next.

It might be worth printing another a new set of targets just in case something in the system has perversely 'settled down' and is now working correctly; just for comparison.

If all the targets measure identically then it is probably be something to do with the way with the profiles are being generated, or possibly the measuring instrument.

I do hope you get to the bottom of this Mick;  and I'm very pleased that you can now at least print properly !

[Mick Sang]

If you still have the original (2017) target prints it would be interesting to take sample measurements of some relevant patches and compare them with measurements from the same patches on the new target prints.

Yes, it would. We just searched and were unfortunately unable to locate either the specific measurements from those charts or the charts themselves. That said, is it not true that the measurements are embedded in the profile? I thought I had read that somewhere. I'll check it out. In any case, those charts would have been read by an Isis-1. We now use an Isis-2. The readings would probably have differed somewhat as a result which is true with most spectros, I think.

It might be worth printing another a new set of targets just in case something in the system has perversely 'settled down' and is now working correctly; just for comparison.

A new set of charts has been printed from which we will make a new profile. These charts reflect the involvement of both Mojave and the latest driver (10.35) the idea being that this should solve the issue. We'll see.

I do hope you get to the bottom of this Mick;  and I'm very pleased that you can now at least print properly !

Thank you, very much. We will get to the bottom of this come hell or high water. It's just a matter of time, tests and helpful advice from caring, knowledgeable people like many participants in this forum.

Mick

[Simon J.A. Simpson]

Mick, BTW I forgot to mention in case you didn’t already know, that the null transform method no longer works on a Mac (later iterations of Mac OSX and of Photoshop).  Tried and tested with the assistance of Eric Chan from Adobe.

[Doug Gray]

Mick, BTW I forgot to mention in case you didn’t already know, that the null transform method no longer works on a Mac (later iterations of Mac OSX and of Photoshop).  Tried and tested with the assistance of Eric Chan from Adobe.

I've heard that about Macs.  Glad I don't have a Mac. Because of the warning Photoshop puts up, I test it in Windows whenever Adobe does a major update. So far never a problem with results matching to instrument error. ACPU is severely limited trying to print anything dimensionally accurate as it has a tendency to shrink the printed image slightly. Also, I print black registration bars symmetric with the top ones so I can read charts in flipped upside down then compare/average measurements. It's a way of error checking the iSis. Has to be positioned just right with enough white space between the bars and top/bottom. Can't make it work with ACPU.

[digitaldog]

I've heard that about Macs.  Glad I don't have a Mac. Because of the warning Photoshop puts up, I test it in Windows whenever Adobe does a major update.

Well I can't help but comment, if you did have a Mac, you wouldn't have to do all that testing. 
As for ACPU, those scaling bugs are nearly always found on the Windows version. And if you build your targets for the iSis with sufficient fudge factor, as I have, it's never an issue unless someone printing the targets screws up and picks the wrong page setup/size which can hose any target for the iSis using any software to print.

[Mick Sang]

And if you build your targets for the iSis with sufficient fudge factor, as I have, it's never an issue....

Do you mind sharing the "fudge factor" or is that secret sauce?

Or perhaps I should ask instead why do you feel that a "fudge factor" is necessary for the Isis?

Mick

[digitaldog]

Do you mind sharing the "fudge factor" or is that secret sauce?

Mick

Do not use anything too close to the minimums in i1P for targets patch size and minimum margins.

[Mick Sang]

Do not use anything too close to the minimums in i1P for targets patch size and minimum margins.

Thank you. I understood that the patch size should be at least 2mm larger than the aperture of the spectro. So, I've been using 6mm patches. Too small in your opinion?

Mick

[digitaldog]

Thank you. I understood that the patch size should be at least 2mm larger than the aperture of the spectro. So, I've been using 6mm patches. Too small in your opinion?

Mick

My targets are here, they work:
http://www.digitaldog.net/icc-profiles.html

[Mick Sang]

My targets are here, they work:
http://www.digitaldog.net/icc-profiles.html

Thank you very much, sir. I will study this.

Mick

[GWGill]

The following DropBox Link is to a folder containing the oldest profile from Jan 2017 made from charts printed from ACPU on a MAC running OS 10.12.6 High Sierra and using the Epson driver 9.65 and a new profile made with charts printed from ACPU on a MAC running OS 10.14.6. Mojave with the same Epson driver.: https://www.dropbox.com/sh/7ow76rko3sglpdt/AACbn5HVYdjFZLbBCgKkERFVa?dl=0

While the two profiles have a similar gamut, the characterization of the red response is rather different.

Plucking a value from the cheek of the image you showed earlier of RGB 210 134 111, and assuming the image is encoded in sRGB space, I get an L*a*b* value of roughly 65 31 27. Running that through the earlier profile I get an RGB of about 212 88 88. With the new profile I get 102 102 88 - substantially different. The A2B and B2A tables are consistent in this, so there's nothing wrong with the table construction, implying it is in the original patch data.

Unfortunately I can't find any usable patch data in the ICC profiles (The CxF tag appears to be in some binary format rather than canonical XML).

[Doug Gray]

While the two profiles have a similar gamut, the characterization of the red response is rather different.

Plucking a value from the cheek of the image you showed earlier of RGB 210 134 111, and assuming the image is encoded in sRGB space, I get an L*a*b* value of roughly 65 31 27. Running that through the earlier profile I get an RGB of about 212 88 88. With the new profile I get 102 102 88 - substantially different. The A2B and B2A tables are consistent in this, so there's nothing wrong with the table construction, implying it is in the original patch data.

Unfortunately I can't find any usable patch data in the ICC profiles (The CxF tag appears to be in some binary format rather than canonical XML).

Graeme, I extracted the CGATs (See attached) and also noticed the white points were quite different.

I get some rather curious results looking at the CGATS data embedded in the profiles. They are from different spectros:

CGATS: CSI 4900 2880 RGB Espon UPP Matte_M2.txt

ORIGINATOR   "i1Profiler - X-Rite, Inc."
INSTRUMENTATION   "i1iSis 2 ; Serial number 11929"
DESCRIPTOR   "CSI 4900 2880 RGB Espon UPP Matte_M2"
MEASUREMENT_SOURCE   "MeasurementCondition=M2   Filter=UVcut"

CGATS: CSI 4900 1440 RGB Epson UltraPremPres Matte_M2.txt

ORIGINATOR   "i1Profiler - X-Rite, Inc."
INSTRUMENTATION   "i1iSis ; Serial number 5652"
DESCRIPTOR   "CSI 4900 1440 RGB Epson UltraPremPres Matte"
MEASUREMENT_SOURCE   "MeasurementCondition=M2   Filter=UVcut"

Secondly, the white points are quite different. Since whites are unprinted paper they should be reasonably close to each other. At least < 2 dE. These are over 3 dE1976 different.

Perhaps the ISIS 2 and ISIS differ that much but it seems a bit larger than usual. Perhaps the calibration tiles are dirty or aged. a b* of 4.4 seems pretty yellowish

First WP, Lab 94.98 -0.60 4.41
Second WP, Lab 96.03 -0.83 1.48


sRGB(210, 134, 111) -> Lab (63.7, 28.1, 25.2)

Running that lab through AtoB1 in Abs yields:
CSI 4900 1440 RGB Epson UltraPremPres Matte.icc -> Lab (63.6, 28.0, 25.1)
CSI 4900 2880 RGB Espon UPP Matte_M2.icc -> Lab (65.9, 45.8, 27.1)

Which are hugely off. I note that the print resolution differs, 1440 v 2880, perhaps that is the cause but generally driver settings for dpi don't have that much shift in my experience. Maybe 2 or 3 dE is typical. This is close to 20.

Attached are the extracted CGATS for M2 measurements.