Thanks for the insightful article on the challenges of printing targets from CS4/Leopard and Snow Leopard. The original post noting this problem was last January from Ryan, so it's been a long time coming. I'm glad someone with enough knowledge and enough clout experienced the problem and finally raised some attention at Apple and Adobe, for many of us have been fighting this for a long time. Currently I have not profiled a few papers for my 7900 because I had no method of using an older operating system or version of Photoshop.

I also appreciate the explanation ... it provides a little more confidence in the fix. Before it was impossible to "trust" a target ... now because of the logic of the explanation I'm feeling better about the work around.

So many thanks to Mark and Eric (and all of the others who have helped.) Hopefully it gets fixed someday, after all turning color management off in Photoshop should do just that, but at least I can resume making profiles for my 7900.

The root problem has been lurking in ColorSync since, well pre-Tiger as I recall. The ColorSync pipeline just "hates" untagged data...even if it's intentionally untagged like in Photoshop. So, various workarounds have been done in previous versions of Photoshop. However, Photoshop CS4 was strictly designed to adhere to the most recent printing APIs...

Regardless of the fact that recent Epson drivers have had the issue exposed, make no mistake about it–the root cause of the problem is Apple's refusal to allow a pathway for "intentionally untagged data".

The workaround works...thank goodness, but hopefully Mark can light a fire somebody at Apple to "fix" this issue once and for finally, all!

Yep, a big thank you indeed. My i1io will finally start to become worth its price.

It is really comforting to see that Adobe does indeed care about us the way they do!

Cheers,
Bernard

As a PC user, I have found some weird humor in all the travails Mac users have had to endure. Glad you will now finally be able to profile your papers. I can just see the new PC/Apple commercials: "Hi, I'm a PC and I don't need a work around to work with Photoshop!"

Big ups of course to Eric for getting to the root problem, on his own time, no less. But this workaround has been circulating for months. I even blogged it back in Feb. And I was pretty sure the workaround actually came from one of Eric's public posts...

Hi Amadou, yes, the two workarounds are related. There was a similar glitch back when we were trying to print Advanced B&W (ABW) photo targets and nothing came out. I see from your blog that you actually had a better workaround than the one I had originally suggested for the ABW case; I had originally proposed using Printer Manages Colors with Generic Gray / Generic RGB, with the caveat that it would break when Snow Leopard came out.

Also, as I recall, back then even though the ABW target printing wasn't working, the RGB target printing was still fine. Unfortunately now the RGB target printing is necessitating a similar workaround ...

The issue is not confined to Leopard and Epson drivers. I'm using Tiger and an HP Z3100 with CS4 and I had the same problem. The workaround solved it. I read about it in Amadou's blog a few months ago.
-John

Hi,

Thanks a lot to all who have been involved! I have a few questions, though.

1) Is this issue specific to Snow Leopard only or also to Leopard?
2) Is this issue specific to Photoshop or does it also apply to other profiling solution like the Color Munki?

Best regards
Erik

So just to be clear, could you please give the work around again for SL and CS4 or point me to the thread. Thank you.

Solving Recent Profiling Issues With Apple Computers Epson Printers and Photoshop

Erik, the problem can affect any application that goes through Apple's new print system. This is mainly on both Leopard and Snow Leopard. The issue that John reported with the Z series on Tiger may have had similar symptoms, and the workaround may have solved it, but it was likely a different root cause than the current problem. I have not tried Color Munki software recently and so I can't comment on that. It may work if it's using Apple's older print system (like Photoshop CS2 and CS3 did) but eventually it will break when the new OS versions come out without the older print system.

What's interesting is that Canon at least with the iPF drivers had fixed this issue as early as Dec 2008. And I haven't seen it crop up since except in the recent LR 3 beta, which is even stranger. Why would Adobe release LR 3 Beta with old code after the goof up in LR2.3RC, especially since LR2.5 and PSCS4 do not have this problem using the same driver.

Seems like there is still a lot of misunderstanding about this whole issue.

Doyle

Both exhibit the problem.

The issue even goes back to Tiger. Of course LR was the only app using the new printing path back then, but we had to use the ColorSync workaround to print from LR1.31 but somehow it was fixed with 1.4. I would think PSCS4 would have this same problem with drivers that are not written correctly for the new printing path no matter how far back in the OS's you would go? I don't know, can CS4 even run on Tiger?

Doyle

Thank You.

Let me ask a few questions-

1. Does the same issue apply to Lightroom, and if so WHAT is the work around?

2. Never mind printing profiles, does the same work around need to be applied to printing any photo, on CS(X) and/or Lightroom?

And by the way, somewhat with pique, I'm really glad this happened to Marc. I also learned that Apple is NO BETTER than the evil empire.


AND LASTLY, THE ONLY ONE WHO COMES OUT OF THIS WITH ANY CREDIBILITY IS ERIC CHAN. Guess JS doesn't have the stones he thinks he has. Sorry for the rant, three years of dealing with this "non" issue has its effect.

I really think the pressure needs to be put on Epson and HP if they have the same problem.

I don't see where this is a problem with Apple or Adobe. If Canon can get it right, why can't Epson and HP. What would it benefit anyone for Adobe or Apple to make changes just because Epson can't get it right.

Is this maybe why the screwup with the LR3 beta?

Apple could at least offer a way to print without going through the ColorSync system.

If the drivers are written properly is it doesn't go through the ColorSync system.

Why continue pointing fingers at Apple and Adobe?

Much thanks to Mark, Eric and Luminous Landscape for responding to this issue which I reported in January 2009:
http://luminous-landscape.com/forum/index....howtopic=31410

I am now aware of three workarounds for printing profiling test charts using the combination of MacOS X 10.5 / 10.6; Photoshop CS4 and the Epson 7900/9900. All of them have been previously reported.

1. I have just tested Eric's latest workaround on matte paper and compared the results to my January benchmarks. Both Adobe RGB and ProPhoto RGB gave the correct result on matte paper with this work-around.



2. Although Eric's original Generic RGB workaround broke with Snow Leopard, it will work if sRGB is used instead of Generic RGB. I tested this a couple of months ago and reported here:
http://luminous-landscape.com/forum/index....showtopic=37353

3. The third workaround is based upon Jason Hicking's original LightRoom ColourSync Utility workaround from nearly two years ago.
I successfully tested this method and reported this back in January:
http://luminous-landscape.com/forum/index....st&p=253973

[Edit 1: Provided a link back to the LL article.]

And who do you think went backchannel to Eric and Dave P. from Adobe?

:~)

Why? Because it _IS_ a ColorSync problem...

EVERYTHING in the Mac print pipeline goes THROUGH ColorSync. The problem is there _IS_ no method of bypassing ColorSync's inability to deal with intentionally untagged data...previous versions of the OS and printing APIs where worked around, But in the current print API there _IS_ no method of workaround (which is why the whole thing is broken–BECAUSE of Apple).

No...because you can't print out a target from Lightroom There is no way in Lightroom of bypassing the ACR/LR color processing pipeline.

DYP, unfortunately, they have to go thru ColorSync. The app needs to give the image data to ColorSync, and the driver needs to get its image data from ColorSync (*). There is no other mechanism. The key is to prevent ColorSync from performing a color transform while it has its hands on the image data. It's rather like sending a package via the post office to a friend, and hoping the post office passes it along as-is (unmodified) instead of opening it up and mucking with it.

Eric

(*) There is an exception, of course, which is the special case of an app talking directly to printer hardware, like ImagePrint and QuadToneRIP.

Before we get the pitch forks out for Apple, its very, very possible (based on private email conversations I’ve had with some of the engineers mentioned in this post) that the problem is at least partially an Epson driver issue. Some of the drivers will use sRGB as the default profile which you can see in the ColorSync utility. This is not what “other” companies have recommended they do.

Drivers older than 6.5 don’t appear to exhibit this one issue, I can’t replicate it on an Epson 2880 or 3800 but CAN on an Epson 3880 using version 6.5.

A pitch fork for Apple for not documenting what’s going on with the OS is appropriate, I’ll give you that.

Lastly, if you do use Eric’s technique, its very important in the Print dialog of Photoshop to actually select the profile, not the same profile associated with the “RGB Working space” in the popup. IOW, if you assign Adobe RGB (1998) to the target, and your RGB working space in color settings is set to Adobe RGB (1998), DO NOT select “Working RGB” but instead specifically select the Adobe RGB (1998) profile from the popup menu.

But yet with the Canon iPF drivers ColorSync does not mess with intentionally untagged data. There does not appear to be anything broken with Adobe - Canon iPF drivers - Apple with LR2 and PSCS4. But I can not say the same about the LR3 beta.

Doyle

And how have you reached that conclusion?

Personally, I'm rather disappointed with Apple over this... clearly there has to be a method of passing untagged data through colorsync otherwise the process of creating profiles isn't possible, and to eliminate that path and not provide sufficient justification or documentation is not good sense.

I'm also concerned that all the companies involved have spent so long finger-pointing over this issue (instead of getting their heads together and solving it), that we the customer have been left dangling without a resolution, and unable to effectively use the tools we've paid good money for. Poor show.

It shouldn't have been necessary for the issue to be highlighted on a high profile website such as this before the companies involved would take action ( assuming they even will ).

I applaud Mark and those involved for publicizing this issue, and urge them to continue to use their contacts and influence to keep the pressure on until a proper resolution is made available. This is a major issue... and needs fixing in short order.

I believe it is because Canon drivers are not drivers in the same way Epson drivers are drivers. Canon drivers are more like an 'export'.

There is a method of passing untagged data through colorsync, I print all the time with these printers.



Some have.

Doyle

Are you referring the Canon PS Plugin which is an export plugin?

I do not see where the drivers are like an export. There is a Fast Graphic Process option that bypasses the Apple print path which is a god send when printing from Indesign avoiding using the Print as Bitmap work around. But that makes no difference in for example the LR3 beta mess up. In fact the LR3 beta is so messed up that you can not even choose Fast Graphic Process. Really though FGP only comes into affect when passing off vector data which ID does if Print as Bitmap is not selected.

Doyle

Sorry Jeff, really. THAT was my feeble attempt to get you involved in this "discussion". Further more, thank you for the following-

"EVERYTHING in the Mac print pipeline goes THROUGH ColorSync. The problem is there _IS_ no method of bypassing ColorSync's inability to deal with intentionally untagged data...previous versions of the OS and printing APIs where worked around, But in the current print API there _IS_ no method of workaround (which is why the whole thing is broken–BECAUSE of Apple)."

FINALLY, someone with stones can tell it like it is. That's refreshing. Now, specifically to Lightroom, DOES Colorsync "muck" up the process when printing photos not profiles, i.e. to the Epson R2880 (DigitalDog-Epson has updated the R2880 Mac driver to 6.62). I (and I assume) others do have CS4 and can follow the work around for printing profiles. BUT, is there a problem printing photos with Lightroom (2.5 or Beta 3) due to this Colorsync "thingy"?

Andrew- the R2880 6.62 driver does default to sRGB in ColorSync. So, hence, my question when printing a photo from LR. Does ColorSync take the ProPhoto colorspace from LR, manipulate it because of the sRGB default and create a problem for the driver and thus the resultant print.

Yes and no. The way its achieved is by a null profile whereby the source and destination profile are the same. All data is color managed but if you use such a null approach the result is “no color management”. And here’s the problem this article uncovers and why Eric’s tip works. In the old days, when things worked properly, an untagged target was tagged in the printing system with Generic RGB as both source and destination and thus, nothing happened. The print driver registers a profile with ColorSync and when working correctly, an Epson driver will register the correct profile based on the media setting. With the current crop of drivers that are not working correctly, they always register sRGB, at least that’s what the CS utility shows me for my 3880 but not my 7880 or 4800. Its not totally clear what causes this (is it an Apple bug, an Epson bug or a combo of each)? Based on private conversations and the fact that newer drivers from Epson appear to have this condition, it wouldn’t surprise me to hear its a driver issue.

I think some people have had problems when using non-Epson paper and profiles where the Epson default profile for the media setting can get into the way. There was a workaround for that too I think. But as far as I know the specific and special case where one is trying to print out intentionally untagged data doesn't relate to Lightroom cause you really can't print out color targets with Lightroom.

As it relates to Lightroom if you print with Lightroom managing color, the default sRGB register is a non issue.

Thank you (again)!

I read also somewhere in the last week or so ( I think it was the release notes for i1Match 3.6.3 for OS-X ) that Colorsync on Snow Leopard does not work with v4 ICC profiles.

Now I know this not related to the tagging issue under discussion here, but is another cause for concern, and frankly reduces my confidence in Apple's commitment to Color Management.

I have a brand new 7880 sitting in a corner that's never been powered up, I'm somewhat reticent to do so as I am not confident the tools I have to profile it and use it effectively will work as intended. I am actually considering printing from the... oh I can barely bring myself to say it... from the dusty Windows XP machine.

From X-rite re i1Match 3.6.3:

"Known issues —
This release of i1Match is currently not able to create correct large ICC4 monitor profiles on the new Intel Macs. It is recommended to create only default monitor profiles on the Intel Macs until a new version of i1Match will be released."

So the i1Match issue only relates to monitor profiling on new Intel Macs.

That'll work, but you'll have a much better iTunes experience on the Mac. Apparently that's where the really serious beta testing goes.

If for some reason (can't think of any) I would go the Epson route I would use a RIP. I do have a 9600 here that never gets used anymore even though I have a RIP for it.

Doyle

That could have been it, though I thought it was a little more serious than that, I'm trying to find the release notes of the new ColorMunki software to check those as well. That aside, if it's just the issue detailed above, then it's not an issue. I felt sure I read somewhere there was an issue with v4 and Colorsync in Snow Leopard.

Anyway, it's off topic, so, moot.

I think you have some unresolved issues with Epson...

Either way, not interested in commercial RIPs. Limited to one printer model and a niche market ( so limited resaleability ) which makes it too high a cost to justify, and arguably not worth the price in the first place. In my own ( naturally subjective ) testing no better in quality over a well setup and profiled printer using decent drivers *cough*.

That said, I'm a keen supporter of QuadToneRIP.

Anyway, we're veering off-topic again...

Blue Eye Pro has no problem with creating and SL has no problem using Version 4 profiles. I have not heard of any problem with ColorEyes. And have no problems with version 4 printer profiles.

Doyle

In what way could there be the same problem? The Z models use a separate application (Printer Utility>Color Center) that triggers the target printing and if I'm not mistaken the targets are stored on the printer like the calibration target is. At least I tried to find them in the Color Center map for other reasons and they are not there. The software doesn't even ask to switch off CM as there shouldn't be a channel that is affected by CM. The only treatment it gets is the ink limitation etc of the media preset. For the profile creation process after that there shouldn't be any interference of Adobe ACE or Apple Colorsync either.

Printing from Photoshop and the created profiles used there is another issue but as far as I understand it that should work well with tagged images. If you want to print targets with Photoshop for other profile creation programs then I can understand there is an issue. For example with QTR profile creation.

HP's optional APS does have the targets in the program map and it could use a driver channel that interferes with Colorsync but I have not seen a report of problems there.

Standing at the sideline here as I print from Qimage in a Windows environment with a Z3100 and Z3200. BTW an application where you can switch off CM and then it is really OFF. The way I print the QTR targets for B&W profiles.



met vriendelijke groeten, Ernst Dinkla

Try: http://groups.yahoo.com/group/Wide_Inkjet_Printers/

Could this be a situation where it makes sense to leverage diagnostics by recourse to how these processes are managed between Windows XP (or perhaps Vista if it had no issues - I don't know I never adopted it) and the Windows versions of the same Epson drivers versus what happens or doesn't happen in the OSX environment? Perhaps if there were a way of drilling down such a comparison, would it help to throw light on the question of what aspects of the problem may be lodged with Colorsync versus what aspects with the Epson drivers? I ask these questions because there seems to be a view from Jeff that the problem is Colorsync, but a view from Andrew that the driver could also be involved; as well, it has intrigued me for some time now why using Epson professional printers with Windows appears to be more seamless than with OSX, so perhaps some cross-comparison between the technologies may help to confirm where the real solutions need to be implemented.

This episode also raises, yet again, a real question about why these several companies can't sit together and make sure that before they release crititcal software it will at least perform the most basic functions correctly. It's hard to believe that Apple, Epson, Adobe and if the situation were to arise Microsoft rather than Apple, would be hauled before any kind of anti-trust proceeding on such technical collaboration, because they mainly operate in different niches of the industry and could hardly be accused of stifling competition between themselves for conspiring to achieve technical coherence of their various products in aid of all their consumers. Why is this too much to expect?

The big question why do the Epson drivers handle the call from PS No Colormanagement differently than PS Manages Color. These two calls should give the same reaction in the driver, No Colormanagement. The Canon iPF drivers handle both these calls exactly the same, No Correction.

That is why I conclude there is clearly something wrong with the Epson drivers.

Doyle

I'm not convinced either contention is correct. No colour management in PS means Photoshop isn't managing colour - in which case the driver is managing colour, unless it is also switched off. These are separate functions in each software. I have no idea what goes on with Canon iPF drivers because I print with an Epson 3800, but if the Epson driver is correctly specified for Windows, it would seem counter-intuitive to me that Epson would be unable to correctly specify the same driver for Mac OSX - they have AT LEAST as much of a commercial interest in getting it right for Mac as they do for Windows given the high percentage of their clientele using their printers on Mac operating systems.

Windows Vista worked fine with my R2880; never had a problem in printing. Upgraded to Win7 two weeks ago and printed fine (though the print dialogue box said the printer was busy when it wasn't but that was cleared up by downloading the latest Win7 driver). Microsoft clearly makes their OS available to printer vendors so that drivers can be checked and updated without a problem. It's not clear why Apple is encountering the snafus that this thread is discussing other than they are not being as transparent as need be. I don't think that cooperation between Apple and printer manufacturers raises any antitrust issues in the same way that some Microsoft practices have. I've been a happy PC user since day one and have not had any problems as things migrated from DOS -> Win3 -> XP -> Vista -> Win7. All the hardware worked as promised.

I guess I'll begin working on my C++ programing skills and apply for a job with Apple to clean up this mess!!!!

No, there is a separate PS call, Printer Manages Color. This should be the only selection that allows the driver to managing color. All functions in the driver should be available with this call including No Colormanagement.

It has always appeared that Apples desire in the new printing path is that when Application Manages Color or in the case of PS No Color Management that the printer drivers will turn off CM with no CM options available to the end user other than adjustment sliders. I believe any printer driver not following this is not coded correctly for Apples new printing path. Likewise any printer driver that defaults to colorsync instead of No CM is likewise coded wrong.

Doyle

The way the Windows implementation works is that in Photoshop Print Preview, if you select Printer Manages Colour, then Photoshop is not managing colour. However, within the Epson driver there are colour management options from which the user selects, as to HOW the printer will manage colour. This is accessed either from Page Set-Up in the Photoshop Print Preview or from Preferences when the printer driver is called-up after one clicks on Print.

I don't understand what the first sentence of your second paragraph means, so the rest of it doesn't click in my mind. Either the printer or the imaging application must manage colour unless colour management is intentionally disabled in both, say in order to print profiling targets - the case at hand here. The imaging application and the printer driver should be independently user-controllable, and the operating system should respect that. These companies need to cohere enough to make it happen that way.

I don't think it works that way. A Windows OS has millions upon millions of lines of code and it's proprietary. I believe they make an SDK available which is supposed to allow third party applications and drivers to be crafted coherently. I believe this is standard industry practice.