0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 2362N/A * published by the Free Software Foundation. Oracle designates this 0N/A * particular file as subject to the "Classpath" exception as provided 2362N/A * by Oracle in the LICENSE file that accompanied this code. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A * This file is available under and governed by the GNU General Public 0N/A * License version 2 only, as published by the Free Software Foundation. 0N/A * However, the following notice accompanied the original version of this 0N/A * file and, per its terms, should not be removed: 4418N/A * Last changed in libpng 1.5.4 [July 7, 2011] 4418N/A * Copyright (c) 1998-2011 Glenn Randers-Pehrson 0N/A * (Version 0.96 Copyright (c) 1996, 1997 Andreas Dilger) 0N/A * (Version 0.88 Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.) 4418N/A * This code is released under the libpng license. 4418N/A * For conditions of distribution and use, see the disclaimer 0N/A * This file contains functions optionally called by an application 0N/A * in order to tell libpng how to handle data when reading a PNG. 0N/A * Transformations that are used in both reading and writing are 0N/A/* Set the action on getting a CRC error for an ancillary or critical chunk. */ 0N/A /* Tell libpng how we react to CRC errors in critical chunks */ 4418N/A "Can't discard critical data on CRC error");
4418N/A /* Tell libpng how we react to CRC errors in ancillary chunks */ 4418N/A/* Handle alpha and tRNS via a background color */ 4418N/A#
endif /* FLOATING_POINT */ 4418N/A#
endif /* READ_BACKGROUND */ 4418N/A/* Scale 16-bit depth files to 8-bit depth. If both of these are set then the 4418N/A * one that pngrtran does first (scale) happens. This is necessary to allow the 4418N/A * TRANSFORM and API behavior to be somewhat consistent, and it's simpler. 4418N/A/* Chop 16-bit depth files to 8-bit depth */ 4418N/A /* Check for flag values. The main reason for having the old Mac value as a 4418N/A * flag is that it is pretty near impossible to work out what the correct 4418N/A * value is from Apple documentation - a working Mac system is needed to 4418N/A /* If there is no sRGB support this just sets the gamma to the standard 4418N/A * sRGB value. (This is a side effect of using this function!) 4418N/A /* The following silently ignores cases where fixed point (times 100,000) 4418N/A * gamma values are passed to the floating point API. This is safe and it 4418N/A * means the fixed point constants work just fine with the floating point 4418N/A * API. The alternative would just lead to undetected errors and spurious 4418N/A * bug reports. Negative values fail inside the _fixed API unless they 4418N/A * correspond to the flag values. 4418N/A /* This preserves -1 and -2 exactly: */ 4418N/A#
endif /* READ_ALPHA_MODE || READ_GAMMA */ 4418N/A /* Validate the value to ensure it is in a reasonable range. The value 4418N/A * is expected to be 1 or greater, but this range test allows for some 4418N/A * viewing correction values. The intent is to weed out users of this API 4418N/A * who use the inverse of the gamma value accidentally! Since some of these 4418N/A * values are reasonable this may have to be changed. 4418N/A /* The default file gamma is the inverse of the output gamma; the output 4418N/A * gamma may be changed below so get the file value first: 4418N/A /* There are really 8 possibilities here, composed of any combination 4418N/A * premultiply the color channels 4418N/A * do not encode non-opaque pixels 4418N/A * encode the alpha as well as the color channels 4418N/A * because then the encoding is a no-op and there is only the choice of 4418N/A * premultiplying the color channels or not. 4418N/A * png_set_alpha_mode and png_set_background interact because both use 4418N/A * png_compose to do the work. Calling both is only useful when 4418N/A * png_set_alpha_mode is used to set the default mode - PNG_ALPHA_PNG - along 4418N/A * with a default gamma value. Otherwise PNG_COMPOSE must not be set. 4418N/A /* No compose, but it may be set by png_set_background! */ 4418N/A /* The output is linear: */ 4418N/A /* output_gamma records the encoding of opaque pixels! */ 4418N/A /* Only set the default gamma if the file gamma has not been set (this has 4418N/A * the side effect that the gamma in a second call to png_set_alpha_mode will 4418N/A /* But always set the output gamma: */ 4418N/A /* Finally, if pre-multiplying, set the background fields to achieve the 4418N/A /* And obtain alpha pre-multiplication by composing on black: */ 4418N/A "conflicting calls to set alpha mode and background");
4418N/A /* New API, make sure apps call the correct initializers: */ 4418N/A/* Dither file to 8-bit. Supply a palette, the current number 0N/A * of elements in the palette, the maximum number of elements 0N/A * allowed, and a histogram if possible. If the current number 0N/A * of colors is greater then the maximum number, the palette will be 4418N/A * modified to fit in the maximum number. "full_quantize" indicates 4418N/A * whether we need a quantizing cube set up for RGB images, or if we 0N/A * simply are reducing the number of colors in a paletted image. 0N/A /* This is easy enough, just throw out the least used colors. 4418N/A * Perhaps not the best solution, but good enough. 4418N/A /* Initialize an array to sort colors */ 4418N/A /* Initialize the quantize_sort array */ 0N/A /* Find the least used palette entries by starting a 4418N/A * bubble sort, and running it until we have sorted 4418N/A * out enough colors. Note that we don't care about 4418N/A * sorting all the colors, just finding which are 4418N/A int done;
/* To stop early if the list is pre-sorted */ 0N/A for (j = 0; j < i; j++)
4418N/A /* Swap the palette around, and set up a table, if necessary */ 4418N/A /* Put all the useful colors within the max, but don't 4418N/A /* Move all the used colors inside the max limit, and 4418N/A * develop a translation table. 4418N/A /* Only move the colors we need to */ 4418N/A /* Indicate where the color went */ 4418N/A /* Find closest color for those colors we are not using */ 4418N/A /* Find the closest color to one we threw out */ 4418N/A /* Point to closest color */ 0N/A /* This is much harder to do simply (and quickly). Perhaps 4418N/A * we need to go through a median cut routine, but those 4418N/A * don't always behave themselves with only a few colors 4418N/A * as input. So we will just find the closest two colors, 4418N/A * and throw out one of them (chosen somewhat randomly). 4418N/A * [We don't understand this at all, so if someone wants to 4418N/A * work on improving it, be our guest - AED, GRP] 4418N/A /* Initialize palette index arrays */ 4418N/A /* Initialize the sort array */ 4418N/A /* Initial wild guess at how far apart the farthest pixel 4418N/A * pair we will be eliminating will be. Larger 4418N/A * numbers mean more areas will be allocated, Smaller 4418N/A * numbers run the risk of not saving enough data, and 4418N/A * having to do this all over again. 4418N/A * I have not done extensive checking on this number. 0N/A for (i = 0; i <
769; i++)
0N/A /* int dr = abs(ir - r); */ 0N/A /* int dg = abs(ig - g); */ 0N/A /* int db = abs(ib - b); */ 4418N/A#
endif /* PNG_READ_QUANTIZE_SUPPORTED */ 4418N/A /* New in libpng-1.5.4 - reserve particular negative values as flags. */ 4418N/A /* Checking the gamma values for being >0 was added in 1.5.4 along with the 4418N/A * premultiplied alpha support; this actually hides an undocumented feature 4418N/A * of the previous implementation which allowed gamma processing to be 4418N/A * disabled in background handling. There is no evidence (so far) that this 4418N/A * was being used; however, png_set_background itself accepted and must still 4418N/A * accept '0' for the gamma value it takes, because it isn't always used. 4418N/A * Since this is an API change (albeit a very minor one that removes an 4418N/A * undocumented API feature) it will not be made until libpng-1.6.0. 4418N/A /* Set the gamma values unconditionally - this overrides the value in the PNG 4418N/A * file if a gAMA chunk was present. png_set_alpha_mode provides a 4418N/A * different, easier, way to default the file gamma. 4418N/A#
endif /* FLOATING_POINT_SUPPORTED */ 0N/A/* Expand paletted images to RGB, expand grayscale images of 0N/A * less than 8-bit depth to 8-bit depth, and expand tRNS chunks 0N/A * to alpha channels. 0N/A/* GRR 19990627: the following three functions currently are identical 0N/A * to png_set_expand(). However, it is entirely reasonable that someone 0N/A * might wish to expand an indexed image to RGB but *not* expand a single, 0N/A * fully transparent palette entry to a full alpha channel--perhaps instead 0N/A * the transparent color with a particular RGB value, or drop tRNS entirely. 0N/A * IOW, a future version of the library may make the transformations flag 0N/A * a bit more fine-grained, with separate bits for each of these three 0N/A * More to the point, these functions make it obvious what libpng will be 0N/A * doing, whereas "expand" can (and does) mean any number of things. 4418N/A * GRP 20060307: In libpng-1.2.9, png_set_gray_1_2_4_to_8() was modified 4418N/A * to expand only the sample depth but not to expand the tRNS to alpha 4418N/A * and its name was changed to png_set_expand_gray_1_2_4_to_8(). 0N/A/* Expand paletted images to RGB. */ 0N/A/* Expand grayscale images of less than 8-bit depth to 8 bits. */ 0N/A/* Expand tRNS chunks to alpha channels. */ 0N/A#
endif /* defined(PNG_READ_EXPAND_SUPPORTED) */ 4418N/A/* Expand to 16-bit channels, expand the tRNS chunk too (because otherwise 4418N/A * it may not work correctly.) 4418N/A /* New API, make sure apps call the correct initializers: */ 4418N/A /* Because rgb must be 8 bits or more: */ 4418N/A "Cannot do RGB_TO_GRAY without EXPAND_SUPPORTED");
4418N/A "ignoring out of range rgb_to_gray coefficients");
4418N/A /* Use the defaults, from the cHRM chunk if set, else the built in Rec 4418N/A * 709 values (which correspond to sRGB, so we don't have to worry 0N/A/* Convert a RGB image to a grayscale of the same width. This allows us, 0N/A * for example, to convert a 24 bpp RGB image into an 8 bpp grayscale image. 4418N/A/* In the case of gamma transformations only do transformations on images where 4418N/A * the [file] gamma and screen_gamma are not close reciprocals, otherwise it 4418N/A * slows things down slightly, and also needlessly introduces small errors. 4418N/A /* PNG_GAMMA_THRESHOLD is the threshold for performing gamma 4418N/A * correction as a difference of the overall transform from 1.0 4418N/A * We want to compare the threshold with s*f - 1, if we get 4418N/A * overflow here it is because of wacky gamma values so we 4418N/A * turn on processing anyway. 0N/A/* Initialize everything needed for the read. This includes modifying 4418N/A/*For the moment 'png_init_palette_transformations' and 4418N/A * 'png_init_rgb_transformations' only do some flag canceling optimizations. 4418N/A * The intent is that these two routines should have palette or rgb operations 4418N/A * extracted from 'png_init_read_transformations'. 4418N/A /* Called to handle the (input) palette case. In png_do_read_transformations 4418N/A * the first step is to expand the palette if requested, so this code must 4418N/A * take care to only make changes that are invariant with respect to the 4418N/A * palette expansion, or only do them if there is no expansion. 4418N/A * STRIP_ALPHA has already been handled in the caller (by setting num_trans 4418N/A /* Ignore if all the entries are opaque (unlikely!) */ 4418N/A /* If no alpha we can optimize. */ 4418N/A /* Any alpha means background and associative alpha processing is 4418N/A * required, however if the alpha is 0 or 1 throughout OPTIIMIZE_ALPHA 4418N/A * and ENCODE_ALPHA are irrelevant. 4418N/A /* png_set_background handling - deals with the complexity of whether the 4418N/A * background color is in the file format or the screen format in the case 4418N/A * where an 'expand' will happen. 4418N/A /* The following code cannot be entered in the alpha pre-multiplication case 4418N/A * because PNG_BACKGROUND_EXPAND is cancelled below. 4418N/A /* Invert the alpha channel (in tRNS) unless the pixels are 4418N/A * going to be expanded, in which case leave it for later 4418N/A#
endif /* PNG_READ_INVERT_ALPHA_SUPPORTED */ 4418N/A }
/* background expand and (therefore) no alpha association. */ 4418N/A#
endif /* PNG_READ_EXPAND_SUPPORTED && PNG_READ_BACKGROUND_SUPPORTED */ 4418N/A /* Added to libpng-1.5.4: check the color type to determine whether there 4418N/A * is any alpha or transparency in the image and simply cancel the 4418N/A * background and alpha mode stuff if there isn't. 4418N/A /* If no alpha we can optimize. */ 4418N/A /* Any alpha means background and associative alpha processing is 4418N/A * required, however if the alpha is 0 or 1 throughout OPTIIMIZE_ALPHA 4418N/A * and ENCODE_ALPHA are irrelevant. 4418N/A /* png_set_background handling - deals with the complexity of whether the 4418N/A * background color is in the file format or the screen format in the case 4418N/A * where an 'expand' will happen. 4418N/A /* The following code cannot be entered in the alpha pre-multiplication case 4418N/A * because PNG_BACKGROUND_EXPAND is cancelled below. 4418N/A /* i.e., GRAY or GRAY_ALPHA */ 4418N/A /* Expand background and tRNS chunks */ 4418N/A }
/* background expand and (therefore) no alpha association. */ 4418N/A#
endif /* PNG_READ_EXPAND_SUPPORTED && PNG_READ_BACKGROUND_SUPPORTED */ 4418N/A * and it is called before the 'rowbytes' calculation is done, so the code 4418N/A * in here can change or update the transformations flags. 4418N/A * First do updates that do not depend on the details of the PNG image data 4418N/A /* Prior to 1.5.4 these tests were performed from png_set_gamma, 1.5.4 adds 4418N/A * png_set_alpha_mode and this is another source for a default file gamma so 4418N/A * the test needs to be performed later - here. In addition prior to 1.5.4 4418N/A * the tests were repeated for the PALETTE color type here - this is no 4418N/A * longer necessary (and doesn't seem to have been necessary before.) 4418N/A /* The following temporary indicates if overall gamma correction is 4418N/A /* Assume the output matches the input; a long time default behavior 4418N/A * of libpng, although the standard has nothing to say about this. 4418N/A /* The converse - assume the file matches the screen, note that this 4418N/A * perhaps undesireable default can (from 1.5.4) be changed by calling 4418N/A * png_set_alpha_mode (even if the alpha handling mode isn't required 4418N/A * or isn't changed from the default.) 4418N/A /* Just in case the following prevents any processing - file and screen 4418N/A * are both assumed to be linear and there is no way to introduce a 4418N/A * third gamma value other than png_set_background with 'UNIQUE', and, 4418N/A /* Now turn the gamma transformation on or off as appropriate. Notice 4418N/A * that PNG_GAMMA just refers to the file->screen correction. Alpha 4418N/A * composition may independently cause gamma correction because it needs 4418N/A * linear data (e.g. if the file has a gAMA chunk but the screen gamma 4418N/A * hasn't been specified.) In any case this flag may get turned off in 4418N/A * the code immediately below if the transform can be handled outside the 4418N/A /* Certain transformations have the effect of preventing other 4418N/A * transformations that happen afterward in png_do_read_transformations, 4418N/A * resolve the interdependencies here. From the code of 4418N/A * png_do_read_transformations the order is: 4418N/A * 1) PNG_EXPAND (including PNG_EXPAND_tRNS) 4418N/A * 2) PNG_STRIP_ALPHA (if no compose) 4418N/A * 4) PNG_GRAY_TO_RGB iff !PNG_BACKGROUND_IS_GRAY 4418N/A * 7) PNG_STRIP_ALPHA (if compose) 4418N/A * 11) PNG_QUANTIZE (converts to palette) 4418N/A * 13) PNG_GRAY_TO_RGB iff PNG_BACKGROUND_IS_GRAY 4418N/A * 19) PNG_FILLER (includes PNG_ADD_ALPHA) 4418N/A * 23) PNG_USER_TRANSFORM [must be last] 4418N/A /* Stripping the alpha channel happens immediately after the 'expand' 4418N/A * transformations, before all other transformation, so it cancels out 4418N/A * the alpha handling. It has the side effect negating the effect of 4418N/A /* Kill the tRNS chunk itself too. Prior to 1.5.4 this did not happen 4418N/A * so transparency information would remain just so long as it wasn't 4418N/A * expanded. This produces unexpected API changes if the set of things 4418N/A * that do PNG_EXPAND_tRNS changes (perfectly possible given the 4418N/A * documentation - which says ask for what you want, accept what you 4418N/A * get.) This makes the behavior consistent from 1.5.4: 4418N/A#
endif /* STRIP_ALPHA supported, no COMPOSE */ 4418N/A /* If the screen gamma is about 1.0 then the OPTIMIZE_ALPHA and ENCODE_ALPHA 4418N/A * settings will have no effect. 4418N/A /* Detect gray background and attempt to enable optimization for 4418N/A * Note: if PNG_BACKGROUND_EXPAND is set and color_type is either RGB or 4418N/A * RGB_ALPHA (in which case need_expand is superfluous anyway), the 4418N/A * background color might actually be gray yet not be flagged as such. 4418N/A * This is not a problem for the current code, which uses 4418N/A * PNG_BACKGROUND_IS_GRAY only to decide when to do the 4418N/A * png_do_gray_to_rgb() transformation. 4418N/A * TODO: this code needs to be revised to avoid the complexity and 4418N/A * interdependencies. The color type of the background should be recorded in 4418N/A * png_set_background, along with the bit depth, then the code has a record 4418N/A * of exactly what color space the background is currently in. 4418N/A /* PNG_BACKGROUND_EXPAND: the background is in the file color space, so if 4418N/A * the file was greyscale the background value is gray. 4418N/A /* PNG_COMPOSE: png_set_background was called with need_expand false, 4418N/A * so the color is in the color space of the output or png_set_alpha_mode 4418N/A * was called and the color is black. Ignore RGB_TO_GRAY because that 4418N/A * happens before GRAY_TO_RGB. 4418N/A#
endif /* PNG_READ_GRAY_TO_RGB_SUPPORTED (etc) */ 4418N/A /* For indexed PNG data (PNG_COLOR_TYPE_PALETTE) many of the transformations 4418N/A * can be performed directly on the palette, and some (such as rgb to gray) 4418N/A * can be optimized inside the palette. This is particularly true of the 4418N/A * composite (background and alpha) stuff, which can be pretty much all done 4418N/A * in the palette even if the result is expanded to RGB or gray afterward. 4418N/A * NOTE: this is Not Yet Implemented, the code behaves as in 1.5.1 and 4418N/A * earlier and the palette stuff is actually handled on the first row. This 4418N/A * leads to the reported bug that the palette returned by png_get_PLTE is not 4418N/A /* TODO: fix this. Because the expand_16 operation is after the compose 4418N/A * handling the background color must be 8, not 16, bits deep, but the 4418N/A * application will supply a 16-bit value so reduce it here. 4418N/A * The PNG_BACKGROUND_EXPAND code above does not expand to 16 bits at 4418N/A * present, so that case is ok (until do_expand_16 is moved.) 4418N/A * NOTE: this discards the low 16 bits of the user supplied background 4418N/A * color, but until expand_16 works properly there is no choice! 4418N/A#
endif /* PNG_READ_BACKGROUND_SUPPORTED && PNG_READ_EXPAND_16_SUPPORTED */ 4418N/A /* NOTE: below 'PNG_READ_ALPHA_MODE_SUPPORTED' is presumed to also enable the 4418N/A * allows pre-multiplication of the alpha channel to be implemented as 4418N/A * compositing on black. This is probably sub-optimal and has been done in 4418N/A * 1.5.4 betas simply to enable external critique and testing (i.e. to 4418N/A * implement the new API quickly, without lots of internal changes.) 4418N/A /* This needs to change - in the palette image case a whole set of tables are 4418N/A * built when it would be quicker to just calculate the correct value for 4418N/A * each palette entry directly. Also, the test is too tricky - why check 4418N/A * PNG_RGB_TO_GRAY if PNG_GAMMA is not set? The answer seems to be that 4418N/A * PNG_GAMMA is cancelled even if the gamma is known? The test excludes the 4418N/A * PNG_COMPOSE case, so apparently if there is no *overall* gamma correction 4418N/A * the gamma tables will not be built even if composition is required on a 4418N/A * In 1.5.4 this is addressed below by an additional check on the individual 4418N/A * file gamma - if it is not 1.0 both RGB_TO_GRAY and COMPOSE need the 4418N/A /* We don't get to here unless there is a tRNS chunk with non-opaque 4418N/A * entries - see the checking code at the start of this function. 4418N/A else /* if (png_ptr->trans_alpha[i] != 0xff) */ 4418N/A /* Prevent the transformations being done again. 4418N/A * NOTE: this is highly dubious; it zaps the transformations in 4418N/A * place. This seems inconsistent with the general treatment of the 4418N/A * transformations elsewhere. 4418N/A }
/* color_type == PNG_COLOR_TYPE_PALETTE */ 0N/A /* if (png_ptr->background_gamma_type!=PNG_BACKGROUND_GAMMA_UNKNOWN) */ 4418N/A else /* color_type != PNG_COLOR_TYPE_PALETTE */ 0N/A /* RGB or RGBA with color background */ 0N/A /* GRAY, GRAY ALPHA, RGB, or RGBA with gray background */ 4418N/A }
/* color_type != PNG_COLOR_TYPE_PALETTE */ 4418N/A }
/* png_ptr->transformations & PNG_BACKGROUND */ 4418N/A /* Transformation does not include PNG_BACKGROUND */ 0N/A#
endif /* PNG_READ_BACKGROUND_SUPPORTED */ 4418N/A /*NOTE: there are other transformations that should probably be in here 4418N/A /* Done the gamma correction. */ 4418N/A }
/* color_type == PALETTE && !PNG_BACKGROUND transformation */ 4418N/A#
endif /* PNG_READ_GAMMA_SUPPORTED */ 4418N/A /* No GAMMA transformation (see the hanging else 4 lines above) */ 0N/A /* The png_composite() macro is defined in png.h */ 0N/A#
endif /* PNG_READ_BACKGROUND_SUPPORTED */ 0N/A#
endif /* PNG_READ_SHIFT_SUPPORTED */ 0N/A/* Modify the info structure to reflect the transformations. The 0N/A * info should be updated so a PNG file could be written with it, 0N/A * assuming the transformations result in valid PNG data. 4418N/A /* This check must match what actually happens in 4418N/A * png_do_expand_palette; if it ever checks the tRNS chunk to see if 4418N/A * it is all opaque we must do the same (at present it does not.) 4418N/A /* The following is almost certainly wrong unless the background value is in 4418N/A /* The following used to be conditional on PNG_GAMMA (prior to 1.5.4), 4418N/A * however it seems that the code in png_init_read_transformations, which has 4418N/A * been called before this from png_read_update_info->png_read_start_row 4418N/A * sometimes does the gamma transform and cancels the flag. 4418N/A /* No 16 bit support: force chopping 16-bit input down to 8, in this case 4418N/A * the app program can chose if both APIs are available by setting the 4418N/A /* For compatibility with previous versions use the strip method by 4418N/A * default. This code works because if PNG_SCALE_16_TO_8 is already 4418N/A * set the code below will do that in preference to the chop. 4418N/A#
endif /* !READ_16BIT_SUPPORTED */ 0N/A /* STRIP_ALPHA and FILLER allowed: MASK_ALPHA bit stripped above */ 4418N/A /* If adding a true alpha channel not just filler */ 4418N/A /* Adding in 1.5.4: cache the above value in png_struct so that we can later 4418N/A * check in png_rowbytes that the user buffer won't get overwritten. Note 4418N/A * that the field is not always set - if png_read_update_info isn't called 4418N/A * the application has to either not do any transforms or get the calculation 0N/A/* Transform the row. The order of transformations is significant, 0N/A * and is very touchy. If you add a transformation, take care to 0N/A * decide how it fits in with the other transformations here. 4418N/A /* Prior to 1.5.4 this output row/pass where the NULL pointer is, but this 4418N/A * error is incredibly rare and incredibly easy to debug without this 4418N/A /* The following is debugging; prior to 1.5.4 the code was never compiled in; 4418N/A * in 1.5.4 PNG_FLAG_DETECT_UNINITIALIZED was added and the macro 4418N/A * PNG_WARN_UNINITIALIZED_ROW removed. In 1.5 the new flag is set only for 4418N/A * selected new APIs to ensure that there is no API change. 4418N/A /* Application has failed to call either png_read_start_image() or 4418N/A * png_read_update_info() after setting transforms that expand pixels. 4418N/A * This check added to libpng-1.2.19 (but not enabled until 1.5.4). 4418N/A 0
/* at_start == false, because SWAP_ALPHA happens later */);
4418N/A/* From Andreas Dilger e-mail to png-implement, 26 March 1998: 4418N/A * In most cases, the "simple transparency" should be done prior to doing 4418N/A * gray-to-RGB, or you will have to test 3x as many bytes to check if a 4418N/A * pixel is transparent. You would also need to make sure that the 4418N/A * transparency information is upgraded to RGB. 4418N/A * To summarize, the current flow is: 4418N/A * - Gray + simple transparency -> compare 1 or 2 gray bytes and composite 4418N/A * with background "in place" if transparent, 4418N/A * convert to RGB if necessary 4418N/A * - Gray + alpha -> composite with gray background and remove alpha bytes, 4418N/A * convert to RGB if necessary 4418N/A * To support RGB backgrounds for gray images we need: 4418N/A * - Gray + simple transparency -> convert to RGB + simple transparency, 4418N/A * compare 3 or 6 bytes and composite with 4418N/A * background "in place" if transparent 4418N/A * composite with gray bkgrnd) 4418N/A * - Gray + alpha -> convert to RGB + alpha, composite with background and 4418N/A * remove alpha bytes (3x float 4418N/A * Greg's change will do this. The reason it wasn't done before is for 4418N/A * performance, as this increases the per-pixel operations. If we would check 4418N/A * in advance if the background was gray or RGB, and position the gray-to-RGB 4418N/A /* If gray -> RGB, do so now only if background is non-gray; else do later 4418N/A 0
/* at_start == false, because SWAP_ALPHA happens later */);
4418N/A /* There is no harm in doing both of these because only one has any effect, 4418N/A * by putting the 'scale' option first if the app asks for scale (either by 4418N/A * calling the API or in a TRANSFORM flag) this is what happens. 4418N/A#
endif /* PNG_READ_QUANTIZE_SUPPORTED */ 4418N/A /* Do the expansion now, after all the arithmetic has been done. Notice 4418N/A * that previous transformations can handle the PNG_EXPAND_16 flag if this 4418N/A * is efficient (particularly true in the case of gamma correction, where 4418N/A * better accuracy results faster!) 4418N/A /*NOTE: moved here in 1.5.4 (from much later in this list.) */ 4418N/A /* png_uint_32 width; width of row */ 4418N/A /* png_size_t rowbytes; number of bytes in row */ 4418N/A /* png_byte color_type; color type of pixels */ 4418N/A /* png_byte bit_depth; bit depth of samples */ 4418N/A /* png_byte channels; number of channels (1-4) */ 4418N/A /* png_byte pixel_depth; bits per pixel (depth*channels) */ 0N/A/* Unpack pixels of 1, 2, or 4 bits per pixel into 1 byte per pixel, 0N/A * without changing the actual values. Thus, if you had a row with 0N/A * a bit depth of 1, you would end up with bytes that only contained 0N/A * the numbers 0 or 1. If you would rather they contain 0 and 255, use 0N/A * png_do_shift() after this. 0N/A/* Reverse the effects of png_do_shift. This routine merely shifts the 0N/A * pixels back to their significant bits values. Thus, if you have 0N/A * a row of bit depth 8, but only 5 are significant, this will shift 0N/A * the values back to 0 through 31. 4418N/A/* Scale rows of bit depth 16 down to 8 accurately */ 4418N/A /* The input is an array of 16 bit components, these must be scaled to 4418N/A * 8 bits each. For a 16 bit value V the required value (from the PNG 4418N/A * This reduces to round(V / 257), or floor((V + 128.5)/257) 4418N/A * Represent V as the two byte value vhi.vlo. Make a guess that the 4418N/A * result is the top byte of V, vhi, then the correction to this value 4418N/A * error = floor(((V-vhi.vhi) + 128.5) / 257) 4418N/A * = floor(((vlo-vhi) + 128.5) / 257) 4418N/A * This can be approximated using integer arithmetic (and a signed 4418N/A * error = (vlo-vhi+128) >> 8; 4418N/A * The approximate differs from the exact answer only when (vlo-vhi) is 4418N/A * 128; it then gives a correction of +1 when the exact correction is 4418N/A * 0. This gives 128 errors. The exact answer (correct for all 16 bit 4418N/A * error = (vlo-vhi+128)*65535 >> 24; 4418N/A * An alternative arithmetic calculation which also gives no errors is: 4418N/A/* Simply discard the low byte. This was the default behavior prior 0N/A /* This converts from RGBA to ARGB */ 0N/A /* This converts from RRGGBBAA to AARRGGBB */ 0N/A /* This converts from GA to AG */ 0N/A /* This converts from GGAA to AAGG */ 0N/A /* This inverts the alpha channel in RGBA */ 4418N/A /* This inverts the alpha channel in RRGGBBAA */ 0N/A /* This inverts the alpha channel in GA */ 4418N/A /* This inverts the alpha channel in GGAA */ 0N/A/* Add filler channel if we have RGB color */ 4418N/A /* This changes the data from G to GX */ 4418N/A /* This changes the data from G to XG */ 4418N/A /* This changes the data from GG to GGXX */ 4418N/A /* This changes the data from GG to XXGG */ 0N/A }
/* COLOR_TYPE == GRAY */ 4418N/A /* This changes the data from RGB to RGBX */ 4418N/A /* This changes the data from RGB to XRGB */ 4418N/A /* This changes the data from RRGGBB to RRGGBBXX */ 4418N/A /* This changes the data from RRGGBB to XXRRGGBB */ 0N/A }
/* COLOR_TYPE == RGB */ 4418N/A/* Expand grayscale files to RGB, with or without alpha */ 4418N/A /* This changes G to RGB */ 4418N/A /* This changes GG to RRGGBB */ 4418N/A /* This changes GA to RGBA */ 4418N/A /* This changes GGAA to RRGGBBAA */ 4418N/A/* Reduce RGB files to grayscale, with or without alpha 0N/A * using the equation given in Poynton's ColorFAQ at 0N/A * Y = 0.212671 * R + 0.715160 * G + 0.072169 * B 0N/A * We approximate this with 0N/A * Y = 0.21268 * R + 0.7151 * G + 0.07217 * B 0N/A * which can be expressed with integers as 0N/A * Y = (6969 * R + 23434 * G + 2365 * B)/32768 0N/A * The calculation is to be done in a linear colorspace. 0N/A * Other integer coefficents can be used via png_set_rgb_to_gray(). 0N/A else /* RGB bit_depth == 16 */ 0N/A else /* RGBA bit_depth == 16 */ 4418N/A#
endif /* PNG_READ_TRANSFORMS_SUPPORTED */ 0N/A/* Build a grayscale palette. Palette is assumed to be 1 << bit_depth 0N/A * large of png_color. This lets grayscale images be treated as 0N/A * paletted. Most useful for gamma correction and simplification 4418N/A * of code. This API is not used internally. 0N/A/* Replace any alpha or transparency with the supplied background color. 0N/A * "background" is already in the screen gamma, while "background_1" is 0N/A * at a gamma of 1.0. Paletted files have already been taken care of. 0N/A (p <<
4) | (p <<
6)] >>
6) &
0x03);
4418N/A /* Background is already in screen gamma */ 0N/A else /* if (row_info->bit_depth == 16) */ 4418N/A /* Background is already in screen gamma */ 4418N/A /* Background is already in screen gamma */ 4418N/A else /* if (png_ptr->bit_depth == 16) */ 4418N/A /* Background is already in screen gamma */ 4418N/A /* Background is already in screen gamma */ 0N/A else /* if (row_info->bit_depth == 16) */ 4418N/A /* Background is already in screen gamma */ 0N/A/* Gamma correct the image, avoiding the alpha channel. Make sure 0N/A * you do this after you deal with the transparency issue on grayscale 0N/A * or RGB images. If your bit depth is 8, use gamma_table, if it 0N/A * is 16, use gamma_16_table and gamma_shift. Build these with 0N/A * build_gamma_table(). 0N/A else /* if (row_info->bit_depth == 16) */ 0N/A else /* if (row_info->bit_depth == 16) */ 0N/A else /* if (row_info->bit_depth == 16) */ 4418N/A/* Encode the alpha channel to the output gamma (the input channel is always 4418N/A * linear.) Called only with color types that have an alpha channel. Needs the 4418N/A /* The alpha channel is the last component: */ 4418N/A /* The alpha channel is the last component: */ 4418N/A /* Only get to here if called with a weird row_info; no harm has been done, 0N/A/* Expands a palette row to an RGB or RGBA row depending 0N/A * upon whether you supply trans and num_trans. 0N/A/* If the bit depth < 8, it is expanded to 8. Also, if the already 0N/A * expanded transparency value is supplied, an alpha channel is built. 4418N/A/* If the bit depth is 8 and the colour type is not a palette type expand the 4418N/A * whole row to 16 bits. Has no effect otherwise. 4418N/A /* The row have a sequence of bytes containing [0..255] and we need 4418N/A * to turn it into another row containing [0..65535], to do this we 4418N/A * Which happens to be exactly input * 257 and this can be achieved 4418N/A * simply by byte replication in place (copying backwards). 4418N/A /* This looks real messy, but the compiler will reduce 4418N/A * it down to a reasonable formula. For example, with 4418N/A * 5 bits per color, we get: 4418N/A * p = (((r >> 3) & 0x1f) << 10) | 4418N/A * (((g >> 3) & 0x1f) << 5) | 4418N/A#
endif /* PNG_READ_QUANTIZE_SUPPORTED */ 4418N/A#
endif /* PNG_READ_TRANSFORMS_SUPPORTED */ 4418N/A/* Undoes intrapixel differencing */ 0N/A#
endif /* PNG_MNG_FEATURES_SUPPORTED */ 0N/A#
endif /* PNG_READ_SUPPORTED */