Xref: utzoo comp.sys.amiga.tech:17263 comp.graphics:15133 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!karazm.math.uh.edu!jet From: jet@karazm.math.uh.edu ("J. Eric Townsend") Newsgroups: comp.sys.amiga.tech,comp.graphics Subject: Re: QMS plotmaster colors & pantone colors Message-ID: <1990Dec28.225435.214@lavaca.uh.edu> Date: 28 Dec 90 22:54:35 GMT References: <521358@neabbs.UUCP> Sender: nntppost@lavaca.uh.edu (NNTP Posting Service) Organization: University of Houston -- Department of Mathematics Lines: 66 [I've xposted this to comp.graphics as some guru there might be able to correct my mistakes or add more information.] In article <521358@neabbs.UUCP> rrs@neabbs.UUCP (RONALD VAN EIJCK) writes: >The problem is : monitor colors != paper colors. There was a panel devoted to this at SIGGRAPH '90. Believe me, this problem exists with probably every computer sold OTC in the world. (Except MacInTrashes working in on/off bitmap mode with a LaserWriter. 1/2 :-) >The solution at the moment is that they have a lot of papers with colors >on them and find the matching color for the color on screen. they then change >the colors on screen (using the DPAINT pallet function). That's a pretty reasonable way to do things considering the level of technology you own and the bucks the average person has to spend. >The colors on screen are wrong then but if you print the picture it looks >alright. (THIS IS NOT A SOLUTION!) For what you're doing, it's probably *the* solution, barring writing a bunch of new code and buying something big to crunch all the numbers. The linear transformations needed to go from one chunk of colorspace to another are computationally expensive. (One of the SIGGRAPH panelists joked that they didn't see a problem with the linear transformation cost, they just ran it on their Convex.) Your other option is to do what I have done and buy a film recorder. The colors match up pretty damn well -- they'd better, since the idea is to take a picture of the "screen" under controlled settings. >My question is, is there some formula to translate screencolor RGB values >to QMS plotmaster RGB values. If so I can write a program that reads a >picture calculates the paper-RGB's and prints the picture. RGB != RGB, unless you're rather lucky. If I display (128,64,64) on my Sun SparcStation w/ Sony monitor, it will *not* look like (128,64,64) on an Amiga. It'll be close, granted, but it won't be the same. Neither one will look like (128,64,64) on . You might want to try printing a series of "test pages" where you print little blocks of color with the corresponding amiga or QMS RGB values. Now, you can go back and match up all the little blocks by hand and look for a function that describes the relationship. Have fun. :-( >Another great option would be to translate PANTONE COLORS (some international >color numbering system) to RGB values and paper-RGB values Well, again, you're screwed. Seiko has a Pantone (tm) certified Color PostScript printer that you might want to look at. (We're going to get one.) Apparently you can tell it "print Pantone color # x" and it generates that Pantone color. The problem is, nobody makes a Pantone certified monitor (that I'm aware of). fyi, Pantone is a company, not an ISO standard. There *are* ISO standards for color mapping, and I'd be surprised if somebody hasn't written a rough AmigaIFF<->ISO translator. Hell, just play with the knobs on your monitor, that might fix the problem. Or turn on/off various lights in the room. See how complicated the problem of making screen == paper is? -- J. Eric Townsend Internet: jet@uh.edu Bitnet: jet@UHOU Systems Mangler - UH Dept. of Mathematics - (713) 749-2120 "If you are the system administrator and this is the first time you are logging into your system, use the login name root." -- IBM RS/6000 docs