Re: LaserWriter color management ABC
Re: LaserWriter color management ABC
- Subject: Re: LaserWriter color management ABC
- From: Chris Murphy <email@hidden>
- Date: Mon, 8 Jan 2001 00:16:09 -0700
Henrik Holmegaard <email@hidden> writes:
>
None of the LaserWriter driver controls apply when printing from an
>
application that generates its own PostScript.
This contradicts my direct experience and even item b.)
>
b. Select a printer profile and a rendering intent, and the driver
>
writes a CSA for the monitor profile plus a CRD for the LUT in the
>
ICC profile. However, while you may choose this option with 'pass
>
through' applications like QXP and AI, the RIP is not obliged to use
>
the CRD.
When I ask Photoshop to use PostScript Color Management, it creates a CSA
of the document's current Assigned Profile. Then it creates a CRD based
on the ICC profile you select in the printer driver.
Opening the resulting PostScript file confirms this. So I'm not exactly
sure what you mean by none of the Laserwriter controls apply whe printing
from an app that generates it's own PostScript. I haven't done this
extensively from QuarkXPress so I'm not sure what CSA ends up being
created (does the Laserwriter driver assume a CSA?) if any since
QuarkXPress doesn't support PostScript Color Management.
As far as I can tell only Adobe applications support PostScript color
management.
>
The reality is that Apple folks say the color conversions were about
>
30% faster on Macs compared to in the Color LaserWriter controller.
>
The general argument for in-RIP used to be that the RIP has the most
>
horsepower.
I think the idea is to use an industrial strength RIP (i.e.,
imagesetter/platesetter RIPs), not the one in laser printers.
>
>
>This is because it can be safely assumed that the monitor
>
>profile is source, and the destination profile is the printer you're
>
>using. The monitor profile is assumed automatically (as the System
>
>Profile or Display Profile depending on which version of ColorSync you're
>
>using).
>
>
Not quite, see above.
Yeah but I qualified the statement above first by referring to QuickDraw
applications that don't use color management. In that case, a printer
driver that does support ColorSync will assume the display profile based
on the display/system profile setting in the ColorSync control panel.
There will always be exceptions to the rule, and that's what makes driver
level color management even more difficult - the total inconsistency of
color management support in applications and in printer drivers (let
alone the UI issues).
>
>QuarkXPress won't even generate CSA's
>
>
This isn4t a deficiency on Quark's part.
It's something the application needs to do unless it's safe to assume the
image is in monitor RGB (which isn't always safe to assume).
>
Adobe Illustrator never generated CSAs and CRDs. I checked with
>
Shankar Iyer for AI6 and again recently.
I wouldn't expect it to generate CRDs. And if it doesn't generate CSA's
then that is a "deficiency" on the part of Adobe. And not one I blame
them for anyway because I don't really see this stuff working in the real
world. Those who get it to work are few and far between, and it's always
in a close-loop system with specific devices.
>
Meaning that PostScript Color Management was never a reality, and
>
that vector data were always handed off without a CIE reference,
>
either to the PS CMS (CIEXYZ) or the ICC CMS (CIELab / CIEXYZ).
This much is certain. But the lack of vector support in this color
management model is just another problem, and a relatively minor one
considering all of the other problems with actual implementation. It's a
good idea I think, but it's just such a mess that nothing short starting
over totally would make it viable. And since that isn't going to happen
any time soon, I'd say it's not viable except in the case previously
noted.
Chris Murphy