[Openicc] color-policy vs. color-infrastructure

[Graeme Gill]

Jan-Peter Homann wrote:
> 1) CMYK-Output with individual black generation
> -----------------------------------------------
> Reading the colorsync-mailinglist, prepress users often want to change 
> the black generation of the standard CMYK-profiles from the Adobe 
> Creative Suite. To do this, they need to buy a profiling software, which 
> coasts at least 1000,- $
> In argyllcms, this is just a function to use. (Please correct me graeme, 
> if I´m wrong). So for e.g. the GIMP, Scribus, Cinepaint or later 
> Inkscape, it would be not a big deal to deliver this functionality.

It's certainly possible to do this, but I'm not sure if it fits
in the core of a CMM. It's of interest only to graphics professionals
who are likely to want to re-target CMYK, while typical users (even
creative types) are far more likely to be working in more flexible
RGB or CIE spaces, and leave the conversion to the more device and
function specific CMYK until the end of the process (assuming the
goal is printed output).

There is nothing to stop a CMM having an optional preference option
that influences a CMYK->CMYK conversion to preserve black, but it
is not currently something that can be expected of all CMMs, and it
can't be applied across the board, since on many devices the choice
of black generation is very technology dependent.

In the near future I would therefore expect that people who are worried
about preserving black in a CMYK->CMYK conversion will handle this
with a particular tool, and the most they might expect out of a
system CMM is the ability to configure a device link transform to
handle the use of the transformation automatically.

My personal view is that there is room for a technical advance
in which a "rendering intent" attribute accompanies every color
value, so that the underlying purpose of preserving black
can be handled properly. (ie. rendering intent is much like
an alpha plane, except it encodes things like "render this
as black text" etc.)

I thin it's pretty reasonable that a CMM designed at this point
in time support the options of asking for a properly tailored
gamut mapping though (a proper approach to the current
"black point compensation" hacks etc.). This would be a major
practical step forward compared to the currently deployed CMMs.

So in summary, some candidates for new generation CMM features might be:
* Support on-the-fly gamut mapping computation
* Support device links as special cases for particular conversions
* Support rendering intent plane color value extension

> 2) Storing color corrections as abstract or devicelink-profile
> ------------------------------------------------

This is another good idea supported by the ICC format and very
under-utilized.

> graeme, can you describe, if this is already possible with argyllcms, or 
>  how much work must be invested, to do this ?

It's not too hard with the building blocks there. Convert the before and
after RGB values into PCS (probably L*a*b*). If the image is not
a test chart (ie. it was a real image), reduce the number of color
mapping points using a quantisation algorithm (median cut worked well
for me in xli). If the mapping points don't form a full regular grid,
throw them into the thin plate spline code and create a regular grid
mapping. Save the regular grid as an abstract profile.

Graeme Gill.