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 */ 67