rotberg@dms.UUCP (Ed Rotberg) (04/05/91)
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; }