[cairo] [RFC] Color space API (partial proposal)

[Adrian Johnson]

ecir hana wrote:
> On Tue, Feb 23, 2010 at 12:35 PM, Adrian Johnson <ajohnson at redneon.com> wrote:
>> I see the problem with my DeviceN API now. The PDF tint transform function
>> transforms n tint colors to m color components in the alternate color space.
>> I'm not sure of the best way to define a cairo API for this.
> 
> There are several things which can be done about this:
> 
> - ask the user to explicitly supply multi-dimensional table of
> tintTransform samples, making it Not Your Problem. The format of such
> table is defined here:
> http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf
> 3.9.1 Type 0 (Sampled) Functions, p. 169
> 
> - it is my understanding that is is possible to convert one type of
> profile to another type and at least one type is basically a 8-bit
> LUT. That is, you wouldn't specify the profile of DeviceN, only for
> each of the colorants. Then, you consolidate the various spaces into
> one common space and there you blend all the colorant's alternatives.
> Next you somehow skew (not sure if there is support for this in CMS)
> the space so that the final blend lays at its edge. LUT of such space
> would equal to tintTransform.
> 
> - you would ask for LAB alternatives but I don't know how to to
> calculate a tint out of LAB color, nor how to blend many LABs into
> one. It would be nice to have LAB alternatives, but someone would need
> to explain how to do those operations otherwise it is not very useful.
> InDesign might very well use LAB and who knows what else but it might
> also be the case that they are closely working with, say, Pantone and
> the whole conversion process is proprietary.
> 
> - define just one CMYK profile for DeviceN and don't specify further
> profiles for the colorants, just the tints values. Blending would be
> done as I explained above, tint values as well. Think PDF/X-1a.
> 
> Naturally, I lean towards the last option as it can be implemented now
> and covers reasonable portion of alternatives (which you have to
> understand are just a substitute for the original spot, anyway).
> Besides, as this "Color space API" is designed in a way it is as
> orthogonal to the rest of Cairo as possible, you could add new kind of
> fallback based on spectral and opacity data sometime in the future,
> when they become more common.
> 
> (Again, for all the people demanding LAB - why not - how to do
> blending and tints? And please note, even LAB wont cover all of the
> possible spot colors.)

After looking at the ICC specification it should be possible for the PDF 
backend to generate a tint transform from an ICC profile for a DeviceN 
color space and an ICC profile for the alternate color space.

My revised DeviceN API is:

/* Create a Device N color space.
  *   device_n_profile - a color space created from an ICC profile
  *            used to transform the DeviceN color space into an
  *            alternate color space.
  *   alternate_profile - the color space to use for the alternate colors
  */
  cairo_color_space_t *
  cairo_color_space_create_device_n (
                      cairo_color_space_t *device_n_profile,
                      cairo_color_space_t *alternate_profile)


/* Specify a colorant in a DeviceN color space.
  *   colorant_num - the colorant to set.
  *   name - the name of the colorant
  */
  void
  cairo_color_space_set_colorant_name (cairo_space_color_t *color_space,
                                       int                  colorant_num,
                                       const char          *name)