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