I believe that by choosing "Printer Manages Color" there is no forcing of the printer driver to do anything, so that nothing else is happening but what you choose in the printer driver settings.
PS Manages Color setting forces settings in the driver (some you probably can't even see which leads to the double profiling). Some drivers work correctly and turn of CM and some don't.
DYP- Unfortunately just choosing Printer Manages Color in CS4 and then making selections in the Epson ABW driver produced extremely dark images on my Epson 2400. CS3 produced images that matched my monitor.
Now that I'm following Eric Chan's work around (see Eric's and my postings of Dec 17th), the images come out great in CS4.
I should have mentioned converting to printer/paper profile in PS. I just assumed you would assume that is what I meant.
I've been working on this nasty little glitch since the release of CS4 (I think I actually started the thread??). Eric's workaround is solid and works in nearly every ABW situation I've recently encountered. Although I understand exactly how and why it works it's really up to Eric to explain what is really happening "under the hood" with his workaround. I don't presently make my own ABW profiles. . . Eric does. They are working perfectly on both my 7800 & 9800 Epson printers with this not-so-crazy workaround. I might add on a very important note that, on Eric's recommendation, I'm printing my ABW targets using PSCS3 and building ABW profiles from those CS3 targets. I uses these profiles when printing from CS4. This is a very important point! And, needless to say, prints are consistent with the soft proofs from those profiles. Speaking of which, if you soft proof from PSCS4 using the above mentioned profiles, make all your adjustments and do your soft proofing BEFORE you do the Convert/Assign workaround. If you try to adjust your screen image after doing Convert/Assign it will screw up everything on output!!
Eric & King -
King said: "Eric's workaround is solid and works in nearly every ABW situation I've recently encountered. Although I understand exactly how and why it works it's really up to Eric to explain what is really happening "under the hood" with his workaround."
I believe that converting the image to my custom B&W paper/ink profile before going into the print window allows for bypassing the CS4 print window profile setting. Since the CS4 print window software has been changed from CS3, the 'too dark prints' problem is thus avoided.
But what does the assign to profile Generic Gray Profile do?
Glad to hear it works! And yes, choosing Generic Gray in your case is the right thing to do for that image, since you were in Grayscale mode (not RGB mode).
In brief, what's going on is that CS4 moved to a new set of printing APIs provided by Apple (Core Graphics / Quartz). This is a requirement moving forward (e.g., I'm sure you want 64-bit support for Mac Photoshop at some point, right?). However, there is currently a glitch with the result that once you print the image from CS4, Leopard will convert the image data to Generic Gray or Generic RGB (if you're in Grayscale or RGB mode, respectively) before handing it off to the driver. This conversion messes things up because it happens __after__ the conversion using your B&W profile of choice (i.e., what you select from PS's Printer Profile popup menu in the Print box).
The good news is that the glitch is being tackled by Adobe and Epson working together.
In the meantime, if you use the workaround I described, then by doing the conversion "yourself" (step 1) and then assigning Generic Gray or Generic RGB (step 2), this causes Leopard's conversion to do nothing. In other words, Leopard sees the image coming from Photoshop and says, "cool, it's already generic gray/RGB, so I don't have to do anything" and then just passes it off to the driver unmodified.
Yes, it's a little messy and unfortunate that this happened. But the good news is that ultimately it'll get worked out and in the meantime there's a pretty easy workaround (as long as you don't freak out after performing step 2 when you see how bad the image looks).
Eric - I'm having the same problem with Mac OS 10.4.11 Tiger on a G5 PowerMac. So the problem is not just with Leopard.
Your workaround procedure produces great images -- finally!!!
Will the software update Adobe & Epson are working on also fix the problem in Tiger, not just Leopard?
Now I see why Canon introduced Fast Graphic Process in it driver, to prevent Leopard from doing this. Funny thing is they must have already known this or did it because of Indesign. I noticed before (the drivers they just released which fixed the no CM in the driver problem) if I converted to the printer profile in PS I could not get a correct print unless I enabled Fast Graphic Process in the driver. This was with Printer Color Management set in PS.
Interesting point, Doyle. I am not familiar with the internal workings of the Canon printer driver but based on your description I agree that the FGP is likely aimed at avoiding this conversion.
Marj, it is likely that the issue will also be addressed under Tiger (but I cannot say for sure since I am not personally writing the fix).
There are some interesting things being discussed here, and several of them apply to my situation. I apologize for hijacking the thread, but it looks to be dead anyway, and at least this will force it back to the top of the list.
So I had firsthand experience with the "photoshop prints nothing" problem last week while trying to print untagged and unmanaged RBG files for profiling. I read several of the work arounds for that problem, but just wasn't convinced that some type of CM wasn't being applied and therefore defeating the purpose of the targets. In the end, I was able to use someone's laptop with CS3 to print the targets, everything went well, profiles created, problem solved! Or so I thought... Now that I have the profiles created and am trying to print some 16-bit images, we have a big problem- they look terrible! The color is over-saturated, and the prints are way too dark. Take the exact same file(s), don't check the 16-bit box and they look great. I have made sure to enable 16-bit in the photoshop print module as well as the epson driver, I've also tried it enabled in one and not the other. It feels like I have tried every combination of available options, but I really hope I'm missing something... I'm on a MacPro running 10.5.7 and CS4, I've tried both ProPhoto images as well as Adobe1998. I have the Leopard print driver, and to the best of my knowledge everything else is up to date.
Oh and I should mention that these are color images, still trying to get that sorted out before messing with grayscale.
Ah, so that's what's happening...
Good to know.
Having the same issue (Dual G5, OSX 10.4.11, PSCS4, Epson R2880, latest driver for 10.4 downloaded from the site, printer is the default printer).
Saw that the print preview (when saved as pdf) was Generic RGB instead of AdobeRGB (which is embedded when printing from PSCS2). Suspected that somehow the data sent to the printer got converted (since the pdf wasn't garish in color like the PSCS2 output), but couldn't imagine why...
Any new info on whether this'll get resolved?
Back to using PSCS2 for printing I guess, or using this as a workaround.
Did a tests, and there appears to be a huge drawback to this workaround: It prevents you from printing anything that's outside GenericRGB gamut. (Even worse actually, since the "convert to profile > Assign GenericRGB" step oversaturates colors, so even more clipping occurs as in a straight "working space > GenericRGB" conversion)
Posted some examples on my blog here: http://www.getcolormanaged.com/color-management/part2/
I'd love to be wrong here, but I don't think I am...
So, back to PSCS2 for color managed printing. Bummer...
Any updates on this? I can't believe it's been a known issue for this long and still remains unsolved...
Same problem But WITH WINDOWS7?????
cs4, no color management not an allowed option for grayscale.
3 years this has been an issue!?
Yes, we're still working with Apple and the printer manufacturers to try and resolve the color workflow problems.
The printer driver returns information about what it can and can't do to the OS, then the OS feeds that information to the application, and the application has to disable functions that are not available for that driver. If the driver or OS get confused, the application has no idea and just has to do what the OS said was allowable.