🚀 go-pugleaf

In article <521358@neabbs.UUCP>, rrs@neabbs.UUCP (RONALD VAN EIJCK) writes...
|Hi there,
| 
|The problem is : monitor colors != paper colors.
| 

There is a setting in Preferences that does this for you. I'm not sure what the
setting is, but there is one...

|Ronald van Eijck, R&R Software, RRS@Neabbs.uucp
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|   //     Joseph Hillenburg, Secretary, Bloomington Amiga Users Group        |
| \X/  anlhille@ucs.indiana.edu                     anlhille@iurose.BITNET    |
|        "I'd take an Amiga 3000UX over this stupid VAX/VMS anyday!"          |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

In article <521358@neabbs.UUCP> rrs@neabbs.UUCP (RONALD VAN EIJCK) writes:
>Hi there,
>
>Since I am not very good using paintbrushes etc. my knowledge of colormixing
>is very limited. But since one of my customers is using DPAINT & a QMS plot-
>master I am afraid that I have to extend myself.
>
>The problem is : monitor colors != paper colors.
>
This is true.  Unfortunately, you are working with widely disparate
systems here.  Light (for monitors) is subractive and pigment (on paper)
is additive.  Not to mention that it will be different on each printer.

>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).
>The colors on screen are wrong then but if you print the picture it looks
>alright. (THIS IS NOT A SOLUTION!)
>
This has been a solution for many years even before they were using computers.
If they have the RGB or HSV settings written out for each desired color
then translation shouldn't be too bad.

>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.
>
You could do a lookup table based on their current translation that they
are doing by hand.

>Another great option would be to translate PANTONE COLORS (some international
>color numbering system) to RGB values and paper-RGB values
>
I believe Professional Page and/or Professional Draw from Gold Disk support
Panatone.

>thanx for any info,
>
>Ronald van Eijck, R&R Software, RRS@Neabbs.uucp

Larry Cline

>>The problem is : monitor colors != paper colors.

  Yep. Welcome to Color NonWYSIWYG. Its even worse than that, actually,
  monitor colors today != monitor colors tomorrow.
  printer colors today != printer colors tomorrow

  My current job at radius is writing the software for a little gizmo we
 sell that calibrates monitors so that they're consistent from day to day. 

>The linear transformations needed to go from one chunk of colorspace to
>another are computationally expensive.


  Inks are nasty. Most printers work by printing various size dots of Cyan,
 Yellow, and Magenta. Cyan removes Red light, Yellow removes Green light, and
 Magenta removes Blue light.

  In theory.

  In practice, CMY aren't independent of each other, so C != (1-R).
  Also C+M+Y does not equal black, so printers add a fourth ink, black. 
 (called K for Key. Black ink is also cheaper.)

 Imagine you've got four circles of various sizes and colors that are kind
 of transparent. (four glass circles). size the circles until you get the
 color you want, remembering that you have to count both the overlapping and
 non-overlapping portions. (the color is as seen from 10' away).
 
 That's the simplest possible model.

 Now imagine that you have to ask someone else to cut the circles for you.
 Imagine that person is deaf, and doesn't quite hear you correctly, so the
 circles are sometimes a little bigger or smaller, or not quite circles.

 Got a color matched? Good, now feed the paper in crooked and slide all the
 yellow circles over 1%.


>>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.

   There's an alogrithm:

     gamma correct your monitor.
     convert from your monitors phosphor set to CIE XYZ (a device independent
        color space based on human vision).
     Buy a spectrophotometer.

     Print out every possible combination of C,M,Y,K.
     Measure output swatches with spectrophotometer to make a XYZ-CMYK
        lookup table.

    Convert images to XYZ, then lookup CMYK.

    Print.


   Believe or not, that's about the state of the art (minus details).

><device-1> RGB != <other-device> 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 <printer>.

   Yeah, but monitor RGB -> XYZ is a 3x3 multiply and some gamma correciton.

>>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.

   Actually, radius does. Only for the macintosh, though.

   There are a lot of Pantone Certified printers, and Pantone has Pantone
 colors for the screen (using my toolkit), but you have to be a Pantone 
 licensee to get them.

  However, Pantone sells a book with CMYK seperations of the Pantone colros
 for a SWOP standard (standard set of CMYK inks) that you can buy.


Pierce
-- 
My postings are my opinions, and my opinions are my own not that of my employer.
You can get me at radius!pierce@apple.com.
(Wha'ja want? Some cute signature file? Hah! I have real work to do.

In article <1390@radius.com> pierce@radius.com (Pierce T. Wetter III) writes:
>>>The problem is : monitor colors != paper colors.
>
[Much other text deleted...]

>
>   There's an alogrithm:
>
>     gamma correct your monitor.
>     convert from your monitors phosphor set to CIE XYZ (a device independent
>        color space based on human vision).
>     Buy a spectrophotometer.
>
>     Print out every possible combination of C,M,Y,K.
>     Measure output swatches with spectrophotometer to make a XYZ-CMYK
>        lookup table.
>
>    Convert images to XYZ, then lookup CMYK.
>
>    Print.
>
>
>   Believe or not, that's about the state of the art (minus details).
>
Also worth adding, for those about to embark upon attacking this problem, is 
the knowledge that not every monitor color can be expressed on paper as a CMYK
combination. i.e. the monitor's gamut is often a superset of the printer's
gamut and in places the two may  not overlap at all...



-- 
+-----------------------------------------------------------------------------+
|Grant C Blair, DuPont Imaging Systems, Newark, DE 19702, USA                 |
|blair@pyro.ei.dupont.com (192.58.195.64)        (302)-733-9533               |
+-----------------------------------------------------------------------------+

     In a time long long ago, in an industry (photoengraving) far, far
away...

     Macbeth Daylighting, of Newburgh, New York, used to sell a device
called a ChromoCritic, mnaufactured by Macbeth Arc Lamp Company (of
Philadelphia PA, now Cambridge MD, which is where I came in).  The
sole purpose of this device was to allow the backlighting of a color
transparency to be changed to match what the customer wanted on the paper.
Macbeth Daylighting also sold glare free lighting fixtures with a
constant (around 5400 degrees K) North sky daylight for examining the
paper.

    My granfather not only found out that the preferences of the
customers changed with the time of day (in a controlled lighting
environment).  But that the changes were consistant from day to day
and user to user.  In other words the way a person percieves backlit
(or CRT) color compared to reflective (or paper) color changes with
the time of day (actually internal biological clock) all other thing
being held invariant.

    The SMPTE (Society of Motion Picture and Television Engineers) did
a lot of work on this and other problems during the late fifties and
early sixties when trying to make color television something other
than a novelty, and finally came up with some not too impossible rules
for color correction that work.  But to get some reaction other than,
"I think these are the same picture," you are fighting a real uphill
battle.

     Incidently, if you think I'm kidding you, drive down the street
at night.  You can instantly tell which rooms in houses contain a
television because of the color of the light which seems very blue and
although varying in intensity it seems to vary little in hue.  But to
those watching the picture, it seems to show all colors of the
rainbow.  What gives?  Well, the television image is deficient in
yellow relative to an "normal" light source, and the percieved
contrast in hue is principally due to the red/blue ratio.  (See the
work of Ewdin Land on color perception for more information.  He
showed that by using just two colors as little as 10 angstroms apart
he could create an illusion of full color.  However, the fullest
saturation of full color from two images came when one was shown with
red light the other with white.)

      So, if you read Land, and work at it, you can show a beautiful
"Land"scape, with green grass and aquamarine seas on your screen.  But
none of the colors in the image will have an (RGB) G value higher than
zero.  Now try to print that on your printer....

--

					Robert I. Eachus

     When the dictators are ready to make war upon us, they will not
wait for an act of war on our part." - Franklin D. Roosevelt