Actually, I don't think this is true...ColorSync in Leopard (and SL) is ALWAYS engaged regardless of the app/driver settings...your results only apply in the case where the paper you are making a target for has both an Epson media settings _AND_ and installed ICC profile for the paper. Even the No Color Management settings in the driver calls ColorSync and the media settings dictates the "default" profile for ColorSync. Which can STILL cause "issues" if you are trying to profile 3rd party papers...

You are misinformed there. When "Printer Manages Color" is selected you have full control of all driver settings (at least that is how it is supposed to work) so the user can decide if they want to use ColorSync, or Epson Color Color Control which will allow the user to set "No color management" in the driver.

Actually, I don't think this is true...ColorSync in Leopard (and SL) is ALWAYS engaged regardless of the app/driver settings...your results only apply in the case where the paper you are making a target for has both an Epson media settings _AND_ and installed ICC profile for the paper. Even the No Color Management settings in the driver calls ColorSync and the media settings dictates the "default" profile for ColorSync. Which can STILL cause "issues" if you are trying to profile 3rd party papers...

My understanding of the process is limited. But, the bottom line is that I am able to print targets on 3rd party papers that result in very good screen matches using the method I suggested. I just tried the suggestion of printing from Preview 5 and that seems to work too. The target is a little to big but the colors match the references prints. I suspect the resulting profile would be a good screen match as well. It's difficult to pinpoint the root cause of the problem with so many variables. I'm just glad I can make a good profile again.

I hope Apple resolves this issue so developers can fix their stuff. It looks like ColorMunki is dead in the water at this time as there are no reasonable workarounds.

I hope Apple resolves this issue so developers can fix their stuff. It looks like ColorMunki is dead in the water at this time as there are no reasonable workarounds.

Don

Why the continuing misinformation? It serves no useful purpose unless giving an excuse to the developers that cannot get their coding correct. And, what about all the developers who do get their coding correct? What do you expect them to do if Apple changes thing for the few who can't.

And here is what I found out on Colormunki with drivers that work correctly.

"Just for the heck of it I installed ColormunkiPhoto_1-1-1 software in 10.6.2. While I cannot activate ColorMunki Photo I can run Photo ColorPicker. In the print dialog from Photo ColorPicker I can choose Vendor Matching under Color matching and No Correction under Main. This would leave to believe that it is the printer drivers or PEBCAK.

I suppose that there could be a chance that ColorMunki Photo is coded different then Photo ColorPicker and forces the driver to No CM and the driver is not responding correctly."

That is exactly how it is supposed to work when "Printer Manages Color" is selected, you should have all controls available to you in the driver. Where Epson has messed up is when the "No Color Management" call is given from PS the driver should react the same way as when the "PS Manages Color" call is given. Defaults to ColorSync in Color Matching and then turns off CM in the driver.

Doyle

Doyle,

I'm sorry, but even though I have a PhD and have written color code myself, I simply am not able anymore to understand these descriptions of what's going on to a point where I feel I can print with confidence. And at this point I suspect that there is not a single color-geek apart from you who has confidence in Snow Leopard's printing system.

We need some method for normal humans to use the color management functionality with Epson printers. Maybe an effective short-term solution would be for some kindly RIP manufacturer to donate limited-time licenses for a replacement print system that is known to have solid color management policies?

I'm sorry, but even though I have a PhD and have written color code myself, I simply am not able anymore to understand these descriptions of what's going on to a point where I feel I can print with confidence. And at this point I suspect that there is not a single color-geek apart from you who has confidence in Snow Leopard's printing system.

We need some method for normal humans to use the color management functionality with Epson printers. Maybe an effective short-term solution would be for some kindly RIP manufacturer to donate limited-time licenses for a replacement print system that is known to have solid color management policies?

Edmund

I am sorry that you and others have chosen software and printer vendors that can not get there act together. I don't particularly like that path (idiot proofing) that Apple has chosen for their new printing path. But it is what it is and the developers will just have to conform.

When LR came along and had to use this new printing path we discovered what was happening and had no option but to use the ColorSync Utility Workaround to get around the double profiling. I was in contact with Canon technical people about this issue as well as other issues. Being that they were willing to listen and bring this issue up in their meetings these things got fixed very early and we no longer were seeing the double profiling with drivers that were updated in the fall of 2008. I wish I could have had that kind of access with Apple even though I fired many many messages off to them over the Indesign and the monitor profile issue being introduced into the RGB printflow. Apparently they have finally fixed this in 10.6.2.

I have also fired off messages to Apple about idiot proofing the new printing path apparently to no avail. It has caused nothing but trouble when software has not been coded incorrectly for this new path and has forced ColorSync and a profile conversion in the driver instead of No Color Management. I have seen firsthand that it can be coded correctly and work correctly, and that is why I get so irritated at those who constantly blame Apple for this. What do you expect developers to do if Apple keeps changing things just so somebody's bad coding will work right.

Maybe an effective short-term solution would be to find out what software, printer drivers etc. work correctly with SL and use them. This would put the most pressure on those that don't want to conform since they generally are the ones that are not very approachable about correct their problems. As for Adobe we will see if the LR3 FR has the same bad print coding as the LR3 beta. I saw the same thing happen with LR2.3RC. I know none of them are immune from making mistakes but they need to be called on it , especially after making the same mistake over again.

As for printing unmanaged targets for profiling, any application that still use the old printing path should allow turning off CM in the printer drivers that do not conform to the new printing path. But IDCS3 & 4 before 10.6.2 will have the monitor profile applied in the RGB printflow unless you choose "Print as Bitmap" under advanced in the ID print dialog. And, of course the application will have to have the option of turning off CM.Doyle

At this point no one cares about blame or responsibility anymore. People want a way to get out of this mess. Telling them to ditch their $5K Epson or $10K printers in the future because they were idiots to buy them because they didn't know of future changes in the print path is not very constructive. I would bet that if pushed most of these people will prefer swapping their Macs instead for something that works, and keeping the printer.

Anyone smart will set up a PC (Windows or Hackintosh) or more simply acquire an old Mac with Leopard just for printing rather than attempt fixes that sometimes work. For those really stuck with a single machine, wishing to use canned Epson profiles, the simplest solutions might involve running a VM and some Microsoft OS in it, or maybe an older hacked Apple OS.

Last, not least, maybe Epson could just bundle a RIP with every pro or prosumer printer it sells and bypass Apple's or Microsoft's print system altogether? They could also make a version available for a nominal price to their existing userbase. I think this might be a good idea for them.

Last, not least, maybe Epson could just bundle a RIP with every pro or prosumer printer it sells and bypass Apple's or Microsoft's print system altogether? They could also make a version available for a nominal price to their existing userbase. I think this might be a good idea for them.

Why the continuing misinformation? It serves no useful purpose unless giving an excuse to the developers that cannot get their coding correct. And, what about all the developers who do get their coding correct? What do you expect them to do if Apple changes thing for the few who can't.

And here is what I found out on Colormunki with drivers that work correctly.

"Just for the heck of it I installed ColormunkiPhoto_1-1-1 software in 10.6.2. While I cannot activate ColorMunki Photo I can run Photo ColorPicker. In the print dialog from Photo ColorPicker I can choose Vendor Matching under Color matching and No Correction under Main. This would leave to believe that it is the printer drivers or PEBCAK.

I suppose that there could be a chance that ColorMunki Photo is coded different then Photo ColorPicker and forces the driver to No CM and the driver is not responding correctly."

Doyle

Doyle, it was not my intention to misinform. My experience with a friend's ColorMunki is what got me into this in the first place. He lost the ability to make a decent profile using the ColorMunki and Snow Leopard on an Epson Pro3800. Since one cant fix it by printing ColorMunki targets from another program, for all practical purposes ColorMunki is dead on a Mac with Snow Leopard printing to an Epson Pro3800. Yes, it is the developers job to fix it but it may take some help from Apple. This also applies to any profiling software that prints targets from inside the program. I can't print a valid target from Eye-One Match either. There is some work to be done here.

Doyle, it was not my intention to misinform. My experience with a friend's ColorMunki is what got me into this in the first place. He lost the ability to make a decent profile using the ColorMunki and Snow Leopard on an Epson Pro3800. Since one cant fix it by printing ColorMunki targets from another program, for all practical purposes ColorMunki is dead on a Mac with Snow Leopard printing to an Epson Pro3800. Yes, it is the developers job to fix it but it may take some help from Apple. This also applies to any profiling software that prints targets from inside the program. I can't print a valid target from Eye-One Match either. There is some work to be done here.

Don

Under Color Matching in driver for the Pro3800 dialog what can you select?

Are you also telling me that print targets form Eye-One Match does not allow full control of the printer driver settings? I am not seeing that.

Are you sure the printer driver are properly installed? Do they show up correctly in the ColorSync Utility?

If not, you need to uninstall them with the installer and delete the cache file, then install and add the printer back in as it is highly unlikely that the driver will work correctly if SN was installed as an upgrade if this is not done.

Under Color Matching in driver for the Pro3800 dialog what can you select?

Are you also telling me that print targets form Eye-One Match does not allow full control of the printer driver settings? I am not seeing that.

Are you sure the printer driver are properly installed? Do they show up correctly in the ColorSync Utility?

If not, you need to uninstall them with the installer and delete the cache file, then install and add the printer back in as it is highly unlikely that the driver will work correctly if SN was installed as an upgrade if this is not done.

Doyle

Thanks for the info Doyle. I will check that out later today and see what I find. I'll report back as I think the more information we have on what works and what does not work will help clarify the problem for all of us.

I'm sorry, but I've bitten my tongue long enough (along with everyone else I suspect), I'm going to have to speak up.

We have here a known problem, now acknowledged by the vendors involved ( Adobe public statements, Apple printing engineer postings on Dev forums ), tested and confirmed by the engineers working for those vendors ( Eric Chan of Adobe ) and by industry players of some "repute" ( Jeff Schewe, Andrew Rodney, Mark Dubovoy ) who have privileged access to information and people who are in a position to know more than anyone ( i.e. the engineers who have access to the actual code ). All of the above working to achieve a resolution to this problem as quickly as possible.

On the other hand we have "random internet forum dude" ( DYP ) who insists they are all wrong and he is right, provides no evidence to support his conclusions and clearly has an axe to grind with a particular vendor.

Doyle, for someone who (claims he) is not affected by this problem, you've made more posts on these threads than anyone else, many of which are in essence "well mine works, you just bought the wrong printer, VendorX is rubbish".

I think most of the people here are interested in resolving a problem which is affecting them and causing problems to their work and business, as opposed to providing an audience for your agenda.

I'm sorry, but I've bitten my tongue long enough (along with everyone else I suspect), I'm going to have to speak up.

We have here a known problem, now acknowledged by the vendors involved ( Adobe public statements, Apple printing engineer postings on Dev forums ), tested and confirmed by the engineers working for those vendors ( Eric Chan of Adobe ) and by industry players of some "repute" ( Jeff Schewe, Andrew Rodney, Mark Dubovoy ) who have privileged access to information and people who are in a position to know more than anyone ( i.e. the engineers who have access to the actual code ). All of the above working to achieve a resolution to this problem as quickly as possible.

On the other hand we have "random internet forum dude" ( DYP ) who insists they are all wrong and he is right, provides no evidence to support his conclusions and clearly has an axe to grind with a particular vendor.

Doyle, for someone who (claims he) is not affected by this problem, you've made more posts on these threads than anyone else, many of which are in essence "well mine works, you just bought the wrong printer, VendorX is rubbish".

I think most of the people here are interested in resolving a problem which is affecting them and causing problems to their work and business, as opposed to providing an audience for your agenda.

Please try to be constructive...

Talk about not being helpful or constructive.

So I have been printing color almost everyday of my life for the last 20 years. What I am talking about is real world stuff. The goal is to print accurate color for my clients. Whatever has to be done has to be done to achieve that and I have no room for excuses unlike many posters on here who seem to also have a political agenda. And, from this perspective I present the fact as I see them and I don't give a d__n whether you like it or not.

I have helped hundreds of people with these kinds of problems over the years and I not going to stop now because of whiners like you.

For several days I have been testing various methods of printing profile targets on 2 Macintosh systems running Snow Leopard. This started when a frustrated friend showed me some very bad prints he made using profiles he had just created using ColorMunki. I took a look at what he was doing and did not see any obvious errors in his procedures. Calls to Xrite did not resolve the problem and he was told that there were issues with Snow Leopard. A check of Xrite’s download page indicated there was an update for Snow Leopard so I installed v1.1.1.1 on his machine but the problem persisted.

I had not created any new profiles for my own Mac system for many months and never using Snow Leopard or CS4. When I tried printing a target using CS4 and the method I have used in the past the resulting target did not match my previous efforts. I found Mark Dubovoy’s article on Luminous Landscape and realized there was a problem. I tried Eric Chan’s workaround without success. I stumbled into a fix when I selected “Printer Manages Color” in the CS4 print dialog. I also tried other methods of printing the target and found that Andrew Rodney’s suggestion of printing from Preview 5 worked and I could also print from Eye-One Match when I remembered to change “Color Matching” in the Epaon print dialog from the default “Colorsync” to “Epson color controls”.

For me, the key has been to get Colorsync out of the print path. The methods that worked all use “Epson controls color” in the Color Matching dialog.

Back to ColorMunki – that problem was resolved yesterday. My friend had removed the updated ColorMunki program from his computer and re-installed from the original DVD. He was able to create profiles with excellent screen match but they printed with a gray boarder. Profiles form the paper manufacture weren’t great but they printed correctly. I updated the software again and now everything is working properly.

I agree with Mark Dubovoy that this may be a complex problem and am glad he has brought it to the attention of all of the parties involved. What works for me may not work for others using different software and printers.

A long time has passed since your post on this. FWIW I too have tested the Eric Chan workaround. I used SL 10.6.3, and PSCS5 driving a Canon Pro9000.

The short story is the workaround doesn't work for me either. Targets are too light and resulting prints are way too dark: almost as if double profiled. I too tried substituting ProPhoto at both points as per Mark Dubovoy's suggestion. Same result.

Tim

Quote from: SimonS

Printing Targets Without Colour Management

The Eric Chan Workaround With Canon Printers – A Report

I have now found some time to test Eric Chan’s devious(!) workaround for printing colour profiling test targets without colour management.

I have used a print from Photoshop CS2 without Colour Management as a benchmark.

I am sorry to report that Eric’s workaround does not work in the above set-up. The resulting target patches are too light. I tried substituting the ProPhoto RGB Colour Space for Adobe RGB and the patches are printed lighter still, which is contrary to the suggestion that changing the colour space will make no difference to the printed output (something which I find hard to credit). Previewing the workaround prints in CS4 displays clipping of some patches which would appear to suggest that colour management is indeed taking place.

I recall that a similar suggestion was made to me by Tom Attix of Adobe, but using the Generic RGB colour space. Sadly this did not work either.

There are here enough variables to start endless speculations and I suspect a blizzard of postings will follow !

I have to say that I am not convinced that the printer drivers are contributing to the problem, but this is my opinion based on supposition only.

Given that Mark Dubovoy checked the targets he printed (using the workaround) against his reference targets (printed earlier without using CS4 and Snow Leopard), and that they were near enough identical, this would seem to suggest that there is something different about the way Mac OSX 10.6 (Snow Leopard) handles colour management compared to OSX 10.4 (Tiger). As for Leopard (10.5), I can’t say.Perhaps Mark could verify this ?

In the meantime my personal, and strong, recommendation is not to rely on targets printed from CS4 to profile output devices such as printers; but to use an earlier version of Photoshop and Mac OS – one which is known from previous experience to produce accurate targets.

A long time has passed since your post on this. FWIW I too have tested the Eric Chan workaround. I used SL 10.6.3, and PSCS5 driving a Canon Pro9000.

The short story is the workaround doesn't work for me either. Targets are too light and resulting prints are way too dark: almost as if double profiled. I too tried substituting ProPhoto at both points as per Mark Dubovoy's suggestion. Same result.

Tim

I don't know if this will help in your situation but here is a interesting thread describing how to set no CM in the smaller Canon printer drivers.

Thanks. The method described by David Millar of Datacolor, in the post you referenced, is what I routinely do. It generates good profiles for Ilford Gallerie Smooth Pearl on the Pro9000, but not great ones.

I tried the Eric Chan/Mark Dubovoy method for printing targets in the hope of improving my profile for this set up. It definitely does not work at all for me (SL 10.6.3, Canon Pro9000)

David recommends selecting Generic RGB as the Colorsync profile in the printer driver, in the Spyder3 method. FWIW I'm not convinced that Generic RGB is the profile that OS 10.6.3 attaches to untagged images. After consuming very many hours, hundreds of sheets of printer paper, and gallons of ink in experimentation, I've discovered that choosing sRGB for the Colorsync profile in the driver produces good targets, which in turn give me a profile that produces excellent prints with the best screen-print match I've ever been able to achieve. I do not know why this works (or even if it should). I'm speculating that, as part of the SL change to try and make the process 'fool proof', Apple may have decided to have the OS attach sRGB to untagged files in the belief that most people who do not know, or do not want to, attach print profiles to their images, will send their photos to the web or to an online photo printer.

Cheers

Tim

PS Color Management Tool Pro looks good. However, Canon assumes that all profilers use Eye1. Sadly, I could afford only the SpyderPrint set up and couldn't find a way of getting Canon's s/w to print Datacolor's target images!