RSS/Atom feed Twitter
Site is read-only, email is disabled

CMYK and GEGL

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

1 of 1 message available
Toggle history

Please log in to manage your subscriptions.

CMYK and GEGL Øyvind Kolås 15 May 00:53
Øyvind Kolås
2007-05-15 00:53:25 UTC (over 17 years ago)

CMYK and GEGL

I do not know when support for CMYK in GEGL will be added, but the initial support will most probably be as described below, and it can be added without being intrusive on the current code. The various tasks that needs to be done should probably be filed against GEGL as separate enhancement requests in bugzilla.

GEGL itself at the moment focuses mostly at mixing and processing High Dynamic Range additive RGB light. When introducing CMYK subtractive mixing will be added but initially only for export purposes. The following new operations would be desirable:

It should be possible to transform buffer data to CMYK buffers by supplying an ouput profile and a rendering intent, as well as rendering a mask indicating out-of-gamut colors. Both of these tasks will be implemented as operations. And should provide a core set of functionality allowing some control over generated CMYK values, and for most uses sufficient control.

These operations will need some changes and additions to the GEGL code most specifically a ICC profile property on GeglBuffers that is propagated correctly through the graph.

When matching colors in a print job between rasters originating mainly in photographs with CMYK vector graphics, it would be advised to use a color picker on the written output CMYK file intended for inclusion in print. Since if
painting is done on RGB buffers in this model with colors picked in CMYK, the information about the black seperation in the user specified CMYK values is lost.

It should then be possible to add CMYK specific operations, as well as making the existing internal ones CMYK aware. For some operations where abstracting away the number of colorant components, it might be desired, but in most instances I would argue that it adds unneeded complexity to the code.

Being able to preview the range available, perhaps even using perceptual compression of values for display.

The operations could perhaps be structured as follows:

apply-profile -------------
apples a color profile to a buffer, should be followed by an operation that expects CMYK data if the buffer has been converted to CMYK in the process to avoid information loss.

properties: profile - ICC-profile
intent - absolute colorimetric, relative colorimetric, perceptual. convert - boolean value, convert image default value is TRUE.

gamut-distance --------------
generate a gray scale map indicating how far outside the gamut boundary a color is.

properties: profile - ICC-profile being converted to.

A sample chain of operations taking a photo from a raw file, and making a sharpened CMYK file tagged with a profile.

load path:rgb.raw
apply-profile
profile:mycamera.icc
convert:false
apply-profile
profile:sRGB
convert:true
auto-levels
unsharp-mask
std-dev:3.0
amount:0.2
apply-profile
profile:swop.icc
convert:true
save
path:cmyk.tiff

/Øyvind K.