On Mon, May 23, 2011 at 3:59 AM, Arnon Namsanit wrote:

Dear GIMP developer team,

My name is Arnon Namsanit. I am a Thailand government officer working for the Ministry of Science and Technology. My team's main responsibility is introducing the open source software to Thais including GIMP. At the moment we are interested in introducing GIMP to a group of users in publisher manufacturing therefore we have been discussing about CMYK on GIMP. I might need to ask you some questions please.
- Is there any people currently working on CMYK on GIMP? - If yes, How? Can we join them?
- If no, Could we know the complexities or the problems of that please? Since I am not a developer but my organization is able to set up a team to implement the module. I would like to have your opinion on this please. We are looking forward to hear from you.

Kind Regards,

Good morning, Arnon,

The agrreded idea among GIMP developers is that CMYK as an _image editing mode_ will not be implemented in GIMP. Where as there maybe in the future more straightforward ways foreasier CMYK separation and printing. That is due to the fact that CMYK is more the mapping to inks of a printing method
than a color mode. Even though this is the "de facto" printing method for volume, and even personal printing, CMYK values don't have a 1:1 mapping of color values as are visible to the eye, or representable in computer videos or images. (which color is "black" in an image? (100, 100, 100, 0),
(0,0,0,100) or (100, 100, 100,100)? )

That said, for generating CMYK Tiff files as expected for some of today's printshops, and even allowing for some per-plate correction of the amount of colorants in each part of the image, there is the third party plug-in Separate+ ( http://cue.yellowmagic.info/softwares/separate-plus/ ) I believe that installing and getting used to that might your requirements for CMYK.

So ..what is the idea for GIMP presently and on the long term, is that proper printing requires actually conversion between the color spaces of the various devices used in the press chain (video monitor, proof printer, large scale printer),
making use of _color profiles_ . With proper calibration of devices and use of color profiles one can ensure that a color shade will look on paper, under certain lighting conditions, as it does look on the screen at editing time. All the
time the colors are represented internally as an RGB tripplet, and just the printing
driver, or software, takes care of mapping the normalized color to the actual colorants in use on the device - taking into account information on the device's color profile.

On GIMP's roadmap, there lays, in the future, a way to preview a per plate separation of the image prior to having it exported to a CMYK file in a more integrated way than currently possible with the separate+ plug-in. But that depends on the implementation of a new, very different, U.I. that will allow for non-destructive editing, among other things. Work on this U.I. will start only after current development cycle (which will yield GIMP 2.8).

Meanwhile, if you find that GIMP with the Separate+ plugin is not enough for your
office's needs, there are other Open Source graphic editing programs that offer varying CMYK capabilities, such as Krita and Cinepaint.

Regards,

js ->

Arnon Namsanit
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Mon, May 23, 2011 at 10:59 AM, wrote:

Dear GIMP developer team,

My name is Arnon Namsanit. I am a Thailand government officer working for the Ministry of Science and Technology. My team's main responsibility is introducing the open source software to Thais including GIMP. At the moment we are interested in introducing GIMP to a group of users in publisher manufacturing therefore we have been discussing about CMYK on GIMP. I might need to ask you some questions please.
- Is there any people currently working on CMYK on GIMP?

No, there are higher priorities at the moment Please use http://wiki.gimp.org/index.php/GIMP_Roadmap for reference.

- If yes, How? Can we join them?
- If no, Could we know the complexities or the problems of that please?

The No.1 priority past release 2.8 is to clean-up the library (see above) and move to high bit depth, that is, continue integration of GEGL. Only then it will make sense to do anything about CMYK, because 8bit based conversions between color spaces introduce too many errors (not speaking about having to rewrite things). The outlined proposal is here:

http://blog.mmiworks.net/2009/05/gimp-enter.html http://blog.mmiworks.net/2009/06/gimp-squaring-cmyk-circle.html

There are fairly reasonable workarounds. One of them was proposed here:

http://article.gmane.org/gmane.comp.video.gimp.devel/20007

Alexandre Prokoudine http://libregraphicsworld.org

-- cut --

The agrreded idea among GIMP developers is that CMYK as an _image editing mode_ will not be implemented in GIMP. Where as there maybe in the future more straightforward ways foreasier CMYK separation and printing. That is due to the fact that CMYK is more the mapping to inks of a printing method
than a color mode.

Quite similar can be said about RGB or any other device dependent color model.

But first of all there is not only one CMYK. CMYK name itself denotes a family of color spaces. So it is for RGB too.

Even though this is the "de facto" printing method for volume, and even personal printing, CMYK values don't have a 1:1 mapping of color values as are visible to the eye, or representable in computer videos or images.

It's not so easy. Each CMYK color vector can be injectively mapped to color visible to the eye.

(which color is "black" in an image? (100, 100, 100, 0),
(0,0,0,100) or (100, 100, 100,100)? )

That said, for generating CMYK Tiff files as expected for some of today's printshops, and even allowing for some per-plate correction of the amount of colorants in each part of the image, there is the third party plug-in Separate+ ( http://cue.yellowmagic.info/softwares/separate-plus/ ) I believe that installing and getting used to that might your requirements for CMYK.

While useful I consider it only a half-solution.

So ..what is the idea for GIMP presently and on the long term, is that proper printing requires actually conversion between the color spaces of the various devices used in the press chain (video monitor, proof printer, large scale printer),
making use of _color profiles_ . With proper calibration of devices and use of color profiles one can ensure that a color shade will look on paper, under certain lighting conditions, as it does look on the screen at editing time. All the
time the colors are represented internally as an RGB tripplet, and just the printing
driver, or software, takes care of mapping the normalized color to the actual colorants in use on the device - taking into account information on the device's color profile.

Even so, if we consider ICC color management scheme, there's still potential problem: rendering intent. Which one will printshop use? It's all OK if used colors are well within output color space, but what if not? It's not so rare case. In such case the decision which colors to transform unreproducible colors to is left to printshop not the designer.

And what if you want to use some non-standard trick with colorants values? Every color conversion can be done with properly prepared color profile but in practice it's much easier and faster to modify color values in device color space and preview results e.g. on RGB device than mangle color profile each time. Quite often it's better to drop color management completely on "printing side" and prepare material directly for specific device (more exactly: CtF/CtP + actual printing machine + paper) – gives you less surprises in the end.

Color management is cute idea but it's not panaceum and sometimes we're better off without it.

On GIMP's roadmap, there lays, in the future, a way to preview a per plate separation of the image prior to having it exported to a CMYK file in a more integrated way than currently possible with the separate+ plug-in. But that depends on the implementation of a new, very different, U.I. that will allow for non-destructive editing, among other things. Work on this U.I. will start only after current development cycle (which will yield GIMP 2.8).

Meanwhile, if you find that GIMP with the Separate+ plugin is not enough for your
office's needs, there are other Open Source graphic editing programs that offer varying CMYK capabilities, such as Krita and Cinepaint.

-- cut --

One final thougt: CMYK support subject was touched more than once on this list, but I think we should consider much broader view on the matters of printing. CMYK is only most often used set of colorants but there are much more colorants out there. Having native CMYK would be cool thing but even cooler would be to be able to add more colorants to prepared images. What about having "metallic" overprint/underprint in your projects? What about Hexachrome? Sure, one could prepare image in wide enough RGB (example ;)) and rely on profiles with hexachrome or prepare metallic layer in separate file but hey… one could also edit RGB files stored channel by channel in separate files but what for?

My best regards tb

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Mon, May 23, 2011 at 11:05 AM, Bogdan Szczurek wrote:

One final thougt: CMYK support subject was touched more than once on this list, but I think we should consider much broader view on the matters of printing. CMYK is only most often used set of colorants but there are much more colorants out there. Having native CMYK would be cool thing but even cooler would be to be able to add more colorants to prepared images. What about having "metallic" overprint/underprint in your projects? What about Hexachrome? Sure, one could prepare image in wide enough RGB (example ;)) and rely on profiles with hexachrome or prepare metallic layer in separate file but hey… one could also edit RGB files stored channel by channel in separate files but what for?

Note that GIMP does offer support for such a a "manual spot-color" workflow through the use of Channels - it can work for jobs sporting one or more distinct spot ink such as metallic or fluorescent. Although there is no preview or separation for that, at least one can edit everything in the same .xcf project and export to distinct files.

As for yor other comments, even though they might express a need of some designers, as you stated, they are not in current GIMP road map neither seem as a goal of the program. If one is willing to ditch color profiling alltogether, and wants to compose an image work only with colorant intensity, it should be clear that GIMP's code base does not support that, and another program should be used, unless it can be achieved with the naive approach offered by image Channels.

Regards,

js ->

My best regards
tb

On Mon, May 23, 2011 at 11:05 AM, Bogdan Szczurek wrote:

One final thougt: CMYK support subject was touched more than once on this list, but I think we should consider much broader view on the matters of printing. CMYK is only most often used set of colorants but there are much more colorants out there. Having native CMYK would be cool thing but even cooler would be to be able to add more colorants to prepared images. What about having "metallic" overprint/underprint in your projects? What about Hexachrome? Sure, one could prepare image in wide enough RGB (example ;)) and rely on profiles with hexachrome or prepare metallic layer in separate file but hey… one could also edit RGB files stored channel by channel in separate files but what for?

Note that GIMP does offer support for such a a "manual spot-color" workflow through the use of Channels - it can work for jobs sporting one or more distinct spot ink such as metallic or fluorescent. Although there is no preview or separation for that, at least one can edit everything in the same .xcf project and export to distinct files.

Yup, I know, but how appealing it would be to have a preview :). A man can dream… a man can dream… ;)

As for yor other comments, even though they might express a need of some designers, as you stated, they are not in current GIMP road map neither seem as a goal of the program.

It's a pity, though understandable…

If one is willing to ditch
color profiling alltogether, and wants to compose an image work only with colorant intensity, it should be clear that GIMP's code base does not support that, and another program should be used, unless it can be achieved with the naive approach offered by image Channels.

My best!
tb