[Openicc] printer, driver, CUPS, PPD, printing GUI, ICC-profiles, colord, Oyranos, taxi....

Michael Sweet msweet at apple.com
Thu Jan 26 09:55:12 PST 2012


On Jan 26, 2012, at 12:06 AM, Kai-Uwe Behrmann wrote:
> Am 25.01.12, 12:16 -0800 schrieb Michael Sweet:
>> We can choose to pass calibration data to Gutenprint, perhaps through ICC profile metadata, but that doesn't solve the general profiling case and requires a special app to profile just for Gutenprint.
> 
> It would be possible to standardise on a meta data tag for ICC profiles.

But every driver (and printer) will not share the same implementation for dithering, mapping from RGB/CMYK to DeviceN, etc.  And particularly for newer photo printers the RGB/CMYK->DeviceN mapping is non-trivial.

> However, how can a profiling application know that this tag is feeded to the rastertoprinter filter? Can a *toraster filter advertise inside the IPP protocoll that it is potential to do so? (I remember fuzzy *toraster was in CUPS a member of a one way chain.)

The *toraster filters don't need to know about the driver-specific metadata, just what colorspace to convert to and the ICC profile.  The drivers can (as needed) read the profile to get their metadata.

>> We can also choose to support an uncalibrated 16-bit DeviceN space where 0 means no ink and 65535 means 100% ink (for each color). This supports having a general profiling application and is not driver-specific.  And certain key information (such as number and type of colorants) could be supplied as PPD keywords for the Gutenprint driver ("this is a 7-color printer with C, LC, M, LM, Y, K, LK inks") which would take care of the initial defaults when working with standard colorants for the printer.
> 
> I am afraid such 7/8-channel profiles will currently be very large. ICC has no mechanism to define C+LC->combinedC conversions in order to store a calibration in smaller tables. The profile must currently contain a table from all source channels to the destination channels and back for the inverse table. We get for a 8-channel by very poor 9 grid points
> 134,217,728 table points * 3 PCS channels. Thats for one table. Add to that a different perceptual and relative colorimetric flawour and we can
> currently take that as a theoretical thing.

I'm not sure about the math above but I haven't run the numbers in a long time... I know I have been discouraged that ICC tables are based on a linear grid which requires a lot of grid points instead of having most of them "near the edges" where the higher sampling is needed.

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair



More information about the openicc mailing list