cheng/libpng
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[libpng16] Removed some commentary from png.h that is now in the manual.

Browse Source
This commit is contained in:
Glenn Randers-Pehrson 2014-02-24 19:07:04 -06:00
parent be040c98f8
commit 9e06534572
1 changed files with 17 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

109
png.h
View File

@ -1,7 +1,7 @@
/* png.h - header file for PNG reference library
*
* libpng version 1.6.10beta03 - February 23, 2014
* libpng version 1.6.10beta03 - February 25, 2014
* Copyright (c) 1998-2014 Glenn Randers-Pehrson
* (Version 0.96 Copyright (c) 1996, 1997 Andreas Dilger)
* (Version 0.88 Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.)
@ -11,7 +11,7 @@
* Authors and maintainers:
* libpng versions 0.71, May 1995, through 0.88, January 1996: Guy Schalnat
* libpng versions 0.89c, June 1996, through 0.96, May 1997: Andreas Dilger
* libpng versions 0.97, January 1998, through 1.6.10beta03 - February 23, 2014: Glenn
* libpng versions 0.97, January 1998, through 1.6.10beta03 - February 25, 2014: Glenn
* See also "Contributing Authors", below.
*
* Note about libpng version numbers:
@ -224,7 +224,7 @@
*
* This code is released under the libpng license.
*
* libpng versions 1.2.6, August 15, 2004, through 1.6.10beta03, February 23, 2014, are
* libpng versions 1.2.6, August 15, 2004, through 1.6.10beta03, February 25, 2014, are
* Copyright (c) 2004, 2006-2013 Glenn Randers-Pehrson, and are
* distributed according to the same disclaimer and license as libpng-1.2.5
* with the following individual added to the list of Contributing Authors:
@ -336,7 +336,7 @@
* Y2K compliance in libpng:
* =========================
*
* February 23, 2014
* February 25, 2014
*
* Since the PNG Development group is an ad-hoc body, we can't make
* an official declaration.
@ -404,7 +404,7 @@
/* Version information for png.h - this should match the version in png.c */
#define PNG_LIBPNG_VER_STRING "1.6.10beta03"
#define PNG_HEADER_VERSION_STRING \
" libpng version 1.6.10beta03 - February 23, 2014\n"
" libpng version 1.6.10beta03 - February 25, 2014\n"
#define PNG_LIBPNG_VER_SONUM 16
#define PNG_LIBPNG_VER_DLLNUM 16
@ -1210,9 +1210,9 @@ PNG_EXPORT(35, void, png_build_grayscale_palette, (int bit_depth,
#endif
#ifdef PNG_READ_ALPHA_MODE_SUPPORTED
/* How the alpha channel is interpreted - this affects how the color channels of
* a PNG file are returned when an alpha channel, or tRNS chunk in a palette
* file, is present.
/* How the alpha channel is interpreted - this affects how the color channels
* of a PNG file are returned to the calling application when an alpha channel,
* or a tRNS chunk in a palette file, is present.
*
* This has no effect on the way pixels are written into a PNG output
* datastream. The color samples in a PNG datastream are never premultiplied
@ -1220,33 +1220,19 @@ PNG_EXPORT(35, void, png_build_grayscale_palette, (int bit_depth,
*
* The default is to return data according to the PNG specification: the alpha
* channel is a linear measure of the contribution of the pixel to the
* corresponding composited pixel. The gamma encoded color channels must be
* scaled according to the contribution and to do this it is necessary to undo
* corresponding composited pixel, and the color channels are unassociated
* (not premultiplied). The gamma encoded color channels must be scaled
* according to the contribution and to do this it is necessary to undo
* the encoding, scale the color values, perform the composition and reencode
* the values. This is the 'PNG' mode.
*
* The alternative is to 'associate' the alpha with the color information by
* storing color channel values that have been scaled by the alpha. The
* advantage is that the color channels can be resampled (the image can be
* scaled) in this form. The disadvantage is that normal practice is to store
* linear, not (gamma) encoded, values and this requires 16-bit channels for
* still images rather than the 8-bit channels that are just about sufficient if
* gamma encoding is used. In addition all non-transparent pixel values,
* including completely opaque ones, must be gamma encoded to produce the final
* image. This is the 'STANDARD', 'ASSOCIATED' or 'PREMULTIPLIED' mode (the
* latter being the two common names for associated alpha color channels.)
* storing color channel values that have been scaled by the alpha.
* image. These are the 'STANDARD', 'ASSOCIATED' or 'PREMULTIPLIED' modes
* (the latter being the two common names for associated alpha color channels).
*
* Since it is not necessary to perform arithmetic on opaque color values so
* long as they are not to be resampled and are in the final color space it is
* possible to optimize the handling of alpha by storing the opaque pixels in
* the PNG format (adjusted for the output color space) while storing partially
* opaque pixels in the standard, linear, format. The accuracy required for
* standard alpha composition is relatively low, because the pixels are
* isolated, therefore typically the accuracy loss in storing 8-bit linear
* values is acceptable. (This is not true if the alpha channel is used to
* simulate transparency over large areas - use 16 bits or the PNG mode in
* this case!) This is the 'OPTIMIZED' mode. For this mode a pixel is
* treated as opaque only if the alpha value is equal to the maximum value.
* For the 'OPTIMIZED' mode, a pixel is treated as opaque only if the alpha
* value is equal to the maximum value.
*
* The final choice is to gamma encode the alpha channel as well. This is
* broken because, in practice, no implementation that uses this choice
@ -1273,68 +1259,7 @@ PNG_FIXED_EXPORT(228, void, png_set_alpha_mode_fixed, (png_structrp png_ptr,
#if defined(PNG_GAMMA_SUPPORTED) || defined(PNG_READ_ALPHA_MODE_SUPPORTED)
/* The output_gamma value is a screen gamma in libpng terminology: it expresses
* how to decode the output values, not how they are encoded. The values used
* correspond to the normal numbers used to describe the overall gamma of a
* computer display system; for example 2.2 for an sRGB conformant system. The
* values are scaled by 100000 in the _fixed version of the API (so 220000 for
* sRGB.)
*
* The inverse of the value is always used to provide a default for the PNG file
* encoding if it has no gAMA chunk and if png_set_gamma() has not been called
* to override the PNG gamma information.
*
* When the ALPHA_OPTIMIZED mode is selected the output gamma is used to encode
* opaque pixels however pixels with lower alpha values are not encoded,
* regardless of the output gamma setting.
*
* When the standard Porter Duff handling is requested with mode 1 the output
* encoding is set to be linear and the output_gamma value is only relevant
* as a default for input data that has no gamma information. The linear output
* encoding will be overridden if png_set_gamma() is called - the results may be
* highly unexpected!
*
* The following numbers are derived from the sRGB standard and the research
* behind it. sRGB is defined to be approximated by a PNG gAMA chunk value of
* 0.45455 (1/2.2) for PNG. The value implicitly includes any viewing
* correction required to take account of any differences in the color
* environment of the original scene and the intended display environment; the
* value expresses how to *decode* the image for display, not how the original
* data was *encoded*.
*
* sRGB provides a peg for the PNG standard by defining a viewing environment.
* sRGB itself, and earlier TV standards, actually use a more complex transform
* (a linear portion then a gamma 2.4 power law) than PNG can express. (PNG is
* limited to simple power laws.) By saying that an image for direct display on
* an sRGB conformant system should be stored with a gAMA chunk value of 45455
* (11.3.3.2 and 11.3.3.5 of the ISO PNG specification) the PNG specification
* makes it possible to derive values for other display systems and
* environments.
*
* The Mac value is deduced from the sRGB based on an assumption that the actual
* extra viewing correction used in early Mac display systems was implemented as
* a power 1.45 lookup table.
*
* Any system where a programmable lookup table is used or where the behavior of
* the final display device characteristics can be changed requires system
* specific code to obtain the current characteristic. However this can be
* difficult and most PNG gamma correction only requires an approximate value.
*
* By default, if png_set_alpha_mode() is not called, libpng assumes that all
* values are unencoded, linear, values and that the output device also has a
* linear characteristic. This is only very rarely correct - it is invariably
* better to call png_set_alpha_mode() with PNG_DEFAULT_sRGB than rely on the
* default if you don't know what the right answer is!
*
* The special value PNG_GAMMA_MAC_18 indicates an older Mac system (pre Mac OS
* 10.6) which used a correction table to implement a somewhat lower gamma on an
* otherwise sRGB system.
*
* Both these values are reserved (not simple gamma values) in order to allow
* more precise correction internally in the future.
*
* NOTE: the following values can be passed to either the fixed or floating
* point APIs, but the floating point API will also accept floating point
* values.
* how to decode the output values, not how they are encoded.
*/
#define PNG_DEFAULT_sRGB -1 /* sRGB gamma and color space */
#define PNG_GAMMA_MAC_18 -2 /* Old Mac '1.8' gamma and color space */