i am sorry, i didn't attach your letter like i should have. i hope that TheGIMP continues to support methods that are accessible to everyone.

There has been a thorough discussion of how to publish with linux and cmyk issues. My friend took the right path to printing and still got bitched at by the printer for not using a mac. I think they had to do a conversion anyways.

I am sick of this issue, personally.

I don't understand software development, but it seems like if it is needed it gets built. Gimp has been publishing and analysing xrays and such for a very long time, in computer years.

If you need it, if you want it, build it.

I prefer that the printers catch up to modern technology. For the prices they ask, i think they are lagging.

my 21 cents worth carol

On Sun, Jun 08, 2003 at 05:55:52AM -0400, Carol Spears wrote: [ ... ]

I prefer that the printers catch up to modern technology. For the prices they ask, i think they are lagging.

This is the wrong attitude: Assuming that you really are talking about new technology, you have to make sure that it's easy to move to a new technology without losing everything that was done in the past, and without requiring to completely change the way things are done.

But the more important point is that printers are already using new technology. There are a number of digital workflow management packages available from different vendors, printers are using DtP (Digital to Plate) systems or even fully digital presses. All of this however requires either a CMYK workflow, or a fully color managed workflow. You would never send just RGB.

Hi,

"Stefan Klein" writes:

I am a computer science student looking for a final year project. I'd love to do something in the Open Source community and I am looking around where my help might be needed. Having a little interest in graphics design and prepress, I came across GIMP and CMYK support. The little research I've done gives me the impression that over the last couple of years it's regularly been asked for and it might be an important feature to get GIMP into the pre-press world.

What I'd like to know is the following: 1. Is anybody actually working on this? There were hints now and then that people are thinking about it, but I didn't find anything definite, apart from an entry "Additional ColorModels" on the GEGL todo list (http://developer.gimp.org/gegl-todo.html) that seems to point in that direction.

I'd suggest you help to integrate CMYK support with proper color management into GEGL. The GIMP itself is almost feature-frozen and we are working hard at getting it released. That's probably not a good time to integrate CMYK support. We do hope however that GEGL will be ready for consumption when the release is out so that we can start to integrate it.

Sven

Hi,

On Sunday 08 June 2003 06:13, Stefan Klein wrote:

Hi all,

I am a computer science student looking for a final year project. I'd love to do something in the Open Source community and I am looking around where my help might be needed. Having a little interest in graphics design and prepress, I came across GIMP and CMYK support. The little research I've done gives me the impression that over the last couple of years it's regularly been asked for and it might be an important feature to get GIMP into the pre-press world.

Men, would that be great. I just joined this list about a week ago, trying exactly to check this issue: a native CMYK model.

However, taking a look at the code, I just thought it was too much for me, and was waiting for this subject to pop up on the list. As Sven had pointed out, it seens that such profound changes will have to wait gimp 2.0, and a re-writng of the core. It, however, have to be done, and its about time to start with it.

In the meantime, one of the things I am planning is developping a paliative plugin, that will separate the CMYK in different layers - or channels -. Such a Plugin could work from gimp 1.2 already, and has no need to make it in the official GIMP, while it waits for a true CMYK support - but could however make the GIMP more usable for pre-press.

Currently there is a image->mode->split to cmyk option, that however keep the colors addictive. Printing them requisres an aditional inverting in each channel. BTW, the plugin wihich I talk above could be as simple as calling this, and automatting the inversion. Adding some crop and register marks seen not to be hard, via plugin and PDB as well. For crop and register marks, however, the thing could be a little morre permanent than the color separation plugin, and would be a serious candidate to get to the oficial release.

I know very little of color separation theory by bnow, but it seens me that this separation ma ynotbe accurate. The newsprint filter (filters->distorts->newsprint) can make the separation as well, with an extra degree of control.

All in all Stephan, I am wiling to work along with you on this issue, even if I can be of little help.

And...Sven.. maybe there would be time to add a provisorie(sp?) CMYK to the Color Curves tool only before the release? What would you say?

Thanks,

JS ->

What I'd like to know is the following: 1. Is anybody actually working on this? There were hints now and then that people are thinking about it, but I didn't find anything definite, apart from an entry "Additional ColorModels" on the GEGL todo list (http://developer.gimp.org/gegl-todo.html) that seems to point in that direction.
2. How important is this really? What I am talking about is native CMYK support, not just a conversion function. There was a thread on the developers-list in November 2001 (http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/ msg01350. html) that gives the impression that it might not be all that important and that there might be cheaper workarounds (converting when saving, spot color channels). How important is a CMYK mode for people working in prepress? 3. Any guesses on the effort to implement this?

I'd appreciate it if you could answer asap, since I have to hand in my project proposals very shortly.
Thanks
Stefan

This is more about philosophy than an actual answer to Stefan's question, but maybe there it can inspire some more thinking.

This may be entirely my deficiency, but I am unclear on the general usefulness of having a native CMYK implementation. On one hand I understand that there is a perceived value of working with the four values, on the other hand I think we expose too much of the underlying guts of the colour implemetation and gamuts to the poor user already.

Converting RGB to CMYK is algorithmic. Here's the generalised algorithm:

c = (255 - r) * Cr m = (255 - g) * Cg
y = (255 - b) * Cb
k = max(c, m, y) * Cy

Of course the interesting part about the algorithm are what to choose for the values of Cr, Cg, Cb, and Ck, and *unless* you have the data on the printer, the inks (lot numbers and even age), and paper, any values you arbitrarily choose would likely be wrong.

A contribution here would be the development of a good colour abstraction interface. Let the user choose things like if the image is a COLOR image or a Black and White image (GRAY), with or without transparency. None of this business of values like 255 (white in 8bit rgb). Naturally there will be people who want access to the underlying knobs and switches, and that's okay. But we ought to at least put a cover over it.

I think CMYK ought to be a Save As option (as appropriate).

Helvetix

On Sun, Jun 08, 2003 at 11:13:33AM +0200, Stefan Klein wrote:

Hi all,

I am a computer science student looking for a final year project. I'd love to do something in the Open Source community and I am looking around where my help might be needed. Having a little interest in graphics design and prepress, I came across GIMP and CMYK support. The little research I've done gives me the impression that over the last couple of years it's regularly been asked for and it might be an important feature to get GIMP into the pre-press world.

What I'd like to know is the following: 1. Is anybody actually working on this? There were hints now and then that people are thinking about it, but I didn't find anything definite, apart from an entry "Additional ColorModels" on the GEGL todo list (http://developer.gimp.org/gegl-todo.html) that seems to point in that direction.
2. How important is this really? What I am talking about is native CMYK support, not just a conversion function. There was a thread on the developers-list in November 2001
(http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg01350. html) that gives the impression that it might not be all that important and that there might be cheaper workarounds (converting when saving, spot color channels). How important is a CMYK mode for people working in prepress? 3. Any guesses on the effort to implement this?

I'd appreciate it if you could answer asap, since I have to hand in my project proposals very shortly.
Thanks
Stefan

_________________

On Sun, 8 Jun 2003, Helvetix Victorinox wrote:

This may be entirely my deficiency, but I am unclear on the general usefulness of having a native CMYK implementation. On one hand I understand that there is a perceived value of working with the four values, on the other hand I think we expose too much of the underlying guts of the colour implemetation and gamuts to the poor user already.

[snip]

A contribution here would be the development of a good colour abstraction interface. Let the user choose things like if the image is a COLOR image or a Black and White image (GRAY), with or without transparency. None of this business of values like 255 (white in 8bit rgb). Naturally there will be people who want access to the underlying knobs and switches, and that's okay. But we ought to at least put a cover over it.

I think CMYK ought to be a Save As option (as appropriate).

Helvetix

I disagree. I hate it when software shields away the more advanced features. It is adjusting to the user, while the user should be adjusting to software instead. More than that, it's not adjusting to the correct user.

Marco Wessel

Hi,

"Joao S. O. Bueno" writes:

maybe there would be time to add a provisorie(sp?) CMYK to the Color Curves tool only before the release? What would you say?

Adding CMYK to the color selectors and some color correction tools can be done in a few hours work, _but_ only if it is done via the naive approach that Helvetix explained. This approach is however of no practical use. You need to calibrate the conversion with info about the inks, the printer and the paper or the CMYK values will just be arbitrary and useless numbers.

Sven

BTW: Since the color selectors are pluggable modules, a full featured CMYK color selector can be added at any time w/o the risk of breaking other stuff. I actually wonder why noone started to work on this yet.