[Scribus] RGB to CMYK conversion

Peter Nermander m8130
Tue Feb 6 12:12:24 CET 2007

> This is to some degree wrong, because there simply is no "default" in
> CM nor is it in PS CM.
> If you convert from rgb to cmyk you at least have to decide if or if
> not to use the input profile
> wich is provided or not provided within the rgb file.

I think it is very important to understand a few parts of color management to
understand this. (It took a while for me to understand this myself, so I explain
it the way I would have wanted to read it:-)

In a normal digital image each pixel does NOT have a color. It only has a number
(often 24 bit number). But this number alone DOES NOT tell how this color looks.

What tells you how the color looks is the color profile used, whether it is
embedded or not does not matter, the profile is the "cross reference" between
the numbers a pixels have and the color it is supposed to have.

Most of us understand that an RGB of 255:0:0 is a red color, but WHAT red color?
It all depends on the profile. 255:0:0 in one profile is not tha same color as
255:0:0 in another profile. That is very important to understand.

Now, when translating from RGB to CMYK you FIRST have to translate the RBG
number into a color of a suitable colorspace, using the color profile for the
source image. The next step is to translate that color into a CMYK number by
using a target color profile.

(The above also goes for when you need to convert an RGB image to RGB, using a
monitor profile, to have your monitor display colors right.)

Now, if you are going to print on another target than you used for the target
profile, you have to do a backwards conversion of the CMYK value to a color
using your original target profile, and then using the new target profile you
convert to new CMYK values for the new target.

So, as stated above, there is no "default" because there are at least two
different color profiles needed for an RGB to CMYK conversion. Any "default"
will have to assume one or both of these profiles if you do not explicitly state

Of course we would not have these problem if all images were using a wide
colorspace like CIE Lab or something, but if I understand right that would mean
each pixels color would have to be described using float numbers, thus files
would grow by something like a factor of 10. So your 4 megapixel uncompressed
images would become 120 MB instead of 12 MB.


More information about the scribus mailing list