I just ran a print through my epson 9800 and it has a very unpleasant color/tone crossover on the side of the persons face. I have noticed it before on light gradations on the skin where it goes to shadow. Anyone got any ideas? I am very careful with media settings and profiles of course. I've run a nozzle aligment test a nozzle test too.

Can you explain a bit more what you mean? Which paper is this, and which printing mode are you in?

Epson Premium Luster. Setting: the usual no color adjustment setting. Theres deffinately nothing wrong with my color management. It's basically where the skin tones gradate there gets to be a deffinate line. It seems that there are certain "sweet spots" of tone gradations that the printer cant handle, it only comes up say once in a hundred images but when you get one that has it it's a real problem. I use the canned Epson profiles.

You might try Bill Atkinson's profiles, available herehttp://homepage.mac.com/billatkinson/FileSharing2.html.

Sounds like you ran into that odd salmon color bug that's cropped up for some. Do this, if you're on a Mac, make sure in Printer Setup that the 9800 is the default printer selected (bold). Try again. What happens?

I just checked that and it is in bold. The salmon color thing does sound in the right direction as it only happens on skin tones that get close to salmon type colors, any other ideas?

If you happen to be using Mac OS 10.4.6 update the system to any newer version to avoid a ColorSync bug that would cause what you are describing. Otherwise, you might try making a custom profile.

This problem keeps coming up. Look at this discussion:
http://luminous-landscape.com/forum/index....showtopic=13790

The trick is to force colorsync to use the generic rgb profile as the default for the printer. Making the printer the default printer sometimes works, but I prefer to force the default profile to generic rgb.

Run the colorsync utility, select devices, click printers then click the name of the printer you are having trouble with. A list of profiles will show. One of them (the default) has a blue dot beside it. Click on that profile name. You will now see Factory Profile and Current Profile listed. Change the Current Profile to:
/System/Library/ColorSync/Profiles/Generic RGB Profile.icc

You may need to restart.

Apple, Adobe and Epson all know about this bug and all say it is the other guy's problem.

Let us know if it works for you.

A friend with a Mac solved all of his Mac -> Epson printing problems by networking in an older laptop PC as a print server. Now he can print almost as easily and well with his 9800 as I can from my PC.

,

I just tried changing the default profile and it seems to have cleared the problem up. Very strange, I haven't had any problems with the printer except those certain and quite rare salmony skin tones when it just all got a bit strange. Thanks all.

That's a fix but a hack and does appear to alter the output behavior. Did you see any change using profiles built with the original behvaior? Setting the printer as the default seems to fix the issue, at least on Intel Macs (PPC may still be broken) once updating to 10.4.9/10.4.10.

Hi Andrew,

Making the printer default didn't fix it on my original Intel Mac, nor did the workaround suggested by Ian Lyons (http://www.computer-darkroom.com/pwp_901/pwp_901_1.htm) so I've been using the profile fix ever since. (I now have two Intel Macs.) Plus, there is no danger of another printer being inadvertently set as default and the Epson prints going bad again.

I do not use profiles built with the original behaviour. I expect them to be wrong because the measurement target cannot be printed without ColorSync altering it. I only use profiles built with generic rgb set as default. I also get good results with Epson profiles. And I get good results with profiles built before Apple and/or Epson and/or Adobe introduced this bug, i.e. back in the Photoshop 8 and OS 10.3 days.

It is a "hack" but it is based on comments that Bruce Fraser made about the strange workings of ColorSync: you can never turn ColorSync off (even if you select Photoshop to manage colour) and the only way to get ColorSync to leave colour values alone is to tell it that a file is in generic rgb colour space. I defer to your expertise, but I see no ill effects and it finally fixed the problem for me.

But what version of OS X are you running? The default trick does work on my Intel Mac under 10.4.9 (I'm now on 10.4.10). It doesn't on a PPC box.

10.4.10. But my observation that the default trick didn't work is several 10.4.x versions old (not sure how many). I don't have the inclination to to test it all again as generic rgb works for me and my past experience was that using default or the Ian Lyons workaround didn't work for everyone. Generic rgb seems to work for all with no ill effects and I'm happy to get on with printing photos on the Epson 4800.

I plan to be a cautious adopter of Leopard. That will be the next time I do more testing. I'll wait until at least the .1 release. Hope you and others adopt early and test well. :-)

I'm on OS 10.4.9 and a PPC and setting the printer as default didn't seem to help it. The Generic RGB trick seems to do it though. It is quite a peculiar problem as it only came up on 1 out of a hundred or so images, is this what you guys experienced. I'm using canned epson profiles that seem to be good.

After reading this discussion, I took a look at the color sync utility.

It appears to me that my Epson 3800 Standard profile looks exactly like sRGB. IOW if you let the Epson driver manage colors, it first converts to sRGB before converting to the paper profile.

As for "generic rgb", it looks similar in gamut, but perhaps at 1.8 gamma, to the Epson standard profile. I would guess that if one sets the default profile to generic RGB, there might be some lightness/darkness issues in the print, though the colors should look ok when letting the epson driver handle color conversion.

What I don't get is how a profile could "leave color values alone" as some color space must be defined and only identical spaces would not necessitate a conversion of data. Unless there is something special about the "generic RGB" space that tells colorsync "I"m just a slug, don't change the data" Does anyone know if this is how it works?

Just curious,
-bruce