[argyllcms] Re: RGB Printer profiling and ColorSavvy CM2C
From: Gerhard Fuernkranz <nospam456@xxxxxx>
To: argyllcms@xxxxxxxxxxxxx
Date: Tue, 02 Aug 2005 21:50:26 +0200
Alastair M. Robinson schrieb:
Hi Alastair,
Agreed - which is why Robert's had such a rough time getting it to
look good!
I'm actually suprised that it is possible at all to obtain good results
with such an intuitive approach :-)
At the moment, though, we can at least disable all our colour
mangling, and with my own PhotoPrint application we can print images
using an appropriate profile.
Is it possible to print for instance raw 16bpp *N-color* data (e.g.
CMYKRB), such that the driver only performs the halftoning for each of
the N channels, and the ESC/P stuff, but nothing else?
If I'm informed correctly, Gutenprint also supports a pre-dithered mode,
where it only handles the ESC/P stuff, while everything else (inc.
halftoning) can be done by the application, is that correct? Does this
mode also support multiple ink-levels (drop sizes) per pixel?
Btw, this is likely off-topic, but just came into my mind, and maybe you
know the answer: When I print an image from gimp to a PostScript file,
the DeviceRGB colors written to the PostScript file are *different* from
the RGB colors in my image. Do you have any idea, what kind of color
mangling gimp-print does apply, or whether and how I can avoid it? (To
deal with this color mangling I have actually profiled the (unknown)
transformation with an input profile, and created a PostScript CSA,
which I send along with the PS file to the PS interperter for printing,
but this is rather a wokaround and does not make things more accurate ...)
You get a much better result from all points of view, if you
are doing lots of conversions between two colorspaces, if you
use a device link profile (icclink -G etc.).
I haven't tried it yet, but I imagine that's a rather expensive
operation, yes?
It is as simple as using the "profile" command. See the docs for
"icclink". For example
Since the CLUT tables do not have to cover the complete CIELAB space as
input, but only need to cover the source color space (which is usually
only a small subset of CIELAB), the device link will have a higher
accuracy than the B2A tables of an output profile with the same number
of grid points. Furthermore, as Graeme said, "icclink -G ..." will
establish a gamut mapping directly between src and dst color space,
bypassing the double gamut mapping from src profile -> PCS, and from PCS
to dst profile.
Regarding "expensive operation": Yes it takes some time, though it's
faster than creating a device profile. But it is probably not an option
do run "icclink -G ..." on the fly, each time a print job is exeecuted.
