Re: CMYK file export plug-in

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux