Very Computer

I'm coding an application that needs a color picker that converts RGB values
into CMYK percentages. It will work just like the color dialog in Adobe
Photoshop. I just need the algorithm that converts the numbers, I'm not
worried about creating device-dependent color models for printing...yet.

I've a tested a few algorithms I've found in books and from internet and
they give me roughly the same values. The problem is when I test these
values with Photoshop's algorithm they're off by quite a bit.

Any help would be greatly appreciated.

The following examples are not yielding accurate values

RGB to CMY

c = 255 - red;
m = 255 - grn;
y = 255 - blu;

CMY to CMYK

k = Math.min( c, Math.min( m, y ) );
c = 255*( c - k ) / (255 - k);
m = 255*( m - k ) / (255 - k);
y = 255*( y - k ) / (255 - k);

RGB to CMYK

m = Math.max(red, Math.max( grn, blu ));
K = 255 - m;
C = 255 * (m - red) / m;
M = 255 * (m - grn)  / m;
Y = 255 * (m - blu) / m;

Quote:> I'm coding an application that needs a color picker that converts RGB values
> into CMYK percentages. It will work just like the color dialog in Adobe
> Photoshop. I just need the algorithm that converts the numbers, I'm not
> worried about creating device-dependent color models for printing...yet.
> I've a tested a few algorithms I've found in books and from internet and
> they give me roughly the same values. The problem is when I test these
> values with Photoshop's algorithm they're off by quite a bit.
> Any help would be greatly appreciated.
> The following examples are not yielding accurate values
>....

Jackson, the pure mathematical transformation should be written
as follws,IMO. Of course, this is far away from an application
for printers.

 RGB to CMY (valid in a color order system like RGB, HLS)
 C = 100*(1-red/255);
 M = 100*(1-grn/255);
 Y = 100*(1-blu/255);

 CMY to CMYK (complete UCR, crude approximation for Offset)
 K = Min(C,M,Y);
 C = C-K;    ( one of CMY is 0 )
 M = M-K;
 Y = Y-K;

 RGB to CMYK
 as above

In PhS I didnt find such a conversion. In my opinion, PhS
applies always the selected Printing Process Profile, like
SWOP, EuroStandard ...
There is a discussion about in the Google PhS Forum
(True CMYK ...).

Best regards  --Gernot Hoffmann

Hello Gernot,
What I'm referring to is the Brushes window in Photoshop. If you select the
Color tab it shows you the individual values for RGB, CMYK, LAB, Grayscale
and HSB for the current selected color. You can make this selection by
clicking the right arrow button in the far right corner of the window.

For example, if the current selected color has a RGB value of {45, 151, 19},
you can select CMYK sliders and the equivalant in CMYK {69%, 20%, 100%, 5%}
will be shown. This is what I'm trying to do. I need to write a method that
takes the current RGB values and returns an array of equivalent CMYK
percantages.

Quote:

> In PhS I didnt find such a conversion. In my opinion, PhS
> applies always the selected Printing Process Profile, like
> SWOP, EuroStandard ...
> There is a discussion about in the Google PhS Forum
> (True CMYK ...).

> Best regards  --Gernot Hoffmann

Quote:> I need to write a method that takes the current RGB values and returns an
> array of equivalent CMYK percantages.

This is easy to do badly. It is harder to do correctly. It is very hard to
do it for an arbitrary set of inks or variable definitions of CMYK, which is
why everyone uses ICC profiles. There is a freeware ICC implementation
available somewhere.

If you are interested in state-of-the-art separation technology that
doesn't require an existing profile definition, see Cerilica's TruismII:
<http://www.cerilica.com/truism/>

--

Quote:> For example, if the current selected color has a RGB value of {45, 151, 19},
> you can select CMYK sliders and the equivalant in CMYK {69%, 20%, 100%, 5%}
> will be shown. This is what I'm trying to do. I need to write a method that
> takes the current RGB values and returns an array of equivalent CMYK
> percantages.

how many CMYK percents do you get with a RGB(255,255,255) and
RGB(128,128,128) ? Does it seems to be linear or not over all the RGB
range ? Normally, CMY is supposed to be linear as it's just a
substraction but well, one can expect some calibration from Photoshop
and that would explain the differences.

dake/calodox
www.calodox.org

The biggest problem is finding the right way to calculate k (black).  It
varies for
every device.  This algorithm just minimizes the use of color and increases
the use of black.

I found this info at
http://www.research.microsoft.com/~hollasch/cgindex/color/cmyk.html
-----------------------------------------------------------------------
Bill Rozzi, comp.graphics
Many people have written:

 black   = min (cyan, magenta, yellow)
 cyan    = cyan - black
 magenta = magenta - black
 yellow  = yellow - black

Let's clear this up now. If you read the PostScript manuals, the above
equations are what you'll find. Unfortunately, they're not quite correct.
What you really want to use to adjust the cyan, magenta, and yellow values
for the addition of the black are:
 cyan    = (cyan - black) / (1 - black)
 magenta = (magenta - black) / (1 - black)
 yellow  = (yellow - black) / (1 - black)

assuming component values in the range [0, 1]. These equations have been
(correctly) derived for many years in many graphics arts texts (e.g. Ref 1
and many TAGA publications); I don't know why Adobe couldn't get it right.

-----------------------------------------------------------------------

Once again the problem is with calculating the percentage of black. I've
read
about using a 2D lookup table, but I'm not in league mathmatically with
most of the users found in this group. When I use the algorithm above I get
correct values linearly for CMY but the K component is giving me fits.

For example, if the minimum value for black is 0.0 (or 0%), then this is the
value
used to calculate black. But black in CMYK is 1.0 (or 100%).

RGB to CMYK
(division takes 1 or 2 instructions per bit of precision in result)
(0 - 255 scale)

    m = 255 - max(red, grn, blu);
    K = 255 - m;
    C = 255 * (m - red) / m;
    M = 255 * (m - grn) / m;
    Y = 255 * (m - blu) / m;
    m = max(red, grn, blu); 2-D Lookup Tables

Confused? I am. Thanks everyone, I'll keep hacking!

Jackson - no problem.
The UCR (Undercolor Removal) or GCR (Gray Component Replacement)
can be done by many different formulas.
It depends entirely on the physical printing process.
E.g. for InkJets its highly recommended to replace much CMY by K
because of the instability if ink mixtures.
You may have a look in PhS, CMYK settings. Here you can see the
curves. Normally, min(C,M,Y)is not totally replaced because this
works only in theory (causes ugly blotches).
And not to forget:
Gamma correction before and Dot Gain correction after RGB-CMYK
conversion.
The Gamma-Distortion cannot be used as Dot-Gain-Correction,
because the curves are different (there is no "fortunate coin-
cidence" as you may read here and there, its just the same
tendency).

Best regards ----Gernot Hoffmann

Wow! Thank you. I think I finally got something working. I've
been writing these functions in Java 2 and just installed the
Java Advanced Imaging Kit (JAI) which includes an ICC
profile for CMYK. The difficulty for me has been once
a valid CMYK color model has been converted from
RGB, how do I represent the individual RGB and CMYK
values accurately to the user after the calibration? Just
thinking out loud here, I could possibly write object info
out as a string and see if it contains a list of color
parameters.

Thanks to everyone for their replys!

Jackson, let me also think loud here:

An RGB image can have an embedded profile (tagged profile).
This includes the three corners and the white point of the RGB
editing space (working space). With THIS information its
possible to calculate the true physical colors e.g. in
CIE XYZ, and any further transformation into a new working
space is possible. This is used in the PhS color management.
Select "embed profiles".

A CMYK file could have also an embedded profile, but this is
totally useless, because CMYK files are made for a final pur-
pose, e.g. offset printing, and further conversions are (lets
say) not allowed.
I ask my Print&Pressman: shall we use Euro Coated with dot gain
9% and UCR as recommended in PhS ? If yes, then I convert the
color images by this profile and the Print&PressMan sends these
data without a conversion to the image setter for the films.
So, the embedded CMYK profile can be used to tell the receiver
which printing process was assumed, the numerical data are not
required and very often confusing.

In PageMaker (Desktop Publishing) either the embedded CMYK infor-
mation has to be used, or I tell PM explicitely the source profile
name.
This is an exception, because PM shows CMYK images ON THE MONITOR
correctly only if the color management is enabled.

Best regards  --Gernot Hoffmann

The www.inforamp.net/~poynton/ColorFAQ.html specifically warns against using
[CMY] = 1 - [RGB]. Many sources have cited this linear approach as the
defacto standard for converting CMY to RGB. No wonder my results have been a
dismal failure, particularly when you factor in the complexities of
representing this information numerically as a RGB to CMYK color space!

I realize that due to the differences in Ink and paper that a true and
accurate
representation of a CMYK color on a computer screen converted from RGB is
almost an excercise in futility.

What if I convert RGB to sRGB to CIE ZYZ and then to CMYK? I can
do this using Java Advanced Imaging and a CMYK ICC Color profile.