On Sat, Mar 12, 2011 at 5:15 PM, Yoshinori Yamakawa wrote:

Hi,

According to the GIMP Roadmap, it seems to take time very much for the CMYK support to be added to the GIMP.

Now we can use the separate+ plug-in, but I think that the separate+ plug-in is not proper for the GIMP distribution because the separate+ plug-in has unnecessary features for general users and the separate+ workflow is not very seamless.

The Separate+ team has written the subset version of separate+ (named separate-) as a GIMP file plug-in. Separate- is the CMYK file exporter and is very simple to use. It supports TIFF, JPEG and Photoshop PSD formats.

https://bugzilla.gnome.org/show_bug.cgi?id=640613

From the feedback I have from users here in Brazil - and I mean

professional artists
working with FreeSoftware, I'd say it would be very important if we could get this in GIMP 2.8

Even if for gimp 3.0 and beyod we think of CMYK exports in a totally different way - all plug-ins will have to be rethough when we get to GIMP 3.0 anyway. The demand for this ability however we agree that it is not the best approach, is very high in the professional levels. At least around here, where the print stores use to require pre-separated artwork from the authors.

Regards,

js ->

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

Hi. Although it's a good idea to have the separate- plugin bundled in default GIMP installation, I'd like to discuss some enhancements that could be done in its bigger brother Separate+ to make it more functional for people who needs more advanced CMYK usage. The idea is quite simple and wouldn't even require changes in GIMP, although I think we should discuss the default behavior of GIMP when opening CMYK files (and that would probably require the modification of the import plugins of formats that allow that color mode). But that's a different story, let me explain the idea first :-)

After reading about (Pippin's) idea of CMYK/spot projections instead of a native CMYK mode for GIMP I realized that some of those concepts could be applied to extend the existing separate+ plugin. It doesn't look too difficult to implement and it would probably calm down most of the people who needs CMYK and grasps every opportunity to start endless discussions about why GIMP isn't adequate :-p, at least until the real thing is ready*

Currently, Separate+ plugin separates a flattened RGB image into CMYK. it uses layers (or layers with layer masks) to display the separated CMYK "channels".
It's effective for color managed conversions (it even allows to use devicelink profiles) but when some manual tweaking is needed there's no way other than working on the fake channels or the pseudo-composite masks directly, with the disadvantage of not having a reliable feedback of the operations performed.

Most of the people ask for CMYK because: - they want to use C, M, Y, K channels as spot colors in certain parts of the image (for pure cyan, magenta, yellow, green, red or blue) - they want to control black generation (for pure black text or grays. Which is again using the K plate as a spot plate). - They want to create custom rich black or super black areas. - they think they can get perfect Pantone colors.

For the rest of the cases there's no better choice than relying on color management, so it's reasonable to expect a proper conversion when the right profiles are used.

But what happens with those particular cases I mentioned? Is it possible to do that currently in GIMP? Pretty much, yes. But it's tedious and error prone. Using Separate and then tweaking the pseudo-channels allows to solve those problems, but with some time consuming operations.

Those operations are: - Combining the alpha channel of the pure C, M, Y, K areas with the corresponding separated channel via screen blending mode. - Converting desired CMYK percentages to grayscale values and fill the selection (the alpha of the area that should have a specific CMYK) with the resulting values for each layer created by Separate+

The resulting file will be perfectly fine, but reaching that point is tedious and several things can go wrong in the process. So, what if the ideas of spot layers is applied to Separate+, using naming conventions to define what to do with them?

Example 1: Adding overprinted pure black text and strokes on a color illustration. Preparation: put the color illustration to be separated with Separate+ in the bottom layer, in other layer named "pure-k" put the text and strokes.
Procedure (to be automated):
a) Separate with Separate+ as usual. b) take the "pure-k" layer's alpha channel in the original file, blend it using screen mode on the separated k pseudo-channel.

note: "pure-k", "pure-c", "pure-m", "pure-y" would be the names for these special layers.

Example 2: Creating a logo with a custom rich black or Pantone color Preparation: put the color illustration to be separated with Separate+ in the bottom layer, in other layer named "c60m50y30k10" put the logo. Procedure (to be automated):
a) separate with Separate+ as usual. b) take the "c60m50y30k10" layer's alpha, copy the selection to the separated document, convert every porcentage to a grayscale value and fill the selection with the corresponding values for each pseudo-channel.

note: choosing arbitrary ink amounts may exceed the TAC for the target profile. Ideally this should be controlled but probably this is too fine-grained for a temporary solution and the user should take this precaution (after all, this can also happen with a native CMYK mode if the user doesn't check warnings)
About Pantone colors: it's pretty much useless to rely on Pantone CMYK values since they only work if very precise printing conditions are met. In my experience it's better to recourse to a color managed conversion from the Formula swatches (which are stored in Lab and GIMP can use them converted to RGB in a GPL palette). In my opinion converted formula colors look closer to spot colors than official Pantone CMYK values in most of the print shops I printed with.
This method is actually endorsed by Pantone as the most appropriate for intermediate/late binding workflows.

Example 3: In this post from David Revoy he used the previous cases together, but he used Photoshop for the task:
http://www.davidrevoy.com/index.php?article32/comics-inking-and-coloring-with-gimp-painter/ I took his file and re-created the case in GIMP using the available tools. Here's a screenshot of the preparation of the material: http://ubuntuone.com/p/iqO/
Here's an XCF with the Separate+ result and the CMYK special "plates" as stored channels.
http://ubuntuone.com/p/iqk/
And finally here's the final result in CMYK, with the desired black setting and overprint:
http://ubuntuone.com/p/iqm/
I did this manually, of course. But I wanted to show an everyday, real-life work that could be easier with this relatively minor modifications.

What do you think?

*) Pippin clarified in an IRC conversation that since there is still a lot of work to do to finish GEGL integration into GIMP, there are no immediate plans or anybody interested yet for adding CMYK support.

On Mon, Mar 21, 2011 at 11:30 PM, gespertino@gmail.com wrote:

Most of the people ask for CMYK because:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3. Instead focusing on CMYK I would give Gimp access to use any defined colorspace in realtime, just as RGB.

Any RGB image can be coverted to LAB/HSV/CMYK, it works in current version of Gimp.
The thing which doesn't work is realtime display, after decomposing layers user see only grayscale representation of each layer.

So adding support to display group of layers as RGB/LAB/HSV/CMYK could be good first step.

2011/3/21 Jacek Poplawski :

On Mon, Mar 21, 2011 at 11:30 PM, gespertino@gmail.com wrote:

Most of the people ask for CMYK because:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB.

Well, CMYK is quite different than LAB actually. Could you please elaborate about how you can create better color in a colorspace which is device dependent and has tipically a smaller gamut than most of the RGB working spaces? When you work in CMYK mode in a program like Photoshop, the visual feedback you get is an on-screen soft-proof of the CMYK color converted to your working RGB profile. So what you see isn't really what you get, and it's probably better idea to do your photo retouching in RGB soft-proofing to your target CMYK. The good thing about this is that you'll keep the larger gamut and your colors won't be unnecessarily and irreversibly clipped to a smaller gamut.
CMYK (and it's not just me saying this) is an output colorspace to send images to four-inks process printers. With color management the CMYK mode should be legacy.

It is colorspace like
others, but uses 4 channels instead 3.

That's not completely true. If inks were perfect, the fourth channel wouldn't be necessary.
Black was added to compensate CMY inks imperfections and also to save ink and make prints cheaper.
Tell me if that's not a declaration of device-dependent colorspace! When it comes to monitors, it's obvious you need to work in a device dependent colorspace. You can't use another device to see your images when you manipulate them, so there's a reasonable excuse to use device dependent colorspaces as working profiles in that case. But how your RGB image is separated to CMYK is defined in the target profile. Messing with those separations individually is modifying the way they were separated by the profile, which is the one in charge of converting the colors to the best possible values for the target device.
Despite it's a pretty common practice, it doesn't sound correct.

Instead focusing on CMYK I would give Gimp access to use any defined colorspace in realtime, just as RGB.

...

So adding support to display group of layers as RGB/LAB/HSV/CMYK could be good first step.

As far as I know (please correct me if I'm wrong), the idea with GEGL is to work in device-independent, 32bpc float linear space and then go to Lab, RGB (or even CMYK) depending on the need. So the first step you mention is on the works. What I discussed in my previous message was an interim solution mostly for black generation and pure CMYK primaries, the things that management won't solve exactly as the user wants.

Gez.

On 3/22/11, Jacek Poplawski wrote:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3.

Right, all colorspaces are equal, but some are more equal than others :-) The willingness to go from a wider gamut to a narrower gamut for editing what will then go to a different color space once again is, er, equally amazing :)

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Mar 22, 2011 at 4:12 AM, Alexandre Prokoudine wrote:

On 3/22/11, Jacek Poplawski wrote:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3.

Right, all colorspaces are equal, but some are more equal than others :-) The willingness to go from a wider gamut to a narrower gamut for editing what will then go to a different color space once again is, er, equally amazing :)

I just mean that they should be treated similarly :)

On 3/22/11, Jacek Poplawski wrote:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3.

Right, all colorspaces are equal, but some are more equal than others :-) The willingness to go from a wider gamut to a narrower gamut for editing what will then go to a different color space once again is, er, equally amazing :)

I just mean that they should be treated similarly :)

For photography? I very much doubt that. When it comes to all things related to photography, the point is to preserve as many colors as possible. Which is how all those ProPhotoRGB and the like were introduced all those years ago. Jumping between wide and narrow gamuts effectively kills useful information. Hardly better colors, sorry.

It *might* be OK to go from RGB to CMYK in case the picture will then be saved to CMYK TIFF or CMYK PSD and inserted into a DTP app, an even then you need a profile for exactly the printing device that will be used, because in case of printing color reproduction depends on things like the kind of paper and the kind of inks. There simply is no such thing as device independent CMYK profile. So editing an arbitrary picture in arbitrary CMYK color space defined by an arbitrary ICC profile simply doesn't make any sense. For some reason this has become a sad common practice, but it doesn't mean that it's the right thing to do :)

Even working in CMYK natively from scratch makes sense in just one case: when you create an illustration for printing and, again, you have the profile for the device that will do the printing. Otherwise you just screw up color reproduction.

Given how design tends to be multidevice now, especially branding (same pictures used in e.g. printed leaflets and on website) the best workflow is to work with high bit depth precision in a color space with as wide gamut as possible (not CMYK) and then selectively tune things for every output device. The earlier proposal by Peter Sikking (a special projection in output device color space) makes quite a lot of sense there, *if* there will be additional tools implemented to do on-site work like trapping etc. and *if* it will be possible to assign spot colors and export them properly to PDF. The latter right now simply isn't possible, because the existing PDF exporter uses Cairo which is still missing spot colors implementation in thePDF backend.

There are so many things regarding CMYK and printing like GCR and UCR and best method for rendering intent for each job that should be taken into consideration when going from RGB to CMYK that treating CMYK as any arbitrary color space is simply impossible. I can understand how this could be frustrating for someone who is used to treat CMYK exactly that way, though.

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Mar 22, 2011 at 4:52 AM, Alexandre Prokoudine wrote:

On 3/22/11, Jacek Poplawski wrote:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3.

Right, all colorspaces are equal, but some are more equal than others :-) The willingness to go from a wider gamut to a narrower gamut for editing what will then go to a different color space once again is, er, equally amazing :)

I just mean that they should be treated similarly :)

For photography? I very much doubt that. When it comes to all things related to photography, the point is to preserve as many colors as possible. Which is how all those ProPhotoRGB and the like were introduced all those years ago. Jumping between wide and narrow gamuts effectively kills useful information. Hardly better colors, sorry.

I was influenced by Dan Margulis. I try to follow his ideas in Gimp, instead Photoshop.
He generally assumes that photography is made from 10 channels: R, G, B, L*, A*, B*, C, M, Y, K and you can use any subset of them to generate good quality image with good colours. (http://en.wikipedia.org/wiki/Dan_Margulis)

And everything works as expected, with the exception of realtime preview. I just decompose image to LAB or CMYK then use these layers for increasing contrast, masking, etc... but using curves in LAB or CMYK is very hard without preview, because you have to "imagine" colors. The good thing is that GMIC has support for these colorspaces now, and RawTherapee is developing fast.

PS. sorry for offtopic

Jacek - you don't need CMYK for photos ["I need CMYK support for photo retouch, to create better colors"].

CMYK eventually will kill some nuances - being dependent on the paper (or other support) color.
RGB colors on screen make use of luminance of the screen pixels - you can have many nuances of a base color because you can control the pixel luminosity. CMYK is made for help transferring as much color as possible from screen (other color spaces) to paper - the only white (read light) come
from the printing support (paper, plastic, etc). True, there are some special colors with fluorescent additives - but they can't go everywhere. That's why CMYK is not so equal with other screen based color spaces.
On short, CMYK can not reproduce the same number of colors.

The assumption that 4 channels is better than 3 is wrong on this case.

You can only make sense working in pure CMYK when you want to have a very precise reproduction
- but for this goal you need to know exactly the paper they use (printers) and color profiles they use for the offset. The best is to send them your work in RGB [16 bits / channel - for smoothest gradients ] and your monitor profile, then they will know how to get it right. Think that for RGB to CMYK you loose something anyway.

2011/3/22 Jacek Poplawski :

On Tue, Mar 22, 2011 at 4:52 AM, Alexandre Prokoudine wrote:

On 3/22/11, Jacek Poplawski wrote:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3.

Right, all colorspaces are equal, but some are more equal than others :-) The willingness to go from a wider gamut to a narrower gamut for editing what will then go to a different color space once again is, er, equally amazing :)

I just mean that they should be treated similarly :)

For photography? I very much doubt that. When it comes to all things related to photography, the point is to preserve as many colors as possible. Which is how all those ProPhotoRGB and the like were introduced all those years ago. Jumping between wide and narrow gamuts effectively kills useful information. Hardly better colors, sorry.

I was influenced by Dan Margulis. I try to follow his ideas in Gimp, instead Photoshop.
He generally assumes that photography is made from 10 channels: R, G, B, L*, A*, B*, C, M, Y, K and you can use any subset of them to generate good quality image with good colours. (http://en.wikipedia.org/wiki/Dan_Margulis)

And everything works as expected, with the exception of realtime preview. I just decompose image to LAB or CMYK then use these layers for increasing contrast, masking, etc... but using curves in LAB or CMYK is very hard without preview, because you have to "imagine" colors. The good thing is that GMIC has support for these colorspaces now, and RawTherapee is developing fast.

PS. sorry for offtopic _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On 03/22/2011 01:37 AM, Jacek Poplawski wrote:

On Mon, Mar 21, 2011 at 11:30 PM, gespertino@gmail.com wrote:

Most of the people ask for CMYK because:

I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3.

CMYK is fundamentally different than LAB, HSV and RGB.

In order for RGB values to make colorimetric sense, meaning that the CIEXYZ tristimulus values are known, all you need to know are the primaries and the white point used.

The tristimulus values for a set of CMYK values depends on the characteristics of the pigmets, the pattern in which the colorants are arranged on paper, the order in which they are applied, the illuminant used, the characteristics of the paper they are applied on, and even the age of the print.

Another difference of the CMYK color space compared to e.g. RGB is of course it's subtractive nature, meaning that as you increase CMYK values, the resulting color will be darker, whereas with RGB, larger values means a brighter color.

HSV is just a different representation of RGB values, and LAB values makes colorimetric sense by themselves, without any additional information.

That CMYK is fundamentally different than light based additive color spaces is the reason why GIMP developers considers CMYK somewhat of a special case we can take care of later, we first need to make a program that is powerful in the additive color space world.

/ Martin

On Tue, Mar 22, 2011 at 8:19 AM, SorinN wrote:

Jacek - you don't need CMYK for photos ["I need CMYK support for photo retouch, to create better colors"].

I am familiar with this opinion. I don't want to continue offtopic discussion in this thread, so I just give one example: curves. You can get more interesting retouch when using curves in CMYK and in LAB and in RGB than using only RGB curves. You can get more data from shadows by using K curve in CMYK for instance. You can increase contrast without touching the colors by using L curve. etc

On 03/22/2011 08:25 AM, Jacek Poplawski wrote:

On Tue, Mar 22, 2011 at 8:19 AM, SorinN wrote:

Jacek - you don't need CMYK for photos ["I need CMYK support for photo retouch, to create better colors"].

I am familiar with this opinion. I don't want to continue offtopic discussion in this thread, so I just give one example: curves. You can get more interesting retouch when using curves in CMYK and in LAB and in RGB than using only RGB curves. You can get more data from shadows by using K curve in CMYK for instance. You can increase contrast without touching the colors by using L curve. etc

We are talking about techniques to retouch photos on a mailing list for the development of an image editing application, so this is not offtopic.

Why would you transform to CMYK to lose color information just so you can increase the K value, rather than making a lossless transformation into LAB and decrease the L value?

Note that with GEGL, we will easily be able to have adjustment layers that work on the L component in CIELAB.

/ Martin

My current workflow:

1) choose photos in Digikam, copy them to another folder 2) open photo in RawTherapee
3) try to get good colour and contrast in RT, fix highlights, etc, then export to Gimp (RT has no layers) 4) use RGB curves in Gimp, sometimes decompose to RGB and combine layers to create BW version
5) use color mixer in GMIC, LAB mixer is good to create "toned down" version of colors, CMYK is mixer is good to fix colors different way (or use GMIC for quick BW version) 6) healing tool (only Gimp can do this) 7) save xcf, export jpgs

The thing I miss are LAB curves and CMYK curves. I asked GMIC developer for LAB/CMYK curves support and it is there, but UI is hard to use. RawTherapee has support for LAB curves and they work very good (and in 16bit mode), but there are no layers in RT.

So I am fan of RT, Gimp and GMIC, this is very good, quite mature free software. I am also aware of Photivo / LAB Curves. Never tried Darktable and Krita for photos.

After looking at all available solutions the only way I see for me is to develop simple application (of course GPL) which will open jpg/tiff, process image in RGB/LAB/CMYK with curves/mixers/blend modes then save tiff/jpg again. But I will announce it when ready (or won't if I fail).

PS. CMYK is also best colorspace for skin color retouch by numbers, that's why I wanted to fix CMYK values in Gimp colorpicker, but there was big discussion on this mailing on this subject

On 03/22/2011 08:20 AM, Martin Nordholts wrote:

LAB values
makes colorimetric sense by themselves, without any additional information.

Correction: For CIELAB values to make colorimetric sense, it is necessary to also know the reference white point.

/ Martin

On Tue, 22 Mar 2011 09:14:43 +0100 Jacek Poplawski wrote:

PS. CMYK is also best colorspace for skin color retouch by numbers, that's why I wanted to fix CMYK values in Gimp colorpicker, but there was big discussion on this mailing on this subject

Martin: I don't know if this originates with him, but a reference for this can be found in "Skin" by Lee Varis. He describes a ratio of C-M-Y which can be used to numerically adjust skin tone in an image. This ratio appears to be based on PSes internal CMY(K) colour profile and thus (I've since discovered) probably has no bearing on anything!

Jacek: My suggestion would be to use a calibrated monitor and an image which has been curve adjusted in PS to get the skin tones numerically "correct", and then to learn to do it by eye. I think that the numerical method is good for starting out, but after a while you should be adjusting to what *you* want, not what the numbers suggest! :-)

Jon

2011/3/22 Jacek Poplawski :

CMYK is also best colorspace for skin color retouch by numbers,

No it isn't, because unless you go through a lot of extra work to avoid it, colors in the image that the used CMYK color space is unable to represent will get lost.

/ Martin

"No it isn't, because unless you go through a lot of extra work to avoid it, colors in the image that the used CMYK color space is unable to represent will get lost."

True. Lot of work in studio then offset hardware will trow out different things ..because : paper quality, paper type ( coated / uncoated ) which affect reflection of white light (color nuances) ..hardware color profile ..etc.

2011/3/22 Martin Nordholts :

2011/3/22 Jacek Poplawski :

CMYK is also best colorspace for skin color retouch by numbers,

No it isn't, because unless you go through a lot of extra work to avoid it, colors in the image that the used CMYK color space is unable to represent will get lost.

 / Martin

--

My GIMP Blog: http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On 3/22/11, Jacek Poplawski wrote:

I am familiar with this opinion. I don't want to continue offtopic discussion in this thread, so I just give one example: curves. You can get more interesting retouch when using curves in CMYK and in LAB and in RGB than using only RGB curves.

LAB curves are fine. Transparent work in LAB makes sense, but the prerequisite is still GIMP 3.0 with high bit depth precision, otherwise you still lose color data due to rounding errors in 8bpc mode.

Reference 1: http://brucelindbloom.com/index.html?RGB16Million.html Reference 2: http://bit.ly/gIjQUh

You can get more data from shadows by using K curve in CMYK for instance.

Oh come on. K curve is simply not the only and even not the best way to work on various tonal ranges selectively. Check out zone system implementation in both commercial LightZone and free-as-in-speech darktable.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Mar 21, 2011 at 5:30 PM, gespertino@gmail.com wrote:

Those operations are:
- Combining the alpha channel of the pure C, M, Y, K areas with the corresponding separated channel via screen blending mode. - Converting desired CMYK percentages to grayscale values and fill the selection (the alpha of the area that should have a specific CMYK) with the resulting values for each layer created by Separate+

The resulting file will be perfectly fine, but reaching that point is tedious and several things can go wrong in the process. So, what if the ideas of spot layers is applied to Separate+, using naming conventions to define what to do with them?

This approach you outline would solve most of the use cases I have for CMYK (overprint, underlay (for dark substrate), one or more CMYK as spot/solid color, rich black).

What I really miss from photoshop is the poorly-named "apply image" command. It basically allows you to combine any two channels using the available blending modes (Multiply, Screen, etc.). Right now, I have to do a lot of bouncing back and forth between layers, selections and channels. But that's probably well beyond the scope of what you're suggesting so I'll shut up now ;)

Chris