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

[Robert Krawitz]

On Thu, 19 May 2011 13:24:11 +1000, Graeme Gill wrote:
> 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.]

True.  Everything I've ever seen from the OEM drivers -- including
through the x600 printers -- has been ESC/P2.  I haven't seen output
for later wide carriage printers, but there isn't that much difference
between the x600, x800, and x880 printers that I've observed.  ESC/P-R
has been presented to me as something appropriate for lightweight
drivers for embedded devices (phones and such) because it takes much
less compute power and memory on the host.

>> * 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.

That's true.

>>    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.

Again, that's true, but it would be hard to see the business reason
for creating a halftone driver for each printer that they're not going
to then use.  It would mean a fair bit of engineering and testing work
for not much additional income (how big is the RIP market compared to
the OEM market?).

And if they're not in fact using ESC/P-R, why would they go to all the
effort to make the firmware sRGB emulation be tunable and downloadable
only to have their driver not use it?

I can clear this up very quickly if someone can capture output to the
printer for me.

>>    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.

Well, *firmware* downloads are almost always encrypted, and this is in
essence part of the firmware.