| 2 |
- |
1 |
/* Copyright (C) 1997 Aladdin Enterprises. All rights reserved.
|
|
|
2 |
|
|
|
3 |
This software is provided AS-IS with no warranty, either express or
|
|
|
4 |
implied.
|
|
|
5 |
|
|
|
6 |
This software is distributed under license and may not be copied,
|
|
|
7 |
modified or distributed except as expressly authorized under the terms
|
|
|
8 |
of the license contained in the file LICENSE in this distribution.
|
|
|
9 |
|
|
|
10 |
For more information about licensing, please refer to
|
|
|
11 |
http://www.ghostscript.com/licensing/. For information on
|
|
|
12 |
commercial licensing, go to http://www.artifex.com/licensing/ or
|
|
|
13 |
contact Artifex Software, Inc., 101 Lucas Valley Road #110,
|
|
|
14 |
San Rafael, CA 94903, U.S.A., +1(415)492-9861.
|
|
|
15 |
*/
|
|
|
16 |
|
|
|
17 |
/* $Id: gxalpha.h,v 1.4 2002/02/21 22:24:52 giles Exp $ */
|
|
|
18 |
/* Internal machinery for alpha channel support */
|
|
|
19 |
|
|
|
20 |
#ifndef gxalpha_INCLUDED
|
|
|
21 |
# define gxalpha_INCLUDED
|
|
|
22 |
|
|
|
23 |
/*
|
|
|
24 |
* As discussed in the classic Porter & Duff paper on compositing,
|
|
|
25 |
* supporting alpha channel properly involves premultiplying color values
|
|
|
26 |
* that are associated with non-unity alpha values. After considerable
|
|
|
27 |
* thrashing around trying to read between the lines of the spotty NeXT
|
|
|
28 |
* documentation, we've concluded that the correct approach is to
|
|
|
29 |
* premultiply towards whatever the color value 0 represents in the device's
|
|
|
30 |
* native color space: black for DeviceGray and DeviceRGB (displays and some
|
|
|
31 |
* file formats), white for DeviceCMYK (color printers), with a special hack
|
|
|
32 |
* for monochrome printers TBD. This makes things very easy internally, at
|
|
|
33 |
* the expense of some inconsistency at the boundaries.
|
|
|
34 |
*
|
|
|
35 |
* For the record, the only places apparently affected by this decision
|
|
|
36 |
* are the following:
|
|
|
37 |
* - alphaimage, if it doesn't assume premultiplication (see below)
|
|
|
38 |
* - readimage
|
|
|
39 |
* - The cmap_rgb_alpha_ procedures in gxcmap.c
|
|
|
40 |
* - [color]image, if they are supposed to use currentalpha (see below)
|
|
|
41 |
* - The compositing code in gsalphac.c
|
|
|
42 |
*
|
|
|
43 |
* The NeXT documentation also is very unclear as to how readimage,
|
|
|
44 |
* alphaimage, and [color]image are supposed to work. Our current
|
|
|
45 |
* interpretation is the following:
|
|
|
46 |
*
|
|
|
47 |
* - readimage reads pixels exactly as the device stores them
|
|
|
48 |
* (converted into DeviceGray or DeviceRGB space if the device
|
|
|
49 |
* uses a palette). Pixels with non-unity alpha come out
|
|
|
50 |
* premultiplied, however the device stores them.
|
|
|
51 |
*
|
|
|
52 |
* - alphaimage assumes the pixels are premultiplied as appropriate
|
|
|
53 |
* for the relevant color space. This makes alphaimage and
|
|
|
54 |
* readimage complementary, i.e., the output of readimage is
|
|
|
55 |
* suitable as the input of alphaimage.
|
|
|
56 |
*
|
|
|
57 |
* - [color]image disregard currentalpha, and treat all input as
|
|
|
58 |
* opaque (alpha = 1). */
|
|
|
59 |
/*
|
|
|
60 |
* Just in case we ever change our minds about the direction of
|
|
|
61 |
* premultiplication, uncommenting the following preprocessor definition is
|
|
|
62 |
* supposed to produce premultiplication towards white.
|
|
|
63 |
*/
|
|
|
64 |
/*#define PREMULTIPLY_TOWARDS_WHITE */
|
|
|
65 |
|
|
|
66 |
#endif /* gxalpha_INCLUDED */
|