[Scribus] CMYK image processing

[Craig Ringer]

On Tue, Mar 21, 2006 at 11:17:02AM +0100, Tino Schwarze wrote:

> > You need CMYK support in your graphics app if:
> > 	- You're working without colour management (bad idea!) and want
> > 	  to try to manually adjust the input images.
> 
> - You are an artist or are working with artists which just happen to
>   THINK in CMYK.

Nothing I can do about that one ;-)

> - You've got a photo which looks nice on screen but a bit too yellow
>   when printed - you'll just remove some yellow after conversion to CMYK.

I'd argue that the need to do that means your colour management profiles
/ configuration / tools are deficient. It's possible there's no way to
get them good enough - I won't be able to say until I've personally
been using it in production for a while - but off the top of my head I'd
be surprised if it were necessary to work manually with CMYK data most
of the time.

> - You're using printed color reference charts to get colors right. They
>   are always in CMYK since that's what will be used to print.

Using CMYK values from a chart doesn't necessarily get things to match,
unless the chart was printed by - or to match - your target output
device. That's unusual. I've learned from "interesting" personal
experience that a CMYK value does come out different on different
targets, media (eg basic vs whiter newspaper), and so on. The staff at
work rely on Photoshop correction tables, manual offsets based on
experience, and PANTONE spots to handle this - they too know that a CMYK
colour looks different in different contexts. We've done tests
(usually unwittingly due to customers or our staff doing something
wrong, but sometimes intentionally) where we print a PANTONE named spot
colour directly beside the CMYK alternative provided for that spot. The
difference is usually remarkable.

As it happens, at work we also work on images in RGB in Photoshop,
previewing the CMYK result after profiled conversion. We use Photoshop
to do the CMYK conversion, but it'd be the SAME to use the DTP app to do
it (if the profiles and CMM are the same), it's just that our version of
Quark is not capable of doing so. The POST's printers actually recommend
working in RGB and deferring the CMYK conversion to the last minute,
which we do.  In that sense, we already rely on colour management.

This is what the GIMP should support doing soon, if I understand
correctly. Since Scribus will be able to perform the desired CMYK
conversion on the fly (using the same profiles and CMM that GIMP used to
make the screen preview), you should be just fine.

By the way, the fact that CMYK colours look different on different
devices and media is also why I think it's not that important to handle
manual tweaking of images. Whether you're working in CMYK or RGB, you
need colour management (whether ICC, hand display profiling, some
proprietary system, etc) to see on screen what you will see in print.
Given that, why not let the colour management engine take care of the
final RGB->CMYK managed conversion - you already know what the result
will look like within the limits your display device is capable of
showing.

I'm NOT an expert in this by any stretch. Colour management is complex,
I don't know it as well as I'd like, and I'm still learning fast. I'd be
happy to be corrected, and I'll gladly listen to other opinions. I don't
personally think the issues bought up thus far are a big deal (except
for being used to working in CMYK - and we must all deal with change
eventually). Again, I'm not saying CMYK bitmap editing is irrelevant,
just that I don't think it's as important as it used to be, and that
many or most users should be just fine without it now.
 
> Having a fully color-managed workflow is a nice goal. But in practice, there
> are a lot of people who will not put a lot of effort into this since
> it's okay for them to work in CMYK and they are used to it. IMO it's a
> matter of complexity.

Complexity, and resistance to change (by virtue of not wanting to invest
the time to learn and tweak and set up the new method, if nothing else.
Entirely understandable.).  I'm not sure that - when the documentation
is good and the tools do the sensible thing by default (neither of which
is now as true as it could be), a colour managed workflow is any harder
than hand-correcting CMYK images by eye, experience, and hand-tweaked
displays. Of course if you already know how to manage a workflow that
uses early conversion to CMYK you'll want to keep doing that. I'm just
arguing that you don't have to work that way to get the results you
want, and that existing OSS tools can provide another method that'll
produce results as good, where they can't currently provide support for
working the way you're used to. I don't think it'll be _necessary_ or
even that important to have CMYK support in GIMP to get good print
results, though of course it's always _nice_, and not having it will
force some people to adopt a new and thus initially challenging
workflow.

-- 
Craig Ringer
GPG Key Fingerprint: AF1C ABFE 7E64 E9C8 FC27  C16E D3CE CDC0 0E93 380D