Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Mick Sang on February 27, 2020, 10:03:00 pm
-
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
-
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!
-
- 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.
-
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.
-
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.
-
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 (http://www.argyllcms.com/doc/xicclu.html) 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.
-
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
-
ColorThink Pro can absolutely provide such analysis. Do you have the Pro version?
-
Mick, the orange cartridge in the 4900, is that one not way over date? Just asking.
-
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, 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.
-
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,
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
-
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?
-
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.
-
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.
-
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
-
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
-
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?
-
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.
-
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.
-
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.
-
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.
-
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:
-
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).
-
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.
-
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
-
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. :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Great! Looking forward to checking the info out. Off to dinner. Check back in 2 hours.
:)
-
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
-
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.
-
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.
-
"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).
-
The ICC profile looks fine. Gamut shape is excellent. I see you are using 4066 patches.
I'm surprised that you found that as well. It looked ok to me in ColorThink.
But the CC image!
Yikes. 13 of the CC colors are between deltaE 13 and 35.
Quite right. The more I look at it the worse it looks. I will get and attach screen captures of the settings as you request. I could understand making a mistake once or even thrice. But, every single time we print an image that started this whole thing, including again this afternoon, it is consistently anemic - very much so. We printed the same image on a P5000 which sits near the 4900 and got excellent results on the same stock. So, I don't know. But another set of eyes and experts eyes to boot is greatly appreciated. I will get those posted as soon as I can.
Thank you again, sir, for your time and help with this.
Mick
-
Mick,
Something else I want to check is the amount of difference between the profile you posted and an earlier one from the same printer/paper when it was working. I can see what might have drifted/changed by comparing the two and if they were made from the same patch set I can compare those colors directly.
So please post a zip file with the old working profile.
-
Something else I want to check is the amount of difference between the profile you posted and an earlier one from the same printer/paper when it was working. I can see what might have drifted/changed by comparing the two and if they were made from the same patch set I can compare those colors directly.
So please post a zip file with the old working profile.
Fortunately, we tend to keep the older profiles. I'm not sure why. I suppose it's because whenever I toss things that I've kept because "I might need it someday" I usually need it a day or so after it's gone.
Re the print settings, I'll follow up with those when I get back to that printer.
Zip file attached.
Mick
-
I just took at look at both the old and the new profile myself in CTP. While the new profile looks ok in CTP with "Volume" selected, when it is viewed with points joined by lines, it looks very strange especially as compared to the old profile the gamut surface of which looks ok for both views. Something is very wrong with that new profile that I had not seen before as I looked only at the "Volume" view in CTP. Not sure how I can fix it aside from making a new profile. Not sure why it happened. The Isis-2 is new. I wonder what you have found Mr. Gray.
I tried to upload CTP videos of both. But, they're too large. So, I've attache 2 pix of each profile.
Mick
-
Please find attached screen captures of the print settings that we used to print the pic that made us aware of the anemic print issue.
While looking at the new and old profiles in CTP earlier today, I recalled that the reason for our making a new profile in February in the first place was because we got a very anemic result upon printing a sample / proof of a scanned and corrected painting for our client. So, we simply assumed that we needed a new profile. After looking at both profiles earlier today, though, while there does appear to be something wrong with that new profile, the anemic results first appeared through the older profile. Both have been uploaded.
Mick
-
Profiles are indeed internally quite different.
First the things that are within normal variation:
There are some differences in white point and small differences in gamut boundaries but these are normal. As are small differences from different spectrophotometers (iSis 2, I1Pro2). Both profiles are made with M2.
There is also a difference in white points of about dE:3. This is not unusual.
Then the things that aren't:
The mapping of internal gamut colors varies a large amount between the old and new profiles:
Here's a DeltaE histogram of Lab values from the A2D1 tables using 100,000 random RGB values. Mean dE is 13.4 which is extremely large. Typical mean variations from differing instruments are on the order of 1 dE.
-
Please find attached screen captures of the print settings that we used to print the pic that made us aware of the anemic print issue.
While looking at the new and old profiles in CTP earlier today, I recalled that the reason for our making a new profile in February in the first place was because we got a very anemic result upon printing a sample / proof of a scanned and corrected painting for our client. So, we simply assumed that we needed a new profile. After looking at both profiles earlier today, though, while there does appear to be something wrong with that new profile, the anemic results first appeared through the older profile. Both have been uploaded.
Mick
I can verify that anemic is a good description. Most all the CC colors are printed and much less saturated. But hue and luminance is shifted as well.
I don't see anything wrong in your screenshots. However, I only use Windows and 16 bit print mode is not available for Epsons on Windows. I don't believe ACPU operates in 16 bits. I1Profiler only generates 8 bit targets and should be printed in 8 bit mode.
Generally, 16 bit print mode has some issues. I've seen compatibility issue reports from iOS and I know first hand that Canon's purported 16 bit capable Win. 10 add-in did not, in fact, work but produced 8 bit banding. As a practical matter detecting the difference between 8 bit and higher rez requires instrumentation as the differences are very small and not measurable with 8 bit dithering enabled in Photoshop.
1. So rule of thumb is to use exactly the same device driver settings in I1Profiler as when using the profile with Photoshop manages color and using the profile created by i1Profiler.
2. Avoid 16 bit until 8 bit process has been verified since i1Profiler makes 8 bits print targets. If you actually visually see any difference in 16 bits v 8 bits in any normal photo, run, don't walk back to 8 bits because there is something messed up in 16 bit rendering.
-
None of the issues has anything to do with bit depth nor is there any need to profile with a higher than 8 bits per color.
-
The mapping of internal gamut colors varies a large amount between the old and new profiles:
Here's a DeltaE histogram of Lab values from the A2D1 tables using 100,000 random RGB values. Mean dE is 13.4 which is extremely large. Typical mean variations from differing instruments are on the order of 1 dE.
Thank you for taking the time & trouble to doing this for me. I appreciate it very much. Now we have two issues to try to figure out and fix. We have to try to determine how this happened to the newer profile and we still have no answer as to why our prints are anemic on that printer, since both profiles resulted in anemic prints.
Generally, 16 bit print mode has some issues. I've seen compatibility issue reports from iOS and I know first hand that Canon's purported 16 bit capable Win. 10 add-in did not, in fact, work but produced 8 bit banding. As a practical matter detecting the difference between 8 bit and higher rez requires instrumentation as the differences are very small and not measurable with 8 bit dithering enabled in Photoshop.
None of the issues has anything to do with bit depth nor is there any need to profile with a higher than 8 bits per color.
Thank you both for this. I did not know this. Generally, we print in 16 bit. Also when we profile using our Barbieri LFP, Gateway gives a 16 bit option for its charts. So as a matter of habit we print the charts in 16 bit. But, if there's no point to it and if instead it may even be problematic, we will move to 8 bit for the charts.
So rule of thumb is to use exactly the same device driver settings in I1Profiler as when using the profile with Photoshop manages color and using the profile created by i1Profiler.
This is the other reason why we print profile charts in 16 bit i.e. because we print mostly in 16 bit and we do use exactly the same settings for the prints as for the profile charts.
2. Avoid 16 bit until 8 bit process has been verified since i1Profiler makes 8 bits print targets. If you actually visually see any difference in 16 bits v 8 bits in any normal photo, run, don't walk back to 8 bits because there is something messed up in 16 bit rendering.
I have encountered articles on this before. It's time we tested it ourselves to find out which is best for us. With the additional time afforded us by the virus outbreak now is as good a time as any. Thanks again for bringing this to my attention.
Tomorrow, we'll reprofile that paper to see if we can resolve that issue. The, we'll continue to pursue an answer to the cause of our anemic print issue. It's a tough one for sure. I thank everyone who posted for your help, information and patience with my attempts to understand certain terms and concepts. I still have much to learn.
Mick
-
Andrew is absolutely right that there is no point in making profiles with more than 8 bits. And there should be no issue using 16 bits too.
Except for bugs. 16 bits isn't often used and it's a different datapath in OS drivers. It's also not handled properly by XRite's I1Profiler.
Read the thread below on I1Profiler's strange behavior with fractional (ie: 16 bit) RGB values. This was a few years ago and I don't know if they've fixed it. But as a result I've made a point of making sure all my profiler targets were 8 bit compatible and had no fractional components. Good example of why it's a good idea to stick to default print targets and 8 bits for all paths. Get things working in the simplest configuration then increase patch counts if needed to improve accuracy. I recommend the iSis single US letter target with 957 patches until you find where the problem is.
Side hint: Use M2 only for the iSiS 2. This reduces the scan time by 2x and slightly improves repeatability. The backhitch used for the extra uV pass can increase positioning error though it's normally a very small effect ( < .1dE ave).
Thread on 16 bit I1Profiler issues.
https://forum.luminous-landscape.com/index.php?topic=128070.0
-
Side hint: Use M2 only for the iSiS 2. This reduces the scan time by 2x and slightly improves repeatability. The backhitch used for the extra uV pass can increase positioning error though it's normally a very small effect ( < .1dE ave).
Thanks very much again for the good advice. We've been profiling to M1 lately for some papers and M2 for OBA laden papers - rarely M0. With the Barbieri we profile to M3. That produces better shadow separation for some fine art papers. But, we discovered that it sometimes reduces shadow separation. That's for another post. Nevertheless, we'll print charts with 8bit from now on to play it safe for at least the charts and the profiles.
Re the link that you kindly provided, I read those posts some time ago. I've learned a more since then. So, I'll reread them to get up to date.
Also, F.Y.I. I should add, regarding the old profile that I uploaded earlier, you had requested that I upload an old profile which had worked for us well before. That old profile had indeed worked well enough in the past until one day the prints rendered with very anemic reds. We apresumed the printer had drifted or the paper had changed slightly as Epson doesn't make these papers. That's when we reprofiled and this whole thing started.
We'll get to the bottom of this thing yet. Thanks to all.
Mick
-
A profile is meant to be a model of the device (i.e. printer) behavior. ….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.
If anyone is still interested in this, here’s an update: We still have not found any reason for or solution to the anemic reds that we’ve been getting in prints from our 4900 and the more we look into this, the stranger the issue becomes. We’ve encountered some interesting test results as we've explored this.
To review, the printer is an Epson Stylus Pro 4900. All nozzles are completely clear. The Vivid Magenta and Vivid Light Magenta inks are new. They were replaced when the issue first became apparent. The paper is Ultra Premium Presentation Matte from Epson. But, as it turns out, other papers are also affected. The custom profile we used had been created two years ago. But, it had worked well until early February when things suddenly changed i.e. reds were suddenly very weak - anemic. The image currently in question is a scan of a painting of a woman’s face in cameo which is primarily comprised of skin tones and warm copper tones. The image was painted on an 8" x 10" copper plate.
We made and printed through 2 new profiles which did not solve or even change the issue. ColorThink Pro revealed that the second profile also turned out to have some malformations as it had been hastily made. So, this week, to really drill down on this thing we made a new profile from 2 sets of large targets each of which was scanned twice through our Isis-2. This yielded four large sets of data which was averaged and two profiles were generated one for M2 and the other for M1 conditions. The structure of the new profiles is much smoother and more uniform than the previous profiles, as seen in CTP.
Then, for our first test, we imported the image into ColorThink Pro, selected 100 colours from the image and transformed them through the UPPM M2 profile. CTP reported average Delta-e2000 of 0.93 to 1.73
For comparison and context, the same colours were transformed through a 1 year old Hot Press Bright M2 profile from the same printer. CTP reported Delta-e2000 average of 1.03 to a high blip of 2.15. A soft proof through this profile looked very good. But a print through that profile on the Hot Press bright yielded a print which was as anemic as the other prints on UPPM.
The soft proof of the file in PhotoShop through the UPPM profile looks good as well i.e. no indication of anemic reds. That said, it had also looked good though the old profile, despite some anomalies in the profile and the anemic result in print. Again, out of interest, we soft proofed through our Hot Press Bright profile as well as the UPPM profile. A comparison of the 2 soft proofed images revealed no appreciable visual difference or change as far as the copper tones and reds are concerned and both soft proofs looked very good.
Nevertheless, the actual print from the 4900 on UPPM is as anemic as before - consistently so. The overall appearance has moved from the warm copper tones in the image to cool sandy browns in print. In fact, there is no immediately apparent difference between the printed result from new profile and previous prints through the old profiles.
Then, we printed the same image on a P5000 which sits a few feet away from the 4900. But we used the same profile from the 4900 for the UPPM stock. To our amazement, the print was very close to the original image - the copper tone reds were all ok.
Following that we ran another print back on the 4900 through Photoshop using “Printer Manages Colour" and "Adobe RGB.” The print was good! No trouble at all with the reds.
BUT then we ran another print on the 4900 this time through Epson’s canned profile for that paper and the result was as anemic as the prints through our own profiles. They were all very close.
So, in conclusion, the new profile appears to be ok when printed by the P5000 on UPPM. And the Isis2 appears to be working well especially in view of the fact that we have recently made many new profiles for our new P9570 which are performing beautifully. Finally, it appears that the 4900 is still capable of printing the reds properly but not through ICC profiles - custom or canned.
So, my question is what the hell is going on here? Has anyone experienced this sort of thing before?
Thanks for your time,
Mick
-
Something is wonky. I suspect driver/iOS bugs.
Here's an interesting idea. Duplicate whatever the driver is doing so it's the same for printing patches you make profiles from and a regular image you are trying to print. Here's how:
1. Take the image you wish to print and convert to your printer profile in Photoshop. Select whatever settings you normally use like Rel. Col. or Perc and possibly BPC.
2. Save it as an 8 bit tif but deselect the attach profile option. You want an untagged image file. Probably not necessary but I like to keep as many things unchanged when troubleshooting.
3. Print the file with ACPU using exactly the same driver settings used for printing profile patches.
-
Something is wonky. I suspect driver/iOS bugs.
Here's an interesting idea. Duplicate whatever the driver is doing so it's the same for printing patches you make profiles from and a regular image you are trying to print. Here's how:
1. Take the image you wish to print and convert to your printer profile in Photoshop. Select whatever settings you normally use like Rel. Col. or Perc and possibly BPC.
2. Save it as an 8 bit tif but deselect the attach profile option. You want an untagged image file. Probably not necessary but I like to keep as many things unchanged when troubleshooting.
3. Print the file with ACPU using exactly the same driver settings used for printing profile patches.
Mr. Gray, I thank you for your time and especially your expertise, sir. I would NEVER have though to try this. But, it worked. So, I will now see about changing the driver unless you have another suggestion. The driver in use is 9.66 for that machine. I know there is a new one, 10.35 I believe. But, we generally don't upgrade until the need arises. I suppose it has. I will change it and get back. That you again for helping us with this.
Mick
-
Mr. Gray, I thank you for your time and especially your expertise, sir. I would NEVER have though to try this. But, it worked. So, I will now see about changing the driver unless you have another suggestion. The driver in use is 9.66 for that machine. I know there is a new one, 10.35 I believe. But, we generally don't upgrade until the need arises. I suppose it has. I will change it and get back. That you again for helping us with this.
Mick
I've never encountered a driver/OS change on Windows but others here have posted things suggesting that iOS changes at times have affected printing. Apple has more coupling between their OS and drivers that is meant to reduce operators misconfiguring things. That tighter coupling may create compatibility issues when either the OEM or Apple upgrades their products.
So there is a very good chance upgrading the driver will fix things. There is an outside chance it won't but I consider it remote since you see the same problems with the OEM profiles.
So let us know if this fixes things. It likely will. Fortunately, you have instrumentation/tools that provided enough quality info to find this.
-
Mick, you're on Mac OS right? And is there a checkbox in your driver of 16-bit and have you been having it set for on? Because there was a bug in older drivers having that option with the check box on.
-
Mick, you're on Mac OS right? And is there a checkbox in your driver of 16-bit and have you been having it set for on? Because there was a bug in older drivers having that option with the check box on.
Yes, thank you Mr. Rodney, we are using a 2016 MacBook Pro for that printer and the P5000 which is a few feet away from it. Generally, we print with 16 bit - not always, but more often than not. We have been doing that only for the past couple of years. Prior to that it was usually 8 bit. The thing is that that printer is 9 years old now and was working very well throughout until this thing started in late January - early February. The only other thing that also changed around then was an OS update to Mojave. But, while we did update the drivers on other MACs for other printers, we did not update for the 4900. I'll do that shortly and we'll see what happens.
The other strange thing that happened earlier in all our testing is that we tried printing to a different paper on that 4900 but using the profile specific to UPPM. To our surprise, the result was good. However, I can't repeat that. So either the problem is intermittent or I screwed something up. But, I really don't believe that I did.
Mick
-
And is there a checkbox in your driver of 16-bit and have you been having it set for on? Because there was a bug in older drivers having that option with the check box on.
So, I replaced the old driver (9.66) with the new (10.35) and ran a print with 16 bit unchecked. I'm surprised and sorry to say that there is no difference. Another print with 16 bit is the same. The problem persists. All the warm copper tones and reds are muted down to sandy-brown.
I really thought we were onto a cure here. But, now I'm at a total loss and can only hope that someone has another avenue to explore.
At least now we now know that the profile is ok, the printer is capable of printing the reds properly and the driver is new. The only thing that has not been changed AFAIK is the firmware which is MO28B7, 1.00, A000.
Thank you for your time,
Mick
-
So, I replaced the old driver (9.66) with the new (10.35) and ran a print with 16 bit unchecked. I'm surprised and sorry to say that there is no difference. Another print with 16 bit is the same. The problem persists. All the warm copper tones and reds are muted down to sandy-brown.
I really thought we were onto a cure here. But, now I'm at a total loss and can only hope that someone has another avenue to explore.
At least now we now know that the profile is ok, the printer is capable of printing the reds properly and the driver is new. The only thing that has not been changed AFAIK is the firmware which is MO28B7, 1.00, A000.
Thank you for your time,
Mick
Well, you can grab a used Windows laptop for cheap until they fix the compatibility problem but since it's an old printer it might be never.
-
At least now we now know that the profile is ok, the printer is capable of printing the reds properly and the driver is new. The only thing that has not been changed AFAIK is the firmware which is MO28B7, 1.00, A000.
I'm told that the firmware is also current. So now what?
-
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.
-
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
-
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.
-
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, 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
-
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, 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
-
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.
-
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.
-
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!
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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 ?
-
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
-
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
-
I am very glad it worked out - since it was just a guess :-)
Got any "guesses" re the upcoming lottery? ;)
Mick
-
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
-
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? ;)
-
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 !
-
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
-
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.
-
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.
-
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.
-
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
-
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.
-
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
-
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
-
My targets are here, they work:
http://www.digitaldog.net/icc-profiles.html
Thank you very much, sir. I will study this.
Mick
-
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).
-
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.
-
Graeme, I extracted the CGATs (See attached) and also noticed the white points were quite different.
Thanks.
Ignoring the white point for the moment, running profcheck against the data files and the profiles I get good agreement between the old data and old profile, and poor agreement between the new data and new profile (i.e. data vs. absolute A2B). The most usual reason for this with handheld instruments is user error - i.e. reading the wrong strip. I'm not sure what the explanation would be when using an isis. Is it possible to get randomized chart layouts mixed up when using an isis ? Is it possible for the isis to mis-read patches ?
Running profcheck -w and looking at the visualization shows systematic differences between patch data and the profile though. Most of the discrepancies seem to be at the surface of the gamut, and hint at clipping behavior - i.e. that the RGB has been clipped, and so a lot of a values near the gamut surface are being mapped to the gamut surface values. Naturally this would distort the smoothed characterization.
(Interestingly an Argyll made profile has smaller but non-normal level errors when made from the new data set.)
There are huge discrepancies when the new profile is checked against the old data set - i.e.
max. = 46.732429, avg. = 11.529630, RMS = 14.164539. (There is similarly a huge difference with an Argyll made profile.)
So to me it looks like something is seriously wrong with the new measurement data, if the old data is taken to be nearer the truth.
It's interesting that the new data file doesn't match the old one in the number of patches, and in fact appears to be a different chart.
-
Thanks.
Ignoring the white point for the moment, running profcheck against the data files and the profiles I get good agreement between the old data and old profile, and poor agreement between the new data and new profile (i.e. data vs. absolute A2B). The most usual reason for this with handheld instruments is user error - i.e. reading the wrong strip. I'm not sure what the explanation would be when using an isis. Is it possible to get randomized chart layouts mixed up when using an isis ? Is it possible for the isis to mis-read patches ?
It's absolutely possible!
I've found several sources of error:
1. Registration errors that occur due to back hitching to measure with the uV LED in addition to the white LED that's used for M2 measurements. The uV pass then provides data used to calculate M1/0 spectra. I saw a 10 dE error between reading M2 only and M0/1/2 which requires a back hitch on a large A3+ target. This turned out to be because the paper feed was hanging slightly off my table near one end. When that happened friction increases and is asymmetrical when the stepper motor advances forward v reverse. This went away when I rearranged things so that the paper was always flat on the table never bending over the table edge.
2. Errors due to small amounts of dust inside the iSis sensor assy. This seems to occur with matte paper more than glossy. The worst thing about this is that it can occur suddenly and abruptly and there is usually no obvious warning signs. Symptoms were readings that were way off and, oddly, sensitive to the scan direction. Typically every other row is scanned in opposing directions. These sometimes caused dE errors in the 10-20 range over multiple patches. Worse. They repeated when reading the same chart again so sometimes don't show up using a duplicate scan verification check. I also discovered an easy way to check this. Adding a registration bar on the bottom in addition to the one on the top allows a chart to be read normally and upside down. Then I just test the two scan CGATs for consistency. This is all automated now for my work. Every now and then it will detect the problem which goes away once I peel the cover back and blow forced air under the sensor assy.
I've also explored registration errors of letter size targets using an iSis all black target. By adding thin, white strips around each of the black squares even small amounts of contamination from light reflecting off the white strips becomes easily measureable. This has made me quite comfortable using 6x6mm patches on a 957 patch 8.5x1l US letter page.
https://forum.luminous-landscape.com/index.php?topic=119448.msg1003106#msg1003106
https://forum.luminous-landscape.com/index.php?topic=121256.msg1008190#msg1008190
Running profcheck -w and looking at the visualization shows systematic differences between patch data and the profile though. Most of the discrepancies seem to be at the surface of the gamut, and hint at clipping behavior - i.e. that the RGB has been clipped, and so a lot of a values near the gamut surface are being mapped to the gamut surface values. Naturally this would distort the smoothed characterization.
(Interestingly an Argyll made profile has smaller but non-normal level errors when made from the old data set.)
There are huge discrepancies when the new profile is checked against the old data set - i.e.
max. = 46.732429, avg. = 11.529630, RMS = 14.164539. (There is similarly a huge difference with an Argyll made profile.)
So to me it looks like something is seriously wrong with the new measurement data, if the old data is taken to be nearer the truth.
It's interesting that the new data file doesn't match the old one in the number of patches, and in fact appears to be a different chart.
Great observation Graeme! Since the chart layouts are also in the created profile I'm going to create the associated tiff files and do some experiments. Stay tuned
-
I reconstructed the charts since the profiles contain the chart parameters. They are not randomized but follow from entering the patch count w/o randomizing. Charts are all 8.5" wide and of differing paper lengths.
Looking at the data from the two profiles the differences cannot be explained by any of the issues that I posted in my previous post. The differences are extreme and not associated with any given page, nor top/bottom, left/right registration issues.
I also agree with what Graeme noted that it appears colors in one are clipped well before the gamut boundary. This suggests a possible avenue to explore which I am now doing.
Suggestion for Mick. Until this is ironed out, Simplify, simplify.
1. Create profiles using the same iSiS, the same printer driver setting (ie:dpi differs), and the same paper. Use 8 bit everywhere and follow the same process to print charts and make profiles.
2. Don't bother letting them dry more than an hour as it makes almost no difference after 30 minutes with pigment printers.
3. Use the single patch set, the 957 patch count, Default iSis that fits on a single 8.5x11 sheet. Higher counts can improve profile dEs but much less than 1 dE average. It's a waste of time, paper, and ink until this is resolved.
-
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).
At first it seemed like this post from Michael had hit the nail on the head. Yesterday we made a new profile using 8 bit charts printed via the new driver (10.35) on a MAC running OS 10.14.6 Mojave. We let the charts dry for 24 hours. I know you don’t need to let matte papers dry for that long. But we wanted to eliminate as many variables as possible. A print through the new profile was good. All reds were spot on. But, how could it be that the driver alone could make this difference? It didn’t.
There are huge discrepancies when the new profile is checked against the old data set - i.e.
max. = 46.732429, avg. = 11.529630, RMS = 14.164539. (There is similarly a huge difference with an Argyll made profile.)
So to me it looks like something is seriously wrong with the new measurement data, if the old data is taken to be nearer the truth.
It's interesting that the new data file doesn't match the old one in the number of patches, and in fact appears to be a different chart.
This analysis and new information makes much more sense to me. While I don't yet know how to do such in-depth analysis, I had also seen malformations in the form of the newer profiles as graphed in ColorThink Pro using points joined with lines which visually exaggerates such deformities. But, I wasn’t sure where those anomalies had come from. On the other hand, the form of the newest profile which was made late yesterday looks very smooth and uniform. I did no further tests at that point as it was more important to get a print through the new profile.
Based upon this new information from Mr. Gill and Mr. Gray, I wondered what could be so different between the creation of the old Jan 2017 profile and the recent February 2020 profile both of which were analyzed by Mr. Gray and Mr. Gill versus the new profile made yesterday evening which yielded a good print. Aside from the fact that the charts for the 2017 profile were read by an Isis-1 and the charts for the Feb 2020 and the newest profile were read by an Isis-2, the most obvious difference is that the charts for the old 2017 profile and the newest one from last night were not scrambled. The charts for the Feb 2020 profile were scrambled. Either the scrambled charts were made incorrectly by i1Profiler or they must have shifted between the saved workflow and the saved Tiffs. If the latter is the case, this was not at all obvious.
Another difference between the old 2017 profile and all the newer profiles in question including the one made last night is that the 2017 profile was generated using i1Profiler v. 1.6.6.19866 and the new profiles were all made using version 3.2.1.
So, if this is all correct now, then you gentlemen have helped me to solve this issue for which we are extremely grateful. Now we will have a great deal of additional work on our hands to remake many profiles which were made recently using those same scrambled charts for our new 9570. That said, I still wonder why the prints were ok (not perfect - but not anemic) using the same defective profiles with different, newer printers. And of course I'd like to understand why scrambled charts from our i1Profiler caused this failure and how to overcome it.
Mr. Gray, Mr. Gill, Mr. Simpson, Mr. Rodney, Michael (fineartelier) and anyone else who tried to help us with this, I thank you very, very much for your time, your suggestions, your experience and your expertise. This foray has yielded several excellent lessons. I do not believe that we would have been able to figure this thing out anytime soon without your help. I know that I wouldn’t have been. We have learned a lot in the process as well. My goal now is to eventually learn how to make such analyses as those done by Mr. Gill and Mr. Gray.
Mick
-
Mick,
Since you are using the I1Profiler Patch generator you should be aware of a problem. It generates 16 bit (RGB fractional values from 0:255). You can see this when you click on a patch after generating a set. These have been shown to produce strange results sometimes with I1Profiler. Usually very subtle but sometimes really large, unexplained results. In particular they don't correspond to the tif files printed nor do they correspond to the values saved in the profile. These are 8 bit. One of them rounds, the other truncates. Also, small fractiona value changes can produce big differences in the profile. It's almost as if I1Profiler uses different math processes for fractional RGB values. Ethan and I discussed this some years ago.
Easy way to avoid this is, when you generate a patch set the very first thing to do is save it. Saving it eliminates the fractional RGB parts. Then reload the saved patch chart immediately and continue. In the future always load that patch chart when you prepare to make or print targets.
See this for a more complete discussion:
https://forum.luminous-landscape.com/index.php?topic=128070.msg1083715#msg1083715
-
Since you are using the I1Profiler Patch generator you should be aware of a problem. It generates 16 bit (RGB fractional values from 0:255). You can see this when you click on a patch after generating a set. These have been shown to produce strange results sometimes with I1Profiler. Usually very subtle but sometimes really large, unexplained results. In particular they don't correspond to the tif files printed nor do they correspond to the values saved in the profile. These are 8 bit. One of them rounds, the other truncates. Also, small fractiona value changes can produce big differences in the profile. It's almost as if I1Profiler uses different math processes for fractional RGB values. Ethan and I discussed this some years ago.
Easy way to avoid this is, when you generate a patch set the very first thing to do is save it. Saving it eliminates the fractional RGB parts. Then, always load that patch chart when you prepare to make or print targets.
See this for a more complete discussion:
https://forum.luminous-landscape.com/index.php?topic=128070.msg1083715#msg1083715
SON OF A........ !! "Sometimes really large," no kidding. Well, what next? So, all this time we've been carrying on like morons completely unaware of this. I don't know if the math you're referring to caused our problem or it has come to light as a result of the fact that we scrambled the charts. Prior to our decision to start doing that everything seemed to be working well. I'm reminded: "Don't fix it if it ain't broke." All we want to do is to make good, accurate, reliable ICC profiles for all of our printers.
So, before having the knowledge which you have thankfully provided here, we nevertheless did save the charts immediately after saving the workflow which was done immediately after creating them. So, hopefully that has provided accurate charts and reference files. That seems to be the case at least for our unscrambled chart workflows. If not, what else can we do?
Thank you, again, for your valuable help and advice Mr. Gray. I'll check out the link you've kindly provided.
Mick.
-
Mick,
Both profiles you provided above were made with unscrambled patches. I don't think scrambling or not makes any difference in the problem but it might. I haven't investigate it. Most of my work is with scrambled patches. I sometimes duplicate all the patches and then scramble them. This provides some statistical data on how optimal things like vacuum level and head spacing is.
-
Both profiles you provided above were made with unscrambled patches. I don't think scrambling or not makes any difference in the problem but it might. I haven't investigate it. Most of my work is with scrambled patches. I sometimes duplicate all the patches and then scramble them. This provides some statistical data on how optimal things like vacuum level and head spacing is.
Well, if that's the case then I apologise and once again I'm dazed and confused. There were actually 2 or 3 different profiles made for that printer and paper combo in the period of January - April 2020. We would see the problem then put it aside and use another printer. But we have been scrambling patches lately. So, I thought that that April profile had been made from scrambled charts. Since it wasn't, what could have caused this? None of those profiles through that period work. Only the old one from Jan. 2017 and the newest one from last night work.
There was also definitely something going on with that older driver (9.65) in combination with OS10.14.6 (Mohave). One of the tests which we made while trying to resolve the issue involved our printing the image in question using various other profiles fo other papers which had worked well in the past on that machine. But, we got the same anemic result. The driver at the time was 9.65. Now, however, the result is no longer anemic using those profiles either. The only thing that is changed is that driver.
In case you are interested, here is a link to the newest profile which was made with unscrambled patches.: https://www.dropbox.com/sh/156dgw79mwtaowe/AACOnY0u4l-TuPyVc-o-cBBpa?dl=0
It was also made with large patch charts. We are listening to you and will try to follow your guidelines as well as others that have come along during this. But, I didn't want to introduce anything new until this is settled.
Thank you, sir.
Mick
-
Using a set of 10,000 random RGB values, these two profiles had an average dE 1976 of 2.3
'CSI 4900 1440 RGB Epson UltraPremPres Matte.icc'
'CSI 4900 2880 RGB Epson UltraPremPresMATTE_M2.icc'
This is about right and fairly typical of the differences one gets from a DPI change like 1440<->2880. Both of these profiles behave reasonably.
---
This is the profile that Graeme commented on with clipped colors near the gamut boundary:
CSI 4900 2880 RGB Espon UPP Matte_M2.icc
All 3 RGB channels in the extracted data exhibit the clipping effect. I've never seen anything like it.
-
Thank you again, sir.
This is the profile that Graeme commented on with clipped colors near the gamut boundary:
CSI 4900 2880 RGB Espon UPP Matte_M2.icc
All 3 RGB channels in the extracted data exhibit the clipping effect. I've never seen anything like it.
Nor have I. It is also the profile which I described in my previous post as having deformities as viewed in the grapher of ColorThink Pro. But, I'm only referring to the effect in print.
Using a set of 10,000 random RGB values, these two profiles had an average dE 1976 of 2.3
Can you or would you direct me as to where I can find instruction on how to do the test which you describe here?
Mick
-
Using a set of 10,000 random RGB values, these two profiles had an average dE 1976 of 2.3
Do you have a preference of dE 1976 over dE 2000? If so, may I ask why?
Mick
-
Can you or would you direct me as to where I can find instruction on how to do the test which you describe here?
Mick
I wish I could but it's just a quick set of code I wrote to compare your profiles for consistency. It's only took a few minutes but uses a lot of functions in Matlab I've written for other purposes over the years for my main focus. That was precision target creation and analysis for a camera surveillance company I was an investor/director in.
I have no idea where one would find similar stuff. Graeme's Argyll s/w is superb and would probably be what I'd be adapting if I were not using Matlab. There may be folks out there that have done similar things using his great stuff. Another possibility is Marti's Little CMS. It's pretty easy to code with C/C++.
A side effect was becoming obsessed with getting the most out of the inkjet tech.
I generally prefer dE2000 when two very close colors are being compared but for larger distances I use dE1976. The latter is much simpler math wise but the former is better when looking at close colors in a neutral surround. But dE2000 is not as good when looking at color differences where the surround is more saturated.
Vision is just very non-linear.
-
I wish I could but it's just a quick set of code I wrote to compare your profiles for consistency. It's only took a few minutes but uses a lot of functions in Matlab I've written for other purposes over the years for my main focus. That was precision target creation and analysis for a camera surveillance company I was an investor/director in.
Must be nice. I envy you. So, I'll stick with ColorThink Pro and learn as much as I can.
Mr. Gill and his Argyll s/w are indeed extremely impressive to me, based upon his posts here and other information I have encountered and read over the years. His s/w appears to be code intensive, though, which is beyond me at this stage. But, I have yet to encounter any negative speak about it. To the contrary, it is highly respected. Results from it are apparently at least a match and are often superior to the best from i1Profiler in terms of profile quality and accuracy. Otherwise, my only direct experience with Mr. Gill's products is with the ArgyllPRO ColorMeter which I have on my cell. It is a fantastically helpful tool which makes the i1 Pro even more useful.
Thank you again, sir, for all your help.
Mick
-
Must be nice. I envy you. So, I'll stick with ColorThink Pro and learn as much as I can.
Don't. It was not a good investment. However I did learn a lot and had a great deal of fun in that episode of my life. I'm really a techie that's done a bit of this and that. I like to deep dive and understand stuff. And I enjoy helping people like those that helped me. If I encounter people along the way where my experience is useful, I, like most others, try to help. You just happen to have an interesting problem. You want to learn and you put a lot of effort into it. That makes it fun for me.
I'm sure if you look around you will notice you do the same for others from time to time. We all have to make money but we also should be helping each other because we all win doing so.
Mr. Gill and his Argyll s/w are indeed extremely impressive to me, based upon his posts here and other information I have encountered and read over the years. His s/w appears to be code intensive, though, which is beyond me at this stage. But, I have yet to encounter any negative speak about it. To the contrary, it is highly respected. Results from it are apparently at least a match and are often superior to the best from i1Profiler in terms of profile quality and accuracy. Otherwise, my only direct experience with Mr. Gill's products is with the ArgyllPRO ColorMeter which I have on my cell. It is a fantastically helpful tool which makes the i1 Pro even more useful.
Graeme's work is truly outstanding. He's one of the people I've donated to.
-
You just happen to have an interesting problem. You want to learn and you put a lot of effort into it. That makes it fun for me.
Truth be told, I, too, enjoy this stuff immensely. I have a lot to learn and really enjoy the learning of it. The science fascinates me. Every time I watch a print head flying back & forth with an image forming beneath with every pass, I am totally in awe of the technology. I hope someday to be able to help people in need of it as much as you and the others have helped me.
Graeme's work is truly outstanding. He's one of the people I've donated to.
I agree. I have as well.
Mick