[Scribus] RGB to CMYK conversion
Hal V. Engel
Tue Feb 6 20:08:07 CET 2007
On Tuesday 06 February 2007 03:12, Peter Nermander wrote:
> > 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.
This why we say that a profile characterizes a device. Many confuse this with
calibration which is a totally different this.
Also for color management to be really be correct you must use the correct
profiles through out the whole work flow. CM has a significant learning
curve don't expect to understand it in a few hours. And do expect to spend
many days learning about it to be able to use it correctly in every part of
your work flow. If used up to its potential it is a very powerful tool.
> 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
> 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 "suitable colorspace" is called the Profile Conversion Space or PCS for
short. This is either CIELab or CIEXYZ which are both standardized color
spaces that are based on standards (CIE) that predate digital computers.
These color spaces can express every human visible color on an absolute
> (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.
You really should not be doing a backwards conversion and you should always
treat any file that has converted your images to some output (like printer)
color space as a temporary output file. You should maintain as much of your
work in the original color space(s) as possible. These color space
conversions are almost never lossless particularly if the conversion is to a
limited gamut color space device such as a printer.
> 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 them.
> 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.
The real issue with color spaces such as CIELab is that these color spaces are
huge being much bigger than needed for real world work. This is all very
device dependent. Devices like DSLR and slide film cameras can approach 70%
of the gamut of CIELab with consumer digicams being closer to 50% of CIELab.
sRGB which is very close to a typical monitor's gamut is about 35% of CIELab
and most printers are in the 15% to 25% range. For most of these devices
using 16 bits/channel is all that is needed and for some 8 bits/channel is
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
More information about the scribus