[Scribus] CMYK image processing

Tino Schwarze scribus.lists
Wed Mar 22 11:58:52 CET 2006


On Wed, Mar 22, 2006 at 08:52:56AM +0100, Tobias Hilbricht wrote:

> > The POST's printers actually recommend
> > working in RGB and deferring the CMYK conversion to the last minute,
> 
> If you get a colour specification by a client in CMYK, say for a logo, then 
> you definitely have to start in CMYK. 
> And if something goes wrong - the customer complains "The colours in print are 
> not what I intended" and you have to admit you worked with an application 
> which does not have CMYK capabilities at all then you have a very weak stand.
> In addition, if you can convert images from RGB to CMYK and have a CMYK colour 
> picker then you have a second possibility to proof colours in addition to 
> colour management by comparing critical colours with swatches.

To make things worse there is no lossless CMYK->RGB->CMYK conversion (it
is not possible). It's actually pretty difficult to find an RGB color
which will produce a given CMYK color.

Example: I do flyers for a customer with a light magenta background.
The CMYK value is 0/10/0/0. I do not have Photoshop but use GIMP for
image creation. Because of the issues with transparency in print and
because of the nature of the image (I use multiply mode for several
layers to achieve the desired effect), I need the background to be part
of the image. Therefore I need an RGB value which will correspond to
0/10/0/0 when converted to CMYK. I ended up using icctrans from lcms to
fiddle around with the values until I reached something very close to
0/10/0/0: RGB 255/238/255 yields CMYK 0/10.18/0/0. 

When doing the CMYK->RGB calculation directly, I get RGB
251.58/237.30/244.10 which leads to CMYK 0.15/10.21/1/0 and actually
makes a difference on screen. (I just noticed that I probably won't make
a difference in print because everything below 6% tends to get dropped).

That's one example. You're actually in trouble if your customer hands
you a coporate design with CMYK values in it - there must not be the
slightest derivation from these values.

Bye,

Tino.




More information about the scribus mailing list