Hi John,

On Mon, Jun 30, 2008 at 7:22 AM, John Culleton wrote:

A book by MIchael J. Hammel, _The Artist's Guide to Gimp Effects_, published in 2007, states that the "next release" of Gimp is scheduled to offer the CMYK color model. But that seems not to have occurred, alsthough there is a CMYK preview mode.

Is CMYK color model off the agenda for Gimp? It has been under discussion for years. Other Open Source products, such as Krita and Scribus, will work in that model. but they lack the capabilities of Gimp. So is there any hope?

CMYK is definitely ON the agenda. It is a long term thing. GEGL is currently being integrated. Once that is substantially completed (ie. GIMP supports varying colordepths (8bit, 16bit, float,..) and colorspaces (RGB, Yuv, LAB,..), working at an acceptable speed), introducing CMYK support will be relatively simple. I would expect that there might be some limited/experimental CMYK support by 3.0, based on the current rate of integration.

David

On Mon, Jun 30, 2008 at 1:55 AM, David Gowers wrote:

Hi John,

On Mon, Jun 30, 2008 at 7:22 AM, John Culleton wrote:

A book by MIchael J. Hammel, _The Artist's Guide to Gimp Effects_, published in 2007, states that the "next release" of Gimp is scheduled to offer the CMYK color model. But that seems not to have occurred, alsthough there is a CMYK preview mode.

Is CMYK color model off the agenda for Gimp? It has been under discussion for years. Other Open Source products, such as Krita and Scribus, will work in that model. but they lack the capabilities of Gimp. So is there any hope?

CMYK is definitely ON the agenda. It is a long term thing. GEGL is currently being integrated. Once that is substantially completed (ie. GIMP supports varying colordepths (8bit, 16bit, float,..) and colorspaces (RGB, Yuv, LAB,..), working at an acceptable speed), introducing CMYK support will be relatively simple. I would expect that there might be some limited/experimental CMYK support by 3.0, based on the current rate of integration.

Beware that in many instances people manipulating photographs in CMYK mode in photoshop should probably have been working in RGB and converting to CMYK in the end.

Currently GEGL is a powerful engine for processing in three dimensionsal color spaces, most operations are performed in linear light RGB by converting the pixels when needed (and avoiding to do copies when possible). This works fine for RGB, R'G'B', CIE Lab, Y'CbCr, HSV and other color spaces that are three dimensional / tri-stimulus.
CMYK is not one of these as it is fourdimensional and a roundtrip CMYK -> RGB -> CMYK isn't lossless no matter what precision your components have.

The only way it is advisable to use GEGL with CMYK in it's current state would only be for conversion to CMYK space as the final step. I think this is sufficient for professional quality work for 98% or more of potential users. The use cases involving actual processing or compositing in a CMYK color model I'll say are outside the scope of GEGL for now and would have be performed by processing the individual color plates as grey scale layers. Even for pre-press this might be enough since proper compositing in CMYK will probably involve knowing how the ink spreads in the paper and physically interacts with the light being reflected.

I am happy with GEGLs current limited focus on three-dimensional (plus alpha) color models, this might be expanded with something resembling spot colors, for z-buffers from 3d renders for use in compositing, as well as native support for multi-spectral pixels if I find the need. Native CMYK compositing and processing is something I consider to be of little benefit to most and of minimal interest to myself, thus I am unlikely to spend much time on it.

/Øyvind K.

On Mon, Jun 30, 2008 at 12:29 PM, Øyvind Kolås wrote:

I am happy with GEGLs current limited focus on three-dimensional (plus alpha) color models, this might be expanded with something resembling spot colors, for z-buffers from 3d renders for use in compositing, as well as native support for multi-spectral pixels if I find the need. Native CMYK compositing and processing is something I consider to be of little benefit to most and of minimal interest to myself, thus I am unlikely to spend much time on it.

Just to add a note, this wouldn't stop someone from modifying GEGL to be capable of having a set of CMYK processing operations, or alternate code paths for dealing with CMYK buffers in existing operations. If done correctly without intruding much on the existing code - patches that implement the missing functionality would be welcome.

/Øyvind K.