[Openicc] Printing targets: App or driver ? Profiling RGB or CMYK

[Graeme Gill]

Robert Krawitz wrote:

> "DeviceN calibration burnt in" that the driver cannot read back makes
> no sense *whatsoever*, since the printer isn't receiving data in any
> kind of color space, but rather a complete specification of what drops
> are printed.

Right, but it's also possible that they can set the peizo drive
values, which will alter the ink volume at a particular drop size.
(But I see you mention this latter :-)

[Just a possibility to keep in mind. My guess is that it's more
likely that they can change their sRGB emulation, or that
it's being done in the host and the host is driving it
in Device-N. Simply looking at what mode their drivers use
should narrow this down pretty quickly.]

> * Profile data that's created by a fairly normal process involving an
>    external colorimeter.  The advantage of storing this on the printer
>    rather than the host is that if you move the printer around, the
>    profile follows the particular printer, but the driver has to read
>    it out.  This too makes perfect sense.

If it was stored anywhere else, it would be a manufacturing problem -
they'd need to burn individual CD's for each printer. This is unlikely.

>    I can understand Epson keeping this proprietary (but I don't have to
>    like it), but it doesn't explain why third party RIPs using the
>    Epson halftone module can't access it.  Maybe because this interacts
>    with the color module, not the halftone module, and it wouldn't mean
>    anything except in the context of the Epson color module?

If it only changes the built in sRGB emulation and the halftone module
drives it Device-N, then this would explain it.

>    There could always be an encrypted metadata exchange between host
>    and printer, which would make it harder to analyze this (the actual
>    raster data is not encrypted).

Possible, but manufacturers don't often resort to this.

Graeme Gill.