[Openicc] Introduction / Gutenprint

[Michael Sweet]

Robert L Krawitz wrote:
>    Date: Tue, 12 Apr 2005 08:22:25 -0400
>    From: Michael Sweet <mike at easysw.com>
> 
>    Graeme Gill wrote:
>    > ...
>    > 3) Put the RIP and ICC based machinery in series. I.e. RIP to a 
>    > standardized
>    >     RGB or CMYK, and then do a device to device + separation + calibration
>    >     after the RIP. Device links can't work, and accuracy, gamut size and 
>    > speed
>    >     are compromised.
> 
>    Another issue with this approach is performance - doing color
>    management at this point means processing a LOT of pixels, ~45million
>    for a 720 DPI letter/A4 page, and most printers support higher
>    resolutions these days...
> 
> Why can't the driver upsample the color managed input from the
> ICC-based machinery, much like what Gutenprint already does?

The driver certainly *can* do that (and many do), however a lot of
users demand that they can RIP at the full device resolution, whether
it makes sense or not... :)

Anyways, assuming that you use a common base resolution of 600 or
720 DPI and upsample from there, you are still looking at a LOT of
color transforms.  Putting the transform in the RIP allows you to
optimize things such that you only transform the number of colors
in the input data (e.g. pixels in embedded images, colors for text
and paths, etc.) rather than the number of pixels in the output
data.

Also, interpolating/antialiasing in the output colorspace typically
produces better results, although you need to be careful when
scaling images and compositing...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com