[comp.graphics] Re; RGB to CYMK?? Anybody know of an algorithm??

rotberg@dms.UUCP (Ed Rotberg) (03/19/91)

Thanks to all who responded,  I am posting this summary of replies that I
received to my inquiry about RGB to CMYK conversion.



Message #1 (47 lines)
From weitek!pyramid!ratmandu.csd.sgi.com!shreiner Thu Mar 14 05:42:59 1991
Received: from pyramid.UUCP by weitek.COM (4.1/SMI-4.1)
	id AA22462; Wed, 13 Mar 91 21:31:04 PST
Received: by pyramid.pyramid.com (5.61/OSx5.0-890710)
	id AA09730; Wed, 13 Mar 91 21:16:41 -0800
Received: from relay.sgi.com by SGI.COM via SMTP (5.65+bind 1.5+ida/910110.SGI)
	for pyramid!weitek!dms!rotberg id AA15210; Wed, 13 Mar 91 20:58:26 -0800
Received: from rock.csd.sgi.com by relay.sgi.com (5.52/900423.SGI)
	for @sgi.sgi.com:rotberg@dms.UUCP id AA09563; Wed, 13 Mar 91 20:58:23 PST
Received: from ratmandu.csd.sgi.com by rock.csd.sgi.com (5.52/900721.SGI)
	for @relay.sgi.com:rotberg@dms.UUCP id AA05252; Wed, 13 Mar 91 20:58:21 PST
Received: by ratmandu.csd.sgi.com (5.52/900721.SGI)
	for @rock.csd.sgi.com:rotberg@dms.UUCP id AA02076; Wed, 13 Mar 91 20:58:38 PST
Date: Wed, 13 Mar 91 20:58:38 PST
From: weitek!ratmandu.csd.sgi.com!shreiner (Dave Shreiner)
Message-Id: <9103140458.AA02076@ratmandu.csd.sgi.com>
To: dms!rotberg (Ed Rotberg)
Subject: Re: RGB to CYMK??  Anybody know of an algorthim??




Hi Ed,

	If I understand you question correctly, converting between RGB and CMYK
is fairly straight-forward.  I'm going to assume that your RGB values are
0.0 <= r,g,b <= 1.0.  Then the following hold true :

		cyan     =  1.0 - red
		magenta  =  1.0 - green
		yellow   =  1.0 - blue

in the CMYK model, black is given by (cyan,magenta,yellow) = (1,1,1).  The 
text I looked in (Computer Graphics, Hearn & Baker, 1986 Prentice Hall,
ISBN 0-13-165382-2) was a bit foggy on deriving black explicitly.  I wrote a
program for a CMYK color printer (QMS 100 ColorScript), and in that
application,
The best solution was if (r,g,b) = (0,0,0) then black = 1.0, else black = 0.0.
It worked well for my application.  You may want to linearly scale the black
value as a sum of r, g, & b values or some other scheme.  Its kinda a "what
works well is my plan" judgement call.  

Hope that helps,
Dave

____________________________________________________________________________

Message #1 (37 lines)
From motcsd!lance Fri Mar 15 20:03:28 1991
Received: by motcsd.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)
	id AA02775; 15 Mar 91 19:01:02 PST (Fri)
To: dms!rotberg
Subject: Re: RGB to CYMK?? Anybody know of an algorthim??
Newsgroups: comp.graphics
References: <1222@dms.UUCP>
Message-Id: <9103151901.AA02775@motcsd.csd.mot.com>
Date: 15 Mar 91 19:01:02 PST (Fri)
From: lance.norskog <lance@motcsd.csd.mot.com>

Well, the basic theory is that RGB & CMY are complementary.
RGB = 1 - CMY.  That is, R = (Max_value - C), etc.  
I may have the pairs matched up wrong.  You'll just have to experiment there.

Now, the K value is just black.  In light, when you add R&G&B, you get
while.  But, in printing, you can lay down gallons of cyan, magenta, 
and yellow ink, and never get black.  Instead, you get an ugly dull dark
brown.  Printers lay down black first, then lay CMY on top of it.
So, in going between CMYK and RGB, you have to use adjust CMY by
the amount of K you're using.  How much K you're using is the judgment
of an experienced color printer press operator.

This should get you started.  If you want to match colors between
the monitor and the printed page, you'd better hire an expert.
I understand Pantone is getting into the color-match biz.  Call them.

If you're just fooling around, and want to view some CMYK on a VGA-type
screen, just use the above formulae, and experiment with "fudge factors":
common values for scaling and adding to the RGB values.

Lance Norskog

_________________________________________________________________________
Message #2 (109 lines)
From motcsd!infoserv!uunet!watmath!watsol.waterloo.edu!wewallac Sun Mar 17 04:40:29 1991
Received: by motcsd.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)
	id AA23367; 17 Mar 91 07:02:29 EST (Sun)
Received: by infoserv.com (3.1.18.1)
	id <m0jHvVU-0000hzC@infoserv.com>; Sun, 17 Mar 91 11:02 GMT
Received: from watmath.UUCP by uunet.UU.NET with UUCP 
	(5.61/UUNET-primary-gateway) id AA08781; Thu, 14 Mar 91 15:05:21 -0500
Received: from watsol.waterloo.edu by watmath.waterloo.edu with SMTP
	id <AA20419>; Thu, 14 Mar 91 12:34:42 EST
Received: by watsol.waterloo.edu
	id <AA15658>; Thu, 14 Mar 91 12:34:40 EST
Date: Thu, 14 Mar 91 12:34:40 EST
From: Bill Wallace <infoserv!uunet!watmath!watsol.waterloo.edu!wewallac>
Message-Id: <9103141734.AA15658@watsol.waterloo.edu>
To: dms!rotberg
Subject: Re: RGB to CYMK??  Anybody know of an algorthim??
Newsgroups: comp.graphics
In-Reply-To: <1222@dms.UUCP>
Organization: University of Waterloo

    The simple algorithm is to use c=1-r, m=1-g, y=1-b  and k=min(c,m,y)  As
a first, cheap approximation it might be acceptable.  Generally the images
produced with such an approximation are too dark or too light and lose
colour information and detail.  The gray scale produce with such a technique
is often brown, although it is sometimes a bit blue.  A second approximation
might be to print samples of each of c,m,y,k, say equally spaced and about
16 samples for each colour.  Then measure them (either visually or if you
have the equipment with a reflectance meter) and assign them a lightness level. 
For example, if there are four samples, full cyan, almost full cyan, a medium
cyan and a white, then the values might be:

Lightness	Cyan ink printed
0		1
0.1		2/3
0.5		1/3
1.0		0

This can be used to create a a maping between lightness and cyan ink printed.
The transformation then becomes c'=r  m'=g  y'=b  k'=max(c',m',y')
and then c',m',y',k' are mapped to inks printed using linear interpolation
and the lightness levels measured.  This technique is significantly better
than the previous technique.  Unfortunately, detail is still lost, colours
reproduced are not quite correct, and the gray scale is still somewhat
brown or blue.  To improve upon this, print gray scale wedges with about
the same number of steps and modify one of cyan, magenta or yellow ink
printed.  Create the same sort of tables, only choose the grayest sample
from the various wedges for each step.  An example would be:

Ink printed - for each of m,y,k print lightness of 1,2/3,1/3,0
For cyan, as given:
Step	c0	c1	c2	
0	.9	1	1
1	2/3-.1	2/3	2/3+.1
2	1/3-.1	1/3	1/3+.1
3	0	0	.1

If the gray sample  at step 0 where c0, at step 1, c1, at step 2, c0
at step 3,  c1 then the cyan would be modified by:
Lightness	Modification to cyan ink
1		-.1
2/3		0
1/0		-.1
0		0

This produces much better grays.  For many applications this is sufficient.
To get somewhat better results,  see:
M.J.Lamming, W.S.Rhodes,
"A Simple Method for Improved Color Printing of Monitor Images"
ACM Transactions on Graphics, 9(4), 1990, 345-375

still has some problems with colour fidelity and is really only for
monitor to print.  

To get really good results, see my own paper (Wallace and Stone) in the
SPIE 91 conference proceedings.  This technique is applicable to monitor
to offset press, colour LCD to monitor, monitor to monitor etc. 
Another reference which might be easier to acquire is
M.C.Stone, W.B.Cowan, J.C.Beatty
"Color Gamut mapping and the Printing of Digital Color Images"
ACM Transactions on Graphics


A good reference generally on this kind of thing is:
G.Wyszecki and W.S.Styles
Color Science, Second Edition
John Wiley and Sons, New York, 1982.

This last reference explains some of the techniques in much more detail.
It probably also has much more information about colour than you ever
wanted to know.

Bill Wallace
New OED
wewallace@watsol.waterloo.edu

________________________________________________________________________
Message #3 (48 lines)
From motcsd!infoserv!uunet!dartvax!eleazar.dartmouth.edu!npw Sun Mar 17 04:40:31 1991
Received: by motcsd.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)
	id AA23376; 17 Mar 91 07:02:34 EST (Sun)
Received: by infoserv.com (3.1.18.1)
	id <m0jHvVN-0000i7C@infoserv.com>; Sun, 17 Mar 91 11:02 GMT
Received: from dartvax.UUCP by uunet.UU.NET with UUCP 
	(5.61/UUNET-primary-gateway) id AA00334; Fri, 15 Mar 91 00:19:25 -0500
Received: from eleazar.dartmouth.edu by dartvax.dartmouth.edu (5.65+D1/4.4HUB)
	id AA02664; Fri, 15 Mar 91 00:07:06 -0500
Received: by eleazar.dartmouth.edu (5.65D1/4.2)
	id AA11881; Fri, 15 Mar 91 00:07:03 -0500
Date: Fri, 15 Mar 91 00:07:03 -0500
From: infoserv!uunet!dartvax!eleazar.dartmouth.edu!npw (Nicholas Wilt)
Message-Id: <9103150507.AA11881@eleazar.dartmouth.edu>
To: dms!rotberg
Subject: Re: RGB to CYMK??  Anybody know of an algorthim??
Newsgroups: comp.graphics
In-Reply-To: <1222@dms.UUCP>
Organization: Dartmouth College, Hanover, NH
Cc: 

Simplest conversion in the book.  RGB and CMY are complements; RGB are
the additive primaries and CMY are the subtractive primaries.  Thus,
RGB all together make white; CMY all together make black.

R = 1 - C	C = 1 - R
G = 1 - M	M = 1 - G
B = 1 - Y	Y = 1 - B

K is strictly an economical extension to the CMY model.  Take the minimum
of CMY, set K to it.  Subtract it off each of CMY.  This lets printers use
black ink instead of pouring lots of CMY all over the place.
	K = min(C, M, Y)
	C = C - K
	M = M - K
	Y = Y - K

The inverse of the above transformation should be obvious.

--Nick
  npw@eleazar.dartmouth.edu

__________________________________________________________________________
From weitek!sun.Eng.Sun.COM!mcrware!jejones Sun Mar 17 21:42:57 1991
Received: from mcrware.UUCP by weitek.COM (4.1/SMI-4.1)
	id AA12267; Fri, 15 Mar 91 22:02:37 PST
Received: from mcrware.UUCP by sun.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29396; Fri, 15 Mar 91 20:26:18 PST
Received: by microware.com (4.0/SMI-4.0)
	id AA10903; Fri, 15 Mar 91 10:18:18 CST
Date: Fri, 15 Mar 91 10:18:18 CST
From: weitek!sun.Eng.Sun.COM!mcrware!jejones (James Jones)
Message-Id: <9103151618.AA10903@microware.com>
To: sun.Eng.Sun.COM!uunet!samsung!zaphod.mps.ohio-state.edu!usc!apple!motcsd!dms!rotberg
Subject: Re: RGB to CYMK??  Anybody know of an algorthim??
Newsgroups: comp.graphics
In-Reply-To: <1222@dms.UUCP>
Organization: Microware Systems Corp., Des Moines, Iowa
Status: OR

Check out the cover article in the October 1990 ACM *Transactions on
Graphics*.  (Also, please do summarize replies to the net--thanks!)

	James Jones

__________________________________________________________________________
From steinmetz!uunet!leah.Albany.EDU!rsb584 Sun Feb  7 14:52:42 1988
Received:  by kbsvax.steinmetz (1.2/1.1x Steinmetz)
	 id AA16244; Sun, 7 Feb 88 01:21:17 est
Received: from LEAH.ALBANY.EDU by uunet.UU.NET (5.54/1.14) 
	id AA22387; Sun, 7 Feb 88 01:01:14 EST
Date: Sun, 7 Feb 88 01:03:56 EST
From: steinmetz!uunet!leah.Albany.EDU!rsb584 (Raymond S Brand)
Received: by leah.Albany.EDU (5.58/1.1)
	id AA15055; Sun, 7 Feb 88 01:03:56 EST
Message-Id: <8802070603.AA15055@leah.Albany.EDU>
To: beowulf!rsbx

>From spencer@crim.eecs.umich.edu Tue Feb  2 16:30:48 1988
Path: leah!uwmcsd1!bbn!husc6!cmcl2!nrl-cmf!ames!mailrus!umix!umich!spline!spencer
From: spencer@spline (Spencer W. Thomas)
Newsgroups: comp.graphics
Subject: Re: RGB to printer CMYK conversion
Message-ID: <760@zippy.eecs.umich.edu>
Date: 2 Feb 88 21:30:48 GMT
References: <10258@sgi.SGI.COM>
Sender: news@zippy.eecs.umich.edu
Reply-To: spencer@crim.eecs.umich.edu (Spencer W. Thomas)
Organization: University of Michigan EECS, Ann Arbor
Lines: 17
UUCP-Path: spline!spencer

Paul's code is good, as far as it goes.  There is a more complete discussion of
this topic in the most recent (Third issue 1987 = Vol 1, No 3) PostScript
Language Journal.  It goes into derivation details and talks about alignment of
halftone screens.  One thing that is discussed there that Paul's code doesn't
do is "undercolor removal".  This is necessary because the inks aren't pure,
thus magenta ink typically appears to be contaminated by yellow, for example.
The code is similar to that used for black removal.

Anyway, the PSLJ is available from 
	The PSLJ
	P.O. Box 5763
	Parsippany, NJ  07054

Single issues are $5.

[I have no association with the PSLJ other than that of a happy reader.]
=Spencer (spencer@crim.eecs.umich.edu)


From steinmetz!uunet!seismo!sundc!pitstop!sun!decwrl!hplabs!hpda!hpsal2!hpcupt1!hpirs!hpisoa2!jonathan Tue Feb  2 21:36:40 1988
Path: beowulf!steinmetz!uunet!seismo!sundc!pitstop!sun!decwrl!hplabs!hpda!hpsal2!hpcupt1!hpirs!hpisoa2!jonathan
From: jonathan@hpisoa2.HP.COM (Jonathan Hue)
Newsgroups: comp.graphics
Subject: Re: RGB to printer CMYK conversion
Message-ID: <1090001@hpisoa2.HP.COM>
Date: 3 Feb 88 02:36:40 GMT
References: <10258@sgi.SGI.COM>
Organization: Hewlett Packard, Cupertino
Lines: 44

>Someone asked about converting from RGB to prinyer CMYK.  Here is a
>simple conversion technique.

...which doesn't really produce anything useful.  If I had to do this,
(which I don't) here is what I would do:

Let's assume you have your system calibrated so that you can output
to a good film recorder (Dunn, Celco, Genigraphics, etc, but not a QCR)
and your transparency pretty much looks like your monitor.  Decide
what kind of paper and ink you are going to use.  Then, make a
Scitex CT2T magnetic tape of a bunch of color squares.  What would
probably be useful are the CMYK quads from (0,0,0,0) to (255,255,255,255)
in increments of 16.  Have a pre-press shop make a Cromalin from the
tape.  Next, make a transparency consisting of the RGB triplets from
(0,0,0) to (255,255,255) in little squares on your film recorder.  Then use
a transmission-reflection densitometer and measure the densities of your
17^3 RGB triplets and 17^4 CMYK quads.  Use a densitometer with an RS-232
on it so you don't have to write down all those numbers.  Interpolate the
17 levels of each color to some reasonable number, perhaps a number near a
hundred, maybe more for the CMYK quads.  Then map the RGB numbers into
the nearest CMYK quad.  Now you have an CMYK quad (for a given type of
ink and paper which is reasonably close to the RGB value you used to make
the color spot on your transparency.

This is what I thought of doing, other people presented with the same
problem have done the same thing as it's sort of the obvious thing to
do when you don't really understand the physics and math behind the
problem too well.  Some people think the results are pretty good.

This doesn't take too much work and you get way better results than
treating the inks as a "color space" which most people seem to
want to do for some reason, rather than real pigments.  If you are
smart I'm sure you can come up with a much better way, but at least
this does something useful.  If you have a big computer you can perhaps
interpolate 256^3 RGB triplets into 256^4 CMYK quads and get some
accurate numbers, even though you can't reproduce dots on the paper that
well.

Once you get this far it should be pretty easy to calibrate your monitor
to your transparency.  A color-tv analyzer (like Minolta's) would be
useful, and if you can find it, a densitometer that reads out in XYZ
or whatever that color space is called, I forget.

Jonathan Hue		..!hpda!jonathan


From jonathan@jvc.UUCP Fri Mar 31 15:05:24 1989
Path: leah!csd4.milw.wisc.edu!bionet!ames!hc!lll-winken!uunet!jvc!jonathan
From: jonathan@jvc.UUCP (Jonathan Hue)
Newsgroups: comp.graphics
Subject: Re: Computer Graphics Academy Awards.
Message-ID: <478@jvc.UUCP>
Date: 31 Mar 89 20:05:24 GMT
References: <28994@sri-unix.SRI.COM> <96848@sun.Eng.Sun.COM>
Organization: JVC Laboratory of America
Lines: 43

In article <96848@sun.Eng.Sun.COM>, falk@sun.Eng.Sun.COM (Ed Falk) writes:
> Announcing, the first annual comp.graphics awards for most frequently asked
> questions.
> 
> Nomination #1:

I would go even farther than this.  I claim that there is no such thing
as an RGB->CMYK conversion.  The reason is that you can't completely
describe a color as an RGB triplet or CMYK quad.  Describing a color
as RGB or CMYK numbers is device/media dependent.  The numbers don't
mean anything outside the context of the device.  Now, if you were to fully
qualify the RGB numbers with the chromaticity coordinates of the primaries,
and gamma (and viewing conditions for a monitor - as far as I know no standards
exists for "soft" proofing"), and the CMYK numbers as some sort of
ink/paper/press/??? (my understanding is that there are variances due
to which point in a press run something is printed, so that is yet another
variable, there are others) combination, you could come up with an RGB->CMYK
conversion for going between those two devices.

Actually, the relationship between intensity and voltage on a monitor only
approximates I=kV^gamma, so you really need to find out the luminance/voltage
transfer function for each component.

I think the best way to figure out the conversion is to map the color spaces
of the devices into/out of a universal color space.  I would probably pick
Luv, so I could measure color differences as Euclidean distance in L*u*v*
space.  I know this is nothing new, Eikonix has been pushing universal
color spaces for years, but I am dense so I'm just catching on now.

Two useful devices for figuring out the conversion are a spectrophotometer
(Minolta makes a cheap one, the CM-1000 for $20K, Hunter also except the head
isn't separate) and a color TV analyzer (again, Minolta makes a cheap one).
If your requirements are not too high, you can use a colorimeter instead of a
spectrophotometer.  You can get a reasonable colorimeter for about $6K
(Minolta CR221).  All of these devices can measure color in xyY, and you can
convert that to uvL easily.  I've been recommending that users of our color
printer purchase these instruments.

If anyone knows of instruments which offer better price/performance, I'd like
to know about them so I can pass that information on to our users.


-Jonathan Hue		uunet!jvc!jonathan


From hutch@rawfish.UUCP Wed Apr  5 14:59:08 1989
Path: leah!csd4.milw.wisc.edu!lll-winken!uunet!seismo!esosun!cogen!celerity!rawfish!hutch
From: hutch@rawfish.celerity (Jim Hutchison)
Newsgroups: comp.graphics
Subject: Re: RGB -> CYMK conversion
Message-ID: <275@celerity.UUCP>
Date: 5 Apr 89 18:59:08 GMT
References: <28994@sri-unix.SRI.COM> <390026@hpfcdq.HP.COM>
Sender: news@celerity.UUCP
Reply-To: hutch@rawfish.UUCP (Jim Hutchison)
Distribution: na
Organization: FPS Computing
Lines: 32

RGB -> CMYK is not as simple as it might initially appear.
Note for convenience all color values below are normalized.
Gunk is the non-technical term I will use for ink/wax/jam.

If you are taking RGB to perfect CMYK, the operation is trivial,
you set K=0, C=1-(B+G)/2, M=1-(B+R)/2, Y=1-(R+G)/2.

Unfortunately C,M,Y=1,1,1 is a lousy black.  It has too much gunk
on the page, and is a color which I've seen to vary from bluish to
brownish black.  So, in comes black.  You want black to be a good
solid black without having 3 times the amount of gunk on the page
to do it.  An initial guess would be to make the transformation
with as much black as possible; K=1-min(RGB), C=C-K, M=M-K, Y=Y-K.
This puts the least ink on the page, and works.  Unfortunately
this really brings out the detail of the print screen used and
makes the print look a little garish (atleast to me).  So a next
obvious step is to do the black by percentage.  60-80% seems to
be what Hell suggests in their GCR (under color correction) poster.

Now that that is over with, on to gunk correction.  The unfortunate
thing about gunk (be it ink, wax, or some other pigment) is that
it is not pure in its absorption of color.  So you need to do a map
from RGB to CMY.  Luckily this is R3->R3 so there should be only 1
right answer, ignoring sampling frequency.  Unfortunately I can't
tell you the best way I know to do this, as I don't own it.  The
gist of the problem is to figure out how much of each R, G, and B
are absorbed by each C, M, and Y.  Black is excellent, you should
not have to ever worry about black (with any of today's standard
black pigments).  Ramps of uncorrected R, G, and B checked with a
densitometer should get you in the ballpark.
/*    Jim Hutchison   		{dcdwest,ucbvax}!ucsd!celerity!hutch  */
/*    Disclaimor:  I am not a official spokesman for FPS computing    */


From jlg@hpfcdq.HP.COM Mon Apr 10 21:00:44 1989
Path: leah!csd4.milw.wisc.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!hpfcdq!jlg
From: jlg@hpfcdq.HP.COM (Jeff Gerckens)
Newsgroups: comp.graphics
Subject: Re: RGB -> CYMK conversion
Message-ID: <390028@hpfcdq.HP.COM>
Date: 11 Apr 89 01:00:44 GMT
References: <28994@sri-unix.SRI.COM>
Organization: Hewlett-Packard - Fort Collins, CO
Lines: 54

> / hpfcdq:comp.graphics / hutch@net1.ucsd.edu (Jim Hutchison) / 11:38 pm  Apr  5, 1989 /
> RGB -> CMYK is not as simple as it might initially appear.
> Note for convenience all color values below are normalized.
> Gunk is the non-technical term I will use for ink/wax/jam.
> 
> If you are taking RGB to perfect CMYK, the operation is trivial,
> you set K=0, C=1-(B+G)/2, M=1-(B+R)/2, Y=1-(R+G)/2.

No, [ R G B ] = [ 1 1 1 ] - [ C M Y ].

> Unfortunately C,M,Y=1,1,1 is a lousy black.  It has too much gunk

Yes.

> on the page, and is a color which I've seen to vary from bluish to
> brownish black.  So, in comes black.  You want black to be a good
> solid black without having 3 times the amount of gunk on the page
> to do it.  An initial guess would be to make the transformation
> with as much black as possible; K=1-min(RGB), C=C-K, M=M-K, Y=Y-K.
> This puts the least ink on the page, and works.  Unfortunately
> this really brings out the detail of the print screen used and
> makes the print look a little garish (atleast to me).  So a next
> obvious step is to do the black by percentage.  60-80% seems to
> be what Hell suggests in their GCR (under color correction) poster.

K=min(CMY) , preferably with some threshold (&& K > .6),
C=C-K, M=M-K, Y=Y-K as before.

> Now that that is over with, on to gunk correction.  The unfortunate
> thing about gunk (be it ink, wax, or some other pigment) is that
> it is not pure in its absorption of color.  So you need to do a map
> from RGB to CMY.  Luckily this is R3->R3 so there should be only 1
                                   ^^^^^^^^

Actually this is best accomplished by primary conversion using
the CIE 1931 XYZ space as a standard, measurable intermediate.
A brief description of the analogous procedure for phosphors
appears in Rogers (Procedural Elements for Computer Graphics).


> right answer, ignoring sampling frequency.  Unfortunately I can't
> tell you the best way I know to do this, as I don't own it.  The
> gist of the problem is to figure out how much of each R, G, and B
> are absorbed by each C, M, and Y.  Black is excellent, you should
> not have to ever worry about black (with any of today's standard
> black pigments).  Ramps of uncorrected R, G, and B checked with a
> densitometer should get you in the ballpark.

Or call the manufacturer to get the CIE (x,y) chromaticities of the
gunks and your monitor.  Or use a colorimeter.
> 
> /*    Jim Hutchison   		{dcdwest,ucbvax}!ucsd!net1!hutch  */

-- Jeff Gerckens jlg%hpfcrg@hplabs.hp.com


From steinmetz!uunet!leah.Albany.EDU!rsb584 Tue Feb  2 14:51:45 1988
Received:  by kbsvax.steinmetz (1.2/1.1x Steinmetz)
	 id AA01429; Tue, 2 Feb 88 12:12:14 est
Received: from LEAH.ALBANY.EDU by uunet.UU.NET (5.54/1.14) 
	id AA03430; Tue, 2 Feb 88 12:02:08 EST
Date: Tue, 2 Feb 88 12:04:29 EST
From: steinmetz!uunet!leah.Albany.EDU!rsb584 (Raymond S Brand)
Received: by leah.Albany.EDU (5.58/1.1)
	id AA13649; Tue, 2 Feb 88 12:04:29 EST
Message-Id: <8802021704.AA13649@leah.Albany.EDU>
To: beowulf!rsbx

>From paul@sgi.SGI.COM Mon Feb  1 14:45:55 1988
Path: leah!uwmcsd1!ig!agate!aurora!ames!sgi!paul
From: paul@sgi.SGI.COM (Paul Haeberli)
Newsgroups: comp.graphics
Subject: RGB to printer CMYK conversion
Message-ID: <10258@sgi.SGI.COM>
Date: 1 Feb 88 19:45:55 GMT
Organization: Silicon Graphics Inc, Mountain View, CA
Lines: 123

Someone asked about converting from RGB to prinyer CMYK.  Here is a
simple conversion technique.

			Paul Haeberli 

/*
 *	RGBtoCMYK -
 *		This program demonstrates an easy way to convert from
 *	RGB space to printer CMY and K.  This method does grey component 
 *	replacement, so achromatic parts of the image will be printed with 
 *	only black ink.  
 *
 *	R is red.	C is cyan.
 *	G is geen.	M is magenta.
 *	B is blue.	Y is yellow.
 *			K is black.
 *
 *		    Paul Haeberli / Silicon Graphics - 1987
 */
main()
{

/* print header */
    printf("r\tg\tb\t|\tc\tm\ty\tk\n");

/* transform the corners of the color cube */
    printf("-----------------------------------------------------------\n");
    printvals(0,0,0);
    printvals(0,0,255);
    printvals(0,255,0);
    printvals(0,255,255);
    printvals(255,0,0);
    printvals(255,0,255);
    printvals(255,255,0);
    printvals(255,255,255);

/* up one edge of the color cube */
    printf("-----------------------------------------------------------\n");
    printvals(0,0,0);
    printvals(0,0,32);
    printvals(0,0,64);
    printvals(0,0,128);
    printvals(0,0,192);
    printvals(0,0,255);

/* transform a few a chromatic colors */
    printf("-----------------------------------------------------------\n");
    printvals(0,0,0);
    printvals(1,1,1);
    printvals(16,16,16);
    printvals(32,32,32);
    printvals(64,64,64);
    printvals(128,128,128);
    printvals(192,192,192);
    printvals(255,255,255);
}

printvals(r,g,b)
int r, g, b; 
{
    int c,m,y,k;

    rgb_to_cmyk(r,g,b,&c,&m,&y,&k);
    printf("%d\t%d\t%d\t|\t%d\t%d\t%d\t%d\n",r,g,b,c,m,y,k);
}

/*
 *	rgb_to_cmyk -
 *		Convert from rgb to cmyk.  This implements grey component
 *	replacement. 
 *
 *	Inputs:
 *		r intensity 0 to 255
 *		g intensity 0 to 255
 *		b intensity 0 to 255
 *
 *	Outputs:
 *		c coverage 0 to 255
 *		m coverage 0 to 255
 *		y coverage 0 to 255
 *		k coverage 0 to 255
 *
 *
 *	An input value of rgb=[255,255,255] represents white.  When this is
 *	transformed to cmyk, we get cmyk=[0,0,0,0] which represents zero 
 *	coverage. 
 *
 *	An input value of rgb=[128,128,128] represents 50 percent grey.  When
 *	this is transformed to cmyk, we get cmyk=[0,0,0,127] which represents 
 *	zero coverage by cmy, and 50 percent coverage by black. 
 *
 */
rgb_to_cmyk(r,g,b,c,m,y,k)
int r, g, b;
int *c, *m, *y, *k;
{
    int i; 

/* i is the max of r, g, and b */
    i = 0;
    if(r>i)
	i = r;
    if(g>i)
	i = g;
    if(b>i)
	i = b;

/* if r, g and b are all zero then print full black */
    if(i == 0) {
	*c = 0;
	*m = 0;
	*y = 0;
	*k = 255;
	return;
    }
    r = (255*r)/i;
    g = (255*g)/i;
    b = (255*b)/i;
    *c = 255-r;
    *m = 255-g;
    *y = 255-b;
    *k = 255-i;
}