Sorry that it took so long, Simon ;)
Anyways, I had some conversation with two graphics designers about CMYK
problems and the Gimp at the Systems, and I think it might be worthwhile
to read the following "sometimes true" observations. Remember, they are
hearsay ;)
1. "colour matching for photos is a don't care". Ok, this is a blatant
lie, however, exact colours are not that much of a concern for
photos. Much more important are logo colours (most companies have
pretty strict definitions of these). If a photo doesn't exactly
match the screen colours ("which screen colours, anyways") this
is often not a reason to not use gimp. If a logo colour can't be
reproduced, however, it keeps Gimp from being used.
2. "Logo colours are not CMYK". Yupp. Logo "colours" might not be
representable in CMYK at all (gold etc...). Even if, you often (but
not always) want seperate planes for important colours.
Most uses of spot colours want the concept of an "indexed channel",
i.e. a channel where each value represents a different palette
colour. No bleeding with image contents.
Gimp's channels can be used instead, which is not that perfect for
all uses, but exists and at least photoshop doesn't offer a better
solution ;) They also allow gradients of a single spot colour, which
indexed channels wouldn't allow. Wether all this makes them easier
or harder to use is something to explore.
3. "You don't print from within the gimp". At least you don't print
brochures from within the Gimp. You use gimp for artwork, often the
logos, but you obviously don't set text using the Gimp. You instead
import images into some layout program (quark xpress ;).
I was told that the principal reason for bad quality of gimp
images within quarkxpress is that quarkxpress imports gimp's rgb
tiffs like garbage. I was told that loading the rgb data into
photoshop, associating sRGB with it (changing _nothing_ else)
improved the quality very much, making the results reproducable on
printers. Without absolute colours, they look different.
4. "Cheap CMYK vs. RGB makes a difference". Many programs also seem
to have problems ("looks like shit") with RGB data, not because it
isn't associated with a colourspace, but because it's RGB. Cheaply
("formula") converted CMYK data seems to help a lot here. That
CMY has an additional K is of no concern - users don't sue this
additional level of freedom,
Things like trapping are handled by other programs or by very
expensive photoshop plug-ins.
5. "Logos are done by overlays". At least one method of using spot
colours is to create them as seperate channels. Tiff/Eps are
reportadly able to save additional channels in a way that a program
can read them sensibly.
The spot colour "planes" are then laid over the other graphics. For
this to work a mask is necessary, since channels range from white
(not transparent) to "channel colour", at leats in quarkxpress.
It seems that traditional masks are not what's called for - instead
you want a path saved in the tiff/eps file (don't ask me wether that
is possible). This clipping path is then used for the overlay - gimp
can't create this kind of paths, nor can it save it.
CONCLUSIONS - THE 60% WAY TO CMYK
If one were so bold as to draw some conclusions, they would probably be very
similar to these:
1. Enhance the tiff/eps save plug-ins to do cheap RGB->CMYK conversion. This
would work around conversion problems in other programs.
2. Associate sRGB or any other colourspace with the saved data in
tiff/eps. It doesn't matter wether it's true or not, just give
programs something to depend on.
3. Educate users about channels and what they can be used for - on this
Systems I was frequently confronted with users who were unhappy with
the gimp because it didn't allow them to do things as easily as under
photoshop. Often(!) I was able to get exactly the same results, with
a much easier and faster sequence than the one that user used with
Photoshop.....
This could be a start, to work around bugs in other programs. Also
relatively cheap, unlike the following:
4. Find out wether saving paths as paths as opposed to masks is really
required to do overlays in common layout programs. If yes:
4a. enhance the path tool to be able to work with generic paths (holes,
multipart etc.).
4b. enhance the tiff/eps plug-ins to be able to save these paths together
with channels.
4b. (optional) make tiff/eps save images together with their channels in
the same file.
5. Implement "indexed channels", or somethign else that makes handling spot
colours easier. An easy way is to use one channel for each spot colour.
Finished.
I certainly forgot something, probably because I should have written this
much earlier (afetr the systems), but if I had that much time... *sigh* ;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
