|
Schewe
|
 |
« Reply #20 on: November 03, 2009, 08:22:17 AM » |
Reply
|
Guess JS doesn't have the stones he thinks he has. And who do you think went backchannel to Eric and Dave P. from Adobe? :~)
|
|
|
|
|
Logged
|
|
|
|
|
Schewe
|
 |
« Reply #21 on: November 03, 2009, 08:27:49 AM » |
Reply
|
If the drivers are written properly is it doesn't go through the ColorSync system.
Why continue pointing fingers at Apple and 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).
|
|
|
|
|
Logged
|
|
|
|
|
Schewe
|
 |
« Reply #22 on: November 03, 2009, 08:30:12 AM » |
Reply
|
1. Does the same issue apply to Lightroom, and if so WHAT is the work around? 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.
|
|
|
|
|
Logged
|
|
|
|
|
madmanchan
|
 |
« Reply #23 on: November 03, 2009, 08:48:27 AM » |
Reply
|
If the drivers are written properly is it doesn't go through the ColorSync system. 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.
|
|
|
|
|
Logged
|
|
|
|
|
digitaldog
|
 |
« Reply #24 on: November 03, 2009, 08:53:11 AM » |
Reply
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
Doyle Yoder
|
 |
« Reply #25 on: November 03, 2009, 09:14:16 AM » |
Reply
|
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). 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
|
|
|
|
|
Logged
|
|
|
|
djoy
Jr. Member

Offline
Posts: 50
|
 |
« Reply #26 on: November 03, 2009, 09:38:58 AM » |
Reply
|
But yet with the Canon iPF drivers ColorSync does not mess with intentionally untagged data. 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.
|
|
|
|
« Last Edit: November 03, 2009, 09:46:52 AM by djoy »
|
Logged
|
|
|
|
|
jjlphoto
|
 |
« Reply #27 on: November 03, 2009, 10:31:15 AM » |
Reply
|
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....... Doyle 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'.
|
|
|
|
« Last Edit: November 03, 2009, 10:31:54 AM by jjlphoto »
|
Logged
|
Thanks, John Luke
Member-ASMP
|
|
|
|
Doyle Yoder
|
 |
« Reply #28 on: November 03, 2009, 10:36:33 AM » |
Reply
|
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. There is a method of passing untagged data through colorsync, I print all the time with these printers. 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. Some have. Doyle
|
|
|
|
|
Logged
|
|
|
|
|
Doyle Yoder
|
 |
« Reply #29 on: November 03, 2009, 10:45:36 AM » |
Reply
|
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'. 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
|
|
|
|
« Last Edit: November 03, 2009, 11:02:57 AM by DYP »
|
Logged
|
|
|
|
|
Photo Op
|
 |
« Reply #30 on: November 03, 2009, 10:47:59 AM » |
Reply
|
And who do you think went backchannel to Eric and Dave P. from Adobe?
:~) 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.
|
|
|
|
« Last Edit: November 03, 2009, 10:58:12 AM by Photo Op »
|
Logged
|
David
|
|
|
|
digitaldog
|
 |
« Reply #31 on: November 03, 2009, 10:56:13 AM » |
Reply
|
There is a method of passing untagged data through colorsync, I print all the time with these printers. 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.
|
|
|
|
|
Logged
|
|
|
|
|
Schewe
|
 |
« Reply #32 on: November 03, 2009, 10:59:51 AM » |
Reply
|
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"? 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.
|
|
|
|
|
Logged
|
|
|
|
|
Schewe
|
 |
« Reply #33 on: November 03, 2009, 11:03:05 AM » |
Reply
|
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. As it relates to Lightroom if you print with Lightroom managing color, the default sRGB register is a non issue.
|
|
|
|
|
Logged
|
|
|
|
|
Photo Op
|
 |
« Reply #34 on: November 03, 2009, 11:06:34 AM » |
Reply
|
As it relates to Lightroom if you print with Lightroom managing color, the default sRGB register is a non issue. Thank you (again)!
|
|
|
|
|
Logged
|
David
|
|
|
djoy
Jr. Member

Offline
Posts: 50
|
 |
« Reply #35 on: November 03, 2009, 11:19:02 AM » |
Reply
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
Ryan Grayley
|
 |
« Reply #36 on: November 03, 2009, 11:31:27 AM » |
Reply
|
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. 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.
|
|
|
|
« Last Edit: November 03, 2009, 11:32:24 AM by Ionaca »
|
Logged
|
|
|
|
|
bill t.
|
 |
« Reply #37 on: November 03, 2009, 11:34:44 AM » |
Reply
|
I am actually considering printing from the... oh I can barely bring myself to say it... from the dusty Windows XP machine. 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.
|
|
|
|
|
Logged
|
|
|
|
|
Doyle Yoder
|
 |
« Reply #38 on: November 03, 2009, 11:47:17 AM » |
Reply
|
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. 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
|
|
|
|
« Last Edit: November 03, 2009, 12:03:16 PM by DYP »
|
Logged
|
|
|
|
djoy
Jr. Member

Offline
Posts: 50
|
 |
« Reply #39 on: November 03, 2009, 12:19:54 PM » |
Reply
|
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." 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.
|
|
|
|
|
Logged
|
|
|
|
|