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

[Robert Krawitz]

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

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

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

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

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

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