[Openicc] [Printing-architecture] [Gimp-print-devel] Colour

[Robert Krawitz]

   Date: Tue, 17 Nov 2009 02:08:14 +0100
   From: Gerhard Fuernkranz <nospam456 at gmx.de>

   Kai-Uwe Behrmann wrote:
   > Am 16.11.09, 15:16 -0500 schrieb Chris Murphy:
   >> On Nov 16, 2009, at 12:36 PM, Kai-Uwe Behrmann wrote:
   >>
   >>> There will be people who complain about the missed capability to hand tweak their colours. This is quite natural. A way to satisfy those demand is to support effect profiles, which fits well with the point above.
   >>
   >> Abstract profiles could do these kinds of edits in the PCS. Either as an advanced  panel of sliders that institute edits in the PCS - a sort of on-the-fly abstract class  profile. Or a separate means of creating them and just allow a pop-up menu of selections. I like the slider approach.
   >>
   >> I think it's important to not have effects baked into output device profiles.
   >
   > Can the effect profiles be applied in a late binding style - remotely after spooling?

   Well, where and when in the pipeline is the rasterizing is done?
   Once the document has been half-toned, it's rather impossible to
   apply color transformations any more (i.e. in case the final raster
   data were spooled).

Usually the rasterization happens very late in the pipeline -- just
before sending the data directly to the printer.  I recall that
GNOME-Print wanted to do it much earlier (I spent some time trying to
talk them out of it, pointing out how things blow up when rasterized,
in addition to other problems such as drivers detecting what media is
loaded and so forth).  I don't know what they wound up doing.

   And applying an additional device -> PCS -> abstract -> PCS ->
   device transformation in a *separate* post-processing step (after
   converting the object colors to the color space associated with the
   printer's process color model, but before half-toning) will
   certainly not help to improve the overall accuracy of the color
   transformations, and some colors may already have been clipped,
   which cannot be undone any more afterwards by a de-saturation
   effect (though this clipping would have been avoided if the
   de-saturation would have been applied before applying the output
   profile). So I think the effects should be rather incorporated into
   the color transformation chain from object colors to the printer's
   process color model. Or alternatively, the intermediate color space
   before applying the effects would need to be rather PCS.

That's why I think the intermediate color space should be high
precision with extremely wide gamut.  I know memory and CPU isn't
free, but I think arguing over 8 vs. 16 bits of precision is
distinctly penny-wise and pound-foolish.

-- 
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  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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