[Openicc] Printing targets: App or driver ? Profiling RGB or CMYK
rlk at alum.mit.edu
Wed May 18 17:18:27 PDT 2011
On Thu, 19 May 2011 01:15:32 +0200, edmund ronald wrote:
> I thought it is hard printer calibration, ie. you need the native driver to
> calibrate, and a spectro, but once you've done it the printer is calibrated
> to behave to the standard with any software you use with it.
People are making a lot of assumptions about what's going on when we
don't even know that it's anything more sophisticated than generating
a host-side profile. Let's analyze some of the possibilities, but to
do that intelligently, we have to have some background.
For starters, let's distinguish between ESC/P-R (which allows
selection of either grayscale or sRGB -- maybe there are other
built-in profiles, but I'm not aware of any) and ESC/P2 (DeviceN).
These are completely different. I don't even know that the Stylus Pro
printers accept ESC/P-R, but let's assume that they do for the sake of
ESC/P-R accepts standard 8-bit grayscale or 24-bit sRGB in a simple
bitmap (you can also pass JPEG data this way). It doesn't give you a
lot of choices of resolution; I think the choices are 360 DPI and 720
DPI (that alone suggests that it isn't being used by the OEM driver,
but again, let's waive that for now).
ESC/P-2 accepts DeviceN data, one channel at a time. It is *not* 8
bit linear or the like. Each printer supports several sets of drop
sizes, with 3 drop sizes per set (so one set of drop sizes might be 3,
8, and 11 pl, for example). At the beginning of the page, you tell it
which set of drop sizes you want to use and the units for measurements
to be interpreted (those units can be things like 1/360",
1/720"...1/5760"). There's more to it than that, but for our purposes
that (probably) doesn't matter. In any event, when you get right down
to business, an ESC/P-2 driver specifies, for each ink channel and
drop position, which one of the three drop sizes (if any) will be
printed. Each channel is sent to the printer separately, in any
order; you specify which channel you're printing, followed by packed
"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
(There *really* is more to it than that -- a lot more. If you're
curious, read the developer documentation in the Gutenprint
distribution. In particular, there's something called "weaving",
which can affect microbanding. It's conceivable that a printer
profile -- as opposed to an ICC profile -- could contain information
about that, but right here it really doesn't matter.)
I've observed that the OEM driver sends a blob of opaque data to the
printer in the initialization sequence. The command that's sent is
from the "set mechanism sequence" command family, and I've observed
that mucking with that can cause the paper to feed differently or
sometimes suppress any printing. For example, on the C80, if I took
the blob from the OEM driver for plain paper, it would feed much
faster. If I mucked with that command, it might slow down the paper
feed to the default speed.
So let's assume that there's data stored on the printer and perhaps
the cartridges. What might that data be?
* Spectrographic or other colorimetric information about the
particular ink cartridges. This would make a lot of sense, and
would be one of the few end-user benefits of chipped cartridges.
It's very obvious how a driver could use that information.
It could be tested by reloading a cartridge from another OEM
cartridge and resetting the chip (Epson doesn't support that, but
there are third party ways of doing this). If that resulted in
different output from the original second cartridge, it would
suggest that the driver can read colorimetric data from the
* 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.
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?
This wouldn't be too hard to test, with two different printers of
the same model; print a fixed job to both printers, and capture the
output. Since the driver might randomize the output, this procedure
may not be quite as straightforward as it sounds at first glance,
but I think it would be possible to analyze this.
* Actual measured drop sizes. This would make some sense. A printer
with a nominal minimum drop size of, say, 3 pl might actually vary
some. Actually, each nozzle in the head might also vary, which is
part of the cause of banding.
The problem with this is that mechanical wear on the nozzles will
slowly enlarge them. Perhaps the calibration procedure allows the
driver to update the nozzle sizes.
One difficulty with this theory, though, is that different papers
will have different responses to the ink, in addition to ink
variations. So unless the paper itself is very well calibrated and
stable long-term across batches, it's hard to be certain what the
ink requirement really means in terms of nozzle sizes. But if
you're simply trying to ensure that a particular paper and ink are
tuned to work well together, this kind of calibration would make
sense. But there's nothing particularly magical about that.
* Ink limits. This could apply for real with ESC/P-R, but I don't
think that that's what the OEM driver uses, as I've previously
explained. For ESC/P-2, there's no practical way that the printer
can apply ink limits; it has to be done in the driver. The only way
to do that on the printer is to suppress printing some drops, which
will wreck the screening pattern. It could certainly be storing
suggested ink limits that the driver could retrieve, but then you're
back to the problem of long-term stability of paper manufacture.
* Micro-adjustments to the actual drop size. This is the most
intriguing possibility, and would be more difficult to test. I'd
probably have to look at the initialization sequences to two
printers (in addition to bidirectional communication) to figure this
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).
*Personally*, I doubt that the printer's storing anything more
sophisticated than a profile, if it's storing anything at all.
> On Thu, May 19, 2011 at 12:49 AM, Graeme Gill <graeme at argyllcms.com> wrote:
>> Chris Murphy wrote:
>>> Twould be interesting. Most useful would be if the resulting in-printer
>>> could be used with non-native drivers/RIPS.
>> That's why I mentioned it :-)
>> Of course it would be nice to know if the information can
>> be retrieved from the printer, so that external color
>> management can use it.
>> Graeme Gill.
More information about the openicc