[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


 icclink -v -qh -G -i4 -c3 -d0 sRGB.icc your-printer.icc devicelink.icc

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.

Regards,
Gerhard




Other related posts: