falk@sun.Eng.Sun.COM (Ed Falk) (03/31/89)
Announcing, the first annual comp.graphics awards for most frequently asked questions. Nomination #1: > Does someone have some good ideas and/or snippets of C code > for doing RGB -> CYMK conversion? TIA. ...doug beck > dbeck@unix.sri.com One of my personal favorites. Most questions reveal intelligence of the answerer in that smart people can answer the question and not-so-smart people can't. This question is unique in that the smart people are the ones who tell you they *can't* answer it. A common solution is to tell you that CMY = [ 1 1 1 ] - [ r g b ] with some correction applied to obtain black. However, the transfer function is nowhere near linear and varies with everything from how you adjusted your monitor when you looked at the original to how the room is lit to the phase of the moon. There are people who make their livings coming up with good values for C,M,Y,K. To do it properly, what you need to do is sit down with a book of sample colors with their CMYK components listed. Look through the book and choose the color you want. With luck, you can come up with a graphics program that can display reasonable approximation to what you want under certain circumstances, but there's no one way to do the transformation. Also, CMY = [ 1 1 1 ] - [ RGB ] doesn't even come close. At the very least you need to do gamma correction. Our next nominee is: > Hello all, > > I am looking for a fast algorithm to find all the points inside an > arbitrary polygon. Does anyone have any code (in any reasonable > language) to do this reliably and quickly? I hope you're not talking about real numbers here. There are an infinite number of points inside a polygon. Are you talking about how to scan-convert a polygon in integer coordinates or are you talking about how to test a point to see if it's inside or outside? If you want to scan-convert a polygon, check out Fundamentals of Interactive Computer Graphics by Foley and VanDam (sp?). They give a nice algorithm there. Also, Foley & VanD. give a couple of nice algorithms for filling an arbitrary boundary given any one point inside the boundary (this is called "seed-fill"). If you want to test to see if a point is inside a polygon, a simple way to to project a half-line out of the point and count how many edges it intersects. If the answer is odd, you're inside the polygon. Be careful with round-off error if you're not working with integers and be careful to look for cases where the halfline intersects a vertex of the polygon. Alternatively, you can sum up the angles from your point to all the vertices and see if it comes to 0 or 360. Details left to the reader because I'm late for an appointment. Next, we have: > Could anyone give me some help on this? Do you take the normalized > vector for a particular color and this is your percentage > in the shade of grey? (r * 0.??? + g * 0.??? + b * 0.???) = grey. > I get the impression that the various percentages for r, g, and b > should be about .300, .450, and .250 respectively. It doesn't matter all that much, you can get by with v=(r+g+b)/3 and your eye won't care. The "official" values (NTSC) are v = .299r + .587g + .144b. I've also seen .3r + .59g + .11b quoted. I was surprised that "How do I convert 24-bit true color to 8-bit colormap?" wasn't asked this month. -- -ed falk, sun microsystems sun!falk, falk@sun.com card-carrying ACLU member.
jonathan@jvc.UUCP (Jonathan Hue) (04/01/89)
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