[Openicc] ALL YOU NEED IS A PROFILE, THE MYTH. (WAS CC Profiles In X Specification and dispwin)

[Robert Krawitz]

   Date: Thu, 17 Jan 2008 01:13:30 +0100
   From: Gerhard Fuernkranz <nospam456 at gmx.de>

   But I also would not renounce profiles! Actually I find the way how
   gimp-print performs color conversion/correction too
   complicated. There are a bunch of controls, but the effect of the
   controls to the resulting colors, and the side-effects are not
   really clear and hard to predict.  IMHO, for instance the color
   workflow for a CMYK printer driver can be fairly simple, if it is
   based on color profiles:

The "high accuracy" mode is indeed quote complicated, and we don't
recommend that people use that mode as the basis for color management.
It's the default because we want people to get good results in a
non-CM environment, but anyone doing color management should use one
of the simpler color correction modes (uncorrected -- which really
means gamma corrected -- or density -- which is density-adjusted but
not linearized).

       * driver's CMYK input -> four 1D-curves which do the linearization
	 and the per channel ink limiting -> halftoning engine -> raster
	 data -> done

	 (the 1D curves should IMO support at least 10 or 12 bits/channel
	 on input, and 16 bits on output. The halftoning engine should work
	 with 16 bits/channel)

Gutenprint supports 8 and 16 bit inputs and does halftoning on 16 bit
quantities.

   and if the driver also wants to offer inputs for other color spaces,
   then the flow in the driver could look like

       * CIELAB input (is already PCS) -> CMYK profile for the printer ->
	 feed to driver's CMYK input

       * sRGB input -> sRGB profile -> PCS -> CMYK profile for the printer
	 -> feed to CMYK input
	 (this could even be optimized by using a sRGB -> printer CMYK
	 device link profile)

       * SWOP emulation input (CMYK) -> SWOP profile -> PCS -> CMYK profile
	 for the printer -> feed to CMYK input

       * etc.

   This way there are no hand-crafted color conversions are required.

   For CcMmYKk printers we would basically just need to extend the
   above CMYK model by three additional 1D curves, such that the Cyan,
   Magenta an Black channel of the CMYK input can be split into the
   corresponding light and dark ink components. For multicolor
   printers (with orange, green, red or blue inks in addition to
   CMYK), I admit that the model will become a bit more complicated...

Yes, but we need to handle these cases.  The simple channel splitting
model for light channels has some limitations; I suspect, for example,
that the hue and saturation doesn't perfectly match.  Then there's the
whole issue of ink limiting.  For black ink, sometimes the light inks
have a significant hue and the darkest black is neutral.  You also
missed the drop size issue.

The way we do CMYKRB (it extends to additional inks) is to convert to
HSL, and pick the right combination of color inks from the hue (we
don't use the auxiliary inks in gray/black generation).  It's not all
that scientific; it kindasorta works, but I'd like to do better.

   I don't want to go deeper into details now. However, the important
   issue is IMHO that driver models like above should be well-defined,
   well-documented and fixed, i.e. the behaviour should not change
   incompatibly from version to version. Also the halftoning algorithm
   should not change, since this would have an effect on the color
   reproduction (new halftoning algorithms could of course be
   introduced additionally in new versions, but the old ones should be
   retained too).

Actually, that's pretty much the rule for Gutenprint within a stable
version (e. g. all the 4.2 releases used the same color correction and
same tunings for printers, and likewise within 5.0).  I agree with
this rule.

   Stable driver models would IMHO be a prerequisite in order that a
   repository of calibration curves and ICC profiles for various
   printer/ink/paper combinations could be established by the
   community.  The driver would just implement the bare model(s), and
   the parametrization of the model(s) would come from the repository.
   Additionally there should be tools, which aid in the establisment
   of the calibration curves for the different driver models (CMYK,
   CcMmYKk, multicolor,...) from measurements. Tools to create ICC
   profiles are already available, e.g. Argyll and commercial ones.

Well, OK, but the question of handling the different physical printer
setups is very important for modern printers...

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

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

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