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

[Graeme Gill]

Kai-Uwe Behrmann wrote:
> Am 14.11.09, 17:11 +1100 schrieb Graeme Gill:

>> Yes, basically this is a really dumb API for turning color management 
>> off.
>> The right way to do it is to have a flag that turns color management off,
>> rather than relying on the software to figure out what profile is being
>> used for the end device, and labeling the file as already being in that
>> space. It's easy to demonstrate that this is sematically incorrect -
>> if you were to spool the file and then replay it after the device
>> profile has been changed, it will print incorrectly.
> 
> I am not familiar with such a flag. So I may ask, where does this apply 
> to which API? The print API while sending data which gets converted to PDF?
> The CMS, which is responsible to do the colour conversion or has in that 
> special case to omit a conversion? ... or the spooling system? ...

The RIP or equivalent - the thing that converts incoming PDL
color to the device color.

> Following  Chris' explanation, a print system "correctly" supporting 
> Device(RGB/CMYK/GRAY/N) in PDF/X-3 will have a path to pass all colour 
> management conversions unaltered. Could this become a simple means of 
> implementing Mike Sweets less is more scheme of hiding CM controls? It 
> would mean generate according targets and send them through CPD as file 
> to the selected printer.

The problem is that for historical reasons, many applications print
to Device(RGB/CMYK/GRAY) and expect reasonable looking output. For
this reason many RIPs assign default profiles to these spaces,
and in fact PostScript 3 actually has flags within the language
to do this (I can't remember off hand if the same applies to PDF).

So to truly get device space, you need some other flag beyond
using Device(RGB/CMYK/GRAY).

> Still unresolved is the per paper ICC profile selection. To solve that 
> point CPD would be in need to add custom entries to non traceable 
> variables. These are mainly media and ink types which a driver has 
> currently no way to know of in a programatic manner.

Right. My thought is that even if the RIP/driver automatically
chooses a profile to suite a particular printing media & mode,
it should show the user which profile it picked, so they
can see what's going on.

The problem of mapping a combinatorial explosion of printing modes & media
to available profiles is something I would tackle as follows:

   Assign weights to matches of the various parameters, and
   choose the profile that has the highest weighted match.
   Warn if the match is not perfect.

This allows the users to get the best possible output, without
insisting that profiles be available for every possible mode/paper
combination. If they are not satisfied with a non-perfect match,
and they have instruments and profiling software available,
then they can generate a profile for that particular combination.

Note that if there is a calibration system as well, then additional
options become available, such as using a non-perfect match profile
with a calibration specifically for that profile in combination
with that mode. This is a quick and easy way of improving
the quality of that mode without making a profile.

Graeme Gill.