Section 3 of 3 - Prev - Next
All sections - 1 - 2 - 3

The inverse, decoding matrix is this:

 [ R' ] [ 1.        0.        1.402    ] [  Y'  601 ] 
 [ G' ]=[ 1.       -0.344136 -0.714136 ]*[  PB  601 ] 
 [ B' ] [ 1.        1.772     0.       ] [  PR  601 ] 

{{ 1.      , 0.      , 1.402   },
 { 1.      ,-0.344136,-0.714136},
 { 1.      , 1.772   , 0.      }}


C-29  HOW DO I ENCODE Y'CBCR COMPONENTS FROM R'G'B' IN [0, +1]?

Rec. 601 specifies eight-bit coding where Y' has an excursion of 219 and
an offset of +16. This coding places black at code 16 and white at code
235, reserving the extremes of the range for signal processing headroom and
footroom. CB and CR have excursions of +/-112 and offset of +128, for a
range of 16 through 240 inclusive.

To compute Y'CBCR from R'G'B' in the range [0..+1], scale the rows of
the matrix of Eq 2 by the factors 219, 224 and 224, corresponding to the
excursions of each of the components:

Eq 3

{{    65.481,   128.553,    24.966},
 {   -37.797,   -74.203,   112.   },
 {   112.   ,   -93.786,   -18.214}}

Add [16, 128, 128] to the product to get Y'CBCR. 

Summing the first row of the matrix yields 219, the luma excursion from
black to white. The two entries of 112 reflect the positive CBCR extrema of
the blue and red primaries.

Clamp all three components to the range 1 through 254 inclusive, since Rec.
601 reserves codes 0 and 255 for synchronization signals.

To recover R'G'B' in the range [0..+1] from Y'CBCR, subtract [16, 128, 128]
from Y'CBCR, then multiply by the inverse of the matrix in Eq 3 above:

{{ 0.00456621, 0.        , 0.00625893},
 { 0.00456621,-0.00153632,-0.00318811},
 { 0.00456621, 0.00791071, 0.        }}

This looks scary, but the Y'CBCR components are integers in eight
bits and the reconstructed R'G'B' are scaled down to the range
[0..+1].


C-30  HOW DO I ENCODE Y'CBCR COMPONENTS FROM COMPUTER R'G'B' ?

In computing it is conventional to use eight-bit coding with black at code 0
and white at 255. To encode Y'CBCR from R'G'B' in the range [0..255], using
eight-bit binary arithmetic, scale the Y'CBCR matrix of Eq 3 by 256/255:

{{    65.738,   129.057,    25.064},
 {   -37.945,   -74.494,   112.439},
 {   112.439,   -94.154,   -18.285}}

The entries in this matrix have been scaled up by 256, assuming that you will
implement the equation in fixed-point binary arithmetic, using a shift by eight
bits. Add [16, 128, 128] to the product to get Y'CBCR. 

To decode R'G'B' in the range [0..255] from Rec. 601 Y'CBCR, using
eight-bit binary arithmetic , subtract [16, 128, 128] from Y'CBCR, 
then multiply by the inverse of the matrix above, scaled by 256:

Eq 4

{{   298.082,     0.   ,   408.583},
 {   298.082,  -100.291,  -208.12 },
 {   298.082,   516.411,     0.   }}

You can remove a factor of 1/256 from these coefficients, then accomplish the
multiplication by shifting. Some of the coefficients, when scaled by 256, are
larger than unity. These coefficients will need more than eight multiplier
bits.

For implementation in binary arithmetic the matrix coefficients have to be
rounded. When you round, take care to preserve the row sums of [1, 0, 0].

The matrix of Eq 4 will decode standard Y'CBCR components to RGB
components in the range [0..255], subject to roundoff error. You must take
care to avoid overflow due to roundoff error. But you must protect against
overflow in any case, because studio video signals use the extremes of the
coding range to handle signal overshoot and undershoot, and these will
require clipping when decoded to an RGB range that has no headroom or
footroom.


C-31  HOW DO I ENCODE Y'CBCR COMPONENTS FROM STUDIO VIDEO?

Studio R'G'B' signals use the same 219 excursion as the luma component
of Y'CBCR. To encode Y'CBCR from R'G'B' in the range [0..219], using
eight-bit binary arithmetic, scale the Y'CBCR encoding matrix of Eq 3
above by 256/219. Here is the encoding matrix for studio video:

{{    65.481,   128.553,    24.966},
 {   -37.797,   -74.203,   112.   },
 {   112.   ,   -93.786,   -18.214}}

To decode R'G'B' in the range [0..219] from Y'CBCR, using eight-bit
binary arithmetic, use this matrix:

{{   256.   ,     0.   ,   350.901},
 {   256.   ,   -86.132,  -178.738},
 {   256.   ,   443.506,     0.   }}
 
When scaled by 256, the first column in this matrix is unity, indicating
that the corresponding component can simply be added: there is no need for
a multiplication operation. This matrix contains entries larger than 256;
the corresponding multipliers will need capability for nine bits.

The matrices in this section conform to Rec. 601 and apply directly to
conventional 525/59.94 and 625/50 video. It is not yet decided whether
emerging HDTV standards will use the same matrices, or adopt a new set of
matrices having different luma coefficients. In my view it would be
unfortunate if different matrices were adopted, because then image coding
and decoding would depend on whether the picture was small (conventional
video) or large (HDTV).

In digital video, Rec. 601 standardizes subsampling denoted 4:2:2, where CB
and CR components are subsampled horizontally by a factor of two with
respect to luma. JPEG and MPEG conventionally subsample by a factor of two
in the vertical dimension as well, denoted 4:2:0.

Color difference coding is standardized in Rec. 601. For details on color
difference coding as used in video, consult Poynton [16].


C-32  HOW DO I DECODE R'G'B' FROM PHOTOYCC?

Kodak's PhotoYCC uses the Rec. 709 primaries, white point and transfer
function. Reference white codes to luma 189; this preserves film
highlights. The color difference coding is asymmetrical, to encompass film
gamut. You are unlikely to encounter any raw image data in PhotoYCC form
because YCC is closely associated with the PhotoCD(tm) system whose
compression methods are proprietary. But just in case, the following
equation is comparable to  in that it produces R'G'B' in the range
[0..+1] from integer YCC. If you want to return R'G'B' in a different
range, or implement the equation in eight-bit integer arithmetic, use the
techniques in the section above.

[ R'709 ] [ 0.0054980  0.0000000  0.0051681 ]    [ Y'601,189 ]   [   0 ]
[ G'709 ]=[ 0.0054980 -0.0015446 -0.0026325 ]* ( [    C1     ] - [ 156 ] )
[ B'709 ] [ 0.0054980  0.0079533  0.0000000 ]    [    C2     ]   [ 137 ]

{{ 0.0054980,  0.0000000,  0.0051681},
 { 0.0054980, -0.0015446, -0.0026325},
 { 0.0054980,  0.0079533,  0.0000000}}

Decoded R'G'B' components from PhotoYCC can exceed unity or go below
zero. PhotoYCC extends the Rec. 709 transfer function above unity, and
reflects it around zero, to accommodate wide excursions of R'G'B'. To
decode to CRT primaries, clip R'G'B' to the range zero to one.


C-33  WILL YOU TELL ME HOW TO DECODE Y'UV AND Y'IQ?

No, I won't! Y'UV and Y'IQ have scale factors appropriate to composite
NTSC and PAL. They have no place in component digital video! You shouldn't
code into these systems, and if someone hands you an image claiming it's
Y'UV, chances are it's actually Y'CBCR, it's got the wrong scale factors,
or it's linear-light.

Well OK, just this once. To transform Y', (B'-Y') and (R'-Y')
components from Eq 1 to Y'UV, scale (B'-Y') by 0.492111 to get U and
scale R'-Y' by 0.877283 to get V. The factors are chosen to limit
composite NTSC or PAL amplitude for all legal R'G'B' values:

  << Equation omitted -- see PostScript or PDF version. >>

To transform to Y'IQ to Y'UV, perform a 33 degree rotation and an exchange
of color difference axes:

  << Equation omitted -- see PostScript or PDF version. >>


C-34  HOW SHOULD I TEST MY ENCODERS AND DECODERS?

To test your encoding and decoding, ensure that colorbars are handled
correctly. A colorbar signal comprises a binary RGB sequence ordered for
decreasing luma: white, yellow, cyan, green, magenta, red, blue and black.

  [ 1 1 0 0 1 1 0 0 ]
  [ 1 1 1 1 0 0 0 0 ]
  [ 1 0 1 0 1 0 1 0 ]

To ensure that your scale factors are correct and that clipping is not
being invoked, test 75% bars, a colorbar sequence having 75%-amplitude
bars instead of 100%.


C-35  WHAT IS PERCEPTUAL UNIFORMITY?

A system is perceptually uniform if a small perturbation to a component
value is approximately equally perceptible across the range of that value.
The volume control on your radio is designed to be perceptually uniform:
rotating the knob ten degrees produces approximately the same perceptual
increment in volume anywhere across the range of the control. If the
control were physically linear, the logarithmic nature of human loudness
perception would place all of the perceptual "action" of the control at the
bottom of its range.

The XYZ and RGB systems are far from exhibiting perceptual uniformity.
Finding a transformation of XYZ into a reasonably perceptually-uniform
space consumed a decade or more at the CIE and in the end no single system
could be agreed. So the CIE standardized two systems, L*u*v* and L*a*b*,
sometimes written CIELUV and CIELAB. (The u and v are unrelated to video U
and V.) Both L*u*v* and L*a*b* improve the 80:1 or so perceptual
nonuniformity of XYZ to about 6:1. Both demand too much computation to
accommodate real-time display, although both have been successfully applied
to image coding for printing.

Computation of CIE L*u*v* involves intermediate u' and v ' quantities,
where the prime denotes the successor to the obsolete 1960 CIE u and v
system:

  uprime = 4 * X / (X + 15 * Y + 3 * Z); 
  vprime = 9 * Y / (X + 15 * Y + 3 * Z); 

First compute un' and vn' for your reference white Xn , Yn  and Zn. Then
compute u' and v ' - and L* as discussed earlier - for your colors.
Finally, compute:

  ustar = 13 * Lstar * (uprime - unprime);
  vstar = 13 * Lstar * (vprime - vnprime);

L*a*b* is computed as follows, for (X/Xn, Y/Yn, Z/Zn) > 0.01:

  astar = 500 * (pow(X / Xn, 1./3.) - pow(Y / Yn, 1./3.));
  bstar = 200 * (pow(Y / Yn, 1./3.) - pow(Z / Zn, 1./3.));

These equations are great for a few spot colors, but no fun for a million
pixels. Although it was not specifically optimized for this purpose, the
nonlinear R'G'B' coding used in video is quite perceptually uniform,
and has the advantage of being fast enough for interactive applications.


C-36  WHAT ARE HSB AND HLS?

HSB and HLS were developed to specify numerical Hue, Saturation and
Brightness (or Hue, Lightness and Saturation) in an age when users had to
specify colors numerically. The usual formulations of HSB and HLS are
flawed with respect to the properties of color vision. Now that users can
choose colors visually, or choose colors related to other media (such as
PANTONE), or use perceptually-based systems like L*u*v* and L*a*b*, HSB and
HLS should be abandoned.

Here are some of problems of HSB and HLS. In color selection where
"lightness" runs from zero to 100, a lightness of 50 should appear to be
half as bright as a lightness of 100. But the usual formulations of HSB and
HLS make no reference to the linearity or nonlinearity of the underlying
RGB, and make no reference to the lightness perception of human vision.

The usual formulation of HSB and HLS compute so-called "lightness" or
"brightness" as (R+G+B)/3. This computation conflicts badly with the
properties of color vision, as it computes yellow to be about six times
more intense than blue with the same "lightness" value (say L=50).

HSB and HSL are not useful for image computation because of the
discontinuity of hue at 360 degrees. You cannot perform arithmetic mixtures
of colors expressed in polar coordinates.

Nearly all formulations of HSB and HLS involve different computations
around 60 degree segments of the hue circle. These calculations introduce
visible discontinuities in color space.

Although the claim is made that HSB and HLS are "device independent", the
ubiquitous formulations are based on RGB components whose chromaticities
and white point are unspecified. Consequently, HSB and HLS are useless for
conveyance of accurate color information.

If you really need to specify hue and saturation by numerical values,
rather than HSB and HSL you should use polar coordinate version of u* and
v*: h*uv for hue angle and c*uv  for chroma.


C-37  WHAT IS TRUE COLOR?

True color is the provision of three separate components for additive red,
green and blue reproduction. True color systems often provide eight bits
for each of the three components, so true color is sometimes referred to
as 24-bit color.

A true color system usually interposes a lookup table between each
component of the framestore and each channel to the display. This makes it
possible to use a true color system with either linear or nonlinear
coding. In the X Window System, direct color refers to fixed lookup tables,
and truecolor refers to lookup tables that are under the control of
application software.


C-38  WHAT IS INDEXED COLOR?

Indexed color (or pseudocolor), is the provision of a relatively small
number, say 256, of discrete colors in a colormap or palette. The
framebuffer stores, at each pixel, the index number of a color. At the
output of the framebuffer, a lookup table uses the index to retrieve red,
green and blue components that are then sent to the display.

The colors in the map may be fixed systematically at the design of a
system. As an example, 216 index entries an eight-bit indexed color system
can be partitioned systematically into a 6x6x6 "cube" to implement what
amounts to a direct color system where each of red, green and blue has a
value that is an integer in the range zero to five.

An RGB image can be converted to a predetermined colormap by choosing, for
each pixel in the image, the colormap index corresponding to the "closest"
RGB triple. With a systematic colormap such as a 6x6x6 colorcube this
is straightforward. For an arbitrary colormap, the colormap has to be
searched looking for entries that are "close" to the requested color.
"Closeness" should be determined according to the perceptibility of color
differences. Using color systems such as CIE L*u*v* or L*a*b* is
computationally prohibitive, but in practice it is adequate to use a
Euclidean distance metric in R'G'B' components coded nonlinearly
according to video practice.

A direct color image can be converted to indexed color with an
image-dependent colormap by a process of color quantization that searches
through all of the triples used in the image, and chooses the palette for
the image based on the colors that are in some sense most "important".
Again, the decisions should be made according to the perceptibility of
color differences. Adobe Photoshop(tm) can perform this conversion.
UNIX(tm) users can employ the pbm package.

If your system accommodates arbitrary colormaps, when the map associated
with the image in a particular window is loaded into the hardware colormap,
the maps associated with other windows may be disturbed. In window system
such as the X Window System(tm) running on a multitasking operating system
such as UNIX, even moving the cursor between two windows with different
maps can cause annoying colormap flashing.

An eight-bit indexed color system requires less data to represent a
picture than a twenty-four bit truecolor system. But this data reduction
comes at a high price. The truecolor system can represent each of its
three components according to the principles of sampled continuous signals.
This makes it possible to accomplish, with good quality, operations such as
resizing the image. In indexed color these operations introduce severe
artifacts because the underlying representation lacks the properties of a
continuous representation, even if converted back to RGB.

In graphic file formats such as GIF of TIFF, an indexed color image is
accompanied by its colormap. Generally such a colormap has RGB entries that
are gamma corrected: the colormap's RGB codes are intended to be presented
directly to a CRT, without further gamma correction.


C-39  I WANT TO VISUALIZE A SCALAR FUNCTION OF TWO VARIABLES. SHOULD I USE RGB
      VALUES CORRESPONDING TO THE COLORS OF THE RAINBOW?

When you look at a rainbow you do not see a smooth gradation of colors.
Instead, some bands appear quite narrow, and others are quite broad.
Perceptibility of hue variation near 540 nm is half that of either 500 nm
or 600 nm. If you use the rainbow's colors to represent data, the
visibility of differences among your data values will depend on where they
lie in the spectrum.

If you are using color to aid in the visual detection of patterns, you
should use colors chosen according to the principles of perceptual
uniformity. This an open research problem, but basing your system on CIE
L*a*b* or L*u*v*, or on nonlinear video-like RGB, would be a good start.


C-40  WHAT IS DITHERING?

A display device may have only a small number of choices of greyscale
values or color values at each device pixel. However if the viewer is
sufficiently distant from the display, the value of neighboring pixels can
be set so that the viewer's eye integrates several pixels to achieve an
apparent improvement in the number of levels or colors that can be
reproduced.

Computer displays are generally viewed from distances where the device
pixels subtend a rather large angle at the viewer's eye, relative to his
visual acuity. Applying dither to a conventional computer display often
introduces objectionable artifacts. However, careful application of dither
can be effective. For example, human vision has poor acuity for blue
spatial detail but good color discrimination capability in blue. Blue can
be dithered across two-by-two pixel arrays to produce four times the number
of blue levels, with no perceptible penalty at normal viewing distances.


C-41  HOW DOES HALFTONING RELATE TO COLOR?

The processes of offset printing and conventional laser printing are
intrinsically bilevel: a particular location on the page is either covered
with ink or not. However, each of these devices can reproduce
closely-spaced dots of variable size. An array of small dots produces the
perception of light gray, and an array of large dots produces dark gray.
This process is called halftoning or screening. In a sense this is
dithering, but with device dots so small that acceptable pictures can be
produced at reasonable viewing distances.

Halftone dots are usually placed in a regular grid, although stochastic
screening has recently been introduced that modulates the spacing of the
dots rather than their size.

In color printing it is conventional to use cyan, magenta, yellow and
black grids that have exactly the same dot pitch but different
carefully-chosen screen angles. The recently introduced technique of
Flamenco screening uses the same screen angles for all screens, but its
registration requirements are more stringent than conventional offset
printing.

Agfa's booklet [17] is an excellent introduction to practical concerns of
printing. And it's in color! The standard reference to halftoning
algorithms is Ulichney [18], but that work does not detail the
nonlinearities found in practical printing systems. For details about
screening for color reproduction, consult Fink [19]. Consult Frequently
Asked Questions about Gamma for an introduction to the transfer function of
offset printing.


C-42  WHAT'S A COLOR MANAGEMENT SYSTEM?

Software and hardware for scanner, monitor and printer calibration have had
limited success in dealing with the inaccuracies of color handling in
desktop computing. These solutions deal with specific pairs of devices but
cannot address the end-to-end system. Certain application developers have
added color transformation capability to their applications, but the
majority of application developers have insufficient expertise and
insufficient resources to invest in accurate color.

A color management system (CMS) is a layer of software resident on a
computer that negotiates color reproduction between the application and
color devices. It cooperates with the operating system and the graphics
library components of the platform software. Color management systems
perform the color transformations necessary to exchange accurate color
between diverse devices, in various color coding systems including RGB,
CMYK and CIE L*a*b*.

The CMS makes available to the application a set of facilities whereby the
application can determine what color devices and what color spaces are
available. When the application wishes to access a particular device, it
requests that the color manager perform a mathematical transform from one
space to another. The color spaces involved can be device-independent
abstract color spaces such as CIE XYZ, CIE L*a*b* or calibrated RGB.
Alternatively a color space can be associated with a particular device. In
the second case the Color manager needs access to characterization data
for the device, and perhaps also to calibration data that reflects the
state of the particular instance of the device.

Sophisticated color management systems are commercially available from
Kodak, Electronics for Imaging (EFI) and Agfa. Apple's ColorSync(tm)
provides an interface between a Mac application program and color
management capabilities either built-in to ColorSync or provided by a
plug-in. Sun has announced that Kodak's CMS will be shipped with the next
version of Solaris.

The basic CMS services provided with desktop operating systems are likely
to be adequate for office users, but are unlikely to satisfy high-end users
such as in prepress. All of the announced systems have provisions for
plug-in color management modules (CMMs) that can provide sophisticated
transform machinery. Advanced color management modules will be
commercially available from third parties. 


C-43  HOW DOES A CMS KNOW ABOUT PARTICULAR DEVICES?

A CMS needs access to information that characterizes the color
reproduction capabilities of particular devices. The set of
characterization data for a device is called a device profile. Industry
agreement has been reached on the format of device profiles, although
details have not yet been publicly disseminated. Apple has announced that
the forthcoming ColorSync version 2.0 will adhere to this agreement.
Vendors of color peripherals will soon provide industry-standard profiles
with their devices, and they will have to make, buy or rent
characterization services.

If you have a device that has not been characterized by its manufacturer,
Agfa's FotoTune(tm) software - part of Agfa's FotoFlow(tm) color manager -
can create device profiles.


C-44  IS A COLOR MANAGEMENT SYSTEM USEFUL FOR COLOR SPECIFICATION?

Not yet. But color management system interfaces in the future are likely
to include the ability to accommodate commercial proprietary color
specification systems such as pantone(tm) and colorcurve(tm). These vendors
are likely to provide their color specification systems in shrink-wrapped
form to plug into color managers. In this way, users will have guaranteed
color accuracy among applications and peripherals, and application vendors
will no longer need to pay to license these systems individually.


C-45  I'M NOT A COLOR EXPERT. WHAT PARAMETERS SHOULD I USE TO CODE MY
      IMAGES?

Use the CIE D65 white point (6504 K) if you can.

Use the Rec. 709 primary chromaticities. Your monitor is probably already
quite close to this. Rec. 709 has international agreement, offers excellent
performance, and is the basis for HDTV development so it's future-proof.

If you need to operate in linear light, so be it. Otherwise, for best
perceptual performance and maximum ease of interchange with digital video,
use the Rec. 709 transfer function, with its 0.45-power law. If you need
Mac compatibility you will have to suffer a penalty in perceptual
performance. Raise tristimulus values to the 1/1.8-power before presenting
them to QuickDraw.

To code luma, use the Rec. 601 luma coefficients 0.299, 0.587 and 0.114.
Use Rec. 601 digital video coding with black at 16 and white at 235.

Use prime symbols (') to denote all of your nonlinear components!

PhotoCD uses all of the preceding measures. PhotoCD codes color
differences asymmetrically, according to film gamut. Unless you have a
requirement for film gamut, you should code into color differences using
Y'CBCR coding with Rec. 601 studio video (16..235/128+/-112) excursion.

Tag your image data with the primary and white chromaticity, transfer
function and luma coefficients that you are using. TIFF 6.0 tags have been
defined for these parameters. This will enable intelligent readers, today
or in the future, to determine the parameters of your coded image and give
you the best possible results.


C-46  REFERENCES

[1] Publication CIE No 17.4, International Lighting Vocabulary. Central
Bureau of the Commission Internationale de L'Eclairage, Vienna, Austria.

[2] LeRoy E. DeMarsh and Edward J. Giorgianni, "Color Science for Imaging
Systems", Physics Today, September 1989, 44-52.

[3] W.F. Schreiber, Fundamentals of Electronic Imaging Systems, Second
Edition (Springer-Verlag, 1991).

[4] Publication CIE No 15.2, Colorimetry, Second Edition (1986), Central
Bureau of the Commission Internationale de L'Eclairage, Vienna, Austria.

[5] Guenter Wyszecki and W.S. Styles, Color Science: Concepts and Methods,
Quantitative Data and Formulae, Second Edition (New York: John 
Wiley & Sons, 1982).

[6] Guenter Wyszecki and D.B. Judd, Color in Business, Science and
Industry, Third Edition (New York: John Wiley & Sons, 1975).

[7] R.W.G. Hunt, The Reproduction of Colour in Photography, Printing and
Television, Fourth Edition (Fountain Press, Tolworth, England, 1987).

[8] ITU-R Recommendation BT.709, Basic Parameter Values for the HDTV
Standard for the Studio and for International Programme Exchange (1990),
[formerly CCIR Rec. 709], ITU, 1211 Geneva 20, Switzerland.

[9] Bruce J. Lindbloom, "Accurate Color Reproduction for Computer Graphics
Applications", Computer Graphics, Vol. 23, No. 3 (July 1989), 117-126
(proceedings of SIGGRAPH '89).

[10] William B. Cowan, "An Inexpensive Scheme for Calibration of a Colour
Monitor in terms of CIE Standard Coordinates", Computer Graphics, Vol. 17,
No. 3 (July 1983), 315-321.

[11] SMPTE RP 177-1993, Derivation of Basic Television Color Equations.

[12] Television Engineering Handbook, Featuring HDTV Systems, Revised
Edition by K. Blair Benson, revised by Jerry C. Whitaker (McGraw-Hill,
1992). This supersedes the Second Edition.

[13] Roy Hall, Illumination and Color in Computer Generated Imagery
(Springer-Verlag, 1989).

[14] Chet S. Haase and Gary W. Meyer, "Modelling Pigmented Materials for
Realistic Image Synthesis", ACM Transactions on Graphics, Vol. 11, No. 4,
1992, p. 305.

[15] Maureen C. Stone, William B. Cowan and John C. Beatty, "Color Gamut
Mapping and the Printing of Digital Color Images", ACM Transactions on
Graphics, Vol. 7, No. 3, October 1988.

[16] Charles A. Poynton, A Technical Introduction To Digital Video. 
New York: John Wiley & Sons, 1996. 

[17] Agfa Corporation, An introduction to Digital Color Prepress, Volumes 1
and 2 (1990), Prepress Education Resources, P.O. Box 7917 Mt. Prospect, IL
60056-7917. 800-395-7007.

[18] Robert Ulichney, Digital Halftoning (Cambridge, Mass.: MIT Press,
1988).

[19] Peter Fink, PostScript Screening: Adobe Accurate Screens (Mountain
View, Calif.: Adobe Press, 1992).


C-47  CONTRIBUTORS

Thanks to Norbert Gerfelder, Alan Roberts and Fred Remley for their
proofreading and editing. I learned about color from LeRoy DeMarsh, Ed
Giorgianni, Junji Kumada and Bill Cowan. Thanks!

I welcome corrections, and suggestions for additions and improvements.


Charles A. Poynton
Poynton@Poynton.com

Section 3 of 3 - Prev - Next
All sections - 1 - 2 - 3

© allanswers.org | Terms of use