Re: [Gimp-print-devel] Gutenprint, Mac OS X, R1800 and Color Matching tab

[Robert K. <rl...@al...>]

   Date: Mon, 21 Jul 2008 11:04:56 -0700
   From: "Aleksandar Milivojevic" <al...@mi...>

   On Mon, Jul 21, 2008 at 10:24 AM, Michael R Sweet <ms...@ap...> wrote:
   > Aleksandar Milivojevic wrote:

   Thanks for quick response.

   Is there a way to prevent the printing system from touching the
   colors (do any kind of color correction) when using Gutenprint
   driver?  The way I read your response, it doesn't seem there is.

   The applications I'm using (Photoshop and Aperture) will handle
   colors, and will send already color corrected image when printing
   to the printer (corrected for specific model of printer and type of
   paper and ink).  If anything touches those colors (ColorSync or
   Gutenprint driver), the colors will be ruined.

So here's the really long answer to this, from the Gutenprint
standpoint:

There's an unequivocal yes answer, and several other yes answers with
varying degrees of equivocation, but I suspect that none of them are
what you want.

Inkjet printers, by their very nature, are not 8 or 16 bit monotonic
RGB devices.  They're 1 or 2 bit devices in what's at best a highly
nonlinear (and probably non-monotonic) inverse RGB color space.  Since
most inkjets aren't CMY devices (CMYK, CcMmYK, or even stranger
spaces), they're really DeviceN, and the Stylus Photo R1800 is one of
the worst in this regard (CMYKR"B", which is really purple).  So you
first face the problem of collapsing 8 or 16 bits down into 1 or 2
bits in an entirely foreign color space that's non-uniform, highly
non-linear, probably non-monotonic, non-orthogonal, and interacting
(mixtures of inks may not have the same response as the individual
inks).  The driver is going to do this in (almost) any event, so it's
performing a non-idempotent color transform in any case, which you
could interpret as being a "correction".

Gutenprint *does* offer a way to send true 1 or 2 bit DeviceN data to
the printer, which I can tell you about if you really, really want to
know, but I don't think you do (it's called raw input with Predithered
color "correction" -- basically low bit sampling).  That's the
unequivocal "yes" answer; in this case, the driver simply performs
weaving, generation of printer control codes, and ships it all off.
It offers additional options short of that:

2) 8 or 16 bit DeviceN input color space, which the driver dithers
   down to 1 or 2 bits with only ink drop size adjustment on variable
   ink drop size printers (this is called raw input with Raw color
   correction).

3) 8 or 16 bit RGB or CMYK input color space, which the driver
   converts to DeviceN color space with no linearization or density
   correction (called Raw color correction).  This provides reasonably
   complete results on printers without really exotic inks, but the
   R1800 is one of those printers with really exotic inks.

4) 8 or 16 bit RGB or CMYK input color space, which is converted to
   DeviceN with density correction but no linearization curves applied
   (called Density color correction).  This or Raw color correction
   are good choices for people who want to do their own linearization
   and ink limiting.

5) 8 or 16 bit RGB or CMYK input color color space, which is converted
   to DeviceN with density correction and linearization curves applied
   (however good or bad they may be), which is called Uncorrected
   color correction.  This is normally what we recommend people use
   with profiling.

Then there are various degrees of correction in HSL space: hue only,
adjustment offering brighter colors, and full adjustment.

The upshot of all this is that if you want to provide anything other
than DeviceN input, the driver *is* going to do something with your
input, and there's no way around it.  That's the nature of such a
device.

What I suspect you *really* mean is that you want the driver to
provide the same channel response as the Epson-supplied driver, which
we don't offer and have no plans to ever offer.  This would be a huge
job and wouldn't let us take advantage of any improvements that we
care to make.

BTW, it's not just the choice of paper and ink -- it's also choice of
resolution.

   I could tell Photoshop and Aperture to leave color management to
   the driver (which would produce suboptimal workflow and results).
   However this won't really work.  Because there is still problem how
   to create ICC profile for the printer.

As I explained above, you can't create an ICC profile for the
printer.  You need to create a profile for the combination of printer
and driver, because the printer's color space is so radically
different.  Monitors and scanners really do deal with hardware (or at
least firmware) RGB in reasonable bit depths, but inkjet printers
don't (dye sublimation printers do).

   In order to create color profile for the printer, I need a way to
   disable ColorSync (or any other color correction in the driver or
   other parts of printing system) when printing calibration pattern.
   My spectrophotometer would be measuring the response of both the
   printer and whatever profile ColorSync used.  Instead of just
   measuring the response of the printer.  If I can't disable
   ColorSync in print dialog, then I can't create a profile to be used
   by ColorSync.  Kind of circular dependency.

I agree that you need to be able to disable ColorSync for this, but
for the driver, you just need to select a reasonable choice of color
correction (Uncorrected, Density, or Raw depending upon just how fussy
you want to be with linearization and ink limiting) and stick with it.

   Third possibility would be to select some generic color profile in
   ColorSync, calibrate with it, and than let applications manage
   color.  This is very very suboptimal (the color profiles will be
   applied twice, with custom generated profile correcting both the
   errors of printer and generic profile).  Xrite tech support
   (manufacturer of my spectrophotometer) strongly advised against
   this approach.

Mike, perhaps ColorSync could offer an idempotent profile for just
this purpose?

-- 
Robert Krawitz                                     <rl...@al...>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton