🚀 go-pugleaf

In article <12702@hardy.rl.ac.uk> rjm@inf.rl.ac.uk writes:

>I am  attempting    to   do   colour    matching  between  a monitor and
>a PostScript Level 1 + Colour extensions printer.

>My colour matching has produced a mapping as follows:-

>Cyan -> Matched Cyan
>Magenta -> Matched Magenta
>Yellow -> Matched Yellow
>Black -> Matched Black

>This  all  sounds    fine,   but  implementing    this  in PostScript is
>a problem. I understand that colour  transfer   functions   can  be  used
>to map  colours  into  device  colours.  This  would work fine for  the 
>Cyan, Magenta  and Yellow,   but the Black  depends on the values for C, 
>M and Y.

>Is it  possible    to   get  hold  of the  values  for C, M and Y inside
>the transfer function for Black ?

In reverse order:

Calculating black is easy. K = n * min (C, M, Y) where n is between 0
and 1

Reduce each of C, M, Y by K.

Matching screen secondaries to device primaries is easy and gives poor
results. You do not give quite enough information for me to see what
exactly your matching program is doing. However, let us assume that
you can generate a cyan (say) that matches on screen and printer. Let
us also say you can generate a yellow that matches.

You seem to be assuming that this is a three point mapping problem. It
isn't. Mixing those two colours on the screen will give a colour that
could be precisely predicted from the CIE chromaticities of the two
colours. Mixing the two colours in the printer gives a very different
colour; it is not additive and not linear.

The only sure way to get a match is to print samples of C,M,Y (and K if
you are keen) varying each one from 0 to 1 so you get a sample of the
colours. Using 10 samples for each gives 1000 data points for CMY or
10000 for CMYK. Then you measure the chromaticity and luminance of
each sample, and put this data into a three (or four) dimensional
inverted lookup table.

Given a monitor colour (RGB), the monitor chromaticities, white point
and gamma, you can convert this to a CIE specification, then
interpolate from your table to predict how much of each ink to use.

This is of course rather a lot of work. Level 2 PostScript does all
this for you. I suggest you consider using it if this is an option for
your printer. If not, hassle the manufacturers :)

I have of course simplified this argument to fit a reasonable space;
nonetheless if anyone feels I am off target here feel free to mail me.
This only represents *my* understanding.

--
Chris Lilley
---------------------------------------------------------------------------
Technical Author, ITTI Computer Graphics and Visualisation Training Project
Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
---------------------------------------------------------------------------