Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: madmanchan on November 30, 2010, 10:31:09 pm
-
Free utility for printing profile targets:
http://kb2.adobe.com/cps/834/cpsid_83497.html
-
Is this still, should it be, in beta ?
I've just downloaded and tried it out and it's not really working correctly.
The images are getting resized which isn't very helpful.
My original target image is 263mm x 173mm(untagged, 8bit TIFF, 1050x692 pixels @101dpi) and it can be correctly printed out via PS CS4.
Using ACPU I get a different size I get 253mm x 166mm with all my printers(Epson 3800/1800/OkiB4100).
Not exactly the slick interface we've come to expect from Adobe either, especially considering how long we've waited for this.
Paul
Using Windows 7 64 bit, all fully patched and running the latest drivers.
-
I've found the same. My image gets re-sized from 273mm to 263mm wide (72ppi) on my 3800. Running XP and no problems with printing from any other application.
Thanks for pointing this out Paul. I was just about to recommend it to my profile customers!
-
There is also a slight scale disconnect on this end under 10.6.5 but my iSis does read the target. That’s about the most picky device out there in terms of scaling issues with targets. I ran the same TC918 for the iSis out of CS4 and the new utility. The target from the utility is reading now (even the barcode) so I think we’re OK here. I do want to let both targets dry down and measure them, plot the deltaE in ColorThink.
-
Those of you that have the ability to print a target out of the new ACPU, Photoshop CS5 (using the null transform trick*) and as importantly CS4, you could do a great service by printing and providing CGATS files for analysis (or using ColorThink if you have it) to provide a deltaE of the three different methods. I’m seeing some oddities (differences) I cannot yet account for between ACPU and CS4. ACPU and CS5 using the hack produce very similar results (worst patch 0.24 dE) which is what I’d expect from an iSis. But those two paths and CS4 are off more than I’d like. If you do not have ColorThink, email me the CGATs and I’ll plot them.
*the null transform trick is assign Adobe RGB to the target, then in CS5’s Print dialog, select Photoshop Manages Color and select Adobe RGB as the output color space.
-
The other variable you should also use in this test is printing the target from Indesign which uses Apple's old printing path.
Doyle
-
The other variable you should also use in this test is printing the target from Indesign which uses Apple's old printing path.
At some point yes. But for now, lets look at the scaling issue and more importantly to me, if CS5, CS4 and ACPU are all producing the same behavior.
-
At some point yes. But for now, lets look at the scaling issue and more importantly to me, if CS5, CS4 and ACPU are all producing the same behavior.
At this point I have more trust in ID than CS5, CS4 and ACPU for printing targets. For me when I get around to testing this ID reference point.
-
At this point I have more trust in ID than CS5, CS4 and ACPU for printing targets. For me when I get around to testing this ID reference point.
That’s fine. But many of use have traditionally used CS4 or CS5, the utility is supposed to “fix” the issue of the no No Color Management option in Photoshop so my only suggestion is, before we get too many data points involved, lets see if the three work as we expect. If you don’t have any plans to print targets using the three items, by all means, use ID for this task (we know its print path is different from Photoshop and Lightroom).
-
That’s fine. But many of use have traditionally used CS4 or CS5, the utility is supposed to “fix” the issue of the no No Color Management option in Photoshop so my only suggestion is, before we get too many data points involved, lets see if the three work as we expect. If you don’t have any plans to print targets using the three items, by all means, use ID for this task (we know its print path is different from Photoshop and Lightroom).
Indd/CS5's "print path" different from PSCS5? So, the measured values of targets printed from these two apps won't match even when applying the same null transform technique for target printing? Yikes, now that is a problem because it means a profile built from PSCS5 using the null transform method or this new utility (if the new utility in fact matches PSCS5 output) won't work well for Indd and vice versa, nor for older versions of Mac OS and PS, nor for other non Adobe color managed apps. And, likewise, all older profiles built prior to PSCS5 won't work well in PSCS5. So, I'm with Doyle on this matter. Seems like it's a really important issue that needs to be resolved, indeed more important than whether the new utility matches PSCS5.
FWIW, after upgrading to OS10.6 and PSCS5, printing from PSCS5 became very suspect to me. It almost works right but not really. Like Doyle, my only answer so far has been to quit printing from PSCS5 and both profile and print using InDD.
-
Indd/CS5's "print path" different from PSCS5?
They use different APIs. Going back to my V4 profile testing, I saw the scum dot in Photoshop and Lightroom, not in ID. We still don’t know why this is an issue and we suspect it has something to do with Apple’s handling of the data but the differences in the API’s seem to indicate one reason why ID is immune to the scum dot.
So, the measured values of targets printed from these two apps won't match even when applying the same null transform technique for target printing?
I didn’t say that, it might very well match. Since you use ID for this task, it be a good idea to test this. That the APIs are different doesn’t mean that it will not match. It should.
-
So, I'm with Doyle on this matter. Seems like it's a really important issue that needs to be resolved, indeed more important than whether the new utility matches PSCS5.
It does match CS5, but CS4, not so much. At least it would be useful for others to run the same tests and confirm.
-
They use different APIs. Going back to my V4 profile testing, I saw the scum dot in Photoshop and Lightroom, not in ID. We still don’t know why this is an issue and we suspect it has something to do with Apple’s handling of the data but the differences in the API’s seem to indicate one reason why ID is immune to the scum dot. ...
I didn’t say that, it might very well match. Since you use ID for this task, it be a good idea to test this. That the APIs are different doesn’t mean that it will not match. It should.
I couldn't get a decent match and gave up after a couple of days of trying to sort it out. In light of this discussion thread, I guess it's time to revisit the issue. And yes, I also got very serious scum dot issues from PSCS5 on output through the most recent Canon driver for an iPF8100 (not the 16 bit plug in), strangely not in the image whites but in the margin whites that have no image data being sent to the media at that location. Doesn't happen from InDD.
I concluded at that time the targets printed from InDDCS5 with a null transform technique did match targets I had routinely printed from PSCS3/10.5 on an older PowerPC Mac using PSCS3's no color management mode, but targets printed from PSCS5 under Snow Leopard differed by an average of several delta E. Both sets of targets looked like they were plausibly printed, nothing way out of whack to indicate a target printing problem, but they just didn't match with reasonable accuracy. That means printing targets using PSCS5 appears to make app specific profile builds, perhaps suitable for use only with PSCS5 and Lightroom, but nothing else including other Adobe apps like InDD. So, if all you want to do is print from PS or perhaps lightroom, then maybe that's fine. But for every other app on the Snow Leopard platform, well it seems like we need to use Indd to make decent profiles. Oh, boy. Two steps forward, two steps back.
-
Those of you that have the ability to print a target out of the new ACPU, Photoshop CS5 (using the null transform trick*) and as importantly CS4, you could do a great service by printing and providing CGATS files for analysis (or using ColorThink if you have it) to provide a deltaE of the three different methods. I’m seeing some oddities (differences) I cannot yet account for between ACPU and CS4. ACPU and CS5 using the hack produce very similar results (worst patch 0.24 dE) which is what I’d expect from an iSis.
Hmm... this implies that printing from CS4 and CS5 using the null transform don't match. If that's the case then errrr.... it would appear as if we've missed something.
-
And yes, I also got very serious scum dot issues from PSCS5 on output through the most recent Canon driver for an iPF8100 (not the 16 bit plug in), strangely not in the image whites but in the margin whites that have no image data being sent to the media at that location. Doesn't happen from InDD.
And on my iPF6300, no scum dot with the driver (using V4 profiles). So go figure.
I concluded at that time the targets printed from InDDCS5 with a null transform technique did match targets I had routinely printed from PSCS3/10.5 on an older PowerPC Mac using PSCS3's no color management mode, but targets printed from PSCS5 under Snow Leopard differed by an average of several delta E.
Knowing where in color space this happens would be useful. With the TC918 target I tested quickly today, I see slightly above 1dE for 20 colors, mostly light green’s and teals when I sort this way in ColorThink. I don’t believe I did anything wrong printing because the average dE is low, its those worst 10% that concern me. I guess I’ll pop the same target into ID and see what I get.
-
Knowing where in color space this happens would be useful. With the TC918 target I tested quickly today, I see slightly above 1dE for 20 colors, mostly light green’s and teals when I sort this way in ColorThink. I don’t believe I did anything wrong printing because the average dE is low, its those worst 10% that concern me. I guess I’ll pop the same target into ID and see what I get.
I will try to repeat the problem again in the next day or so. While at it I will throw in the new color printer utility for good measure (no pun intended). So, with TC918 target I will print one with:
1) PSCS3/OS10.5 to Epson 3880 (latest driver), using No color management mode
2) IDCS5/OS10.6 to Epson 3880 (latest driver) with null transform technique
3) PSCS5/OS10.6 to Epson 3880 (latest driver) with null transform technique
4) OS10.6 to Epson 3880 (latest driver) using new color printer utility app
Seems like a good plan?
Sure would be nice to have an ISIS right about now ::) My Spectroscan is a little slow by comparison, but with Measure tool if I find any significant differences, I will also look to see if there is any clustering of the data.
-
Sounds like a plan. Sorry its slow but it would be useful if we tested the same target at this point because if indeed there are some colors that are printing differently, we can compare them.
-
No Epson Prem luster in my lab at the moment, but I'll use some kind of satin/luster RC for these tests.
-
So in ID CS5, what are you doing to print the target untagged? It “thinks” the target is sRGB, I’m thinking of setting the color management area to use sRGB for output producing a null profile conversion. I don’t see a No Color Management option here.
-
So in ID CS5, what are you doing to print the target untagged? It “thinks” the target is sRGB, I’m thinking of setting the color management area to use sRGB for output producing a null profile conversion. I don’t see a No Color Management option here.
right, it needs the null transform technique to do this in InDD. You can set the document color space to sRGB or aRGB, assign same to the image, then pass it through to print with the destination profile set to same. Guarantees a null conversion from what I can tell. And matches my older "no color management" mode from PSCS3/OS10.5, so I'm confident (at least for V2 profiles) that my existing profile library still works in Snow Leopard for most of my apps including Indd but not PSCS5.
-
right, it needs the null transform technique to do this in InDD.
Thanks. Looks like the target from ID using sRGB>sRGB match the null technique out of Photoshop CS5. That’s visually, I have to let it dry down and measure.
Man, ID’s color management setup and print setup sure is crude and in need of the Photoshop or LR team to help them clean it up UI wise.
-
Thanks. Looks like the target from ID using sRGB>sRGB match the null technique out of Photoshop CS5. That’s visually, I have to let it dry down and measure.
Would be great if it does, but I didn't get that result, and hence the thread hijack to indd versus PSCS5 output. Anyway, I will go back and try it again. As I had noted earlier, the target output looks normal enough that it doesn't raise a red flag, but upon measuring I found the errors were pretty significant.
Man, ID’s color management setup and print setup sure is crude and in need of the Photoshop or LR team to help them clean it up UI wise.
Agreed, but it get's the job done. Would definitely be nicer if the whole CS5 suite had a little more UI conformity. It is after all CS5 not CS1 :-\
-
Indd/CS5's "print path" different from PSCS5? So, the measured values of targets printed from these two apps won't match even when applying the same null transform technique for target printing? Yikes, now that is a problem because it means a profile built from PSCS5 using the null transform method or this new utility (if the new utility in fact matches PSCS5 output) won't work well for Indd and vice versa, nor for older versions of Mac OS and PS, nor for other non Adobe color managed apps. And, likewise, all older profiles built prior to PSCS5 won't work well in PSCS5. So, I'm with Doyle on this matter. Seems like it's a really important issue that needs to be resolved, indeed more important than whether the new utility matches PSCS5.
FWIW, after upgrading to OS10.6 and PSCS5, printing from PSCS5 became very suspect to me. It almost works right but not really. Like Doyle, my only answer so far has been to quit printing from PSCS5 and both profile and print using InDD.
First off I was not saying that there is a difference, just that given the problems that we have seen with Apple's new printing path this needs to be considered. In my experience profiles created from targets printed with ID work perfectly in CS4, CS5 and LR. That is if the printer driver works correctly with Apple's new path in 10.6.5 and for that matter with 10.5.8. We have seen many times the moving target from Apple throw a kink in printing from apps that use the new path. Note here my fix for Canon iPF drivers for ACPU. http://www.luminous-landscape.com/forum/index.php?topic=49207.0 This Canon fix is not really an Apple issue/bug, but Canon's way of dealing with this. I can see the pro and cons of this approach. At least you know that the driver is defaulting to No Color Correction seemingly regardless of what changes Apple makes.
The only (old) profiles I can see that might have issues are from targets that were printer through drivers (not correctly written for Apple's new path) that required a workaround. This may be what you have been dealing with printing from CS5. I have seen no color variations printing from CS5 or ID as long as CS5 is listed in Canon's special casing file.
Doyle
-
I concluded at that time the targets printed from InDDCS5 with a null transform technique did match targets I had routinely printed from PSCS3/10.5 on an older PowerPC Mac using PSCS3's no color management mode, but targets printed from PSCS5 under Snow Leopard differed by an average of several delta E. Both sets of targets looked like they were plausibly printed, nothing way out of whack to indicate a target printing problem, but they just didn't match with reasonable accuracy. That means printing targets using PSCS5 appears to make app specific profile builds, perhaps suitable for use only with PSCS5 and Lightroom, but nothing else including other Adobe apps like InDD. So, if all you want to do is print from PS or perhaps lightroom, then maybe that's fine. But for every other app on the Snow Leopard platform, well it seems like we need to use Indd to make decent profiles. Oh, boy. Two steps forward, two steps back.
You should not be using a null transform technique to print targets from ID. ID has the capability to turn off CM. Use "Emulate Adobe InDesign 2.0 CMS Off" in the Color Settings menu.
Of course with ID before 10.6.2 be sure "Print as Bitmap" is checked.
Doyle
-
You should not be using a null transform technique to print targets from ID. ID has the capability to turn off CM. Use "Emulate Adobe InDesign 2.0 CMS Off" in the Color Settings menu.
Doyle
Thanks for the tip Doyle. Even if I'd noticed that menu setting I would not have trusted it without someone like yourself having OK'd that it works. Good to know it equals "no color management" like in the classic PS. The null transform method also works fine in ID, but your method is indeed easier to set up and recommend to others.
-
The only (old) profiles I can see that might have issues are from targets that were printer through drivers (not correctly written for Apple's new path) that required a workaround. This may be what you have been dealing with printing from CS5. I have seen no color variations printing from CS5 or ID as long as CS5 is listed in Canon's special casing file.
Doyle
Can you elaborate on what you mean by Canon's special casing file? I have an x100 series ipF printer, and I can't get around the scum dot problem in the margins when printing to this printer from PSCS5. It occurs from PSCS5 and not IDCS5 when printing to my canon ipf8100. I was on the phone with Canon for about an hour when I first upgraded to CS5 and Snow leopard. The canon techs tossed it around and couldn't recommend a cure. So, I have no choice but to print from ID at the current time or use the 16 bit plug in in 32 bit PS mode (bummer), but I have grown to like the Canon driver's free layout utility better and that rules out PSCS5 until Apple, Adobe, and/or Canon update something.
-
This is beyond lame. What the heck is going on between Adobe and Apple that they can't fix something like this?
-
Can you elaborate on what you mean by Canon's special casing file? I have an x100 series ipF printer, and I can't get around the scum dot problem in the margins when printing to this printer from PSCS5. It occurs from PSCS5 and not IDCS5 when printing to my canon ipf8100. I was on the phone with Canon for about an hour when I first upgraded to CS5 and Snow leopard. The canon techs tossed it around and couldn't recommend a cure. So, I have no choice but to print from ID at the current time or use the 16 bit plug in in 32 bit PS mode (bummer), but I have grown to like the Canon driver's free layout utility better and that rules out PSCS5 until Apple, Adobe, and/or Canon update something.
The special casing file (AppColorMatchingInfo.xml) is a file listing the applications that use Apple's new printing path. If the application (internal executable) is not listed in this driver file when you choose to have the app manage color the driver under Main/Color Mode will default to "Color" which results in double profiling. If the application is listed, Main/Color Mode with default to "No Color Correction" which prints correctly without the driver managing color.
This has nothing to do with the printing of the scrum dot in the none image area of the page size. For a better understanding (but potentially more confusing) of the scrum dot issues check out this thread. http://www.luminous-landscape.com/forum/index.php?topic=48860.0
Doyle
-
You should not be using a null transform technique to print targets from ID. ID has the capability to turn off CM. Use "Emulate Adobe InDesign 2.0 CMS Off" in the Color Settings menu.
Actually, based on a test just done, they produce the same results:
dE Report
Number of Samples: 930
Delta-E Formula dE2000
Overall - (930 colors)
--------------------------------------------------
Average dE: 0.19
Max dE: 0.72
Min dE: 0.01
StdDev dE: 0.10
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.16
Max dE: 0.31
Min dE: 0.01
StdDev dE: 0.07
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.39
Max dE: 0.72
Min dE: 0.32
StdDev dE: 0.07
--------------------------------------------------
Note that the Emulate 2.0 target has not had time to dry down as much as I’d like (I think I’ll measure everything tomorrow). That one max dE of 0.72 is RGB 64/0/32, a dark tone which I’ve seen in the past and would attribute to dry down issues. Yes its close to 1 but I suspect by late tonight or tomorrow, the delta will be far lower.
But here’s the curious part. Lets assume for the time being ID using either method above is fine, how does this compare to using CS4 (No Color Management):
CS4 vs. ID5:
--------------------------------------------------
Average dE: 0.28
Max dE: 1.06
Min dE: 0.02
StdDev dE: 0.16
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.24
Max dE: 0.49
Min dE: 0.02
StdDev dE: 0.11
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.64
Max dE: 1.06
Min dE: 0.49
StdDev dE: 0.13
--------------------------------------------------
These targets have dried a few hours, I don’t like seeing a max dE of 1.06! Interestingly its RGB values are 160/255/96, kind of teal green. Next worst offender at a dE of 1.03 is 255/128/0, an orange. I see the next 5 or so colors listed alternating between a green and orange with high deltaE’s over 1.
OK, how about CS5 vs. CS4 (using CS5 null profile hack):
--------------------------------------------------
Average dE: 0.33
Max dE: 1.18
Min dE: 0.02
StdDev dE: 0.19
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.29
Max dE: 0.59
Min dE: 0.02
StdDev dE: 0.14
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.73
Max dE: 1.18
Min dE: 0.59
StdDev dE: 0.14
--------------------------------------------------
Again, not happy about the high max dE patches. The top 5 are all a teal green (192/255/96 or there about). These are all over a deltaE of 1.
OK, lets examine CS5 with the hack vs. the new APCU product:
--------------------------------------------------
Average dE: 0.24
Max dE: 0.75
Min dE: 0.02
StdDev dE: 0.14
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.21
Max dE: 0.44
Min dE: 0.02
StdDev dE: 0.11
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.53
Max dE: 0.75
Min dE: 0.44
StdDev dE: 0.07
--------------------------------------------------
OK, this is what I expect to see among ALL the various products. Max dE of 0.75 (probably will be less tomorrow). But sort by max dE and again, a green (64/255/64). Next in line is very dark (0/22/0) which again I would attribute to dry down. Keep in mind that even if I printed the same target using the same print process, there will still be differences just from the iSis noise itself (I’d expect something in the range of 0.2 or less deltaE).
So we have CS5 and APCU producing what I’d call today, the same results. We have CS5 and CS4 not producing the same results but close. And ID5 is different still.
To round out the matrix, here is ID5 vs. CS5:
--------------------------------------------------
Average dE: 0.33
Max dE: 1.08
Min dE: 0.02
StdDev dE: 0.16
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.29
Max dE: 0.55
Min dE: 0.02
StdDev dE: 0.12
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.66
Max dE: 1.08
Min dE: 0.55
StdDev dE: 0.10
--------------------------------------------------
Worst offenders are green again (96/224/0) then an orange (255/128/0). Back and forth, green then orange, all at 1.0 or slightly below.
And lastly, to give you an idea of really low detla’s in the example just above, RGB 48/0/255 have a deltaE of 0.02! So yes, we can get really low values as the average dE figure provides. Its the max dE colors that I can’t figure out. Perhaps its printer, don’t know. Everything was output on a 3880 on Luster.
What would be really, really useful for many parties is if those of use with Spectrophotometers could test this matrix. If you don’t have ColorThink Pro, I can build the deltaE reports from saved CGATS files. Sorting by deltaE helps greatly as we can see, based on this one “standard” target (TC918) where in color space the errors are showing.
-
What printer did you use for this?
-
Epson 3880.
-
Epson 3880.
It would be interesting to see if the Canon iPF6300 showed similar differences.
-
...These targets have dried a few hours, I don’t like seeing a max dE of 1.06! Interestingly its RGB values are 160/255/96, kind of teal green. Next worst offender at a dE of 1.03 is 255/128/0, an orange. I see the next 5 or so colors listed alternating between a green and orange with high deltaE’s over 1.
... Keep in mind that even if I printed the same target using the same print process, there will still be differences just from the iSis noise itself (I’d expect something in the range of 0.2 or less deltaE).
IMHO, given that the max deltaE2000 for this many patch values printed on four different prints was less than 1.5, my interpretation is that all target printing techniques produced essentially identical results, all within the experimental error attributable to instrument reading combined with print-to-print inking/substrate variability. I couldn't achieve any where near that result when I tried several months ago, but there has been at least one OS10.6 update and perhaps other system tweaks since then, and alternatively, I could have just plain screwed up in my tests. Operator fatigue can get to be very high in these mind numbing target making exercises, especially for those of us who don't have an Isis :D (Or, as the saying goes "I thought I made a mistake once, but I was wrong!).
Notwithstanding, I've still got the additional but probably unrelated scum dot problem printing from PSCS5 to my Canon printer, so printing from ID is still my only decent work around at the moment.
I will give it another go, and see how I do this time around in matching ID target output to PSCS5 output. Andrew, thanks for sharing these results.
-
IMHO, given that the max deltaE2000 for this many patch values printed on four different prints was less than 1.5, my interpretation is that all target printing techniques produced essentially identical results, all within the experimental error attributable to instrument reading combined with print-to-print inking/substrate variability.
I don’t think so! Those delta’s are way too high. The printer and the Spectrophotometer are going to produce far, far lower max delta’s if printed from the same app using the same driver.
Notwithstanding, I've still got the additional but probably unrelated scum dot problem printing from PSCS5 to my Canon printer, so printing from ID is still my only decent work around at the moment.
That’s a totally different printing issue (at least for many of us, using V4 profiles from some packages with some print drivers and apps).
-
My experience with this utility is "so far, so good". My printer profiling package is the now discontinued XRite Pulse Elite software and DTP-20 Spectrophotometer. The software provides the option to download and save the 729 patch target on two letter-sized pages in TIFF format. I did so, opened them in the new Adobe application and printed them. The process is pretty seamless and simple, although the instructions provided with the app do not exactly match how the application presents itself on my system (Mac version on OSX 10.6.4). But one can figure it out quite easily because there isn't that much that needs to be verified or done. I compared the appearance of the printed sheets with previous successful profiling exercises using the same printer and paper combination (Epson 3800 with Ilford Gold Fibre Silk) and they look pretty much the same. I did not make comparative measurements, because I expect there to be minor differences, given that two different versions of the Epson driver (Windows vs Mac) are involved between the previous (comparator) exercise and the one I am attempting now. I then noted the dimensions of the printed material in Photoshop, and measured the same surface areas with a very accurate steel ruler on the prints. If there is any difference at all, it is very, very small. Hence I expect that the Pulse Elite should be able to read these patches successfully. I shall let the prints dry over-night before attempting that, and I'll report back on both the profile creation experience and my impression of the profile performance with real-world images.
-
It would be interesting to see if the Canon iPF6300 showed similar differences.
Doing that now so targets dry. But here’s an odd one. I can’t print the untagged target through CS4 to the iPF6300! Everything acts normal, printer acts like its actually printing, paper comes out without a drop of ink!
Using the same app, a tagged image and (in this one test) Printer Manages Color, I get a print. I can also print the untagged target in CS5, the new Adobe app for this task and InDesign CS5. But CS4, nada. The Export module works as well (but I don’t want to go that route). Anyone else with this printer and CS4 able to print a target using version 2.2.1?
-
Doing that now so targets dry. But here’s an odd one. I can’t print the untagged target through CS4 to the iPF6300! Everything acts normal, printer acts like its actually printing, paper comes out without a drop of ink!
Using the same app, a tagged image and (in this one test) Printer Manages Color, I get a print. I can also print the untagged target in CS5, the new Adobe app for this task and InDesign CS5. But CS4, nada. The Export module works as well (but I don’t want to go that route). Anyone else with this printer and CS4 able to print a target using version 2.2.1?
No problem here with the 2.17 driver for the iPF9000 for CS4. I printed a TC9.18 target with IDCS5, PSCS4, and the ACPU. Visually they look identical. I will let them dry and read them tomorrow.
I am assuming you updated the AppColorMatchingInfo.xml file to add the ACPU so that it defaults to No Color Correction?
-
Doing that now so targets dry. But here’s an odd one. I can’t print the untagged target through CS4 to the iPF6300! Everything acts normal, printer acts like its actually printing, paper comes out without a drop of ink!
Holy crap... I had the EXACT same thing happen to me today on a 6100. Try this...
Using the regular driver set the depth to 16 bits, then try again but setting it to 8 bits.
I saw the following behavior... at 16 bits it just fed the paper through the printer. Didn't even more the head. At 8 bits it moved the printer through the paper AND moved the heads this time... it just neglected to lay down any ink. If you did a print to preview it would just show a blank page.
I called Canon support. They were truly puzzled.
This was working fine a few days ago. Only change... I ran that Adobe utility.
A reinstall of the driver brought it back to life but now I'm kind of wondering if anything else was changed. I have a backup from a few days ago that I can run off of to see if the charts it spits out are different.
Cheers, Joe
-
This becomes a typical Adobe CM thread again.
I'm paying 6x the price of a Qimage license to get an update on a CS suite. Adobe can not create a CM ghostbusters team to bring one UI + the same CM effects on all its applications including this "cure" tool? Of course the last only needs a CM-Off button on Windows and a CM-Off button on OS-x with a color space loop hidden so no Mac user has to use his brain or might get the impression Apple isn't devine.
met vriendelijke groeten, Ernst Dinkla
Try: http://groups.yahoo.com/group/Wide_Inkjet_Printers/
-
This becomes a typical Adobe CM thread again.
I'm paying 6x the price of a Qimage license to get an update on a CS suite. Adobe can not create a CM ghostbusters team to bring one UI + the same CM effects on all its applications including this "cure" tool? Of course the last only needs a CM-Off button on Windows and a CM-Off button on OS-x with a color space loop hidden so no Mac user has to use his brain or might get the impression Apple isn't devine.
met vriendelijke groeten, Ernst Dinkla
Try: http://groups.yahoo.com/group/Wide_Inkjet_Printers/
Ernst, sorry, but this kind of smearing might improve the taste of your bread and butter, but it does ZERO to advance the discussion in any kind of constructive manner. I'm probably more sharply critical of several major providers in this industry because of their sheer failure to get their acts together and collaborate properly at a technical level on some pretty fundamental issues which affect a great many people who spend large sums of money on their products. That is the larger scale issue which needs to be dealt with at a level and in a manner where perhaps more effective solutions could be forthcoming in the future, in order to mitigate the risk of these costly mishaps. Meanwhile, what we are trying to do in this thread is share experience to help each other and in the process perhaps help Adobe "get it right" wherever that may be necessary.
As for your smear on Apple computer users, I recently switched from Windows to Mac; on the whole I'm satisfied I did the right thing, and not because I am afraid of either technology after being an intensive user of Windows systems since the 1980s; at the same time, I have several major issues with Apple Computer on account of things which don't work properly; and not being a fan-boy of any corporation or any technical approach, they are hearing from me loud and clear to clean it up. All of them and all of it is only as good as it delivers the goods. You seem to imply that you know the answer to this problem and you seem to imply the whole thing is really very simple, so why don't you contact Adobe and offer them your services to fix it.
-
It is not an act of smearing. I have been following these threads for more than a year now. I have the Adobe CS4 suite, Windows version. The CS5 version is crippled in my view because there's a problem between Adobe/Apple color management policies. There was no need to adjust it for Windows. A free application was promised many months ago and now a BETA version of it shows flaws, not just on CM but even with drivers. A company that has more than 7K employees and not getting this right within 6 months should get some criticism. I hardly have written in the threads on this subject, at the beginning I mentioned that a CM-Off button should do exactly what it says. There are OSses + their applications that work like that. I repeat that message here after a year.
I honestly do not understand that there is no anger about this issue. I see the same explorations of what colorspace has to be used to make it work safe as the Chan detour threads have shown for Snow Leopard + Photoshop CS5. It should be a solution not another puzzle. It is like getting a package of band aid and you have to buy glue to let them stick. And yes, part of this problem is caused by that Apple desire to hide anything that may be too complicated for its customers. Fine for an iPhone, different for a print environment. Maybe they should not listen to marketing if it is about CM.
If it is too costly let them write a manual for printing targets from Photoshop, InDesign, Lightroom, etc, with precise instructions for the printer models, what color space loops will work, etc. For one reason or another that is left to the gurus here to explore and to write down and not Adobe or Apple staff. Must be too embarrassing that it has to be done that way. And do not tell that it is all clear to everyone right now. I see enough capable men here in this list that are still confused.
met vriendelijke groeten, Ernst Dinkla
New: Spectral plots of +175 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
-
It is not an act of smearing. I have been following these threads for more than a year now. I have the Adobe CS4 suite, Windows version. The CS5 version is crippled in my view because there's a problem between Adobe/Apple color management policies. There was no need to adjust it for Windows. A free application was promised many months ago and now a BETA version of it shows flaws, not just on CM but even with drivers. A company that has more than 7K employees and not getting this right within 6 months should get some criticism. I hardly have written in the threads on this subject, at the beginning I mentioned that a CM-Off button should do exactly what it says. There are OSses + their applications that work like that. I repeat that message here after a year.
I honestly do not understand that there is no anger about this issue. I see the same explorations of what colorspace has to be used to make it work safe as the Chan detour threads have shown for Snow Leopard + Photoshop CS5. It should be a solution not another puzzle. It is like getting a package of band aid and you have to buy glue to let them stick. And yes, part of this problem is caused by that Apple desire to hide anything that may be too complicated for its customers. Fine for an iPhone, different for a print environment. Maybe they should not listen to marketing if it is about CM.
If it is too costly let them write a manual for printing targets from Photoshop, InDesign, Lightroom, etc, with precise instructions for the printer models, what color space loops will work, etc. For one reason or another that is left to the gurus here to explore and to write down and not Adobe or Apple staff. Must be too embarrassing that it has to be done that way. And do not tell that it is all clear to everyone right now. I see enough capable men here in this list that are still confused.
met vriendelijke groeten, Ernst Dinkla
New: Spectral plots of +175 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
Ernst, the underlying substance of what you are getting at is a real issue. I migrate between frustration and bewilderment over this stuff. My simple message is not to cloud the issue by making off-base comments about people who use Apple computers - not that I'm sensitive to such comments; it's just that they aren't helpful. More difficult to understand is that the version of this application we are discussing is NOT beta software. And yet more difficult to understand is the apparent inconsistency of the issues between users with different software and hardware configurations, which of course is a software engineer's worst nightmare. For example, at least the first step of the profile creation process using this app started very well for me, and I don't pretend to have a magic touch that other people experiencing problems with this don't have - it seems to be luck of the draw. I am now about to haul out the spectro and the backboard and try to create the profile and test it. Will report back in later.
-
Here is my report printing the TC9.18 target from IDCS5 (Emulate Adobe InDesign 2.0 CMS Off), PSCS4, and the Adobe Color Printing Utility to my Canon iPF9000.
IDCS5 Vs. ACPU
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE94
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.55
Max dE: 1.53
Min dE: 0.08
StdDev dE: 0.23
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.50
Max dE: 0.88
Min dE: 0.08
StdDev dE: 0.17
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 1.03
Max dE: 1.53
Min dE: 0.88
StdDev dE: 0.14
--------------------------------------------------
--------------------------------------------------
IDCS5 Vs. PSCS4
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE94
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.31
Max dE: 1.38
Min dE: 0.01
StdDev dE: 0.20
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.26
Max dE: 0.57
Min dE: 0.01
StdDev dE: 0.12
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.78
Max dE: 1.38
Min dE: 0.57
StdDev dE: 0.17
--------------------------------------------------
--------------------------------------------------
PSCS4 Vs. ACPU
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE94
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.35
Max dE: 1.54
Min dE: 0.01
StdDev dE: 0.14
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.32
Max dE: 0.51
Min dE: 0.01
StdDev dE: 0.10
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.61
Max dE: 1.54
Min dE: 0.51
StdDev dE: 0.16
--------------------------------------------------
--------------------------------------------------
-
I am assuming you updated the AppColorMatchingInfo.xml file to add the ACPU so that it defaults to No Color Correction?
Why do I have to do this (and how?). I can still set it manually right (that’s what I did in the driver)?
-
Further to my post #34, I am pleased to report that this whole process worked properly for me. I am more than pleased about this, because I am using a profile making kit (XRite Pulse Color Elite) which dates from 2005, and therefore ante-dates Snow Leopard by some 5 years. The software and spectro both installed and operated seamlessly back in September when I purchased the MacPro. My operating environment is MacPro with OS 10.6.4., Epson 3800 printer and Ilford Gold Fibre Silk paper. The steps I followed were:
1. Install the new Adobe target printing application, save-out the 729 patch target from the Pulse Elite as two TIFF files (it is a two-page target), print each page individually from the Adobe application and let it dry over night.
2. Calibrate the spectro and measure the patches. This all worked fine. No misses, no repeats, which means that the patches printed with correct scale, as I reported in post 34.
3. Create the profile as a V2 for D50 illuminant using the Pulse Elite software.
4. Open Bill Atkinson's printer test target (the one with the strawberries, foliage, gradients, etc) and print it with Photoshop Manages Color using the newly created profile. Printer settings are 2880, finest detail, high speed OFF, Printer Color Management OFF (my usual). The profile for this paper is keyed with Epson Premium Luster paper in the Epson driver.
5. Compare the printed outcome with the soft-proof for the same condition, with and without "Simulate Paper White".
Visually the results are fine. I found the screen-to-print match closer without Simulate Paper White, which is not an unexpected outcome using this printer and paper combination. The Atkinson printer test target is usually a very reliable indicator of what to expect from prints of one's own photographs. Hence based on what I see as of now, I should be able to print my own images with a high degree of predictive confidence. I shall report back if I experience disappointment in this respect. As of now I have the impression that I am satisfactorily colour-managed. BTW, my display is an NEC PA271W calibrated and profiled with BasicColor Display 4, but operating on DVI-to-DVI 8-bit output (rather than the promised 10-bit) due to the unresolved mini-DisplayPort technical issue between Apple Computer and NEC Solutions.
-
Why do I have to do this (and how?). I can still set it manually right (that’s what I did in the driver)?
Are you telling me that with the Canon iPF6300 drivers that when choosing application manages color when printing with apps that use Apple's new printing path that under Color Matching in the driver you can choose "Vendor Matching", and it is not grayed out and defaults to "ColorSync". If you can choose "Vendor Matching" then under Main/Color Mode you should be able to choose "No Color Correction" or "Color". Obviously with the old printing path printing from ID this is the behavior, but I have never ever heard of this being possible with the new printing path when printing with application manages color or as in the case of PSCS4 with No Color Management selected or with ACPU.
If that is the case then Canon has taken a radical change with their iPFx300 drivers as the iPFx000 and x100 drivers need to the have the applications that use the new print path listed in the AppColorMatchingInfo.xml file for the driver to turn off CM when printing with application manages color. I don't believe this to be that case because those with the iPFx000 and x100 printer they can install the iPFx300 drivers which will update the AppColorMatchingInfo.xml file. The AppColorMatchingInfo.xml file from the iPFx300 drivers includes PSCS5 and LR3 which is not in the AppColorMatchingInfo.xml file from the iPFx000 and x100 drivers. But the AppColorMatchingInfo.xml file from the iPFx300 drivers does not include LR3.3RC or ACPU which will cause the driver to default to ColorSync and in the Main/Color Mode to Color which will result in double profiling.
-
Mark- thanks for your post #44. I am a serious enthusiast, with nowhere near the experience you possess. But, I have been following these threads regarding "dark prints" and unsatisfactory print results for a few years. Similar to you, I have a MacPro with OSX 10.6.5, Epson 3880 printer and Red River Arctic Polar Satin (one of Eric's favorites). Your post #44 essentially sums up my results of the past two days working with the released (Beta?) Adobe Color Printer Utility. I do not have reams of technical printouts to quantify my results. I can however offer these comments. Having used for years the methods and printer test targets (of Atkinson and the DigitalDog) and the sage advice of Mr. Schewe and Michael in their various videos, I can say my journey (or search) is over. For me FINALLY, WYSISYG from screen to print. As I said, prints (the various test targets) are NOT dark. The blues are blue, without a purple tint. And the strawberries look good enough to eat. I've saved the results (printouts) of the targets from years of testing v10.4, 10.5, and 10.6, on Epson R2400, R2880 and now 3880. In the last 24 hours, I've compared the previous prints to what I printed today with LR v3.3RC and the differences are stunning.
Now, I don't know whether all this is the result of JUST using the Adobe Color Print Utility. Let me suggest that prior to running all the calibration I also updated "all" the software involved. I also have the most up to date print driver installed. So for me. the journey (or search for print nirvana) is over. That is until Apple does something STUPID, again.
YMMV!
-
So here I am in the dark ages running a Win 7 machine, using ColorMunki to profile my printer (my monitor is a NEC that I profile with their puck and SpectraView). And you know what? My prints match my monitor and the standard print that I use to validate the profile (the Jack Flesher one from the Outback website that uses Atkinson images) shows the colors to be dead on. I guess I must be doing something right. ;)
-
Here is my report printing the TC9.18 target from IDCS5 (Emulate Adobe InDesign 2.0 CMS Off), PSCS4, and the Adobe Color Printing Utility to my Canon iPF9000.
Delta-E Formula dE94
Can you set ColorThink for dE2000? Better for this kind of work.
Got the iPF6300 to print from CS4 after reinstalling print drivers. Odd, this morning unlike last night, it would not even “print” (click print, nothing happened at all, not the no ink on page result). So CS4 will have to dry down to compare to the matrix.
Here’s what I have from iPF6300, this time Prem Glossy paper.
IDCS5 vs. ACPU
Number of Samples: 930
Delta-E Formula dE2000
Overall - (930 colors)
--------------------------------------------------
Average dE: 0.23
Max dE: 0.82
Min dE: 0.02
StdDev dE: 0.13
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.20
Max dE: 0.41
Min dE: 0.02
StdDev dE: 0.09
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.51
Max dE: 0.82
Min dE: 0.41
StdDev dE: 0.09
--------------------------------------------------
CS5 vs. ACPU:
--------------------------------------------------
Average dE: 0.16
Max dE: 0.79
Min dE: 0.01
StdDev dE: 0.10
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.14
Max dE: 0.29
Min dE: 0.01
StdDev dE: 0.07
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.37
Max dE: 0.79
Min dE: 0.29
StdDev dE: 0.09
--------------------------------------------------
Very similar to the results on the Epson with good correlation of the two apps, low max dE. For reference, on the 3880, the dE was: Average dE: 0.19 Max dE: 0.72
CS5 vs. ID5:
--------------------------------------------------
Average dE: 0.25
Max dE: 0.94
Min dE: 0.02
StdDev dE: 0.14
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.22
Max dE: 0.42
Min dE: 0.02
StdDev dE: 0.10
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.54
Max dE: 0.94
Min dE: 0.42
StdDev dE: 0.11
--------------------------------------------------
Not as bad as I saw with the Epson, in this case, the worst RGB values were very dark 0/0/22.
So the Canon with its print driver appears to be more consistent in the three app’s while the Epson is farther off than I think it should be. Another Apple-Adobe-Epson combo issue?
-
I just remeasured the targets from CS4 vs. CS5 I printed on the 3880 yesterday. No dry issues at this point! I’m still not happy with the max dE and if possible, and those who are willing, I’d like to suggest some concentrate on these two app’s with Epson drivers (Canon at this point seems a bit more consistent). With today’s report, I’m still getting a max dE of 1.38 between the two versions of Photoshop, again on greens! 7 greens all above dE of 1 just seems wrong to me.
It appears that ACPU and CS5 correlate well, even with this Epson printer. But CS4 and CS5, not so much.
-
So here I am in the dark ages running a Win 7 machine, using ColorMunki to profile my printer (my monitor is a NEC that I profile with their puck and SpectraView). And you know what? My prints match my monitor and the standard print that I use to validate the profile (the Jack Flesher one from the Outback website that uses Atkinson images) shows the colors to be dead on. I guess I must be doing something right. ;)
Alan: no you are NOT in the dark ages. And you know it :-)
Are you using Photoshop CS4 or CS5 or Lightroom for printing? Have you made new profiles from Photoshop CS5 before this new Adobe utility was announced the other day?
i.e. it would be good to learn a bit more about what you are doing right!
-
Another useful find (I think <g>). Fellow color geek Chris Murphy and I have been doing work behind the scenes. He believes that using CS5 with the hack whereby you Assign a profile and then pick that profile for printing (to get a Null conversion) doesn’t work with sRGB as it does with Adobe RGB (1998). I can confirm that on this end printing to the 3880. Be useful if anyone else can confirm or deny this. If you recall, CS5 and the new ACPU appear to produce the same results when CS5 is set using the Adobe RGB (1998) profiles for assignment and printing.
-
I did my own tests yesterday on a 3880, Mac 10.6.4, driver 6.60. I tested CS4 and CS5 (with the workaround, with Adobe RGB), and ACPU. I let all the prints dry for 4 hours, then measured them all with an Eye-One UV in patch mode. Very slow, but reliable.
The results were all the same (within measurement error).
Namely, comparing pairwise (any 2 pairs), average DE2000 is 0.12. Max DE2000 is ~1.4.
For reference, when I print the target twice with the same app and compare those results, the numbers are the same.
Also, all of the targets printed at exactly the same size (7.5" x 10"). The ACPU printouts were not resized.
-
The results were all the same (within measurement error).
Namely, comparing pairwise (any 2 pairs), average DE2000 is 0.12. Max DE2000 is ~1.4.
Well I can’t say I necessarily agree here that a max dE of 1.4 is within measurement error or acceptable but I’m willing to listen otherwise.
I assume you sort the list in something like ColorThink by max to min dE. Why then are the worst few patches up over 1 dE while others are a fraction of a delta? If I measure the same chart twice, I don’t get the results you report so I have to assume the differences here are how the item is printed, not measured.
For fun, lets both print the same target identically two times in a row and measure and look at the report. So say ACPU printing the target twice. You really think you’ll get a 1 dE on any patch? That would be a real concern for a device like a modern Epson or Canon.
-
Another useful find (I think <g>). Fellow color geek Chris Murphy and I have been doing work behind the scenes. He believes that using CS5 with the hack whereby you Assign a profile and then pick that profile for printing (to get a Null conversion) doesn’t work with sRGB as it does with Adobe RGB (1998). I can confirm that on this end printing to the 3880. Be useful if anyone else can confirm or deny this. If you recall, CS5 and the new ACPU appear to produce the same results when CS5 is set using the Adobe RGB (1998) profiles for assignment and printing.
You may find variation if the a not properly written printer driver/OS does not turn off CM. In the case 10.5 seems to use Generic RGB and 10.6 sRGB.
-
When I measure the TC918 from ACPU (two printed in a row and wet) I get a max dE of 0.70. That seems like a far cry from the max dE I’m getting from the same instrument (iSis XL) between the various app’s (worst case is 1.18). And I see far closer correlation between some app’s and the measurement data in terms of the max dE (CS5 vs. ACPU being 0.72). Should not all the app’s produce roughly the same max’s at least under 1.0?
-
Also, all of the targets printed at exactly the same size (7.5" x 10"). The ACPU printouts were not resized.
What printer and driver? Its absolutely resizing on this end going to an Epson 3880, v6.60 on 10.6.5. Others have reported the sizing differences too but that doesn’t seem to negatively affect the ability to read the targets.
-
I did my own tests yesterday..........Also, all of the targets printed at exactly the same size (7.5" x 10"). The ACPU printouts were not resized.
Hasn't this been tested on any Windows systems ? If so, is the resizing seen by the Windows users here regarded as acceptable ?
Paul
-
Hasn't this been tested on any Windows systems ? If so, is the resizing seen by the Windows users here regarded as acceptable ?
IF its sizing the same on Windows and Mac, its acceptable to the degree that one can measure the targets. I mean, with an EyeOne, the patches can be this far off, no problem. On most auto Spectrophotometers like the iSis, if you are off more than say 5% either way, it will barf. I haven’t tested this on my other auto Spectrophotometer, a DTP-41UV-T but suspect that it would also measure without error. Should this “bug” have been detected and fixed prior to release (assuming this utility is wrong and the others are printing correctly which my rulers say they are)? Yes. Is it a deal breaker, no. And so far, the output from ACPU and CS5 seem to produce the same results which is good. Why ID5 and CS5 are more different <g> may be as much an issue with the OS as anything else. That’s why having some Windows users do the same testing from the same app’s would be real useful.
-
Alan: no you are NOT in the dark ages. And you know it :-)
Are you using Photoshop CS4 or CS5 or Lightroom for printing? Have you made new profiles from Photoshop CS5 before this new Adobe utility was announced the other day?
i.e. it would be good to learn a bit more about what you are doing right!
I use LR for all printing as I agree with Jeff Schewe that once you get the printing presets established everything is pretty much fool proof (I did have a friend print out one of my color images on his 9900 using Qimage and it was really difficult seeing any difference in the color shadings versus my 3880 with a CM profile). I have CS4 (haven't updated to CS5 as I still don't see that there is anything new that will help me out) for pixel edits as necessary. ColorMunki uses it's own utility to create profiles so you don't have to print targets through any Adobe product. The only thing to be aware of with ColorMunki is the target drydown work around that has been mentioned on another thread. For B&W printing I rely on Eric Chan ABW profiles. As I noted, the test prints look excellent with the ColorMunki profiles. If there is a particular print that might warrant a profile improvement, ColorMunki can look at the image and refine the profile.
Alan
-
What printer and driver? Its absolutely resizing on this end going to an Epson 3880, v6.60 on 10.6.5. Others have reported the sizing differences too but that doesn’t seem to negatively affect the ability to read the targets.
Are you seeing a size difference with your Canon because I am not with mine. I set the page size to 12 x 24 landscape in ID, PS and ACPU and all three printed the same size on exact same area of the paper.
-
Is this still, should it be, in beta ?
I've just downloaded and tried it out and it's not really working correctly.
The images are getting resized which isn't very helpful.
My original target image is 263mm x 173mm(untagged, 8bit TIFF, 1050x692 pixels @101dpi) and it can be correctly printed out via PS CS4.
Using ACPU I get a different size I get 253mm x 166mm with all my printers(Epson 3800/1800/OkiB4100).
Not exactly the slick interface we've come to expect from Adobe either, especially considering how long we've waited for this.
Paul
Using Windows 7 64 bit, all fully patched and running the latest drivers.
I have the same issue on Windows XP SP3 and Canon PIXMA Pro9500. Moreover paper margin settings in the utility do not work for my Canon. Targets are printed on the top left corner of a paper. Very uncomfortable for measuring targers using an i1Pro.
-
Are you seeing a size difference with your Canon because I am not with mine. I set the page size to 12 x 24 landscape in ID, PS and ACPU and all three printed the same size on exact same area of the paper.
To the iPF6300 I do see a difference in size but its tiny. The black bar for the iSis is 180mm vs. 179mm (I’ve asked my wife to verify). What is much different is how the target is printing centered on the page. ACPU is shifting far more than the small differences in the scale (which probably explains why I’ve had no measurement issues).
-
That’s why having some Windows users do the same testing from the same app’s would be real useful.
I'd like to help, but haven't bothered to upgrade to CS5 for either application after trying the trials.
What's important about the resizing issue is that when a customer sends a set of targets that aren't the correct size it's the most obvious indication they haven't bothered to read the instructions for printing profiling targets properly or aren't taking enough care to avoid mistakes. In other words they're likely to become a support burden.
So those of us that hoped this utility would provide a useful and reliable tool for our customers may be disappointed.
The second issue is that if the print outs aren't consistent from system to system (Eric says his prints are correct, others are seeing different behaviour) what else may be going wrong too ?
Frankly this is all very disappointing. The package looks like it's been knocked out fast to hit a late deadline and without sufficient care or testing.
-
I'd like to help, but haven't bothered to upgrade to CS5 for either application after trying the trials.
Actually its CS4 vs. the new utility I’m more interested in. CS5 and ACPU correlate well.
Frankly this is all very disappointing. The package looks like it's been knocked out fast to hit a late deadline and without sufficient care or testing.
Lets put this into perspective. If anyone should be producing such a utility its DataColor and X-Rite. They are the ones who ask us to print targets this way. Adobe spent the time and money to produce a utility for a tiny group of users. They removed NCM from Print to simplify the app for a much larger user base who have zero need for this functionality. The utility works on this end, I can measure targets. I would suggest that Adobe ask a few of us willing and able beta testers to help them out next time but in this case, there appears to be nothing so broken we can’t use the product as is.
-
Actually its CS4 vs. the new utility I’m more interested in.
I've already printed those out and will measure and compare them tomorrow when the prints are fully dry.
Lets put this into perspective. If anyone should be producing such a utility its DataColor and X-Rite. They are the ones who ask us to print targets this way. Adobe spent the time and money to produce a utility for a tiny group of users. They removed NCM from Print to simplify the app for a much larger user base who have zero need for this functionality. The utility works on this end, I can measure targets. I would suggest that Adobe ask a few of us willing and able beta testers to help them out next time but in this case, there appears to be nothing so broken we can’t use the product as is.
I take your point, but from what I can see there was no real need to remove the NCM option from PS. Certainly it was no problem for Windows users.
It just seems to have been removed in a clumsy attempt to get round the CMS mess brewing with Macs. The end result has just caused confusion and difficulty for a significant set of PS users.
-
I take your point, but from what I can see there was no real need to remove the NCM option from PS. Certainly it was no problem for Windows users.
If you think Adobe will get heat about this utility, just imagine if they had NCM in Windows but not Mac. Its really not that necessary either. Like I suggested, for but a small group printing untagged targets, what’s the need? The color management companies are the ones who should have engineered a way to print them.
-
Eric and others, in terms of the scaling of targets, on the ColorSync list, David Tobie wrote:
On Dec 3, 2010, at 3:19 PM, C D Tobie wrote:
Depends on the resolution of the file. With a large file, the scaling issue is... quite large.
My reply:
As I said, the letter sized TC918 is 101.6 (40 pixels per centimeter). Using Nearest Neighbor I sampled to 120 PPC and printed with the ACPU utility. The scaling is identical, the black bar for the iSis is 180mm in size. But what IS different is how the target is placed on the page. At 40PPC its nearly centered, at 120PPC its shifted quite a bit to the left side to the point that the black arrows the iSis needs to read is cut off. So it appears the bug is related to the actual resolution of the document as David indicates but its more an image shifting issue than a scaling issue.
There does seem to be a bug here not in terms of scaling but positioning.
-
Lets put this into perspective. If anyone should be producing such a utility its DataColor and X-Rite. They are the ones who ask us to print targets this way. Adobe spent the time and money to produce a utility for a tiny group of users.
That makes the most sense. It really shouldn't be Adobe's responsibility to provide a utility to print targets.
Maybe if the testers for i1Profiler bring the issue up to X-Rite, they might be able to include that functionality. :)
Jim
-
Andrew
Could you reply to this. If the haven't updated the AppColorMatchingInfo.xml file to add the ACPU, then what settings are you getting under "Color Matching" and then under Main/Color Mode in the iPF6300 driver? If you are getting ColorSync and then Color but the target seems normal then it looks like ACPU is assigning a profile.
I am assuming you updated the AppColorMatchingInfo.xml file to add the ACPU so that it defaults to No Color Correction?
Why do I have to do this (and how?). I can still set it manually right (that’s what I did in the driver)?
Are you telling me that with the Canon iPF6300 drivers that when choosing application manages color when printing with apps that use Apple's new printing path that under Color Matching in the driver you can choose "Vendor Matching", and it is not grayed out and defaults to "ColorSync". If you can choose "Vendor Matching" then under Main/Color Mode you should be able to choose "No Color Correction" or "Color". Obviously with the old printing path printing from ID this is the behavior, but I have never ever heard of this being possible with the new printing path when printing with application manages color or as in the case of PSCS4 with No Color Management selected or with ACPU.
If that is the case then Canon has taken a radical change with their iPFx300 drivers as the iPFx000 and x100 drivers need to the have the applications that use the new print path listed in the AppColorMatchingInfo.xml file for the driver to turn off CM when printing with application manages color. I don't believe this to be that case because those with the iPFx000 and x100 printer they can install the iPFx300 drivers which will update the AppColorMatchingInfo.xml file. The AppColorMatchingInfo.xml file from the iPFx300 drivers includes PSCS5 and LR3 which is not in the AppColorMatchingInfo.xml file from the iPFx000 and x100 drivers. But the AppColorMatchingInfo.xml file from the iPFx300 drivers does not include LR3.3RC or ACPU which will cause the driver to default to ColorSync and in the Main/Color Mode to Color which will result in double profiling.
-
Ok I did at test on my iPF9000 by putting the previous AppColorMatchingInfo.xml that does not list the ACPU back in and printed the same target as two days ago. This time when I printed, the print dialog under Main/Color Mode defaulted to Color, and the driver/os did a color conversion. The print was way, way off from from the ones two days ago. That at least confirms that the ACPU is not assigning a sRGB to get around the drivers that can not turned off CM.
So to print a proper untagged print from ACPU to a Canon IPF printer it must have the internal executable file name of the Adobe Color Printer Utility listed in the AppColorMatchingInfo.xml file. Refer to this post on how to install the updated AppColorMatchingInfo.xml file that includes the Adobe Color Printer Utility.
http://www.luminous-landscape.com/forum/index.php?topic=49207.0
-
Could you reply to this. If the haven't updated the AppColorMatchingInfo.xml file to add the ACPU, then what settings are you getting under "Color Matching" and then under Main/Color Mode in the iPF6300 driver?
Like in Photoshop, the options are grayed out but the gray radio button is set to ColorSync. FWIW, that’s also what I see for the Epson (in Photoshop and in the ACPU).
Refer to this post on how to install the updated AppColorMatchingInfo.xml file that includes the Adobe Color Printer Utility.
Will do.
-
Are you telling me that with the Canon iPF6300 drivers that when choosing application manages color when printing with apps that use Apple's new printing path that under Color Matching in the driver you can choose "Vendor Matching", and it is not grayed out and defaults to "ColorSync".
In CS5, its not grayed out, I could select either ColorSync or Vendor Matching. In ACPU, I have no choice. For the Epson driver in either app, I have no choice.
-
Like in Photoshop, the options are grayed out but the gray radio button is set to ColorSync. FWIW, that’s also what I see for the Epson (in Photoshop and in the ACPU).
Will do.
It is not the ColorSync button that is the problem, it is what the Main/Color Mode setting is. If it defaults to "No Color Correction" them no color management is performed by the driver/os. If it defaults to Color then color management is performed by the driver/os.
-
In CS5, its not grayed out, I could select either ColorSync or Vendor Matching.
Are you sure you don't have Printer Manages Color selected?
You just said it was grayed out in the post before.
-
In ACPU, I have no choice. For the Epson driver in either app, I have no choice.
But what is the Main/Color Mode setting in the Canon driver with ACPU?
-
OK so here are some numbers from measuring targets printed from PS CS4, ACPU, ID & Qimage on a Windows 7 64 bit system
Looking at the figures there is no significance colour difference between all four program's output(just ACPU resizing the targets). Any differences could be down to measurement and printer accuracy.
Methodology
Target TC2.83 RGB i1 printed twice from CS4 & ACPU, each print out measured twice.
Printing on Epson 3800 on Jessops gloss paper, Windows 7 64bit.
dE2000 measurements with Eye-One Pro revB in strip mode with PMP 5.0.10
Measurement accuracy, comparing two passes of same target;
Average delta: 0.14
Standard deviation (dE): 0.12
Average delta: 0.12
Standard deviation (dE): 0.10
Average delta: 0.13
Standard deviation (dE): 0.08
Average delta: 0.14
Standard deviation (dE): 0.11
Accuracy of print to print accuracy from same application;
Average delta: 0.36
Standard deviation (dE): 0.24
Average delta: 0.37
Standard deviation (dE): 0.24
Average delta: 0.25
Standard deviation (dE): 0.15
Average delta: 0.22
Standard deviation (dE): 0.15
CS4 - ACPU
Average delta: 0.53
Standard deviation (dE): 0.26
Average delta: 0.29
Standard deviation (dE): 0.18
Average delta: 0.43
Standard deviation (dE): 0.24
Average delta: 0.38
Standard deviation (dE): 0.23
CS4 - InDesign CS4
(Document in AdobeRGB, placed untagged target at same size)
Average delta: 0.43
Standard deviation (dE): 0.24
CS4 - Qimage
Average delta: 0.35
Standard deviation (dE): 0.19
-
I have been following this thread with interest. Most of this discussion has been from Apple users. Is the ACPU working correctly in Windoze 7 64 bit? I have a new Epson 3880 and have not ordered custom profiles yet - waiting on this situation to resolve.
Thanks
Frank
-
Well I can’t say I necessarily agree here that a max dE of 1.4 is within measurement error or acceptable but I’m willing to listen otherwise.
I consider this acceptable for the purposes of assessing whether CS4, CS5, and ACPU are all producing the same results. This is because if I print the same page twice from the same app (i.e., 2 copies from the same app), I get the same measurement results. In other words, the difference between printing a target from CS4 (+workaround) and ACPU in my config is no greater than the difference between the target twice from CS4.
The high max DE2000 of 1.4 may be due to instrument repeatability or printer repeatibility.
-
What printer and driver? Its absolutely resizing on this end going to an Epson 3880, v6.60 on 10.6.5. Others have reported the sizing differences too but that doesn’t seem to negatively affect the ability to read the targets.
As I mentioned previously: 3880, v6.60, 10.6.4. In principle, the only difference between your setup & mine is the OS version (I'm on 10.6.4, and you're on 10.6.5). I doubt that's relevant.
The real distinction is likely the target and its resolution (in pixels/inch).
I was using Bill Atkinson's 1728 target in my test.
-
It is not the ColorSync button that is the problem, it is what the Main/Color Mode setting is. If it defaults to "No Color Correction" them no color management is performed by the driver/os. If it defaults to Color then color management is performed by the driver/os.
In ACPU, Main/Color Mode, its grayed out but the popup is set to Color. In CS5, its grayed out but set to No Color Correction. Odd. I haven’t do anything to the app’s or driver yet the two produce these two grayed out and different options.
-
Are you sure you don't have Printer Manages Color selected?
You just said it was grayed out in the post before.
Photoshop Manages Color its grayed out with ColorSync selected. Printer Manages Color its not grayed out but defaults to ColorSync. I’ve not done anything so far with Printer Manages Color.
-
Is the ACPU working correctly in Windoze 7 64 bit? I have a new Epson 3880 and have not ordered custom profiles yet - waiting on this situation to resolve.
See my comments in the thread above;
ACPU prints colour correctly in Windows 7 64bt from my tests here, but it resizes and repositions the target on the page which isn't very helpful.
If you only have CS5 to print from, ACPU should be acceptable to custom print profilers, it is to us now we've done the tests ;-)
Paul
www.colourprofiles.com
-
We tested Adobe Color Printer Urility not only versus "No Color Management" option in PSCS3 and "Null transform technique" in PSCS5, but also versus "Printer Manages Colors" option (color management in the print driver is also disabled) in PSCS3/PSCS5.
There are no color differences between all of them!
But ACPU v1.0 is the most uncomfortable on Windows platform.
Therefore some people prefer to use "Printer Manages Colors" option - It is included in all versions of Photoshop.
Printers tested: Canon Pro9500, Epson R2880, Epson 3800, Epson 11880.
Platform: Windows XP and Windows 7. Some tests (NCM vs PMC) were also done on Snow Leopard MacOS.
-
I consider this acceptable for the purposes of assessing whether CS4, CS5, and ACPU are all producing the same results. This is because if I print the same page twice from the same app (i.e., 2 copies from the same app), I get the same measurement results. In other words, the difference between printing a target from CS4 (+workaround) and ACPU in my config is no greater than the difference between the target twice from CS4.
Its greater for me but not by a large amount. Its odd that the differences show up in different locations within color space which is another reason I’m suspect. I guess we could say the various utilities are close enough but they are not as close as I’d have expected. That they use different print paths may make this easier to accept.
The real distinction is likely the target and its resolution (in pixels/inch).
Well in terms of resolution, it does appear that this affects the so called scaling of the target (really more the position of the image on the target). When you resample using Nearest Neighbor say 2X up or down, do you see a shift on the page (and a very small difference in scaling) as reported on the ColorSync list?
-
We tested Adobe Color Printer Urility not only versus "No Color Management" option in PSCS3 and "Null transform technique" in PSCS5...
When testing the Null transform technique did you use Adobe RGB (1998)? If you use sRGB instead, do you find a difference (higher delta’s in green)?
-
We used Adobe RGB.
-
OK so here are some numbers from measuring targets printed from PS CS4, ACPU, ID & Qimage on a Windows 7 64 bit system
Looking at the figures there is no significance colour difference between all four program's output(just ACPU resizing the targets). Any differences could be down to measurement and printer accuracy.
Ideally we’d be comparing apples to apples and you’d have used the larger TC918 target. Can you provide the max dE values from your tests?
-
We used Adobe RGB.
If you can, would you try sRGB on the Epson 38XX. If you get the same results as Chris and I, it would point to an issue that could resolve a number of issues.
-
Ideally we’d be comparing apples to apples and you’d have used the larger TC918 target.
Gee thanks, I spent quite a long time doing this. The 9.18 charts would have taken more than three times as long!
Easy with as iSis, but a lot of graft with an Eye1 measuring in strip mode.
Do you think the extra patches would make that much, any?, difference to the general conclusions ?
Can you provide the max dE values from your tests?
Max dE
1.77, 1.31, 1.53, 1.18
Worst 10%
1.08, 0.72, 0.91, 0.68
-
1.77, 1.31, 1.53, 1.18
Measurement accuracy, comparing two passes of same target;you got 1.77? Ouch. That’s the worst of the group.
Do you think the extra patches would make that much, any?, difference to the general conclusions ?
It could yes. Kind of depends on what colors used within each target is or is not being measured. It makes a difference in the Avg dE of course but I’m not looking as closely here as the max dE.
-
Andrew, I do see a shifting in placement (i.e., a translation, but not a scale). No idea why.
-
Andrew, I do see a shifting in placement (i.e., a translation, but not a scale). No idea why.
I think I know why but I would never want to piss off Dave (he’s a big guy, I’m not).
If the page (not scale) shifting is large enough, then we iSis users are screwed, the black triangles are cut off and the iSis barfs. I think a 1.01 version might be needed unless we are told what PPI setting for the targets we need to hit.
-
Measurement accuracy, comparing two passes of same target;you got 1.77? Ouch.
No that's the max dE between CS4 & ACPU targets
For measurement accuracy on the same targets;
max dE = 0.70, 0.94, 0.56, 0.83
Worst 10% = 0.37, 0.41, 0.31, 0.40
-
No that's the max dE between CS4 & ACPU targets
For measurement accuracy on the same targets;
max dE = 0.70, 0.94, 0.56, 0.83
Worst 10% = 0.37, 0.41, 0.31, 0.40
Ah OK, I saw the order of your original reports and this new order and figured they matched. So highest dE was CS4 vs. ACPU which is also what I found. What about the order of the other max dEs?
For max dE accuracy on same target, again that seems the most reasonable (and what I’d like to see from all apps more or less).
-
In ACPU, Main/Color Mode, its grayed out but the popup is set to Color. In CS5, its grayed out but set to No Color Correction. Odd. I haven’t do anything to the app’s or driver yet the two produce these two grayed out and different options.
I figured that is what would be happening. That is because CS5 is listed in the AppColorMatchingInfo.xml file and ACPU is not. Anytime the Main/Color Mode, setting is grayed out and the popup is set to Color you are getting a profile conversion with ACPU in the driver/os. Depending on what that profile is you may or may not notice it, so if you want to test this, use different media settings (especially ones that are listed in the ColorSync Utility the have a corresponding profile) and see if it changes the printed target noticeably.
Or you can avoid wasting any time on this and add the ACPU to Canon AppColorMatchingInfo.xml so that ACPU will be set to No Color Correction just like CS5 and you can be sure that the driver/os is not converting to a profile when printing from ACPU to the iPF6300.
-
So highest dE was CS4 vs. ACPU which is also what I found. What about the order of the other max dEs?
You're a hard task master Mr Rodney ;)
max dE between PS CS4 - Qimage is 1.00, for CS4 - ID CS4 is 1.14
Not sure if anyone would want to print profiling targets from InDesign anyway, this may be a bit of a distraction.
-
Anytime the Main/Color Mode, setting is grayed out and the popup is set to Color you are getting a profile conversion with ACPU in the driver/os. Depending on what that profile is you may or may not notice it, so if you want to test this, use different media settings (especially ones that are listed in the ColorSync Utility the have a corresponding profile) and see if it changes the printed target noticeably.
First, I’ll certainly try fixing this setting for APCU but I’m confused about the statement Depending on what that profile is you may or may not notice it. The target is untagged and I have no profile selection for ACPU so I’m confused. I’m also somewhat confused by the current behavior as CS5 and ACPU produce some of the best measurement correlation of all my tests so far:
CS5 vs. ACPU:
--------------------------------------------------
Average dE: 0.16
Max dE: 0.79
Min dE: 0.01
StdDev dE: 0.10
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.14
Max dE: 0.29
Min dE: 0.01
StdDev dE: 0.07
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.37
Max dE: 0.79
Min dE: 0.29
StdDev dE: 0.09
--------------------------------------------------
Very similar to the results on the Epson with good correlation of the two apps, low max dE. For reference, on the 3880, the dE was: Average dE: 0.19 Max dE: 0.72
-
Not sure if anyone would want to print profiling targets from InDesign anyway, this may be a bit of a distraction.
Well the point is, the various app’s should behave the same way (in a prefect world).
-
First, I’ll certainly try fixing this setting for APCU but I’m confused about the statement Depending on what that profile is you may or may not notice it. The target is untagged and I have no profile selection for ACPU so I’m confused. I’m also somewhat confused by the current behavior as CS5 and ACPU produce some of the best measurement correlation of all my tests so far:
Very similar to the results on the Epson with good correlation of the two apps, low max dE. For reference, on the 3880, the dE was: Average dE: 0.19 Max dE: 0.72
Go back and read my post #70.
If printing to your Epson is not double profiling with CS4, CS5 or LR, then I think your good to go. But from the Canon if the Color Mode is defaulted to Color then there is a profile conversion going on and I would not trust any target printed that way.
-
Well the point is, the various app’s should behave the same way (in a prefect world).
Yes, assuming they're doing the same things.
BUT PS CS4, ACPU & Qimage are all printing untagged documents, InDesign can't do this as it as the document has to have a defined colourspace (in my test AdobeRGB), so this might cause some issues through the path.
-
InDesign can't do this as it as the document has to have a defined colourspace (in my test AdobeRGB), so this might cause some issues through the path.
You are dead wrong. Selecting under Edit/Color Settings "Emulate Indesign 2.0 CMS Off" turns off color management in InDesign.
-
You are dead wrong. Selecting under Edit/Color Settings "Emulate Indesign 2.0 CMS Off" turns off color management in InDesign.
Ah right, that's well buried and unintuitive then.
Huff, another thing to measure tomorrow then.
I still don't see why anyone would try printing targets from InDesign though.
-
Ah right, that's well buried and unintuitive then.
I still don't see why anyone would try printing targets from InDesign though.
On the Mac since ID uses the old printing path it has been a lifesaver for printing targets when all you had were drivers that were not written properly for Apple's new printing path. And by the way 90% of what I print is from ID, so it just makes more sense to print profile targets through the same path.
-
On the Mac since ID uses the old printing path it has been a lifesaver for printing targets when all you had were drivers that were not written properly for Apple's new printing path.
Don't you just love that whole Mac experience ;-)
and yes I do own a Mac too.
And by the way 90% of what I print is from ID, so it just makes more sense to print profile targets through the same path.
In nearly eight years of running a profiling business and thousands of targets, not one set has been printed through ID here. You usage is very exceptional.
-
On the Mac since ID uses the old printing path it has been a lifesaver for printing targets when all you had were drivers that were not written properly for Apple's new printing path. And by the way 90% of what I print is from ID, so it just makes more sense to print profile targets through the same path.
The bottom line here is that I kind of expect that ID, CS, etc at the very least, all Adobe app’s would print the same (don’t they under Windows)? This isn’t about blaming either Apple or Adobe although I suspect the differences in the print paths is more due to Apple. And maybe this is why I’m seeing high max dE’s on the targets differ from app to app. I know its hardly a prefect color managed world, but I’d sure like to know what app I should use to print a target and more importantly, if I use that profile in 5 app’s, they all behave the same.
-
Don't you just love that whole Mac experience ;-)
and yes I do own a Mac too.In nearly eight years of running a profiling business and thousands of targets, not one set has been printed through ID here. You usage is very exceptional.
If it is a artwork or a photo that benefits from 16-bit printing then I will usually use the Canon plugin, or I will print a whole sheets of proofs from a Photoshoot using LR. But the majority of my printing is banners, posters, signage, brochure, flyers, etc. which goes to one of the driver driven aqueous inkjets, or RIP driven, solvent, UV-curable, digital printer/copiers, or offset press. The repeatable printing of photos in various sizes and media is just some much easier to do from ID where all sizes, gangs, print setting etc. can be saved with out take the huge amount of space printing from PS or the time to reset these.
Enough of that though, now lets get back to the main subject of this thread.
-
Don't you just love that whole Mac experience ;-)
and yes I do own a Mac too.In nearly eight years of running a profiling business and thousands of targets, not one set has been printed through ID here. You usage is very exceptional.
Well, add me to the exceptional group that is now printing from ID. Photoshop used to be the one bulletproof app I could print from and get CM to work right on all my computers. Since I mainly print for myself, I didn't need the file nesting capabilities of a more advanced RIP. I had always assumed PS worked right because the PS software team had successfully "hijacked" the CMM and print path away from OS's that didn't seem to handle ICC profiles correctly. But things started to get very strange when Apple introduced OS10.6 and it's "New" print path. Since I have both older and newer Macs (not all able to run 10.6) and older and newer printers (some with updated drivers and some at the end of the road in terms of vendor's support), I'm now finding I can't build compatible ICC profiles to print to the same printer/ink/paper combination from more than one computer in my studio. That's unacceptable, and ID was the only way I could find as a work around to get me back to a shared set of ICC profiles. But my tests that showed PSCS5 printing problems were run last summer, so it's time for me to revisit the issue as at least one update has now occurred to OS10.6.
Bottom line is that at the very least, the null transform method of target printing should produce matching prints from any app! If it doesn't then the profile build will be app specific. I'm encouraged by what everyone is reporting in the tests that are being run here. Maybe it's not a complete mess, but pretty pathetic that we even have to be doing this intensive cross-application testing at this point in time.
-
But things started to get very strange when Apple introduced OS10.6 and it's "New" print path. Since I have both older and newer Macs (not all able to run 10.6) and older and newer printers (some with updated drivers and some at the end of the road in terms of vendor's support),
Apple taking the controls away from the printer driver when applications manages color is chosen always seemed like they were trying to idiot proof it to me.
I wonder what they are going to do when they start making better idiots.
We had to learn to choose the right settings years ago, what is so hard about that?
-
OK so here are some numbers from measuring targets printed from PS CS4, ACPU, ID & Qimage on a Windows 7 64 bit system
CS4 - InDesign CS4
(Document in AdobeRGB, placed untagged target at same size)
Average delta: 0.43
Standard deviation (dE): 0.24
CS4 - Qimage
Average delta: 0.35
Standard deviation (dE): 0.19
Thank you, that's what covers my workflow if I need to make profiles outside the HP Z printers.
met vriendelijke groeten, Ernst Dinkla
New: Spectral plots of +175 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
-
Thank you, that's what covers my workflow
Just to add to that, at Mr Rodney's request I've now reprinted with an untagged ID document (Now Doyle has shown the way to achieve it)
I'm seeing
CS4 - ID untagged document
average dE 0.47
standard deviation 0.27
Max dE 1.42
Worst 10% 1.04
-
When I measure the TC918 from ACPU (two printed in a row and wet) I get a max dE of 0.70.
Here’s the full report as of today (plenty of time for dry down):
Overall - (930 colors)
--------------------------------------------------
Average dE: 0.20
Max dE: 0.72
Min dE: 0.01
StdDev dE: 0.11
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.17
Max dE: 0.34
Min dE: 0.01
StdDev dE: 0.08
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.42
Max dE: 0.72
Min dE: 0.34
StdDev dE: 0.08
--------------------------------------------------
-
Help! Interesting discussion and thanks to everyone for all the effort but with six pages of posts and lots of numbers, I'm lost!
Could someone summarize this please?
Which of these agree: ID, PSCS4, PSCS5, ACPU?
And, do they agree with printing targets straight from calibration software? I gave up on the whole mess when I couldn't get the PSCS5 workaround to give consistent results on a Mac and resorted to printing targets from Eye-One Match 3.6.3, which worked wonderfully.
Thanks.
-
FWIW, one of my colleagues ran ACPU under 10.6.5 on Epson Premium Luster 260 from an Epson Stylus Pro 9900 using our Barbieri SpectroLFP and compared it in ColorThink to the Epson canned profile. It was uniformly larger in gamut then the canned profile and print results were excellent. We haven't been able to achieve such results even using the null target method (although they weren't bad).
I'd like to reproduce the tests that you've all been doing, but I doubt we're going to have the time. If that changes, I'll post some numbers.
So far, though, we've also not had any problem with output size/scaling issues - so I'm not sure exactly what problem Andrew (and others?) is seeing there.
-
I was thinking today about the issue with setting No Color Management in the CS4 print dialog with drivers that were not properly written for 10.5 and 10.6 and did not turn off CM.
Has anyone testing the ACPU with these same drivers and find that CM is not being turned off? Canon of course with it special casing file if listing ACPU would not apply here, but what about the Epson and HP drivers?
-
So far, though, we've also not had any problem with output size/scaling issues - so I'm not sure exactly what problem Andrew (and others?) is seeing there.
Actually I had no problems with “scaling“ when I used the TC918 and similar targets using the resolution native of those targets. But I read on the ColorSync list that “Scaling” issues manifested depending on the resolution (see the post below from David Tobie I pasted #67). I sized the TC918 from 40 pixels per centimeter to 120 PPC using nearest neighbor and the target shifted position on the page (so its not scaling I saw but a severe reposition of the data on the page).
-
Just to add to that, at Mr Rodney's request I've now reprinted with an untagged ID document (Now Doyle has shown the way to achieve it)
I'm seeing
CS4 - ID untagged document
average dE 0.47
standard deviation 0.27
Max dE 1.42
Worst 10% 1.04
Max dE of 1.43, high IMHO (a bit higher than I got).
ID5 vs. CS4 on my end (didn’t provide that in the matrix):
Delta-E Formula dE2000
Overall - (930 colors)
--------------------------------------------------
Average dE: 0.27
Max dE: 1.11
Min dE: 0.03
StdDev dE: 0.16
Best 90% - (836 colors)
--------------------------------------------------
Average dE: 0.23
Max dE: 0.47
Min dE: 0.03
StdDev dE: 0.10
Worst 10% - (94 colors)
--------------------------------------------------
Average dE: 0.63
Max dE: 1.11
Min dE: 0.47
StdDev dE: 0.14
--------------------------------------------------
So yes, we are both getting higher max dE values than I’d like and using either CS5 or CS4, compared to ID5.
-
Just a reminder that the results I've posted are for InDesign CS4 not 5
-
I am using Win7, PS CS1 (!) and trial mode CS5. The reason I haven't upgraded PS in ages is because I mainly use Lr2.x and now LR3.x, but I need PS to do digital negatives.
As I am using Win7, at least I do not suffer from the Snow Leopard / Epson issues.
However, I did print a digital negative calibration chart out on the same sheet of film and so they are processed the same way:
- ACPU
- CS5, with Adobe RGB ->Adobe RGB null transform
- CS1, print with "Same as Source" and "Application Manages Colors" (no color management)
This is on a HP Z3100. I scan results with an Epson Expression 1000XL so it's not as accurate as a densitometer. However, the results are clear:
- ACPU scales the output. This is consistent for letter size and my pano size of 8.5x22". May be it is a bad interaction with HP driver. I do not know, but the behavior is again consistent.
- CS5 with null transform and CS1 with no color management produces output that are virtually the same. Any measurable differences are probably due to the digital negative->contact print->scan workflow.
- ACPU output is VASTLY different from the other two.
My conclusion is that ACPU is a piece of junk. In addition to who knows what it's printing, it:
- has a lousy UI
- scales your images
- doesn't even have the courtesy to remember the last folder
- open TIFF only
Someone is asleep at the wheel in Adobe.
// richard
-
Why would you want it to open anything other than TIFF?
-
You mean like PSD may be? :-)
-
Why would you want it to open anything other than TIFF?
Probably because you don't fully understand what this utility is for.
Besides the resizing and UI issues. Adobe's final mistake has been to give the utility an unhelpfully general name that is going to cause some confusion as to it's usage. Already there is someone on their forums complaining he can't print his 4x6 aircraft pictures properly with it. <sigh>
-
Sure Sir, you are the genius :-)
I will leave this post for you to enjoy. I have better things to do than arguing on the internet.
-
Frankly, with the exception of the translation issues some are seeing (which can lead to critical parts of the target to get cutoff during the printing process), the rest of the stated concerns are non-issues. The tech note and accompanying ReadMe document clearly explain that the purpose of the software is to print targets without color management. Many profile targets (e.g., Bill Atkinson's excellent targets) are available in TIFF format, and existing PSD files can easily be converted to TIFF format.
-
Probably because you don't fully understand what this utility is for.
Besides the resizing and UI issues. Adobe's final mistake has been to give the utility an unhelpfully general name that is going to cause some confusion as to it's usage. Already there is someone on their forums complaining he can't print his 4x6 aircraft pictures properly with it. <sigh>
Yup, no good deed goes unpunished. Yes there is a shifting bug but its not a big deal and anyone who would be using the utility for its stated purpose would unlikely find this an issue (or figure out how to fix it). I’ve never, ever seen a target for a profile in PSD format and as Eric says, it can be converted to TIFF. I wish the size were sticky but heck, I don’t really need to see the target, just hit print and be done. And I’ll say this again, the companies that should have built this software isn’t Adobe but those companies that need their targets printed for their creation of a paper profile.
The only other time I could see the need is if you ganged up multiple images in differing output color space onto one canvas to test say a rendering intent or profile setting (after which you’d use No Color Management in Print). I suspect few do this.
-
The only other time I could see the need is if you ganged up multiple images in differing output color space onto one canvas to test say a rendering intent or profile setting (after which you’d use No Color Management in Print). I suspect few do this.
In case you really need that:
In Qimage you can nest the images on the same print page and apply different renderings and/or profiles to each image and print the total with CM-On. Or print them to file as a Tiff and load that Tiff in an application that can print with CM-Off like ACPU seems to do. Qimage can do the last too. Of course Qimage has LCMS as its color engine.
met vriendelijke groeten, Ernst Dinkla
New: Spectral plots of +180 inkjet papers:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
-
In case you really need that:
I need it to run OS X too...
-
You can't have it all.
met vriendelijke groeten, Ernst Dinkla
Try: http://groups.yahoo.com/group/Wide_Inkjet_Printers/
-
I think didjiman should definitely ask for his money back. Or maybe even double his money. ;)
-
You guys are funny and incredible.
Of course I know how to save TIFF from PSD.
The reasons I am using PSD is because I am printing digital negatives, not just profiles. Sure, I can save the results in the end as TIFF, but only it it is for a good reason and ACPU is not a good reason.
I am a software writer. I own my software company. I write C compilers for a living since 1984.
If I release a piece software as crappy as ACPU, I wouldn't be in business.
I just spent $80 on Qimage. Problems solved.
-
To be clear ...
ACPU was not designed to print digital negatives.
ACPU was not designed to open PSD, PSB, PNG, BMP, JPEG, or any other format besides TIFF.
ACPU was not designed to be pretty.
ACPU was not designed to make Adobe money or to keep anybody in business (it is free software).
Instead ...
ACPU was designed to be a free utility to print TIFF profile targets without color management, for the purposes of building (custom) printer profiles. To the best of my knowledge, with the exception of the translation issues some are reporting, it accomplishes this task.
-
ACPU was designed to be a free utility to print TIFF profile targets without color management, for the purposes of building (custom) printer profiles. To the best of my knowledge, with the exception of the translation issues some are reporting, it accomplishes this task.
As long a the printer driver are properly written and correctly turn off CM in the driver. We know that Adode Color Printing Utility must be listed in the Canon iPF drivers special casing file to turn off CM in the driver. But I will ask again, with Epson drivers that did/do not turn off CM when No Color Management is chosen in CS4, does ACPU change this with these same drivers or is CM being applied with these drivers?
-
Eric, thanks for your summary. I think this thread has shown that, with possible exception of some subtle scaling issues, the utility appears to work as designed to do. As Doyle has noted, turning off CM in the printer driver successfully may still be an issue in some instances, but I was able to implement his recommended patch to Canon's special casing AppColorMatchingInfo.xml file and it works as it's supposed to in my case.
All that said, there still seems to be a serious CM problem when actually trying to use a properly built profile, at least for some of us PSCS5/OS10.6 users. Because there is more than one method of invoking CM even for a single Adobe app, like target printing, we should be seeing matching print output from anyone of these chosen paths, but I'm not getting that result, at least not for my Canon 8100. For that printer, I appear to have three pathways available (not including the 16 bit plugin pathway). I can 1) let Photoshop manage color and select profile and rendering intent on the preview page making sure CM in driver is off, 2) choose printer manages color and use colorsync, or 3) choose printer manages color and select "vendor matching" in the canon driver. Bottom line: I can't make any of these paths work right when using PSCS5. I spent a few hours trying again last night and found once again that I have to drop back to printing from ID to get output that matches the PS or ID softproof view with reasonable accuracy. The ugly printed output I'm seeing from PSCS5 is not due to double profiling. Rather, the output looks like the source tag is being ignored. In my testing the image was tagged with prophotoRGB but the output looks something like what you'd see if you stupidly reassigned an sRGB or monitor profile to the image and then convert to the destination profile.
I'm going to compare "printer manages color" to "photoshop manages color" on an Epson 3880 today. Perhaps my problem is an isolated canon driver issue.
-
I'm going to compare "printer manages color" to "photoshop manages color" on an Epson 3880 today. Perhaps my problem is an isolated canon driver issue.
Ok, so I just ran some printer output tests with an Epson 3880. The good news for the 3880 driver is that PSCS5 "Photoshop manages colors" matches Indesign CS5 output now which is a result I couldn't achieve with the current Canon iPF8100 driver. The bad news is that "Printer manages color" is broken just like the Canon driver. Output looked like the source file's prophoto embedded tag was ignored in favor of an sRGB or monitor profile.
Based on this result, I'm inclined to agree with Doyle Yoder. A lot of Mac Snow leopard's new CM workflow issues seem to stem from incomplete or incorrect handling of Apple's new API by the printer driver. Adobe apps may just be getting caught in the crossfire. Because some Adobe apps still "hijack" parts of the printer output workflow away from a colorsync/printer driver workflow when one chooses "let Photoshop manage color" or "let Indesign manage color" (ironically, there aren't any other options in ID as far as I can tell) we get a lot of convoluted results, but the problems may very well stem from the printer driver side of things.
cheers,
Mark
http://www.aardenburg-imaging.com
-
Ok, so I just ran some printer output tests with an Epson 3880. The good news for the 3880 driver is that PSCS5 "Photoshop manages colors" matches Indesign CS5 output now which is a result I couldn't achieve with the current Canon iPF8100 driver.
What did you get for max dE? With that test, I got an average of 0.33 but a max of 1.08. Seems high (higher than I got with other combo’s).
You used Photoshop Manages Color with Adobe RGB (1998) defined as the source>destination? Seems that works but not so well with sRGB.
-
What did you get for max dE? With that test, I got an average of 0.33 but a max of 1.08. Seems high (higher than I got with other combo’s).
You used Photoshop Manages Color with Adobe RGB (1998) defined as the source>destination? Seems that works but not so well with sRGB.
Andrew, I'm running a real pictorial image test using a profile built from a "vetted profiling-target-making path" that we've been discussing all along in this thread. The problem now (perhaps it deserves a a new thread) is that the output from the profile varies dramatically with the CM workflow path I choose. In other words, use the same profile but try to print from different apps or different workflow choices within an app, and you get different results. You don't need to measure the output, just look at it visually compared to softproof. When it misses, it misses by a mile!
So, for example, with my Canon 8100 I can't make PS and ID CS5 match no matter what I do, but ID output matches softproof visually whereas PS output looks like the embedded source file tag got ignored. In contrast, on my 3880 I was able to invoke a "let Photoshop manage colors"/NCA driver workflow that matched ID output, but switching to a "let printer manage colors"/colorsync workflow produced junk that matched the canon driver problem. In a "let printer manage color" workflow under snow leopard, it looks like the embedded image file's tag (in my case it was prophoto) is being ignored in favor of an sRGB profile or the display profile (something similar to sRGB). Not good.
Why should I care about a "let printer manage colors" workflow if the "let Adobe app manage colors" works? Well, because it is the workflow that just about every other non adobe app I own requires!!!. I should be able to print from them with matching output when printing the same image using the same ICC profile and printer/ink/paper combo.
-
Ok, so I just ran some printer output tests with an Epson 3880. The good news for the 3880 driver is that PSCS5 "Photoshop manages colors" matches Indesign CS5 output now which is a result I couldn't achieve with the current Canon iPF8100 driver. The bad news is that "Printer manages color" is broken just like the Canon driver. Output looked like the source file's prophoto embedded tag was ignored in favor of an sRGB or monitor profile.
http://www.aardenburg-imaging.com
I do not think that the Canon driver understands what to do with Prophoto RGB when selecting "Printer Manages Color". Try sRGB or Adobe RGB once.
But really using PSCS5 "Photoshop manages colors" is the way to go. It works great. We just need to figure out why it is not working for you. When you choose PSCS5 "Photoshop manages colors" does the Main/Color dialog default to (grayed out) "No Color Correction"?
-
I do not think that the Canon driver understands what to do with Prophoto RGB when selecting "Printer Manages Color". Try sRGB or Adobe RGB once.
Well, if it doesn't use the image file's embedded prophoto tag and make a conversion from source to destination, then what is it assuming for source...sRGB?. That's a serious bug.
But really using PSCS5 "Photoshop manages colors" is the way to go. It works great. We just need to figure out why it is not working for you. When you choose PSCS5 "Photoshop manages colors" does the Main/Color dialog default to (grayed out) "No Color Correction"?
Yes, I successfully implemented the update to the special casing file as per your recommendations. It works like you said it would. Double profiling doesn't seem to be my problem. I think the problem is due to the source file being in prophoto RGB. I will try running an sRGB tagged image, but if that works, it merely proves the point that the Canon driver for x100 series printers is broken (admittedly, Canon has made Snow leopard updates to the x300 series but not the x100 series so far). One would have to convert all images to sRGB, and that won't sit well with anyone shooting RAW and using extended color gamut working spaces like aRGB or prophoto.
-
Yes, I successfully implemented the update to the special casing file as per your recommendations. It works like you said it would. Double profiling doesn't seem to be my problem. I think the problem is due to the source file being in prophoto RGB. I will try running an sRGB tagged image, but if that works, it merely proves the point that the Canon driver for x100 series printers is broken (admittedly, Canon has made Snow leopard updates to the x300 series but not the x100 series so far). One would have to convert all images to sRGB, and that won't sit well with anyone shooting RAW and using extended color gamut working spaces like aRGB or prophoto.
I print from CS5 "Photoshop manages colors" using the driver for the Canon iPF9000 with the image tagged as ProPhoto RGB all the time. Prints always match the plugin or ID. I am assuming that your using the 2.13 driver, but I can't see that is is broken as I have never heard of this issue unless Main/Color Mode in the driver default to "Color" instead of "No Color Correction" If you go to the Main/Color Mode/Set dialog of the driver are there any adjustments set in there? Does this happen with any printer/paper profile you choose?
Being that the x100 drivers are the oldest of the 2.x drivers I would try installing one of the x300 drivers (but not adding it) to see if that will make any difference. When I installed the 8300 driver to see if it made any difference with the scrum dot problem, it did not replace the AppColorMatchingInfo.xml special casing file so I would not worry about that.
-
I print from CS5 "Photoshop manages colors" using the driver for the Canon iPF9000 with the image tagged as ProPhoto RGB all the time. Prints always match the plugin or ID. I am assuming that your using the 2.13 driver, but I can't see that is is broken as I have never heard of this issue unless Main/Color Mode in the driver default to "Color" instead of "No Color Correction" If you go to the Main/Color Mode/Set dialog of the driver are there any adjustments set in there? Does this happen with any printer/paper profile you choose?
Ok, so I converted my test image to sRGB (this image was originally tagged in prophoto, but the scene colors were all in sRGB gamut range, so no color translation appeared on screen when I converted). I also reinstalled the latest Canon 2.14 driver for my ipf8100 to make sure no corruption was present with the driver. Result: no difference at all. When printing from "photoshop manages colors" out of CS5, the colors are dull and don't match softproof at all. Yet I can print from CS3 or from ID CS5 with excellent results and softprrof match when using this custom printer/ink/paper profile. Based on these results, I now suspect that my problem is not caused by a failure to honor the embedded image profile tag. More likely it's a failure to invoke the chosen ICC profile for the destination space. Some other "default" profile may be getting used in in it's place. Very strange, and very time consuming to try to figure out what the problem is:
All I can say is that teaching students how to implement an ICC profile workflow is hard enough without having to throw in all of the software/firmware bugs that cause CM workflows to fail on real systems and on a daily basis in more ways than I can count.
-
Ok, so I converted my test image to sRGB (this image was originally tagged in prophoto, but the scene colors were all in sRGB gamut range, so no color translation appeared on screen when I converted). I also reinstalled the latest Canon 2.14 driver for my ipf8100 to make sure no corruption was present with the driver. Result: no difference at all. When printing from "photoshop manages colors" out of CS5, the colors are dull and don't match softproof at all. Yet I can print from CS3 or from ID CS5 with excellent results and softprrof match when using this custom printer/ink/paper profile. Based on these results, I now suspect that my problem is not caused by a failure to honor the embedded image profile tag. More likely it's a failure to invoke the chosen ICC profile for the destination space. Some other "default" profile may be getting used in in it's place. Very strange, and very time consuming to try to figure out what the problem is:
I have to think on this, but is there any chance you might have Proof checked instead of Document in the CS5 print dialog?
-
I have to think on this, but is there any chance you might have Proof checked instead of Document in the CS5 print dialog?
No, the PS print preview window shows that I'm set on document not proof.
-
MHMG, do you by any chance have another Canon model (something besides the iPF8100) to try this on?
I am trying to figure out if this is something specific to the 8100 (specifically, its driver), or in your settings.
-
MHMG, do you by any chance have another Canon model (something besides the iPF8100) to try this on?
I am trying to figure out if this is something specific to the 8100 (specifically, its driver), or in your settings.
Hi Eric, I have a Canon iPF5000 as well. I will give it a go. However, part of the problem is showing up on my Epson 3880 as well. Try printing an image with a colorsync workflow on your 3880 (say for example, printing an aRGB or prophoto tagged image from Word 2011 or Pages.) They are color managed applications, AFAIK, so for example, a prophoto tagged image displays correctly in these apps. We should get a reasonable match to what we can print from Photoshop/MacOS10.6 using printer manages colors/colorsync workflow which in turn should reasonably match a photoshop manages colors workflow. I haven't been able to achieve that result. Granted, these other apps may be irrelevant for LULA readers, but they may provide you with a clue on what part of the Apple Snow leopard/printer driver CM chain is misbehaving and why PS seems to be getting caught in the crossfire.
-
Hi Eric, I have a Canon iPF5000 as well. I will give it a go. However, part of the problem is showing up on my Epson 3880 as well. Try printing an image with a colorsync workflow on your 3880 (say for example, printing an aRGB or prophoto tagged image from Word 2011 or Pages.) They are color managed applications, AFAIK, so for example, a prophoto tagged image displays correctly in these apps. We should get a reasonable match to what we can print from Photoshop/MacOS10.6 using printer manages colors/colorsync workflow which in turn should reasonably match a photoshop manages colors workflow. I haven't been able to achieve that result. Granted, these other apps may be irrelevant for LULA readers, but they may provide you with a clue on what part of the Apple Snow leopard/printer driver CM chain is misbehaving and why PS seems to be getting caught in the crossfire.
I am pretty sure your problem with CS5 "Photoshop manages colors" is not specific to the driver (if Main/Color Mode is grayout and defaults to "Color" then yes it is), CS5 or 10.6.5 but specific to your computer. Let us know what you find with your iPF5000.
-
I am pretty sure your problem with CS5 "Photoshop manages colors" is not specific to the driver (if Main/Color Mode is grayout and defaults to "Color" then yes it is), CS5 or 10.6.5 but specific to your computer. Let us know what you find with your iPF5000.
Hi Doyle, Eric, et al.,
Ok, so today I ran the same CS5/OS10.6 "photoshop manages colors" trial on my iPF5000, Epson 3880, and iPF8100. Conclusion. I get color managed output (print matches PS softproof) with the ipf5000 and the Ep3880, but 8100 is no good. As I noted previously, no color adjust is set correctly, but the printed result looks like either the source profile or the printer profile is being switched with something like an sRGB profile which causes the whole print to look dull. Yet I get good output from ID to the 8100 using ID's "let Indesign manage colors" workflow, so there's also something specific to PSCS5 or old versus new Apple API's going on here.
Hence, I have to conclude mainly that I have an 8100 driver bug, but one that only seems to waken when printing from PSCS5. ID is thus my workaround until I can figure something else out or Canon updates the driver (like Canon just did for the x300 series printers). Weird that the even older x000 series printers don't have the same problem.
Thanks Eric for the suggestion to my other Canon. I probably would have gotten there eventually, but there are so many possible combinations of print settings to try that it could have taken me days!
-
Is the 8100 listed in the ColorSync Utility? Similar to the 5000? If you click on the line that lists sRGB are they both the same or are they different? If different, are both profiles available to the OS as in Library/Colorsync/Profiles?
The other sRGB default profile that Canon uses is CNZSRGBC.icc with an internal file name of sRGB v3.0 (Canon). You may have deleted this file.
-
Is the 8100 listed in the ColorSync Utility? Similar to the 5000? If you click on the line that lists sRGB are they both the same or are they different? If different, are both profiles available to the OS as in Library/Colorsync/Profiles?
The other sRGB default profile that Canon uses is CNZSRGBC.icc with an internal file name of sRGB v3.0 (Canon). You may have deleted this file.
Both the ipF5000 and the iPF8100 are listed in the ColorSync Utility. The 5000 lists sRGB v1.2(canon) with profile internal name and filename the same. the 8100 lists sRGB v3.0 (canon) but with filename CNZSRGBC.icc. Both profiles are located in same Library/Colorsync/Profiles path.
Not to muddy the waters anymore than they already are, but while I was printing to my three printers for the "PS manages colors" tests, I also tried printing the same image (saved to PDF with prophoto embedded tag) from Acrobat Pro 9.0 using "Acrobat manages colors". I was curious to see if it would behave like ID or PS or neither. For all three printers, it behaved like neither ID nor PS. It produced a weird hypersaturated image from all three printers. Are CM workflows a mess in Snow Leopard or what?
I then tried printing with "Printer manages colors" from Pages, IDCS5, PSCS5, and Adobe Reader. Got consistent output from all except the 8100 using PS. That path is also whacked. But the overall consistency I saw using Snow Leopard's colorsync printing path is not particularly useful because it doesn't match output from PS managed color. While it looks like plausibly color managed output it is sufficiently different enough to make Adobe apps that have softproof capability not very predictive. In other words, for us Snow Leopard users we seem to be down to using PS or ID manages colors if we want to work in an effective softproofing environment, and even there it seems like the Adobe apps aren't always playing nice with the printer drivers for whatever reasons.
-
Both the ipF5000 and the iPF8100 are listed in the ColorSync Utility. The 5000 lists sRGB v1.2(canon) with profile internal name and filename the same. the 8100 lists sRGB v3.0 (canon) but with filename CNZSRGBC.icc. Both profiles are located in same Library/Colorsync/Profiles path.
For the 8100 in the ColorSync Utility, are all profiles listed in the CU also in the Library/Colorsync/Profiles folder?
I couple things you could try. Change the default sRGB profile for the 8100 to the sRGB v1.2(canon) or change the 5000 to sRGB v3.0 (canon) to see if either one makes any difference. If you have the Onyx utility delete the CUPS and ColorSync caches. It would not hurt at all to delete all caches while your at it. If it was me I would remove the 8100 for Printer & Fax and then add the 8100 back in. If that does not fix it I would remove both Canon printers and run the uninstall for each. Then install the 5000 and then the 8100 drivers. If you don't want to reupdate your media listings save the cip files (in Library/Printers/Canon/GARO/Frameworks) for each printer and copy them back in after you reinstall the drivers.
-
For the 8100 in the ColorSync Utility, are all profiles listed in the CU also in the Library/Colorsync/Profiles folder?
I couple things you could try. Change the default sRGB profile for the 8100 to the sRGB v1.2(canon) or change the 5000 to sRGB v3.0 (canon) to see if either one makes any difference. If you have the Onyx utility delete the CUPS and ColorSync caches. It would not hurt at all to delete all caches while your at it. If it was me I would remove the 8100 for Printer & Fax and then add the 8100 back in. If that does not fix it I would remove both Canon printers and run the uninstall for each. Then install the 5000 and then the 8100 drivers. If you don't want to reupdate your media listings save the cip files (in Library/Printers/Canon/GARO/Frameworks) for each printer and copy them back in after you reinstall the drivers.
Doyle, thanks. My son comes home from Penn State in a few days. I will install the 8100 driver on his Snow Leopard laptop and see if a clean install fixes the problem. If it does, I will then go the whole uninstall route on my machine. It may be a specific computer/driver issue, but I've seen so much weirdness these last few days with CM in general with Snow leopard that I'm inclined to believe the problems are widespread.
cheers,
Mark