Re: Epson No Color Adjustment Experiment
Re: Epson No Color Adjustment Experiment
- Subject: Re: Epson No Color Adjustment Experiment
- From: John Fieber <email@hidden>
- Date: Tue, 23 Dec 2003 14:45:45 -0500
On Dec 22, 2003, at 4:27 AM, Rick Gordon wrote:
So I'm just trying to get my head around what the actual set of
transforms might be. I figure that some factor of the difference
between Generic RGB and Wide Gamut RGB would be in there.
So might the set of transforms be something like this?:
1) The file begins as Adobe RGB or Untagged RGB interpreted through
the default Adobe RGB working space.
2) Photoshop converts the Adobe RGB data to my custom printer/paper
profile and sends it on to the print engine.
3) ColorSync grabs the data and converts the data to Generic RGB, and
then sends that RGB data to the Epson driver, which being set for No
Color Adjustment passes the data without further transforms into the
portion of the print engine that translates the data into printer
codes.
But in step 2, Photoshop converts the data to your specified output
profile, but it lands in the print queue (mis)tagged as Generic RGB so
no conversion should happen in step 3 because with "No Color
Adjustment" the driver either registers Generic RGB or doesn't register
a profile in which case Generic RGB is apparently assumed. This
appears to be how Apple indents "No Color Adjustment" to work.
The only way I've found that Photoshop tags the stuff going into the
print queue with the actual proper profile for the data is if you
select "PostScript Color Management" (PS7) or "Printer Color
Management" (PS8). I missed this option for a long time in PS7 because
it didn't mentally register as being relevant when printing to my
decidedly non-postscript printer.
"Same as source" only works if your source happens to be your output
device profile and you select "No Color Adjustment" in the print driver
when printing. If either of those two criteria don't hold, you will
not get correct colors.
The trouble with this scheme for "No Color Adjustment" is that the
option doesn't do what it implies. Take a tagged (say, Adobe RGB)
image and drop it in TextEdit.app. TextEdit edit deposits the Adobe
RGB image data directly in the PDF tagged with (surprise!) the Adobe
RGB profile like a well behaved color managed Cocoa application. The
print systems sees the destination profile as Generic RGB and dutifully
converts the Adobe RGB data to Generic RGB, which then goes to the
printer.
This behavior is obviously not "No Color Management" and, Dear Apple
Computer Inc., this is another reason why the null-transform hack for
disabling color management must be replaced with a PROPER means for an
application (as opposed to a printer driver) to disable colorsync
processing while printing. Granted, the utility of using No Color
Management with TextEdit is dubious, but that just emphasizes the
point. If it makes sense for an application to disable color
management, the application needs to be able to do it with certainty,
and provide the user interface for doing it.
-john
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.