diff options
Diffstat (limited to 'libpng.3')
| -rw-r--r-- | libpng.3 | 189 |
1 files changed, 132 insertions, 57 deletions
@@ -1,6 +1,6 @@ -.TH LIBPNG 3 "September 1, 2016" +.TH LIBPNG 3 "September 29, 2017" .SH NAME -libpng \- Portable Network Graphics (PNG) Reference Library 1.6.25 +libpng \- Portable Network Graphics (PNG) Reference Library 1.6.34 .SH SYNOPSIS \fB #include <png.h>\fP @@ -97,6 +97,10 @@ libpng \- Portable Network Graphics (PNG) Reference Library 1.6.25 \fBpng_byte png_get_header_version (png_const_structp \fIpng_ptr\fP\fB);\fP +\fBpng_uint_32 png_get_eXIf (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_bytep \fI*exif\fP\fB);\fP + +\fBpng_uint_32 png_get_eXIf_1 (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_unit_32 \fP\fI*num_exif\fP\fB, png_bytep \fI*exif\fP\fB);\fP + \fBpng_uint_32 png_get_hIST (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_uint_16p \fI*hist\fP\fB);\fP \fBpng_uint_32 png_get_iCCP (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_charpp \fP\fIname\fP\fB, int \fP\fI*compression_type\fP\fB, png_bytepp \fP\fIprofile\fP\fB, png_uint_32 \fI*proflen\fP\fB);\fP @@ -347,6 +351,10 @@ libpng \- Portable Network Graphics (PNG) Reference Library 1.6.25 \fBvoid png_set_gray_to_rgb (png_structp \fIpng_ptr\fP\fB);\fP +\fBvoid png_set_eXIf (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_bytep \fIexif\fP\fB);\fP + +\fBvoid png_set_eXIf_1 (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, const png_uint_32 \fP\fInum_exif\fP\fB, png_bytep \fIexif\fP\fB);\fP + \fBvoid png_set_hIST (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_16p \fIhist\fP\fB);\fP \fBvoid png_set_iCCP (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_const_charp \fP\fIname\fP\fB, int \fP\fIcompression_type\fP\fB, png_const_bytep \fP\fIprofile\fP\fB, png_uint_32 \fIproflen\fP\fB);\fP @@ -510,10 +518,10 @@ Following is a copy of the libpng-manual.txt file that accompanies libpng. .SH LIBPNG.TXT libpng-manual.txt - A description on how to use and modify libpng - libpng version 1.6.25 - September 1, 2016 + libpng version 1.6.34 - September 29, 2017 Updated and distributed by Glenn Randers-Pehrson <glennrp at users.sourceforge.net> - Copyright (c) 1998-2016 Glenn Randers-Pehrson + Copyright (c) 1998-2017 Glenn Randers-Pehrson This document is released under the libpng license. For conditions of distribution and use, see the disclaimer @@ -521,9 +529,9 @@ libpng-manual.txt - A description on how to use and modify libpng Based on: - libpng versions 0.97, January 1998, through 1.6.25 - September 1, 2016 + libpng versions 0.97, January 1998, through 1.6.34 - September 29, 2017 Updated and distributed by Glenn Randers-Pehrson - Copyright (c) 1998-2016 Glenn Randers-Pehrson + Copyright (c) 1998-2017 Glenn Randers-Pehrson libpng 1.0 beta 6 - version 0.96 - May 28, 1997 Updated and distributed by Andreas Dilger @@ -576,17 +584,17 @@ file format in application programs. The PNG specification (second edition), November 2003, is available as a W3C Recommendation and as an ISO Standard (ISO/IEC 15948:2004 (E)) at -<http://www.w3.org/TR/2003/REC-PNG-20031110/ +<https://www.w3.org/TR/2003/REC-PNG-20031110/ The W3C and ISO documents have identical technical content. The PNG-1.2 specification is available at -<http://png-mng.sourceforge.net/pub/png/spec/1.2/>. +<https://png-mng.sourceforge.io/pub/png/spec/1.2/>. It is technically equivalent to the PNG specification (second edition) but has some additional material. -The PNG-1.0 specification is available as RFC 2083 -<http://png-mng.sourceforge.net/pub/png/spec/1.0/> and as a -W3C Recommendation <http://www.w3.org/TR/REC-png-961001>. +The PNG-1.0 specification is available as RFC 2083 +<https://png-mng.sourceforge.io/pub/png/spec/1.0/> and as a +W3C Recommendation <https://www.w3.org/TR/REC-png-961001>. Some additional chunks are described in the special-purpose public chunks documents at <http://www.libpng.org/pub/png/spec/register/> @@ -611,7 +619,7 @@ majority of the needs of its users. Libpng uses zlib for its compression and decompression of PNG files. Further information about zlib, and the latest version of zlib, can -be found at the zlib home page, <http://zlib.net/>. +be found at the zlib home page, <https://zlib.net/>. The zlib compression utility is a general purpose utility that is useful for more than PNG files, and can be used without libpng. See the documentation delivered with zlib for more details. @@ -977,8 +985,9 @@ the default, use The values for png_set_crc_action() say how libpng is to handle CRC errors in ancillary and critical chunks, and whether to use the data contained -therein. Note that it is impossible to "discard" data in a critical -chunk. +therein. Starting with libpng-1.6.26, this also governs how an ADLER32 error +is handled while reading the IDAT chunk. Note that it is impossible to +"discard" data in a critical chunk. Choices for (int) crit_action are PNG_CRC_DEFAULT 0 error/quit @@ -995,6 +1004,9 @@ Choices for (int) ancil_action are PNG_CRC_QUIET_USE 4 quiet/use data PNG_CRC_NO_CHANGE 5 use the current value +When the setting for crit_action is PNG_CRC_QUIET_USE, the CRC and ADLER32 +checksums are not only ignored, but they are not evaluated. + .SS Setting up callback code You can set up a callback function to handle any unknown chunks in the @@ -1194,8 +1206,9 @@ where 0x7fffffffL means unlimited. You can retrieve this limit with chunk_cache_max = png_get_chunk_cache_max(png_ptr); Libpng imposes a limit of 8 Megabytes (8,000,000 bytes) on the amount of -memory that a compressed chunk other than IDAT can occupy, when decompressed. -You can change this limit with +memory that any chunk other than IDAT can occupy, originally or when +decompressed (prior to libpng-1.6.32 the limit was only applied to compressed +chunks after decompression). You can change this limit with png_set_chunk_malloc_max(png_ptr, user_chunk_malloc_max); @@ -1491,8 +1504,17 @@ premultiplication. png_set_alpha_mode(pp, PNG_ALPHA_PNG, PNG_DEFAULT_sRGB); -This is the default libpng handling of the alpha channel - it is not -pre-multiplied into the color components. In addition the call states +Choices for the alpha_mode are + + PNG_ALPHA_PNG 0 /* according to the PNG standard */ + PNG_ALPHA_STANDARD 1 /* according to Porter/Duff */ + PNG_ALPHA_ASSOCIATED 1 /* as above; this is the normal practice */ + PNG_ALPHA_PREMULTIPLIED 1 /* as above */ + PNG_ALPHA_OPTIMIZED 2 /* 'PNG' for opaque pixels, else 'STANDARD' */ + PNG_ALPHA_BROKEN 3 /* the alpha channel is gamma encoded */ + +PNG_ALPHA_PNG is the default libpng handling of the alpha channel. It is not +pre-multiplied into the color components. In addition the call states that the output is for a sRGB system and causes all PNG files without gAMA chunks to be assumed to be encoded using sRGB. @@ -1507,7 +1529,7 @@ early Mac systems behaved. This is the classic Jim Blinn approach and will work in academic environments where everything is done by the book. It has the shortcoming of assuming that input PNG data with no gamma information is linear - this -is unlikely to be correct unless the PNG files where generated locally. +is unlikely to be correct unless the PNG files were generated locally. Most of the time the output precision will be so low as to show significant banding in dark areas of the image. @@ -1696,7 +1718,20 @@ row_pointers prior to calling png_read_png() with png_set_rows(png_ptr, info_ptr, &row_pointers); Alternatively you could allocate your image in one big block and define -row_pointers[i] to point into the proper places in your block. +row_pointers[i] to point into the proper places in your block, but first +be sure that your platform is able to allocate such a large buffer: + + /* Guard against integer overflow */ + if (height > PNG_SIZE_MAX/(width*pixel_size)) { + png_error(png_ptr,"image_data buffer would be too large"); + } + + png_bytep buffer=png_malloc(png_ptr,height*width*pixel_size); + + for (int i=0; i<height, i++) + row_pointers[i]=buffer+i*width*pixel_size; + + png_set_rows(png_ptr, info_ptr, &row_pointers); If you use png_set_rows(), the application is responsible for freeing row_pointers (and row_pointers[i], if they were separately allocated). @@ -1823,6 +1858,11 @@ in until png_read_end() has read the chunk data following the image. rowbytes = png_get_rowbytes(png_ptr, info_ptr); rowbytes - number of bytes needed to hold a row + This value, the bit_depth, color_type, + and the number of channels can change + if you use transforms such as + png_set_expand(). See + png_read_update_info(), below. signature = png_get_signature(png_ptr, info_ptr); @@ -1941,6 +1981,11 @@ png_set_rgb_to_gray()). the single transparent color for non-paletted images (PNG_INFO_tRNS) + png_get_eXIf_1(png_ptr, info_ptr, &num_exif, &exif); + (PNG_INFO_eXIf) + + exif - Exif profile (array of png_byte) + png_get_hIST(png_ptr, info_ptr, &hist); (PNG_INFO_hIST) @@ -2652,6 +2697,16 @@ are allocating one large chunk, you will need to build an array of pointers to each row, as it will be needed for some of the functions below. +Be sure that your platform can allocate the buffer that you'll need. +libpng internally checks for oversize width, but you'll need to +do your own check for number_of_rows*width*pixel_size if you are using +a multiple-row buffer: + + /* Guard against integer overflow */ + if (number_of_rows > PNG_SIZE_MAX/(width*pixel_size)) { + png_error(png_ptr,"image_data buffer would be too large"); + } + Remember: Before you call png_read_update_info(), the png_get_*() functions return the values corresponding to the original PNG image. After you call png_read_update_info the values refer to the image @@ -2976,6 +3031,7 @@ your application instead of by libpng, you can use PNG_INFO_gAMA, PNG_INFO_sBIT, PNG_INFO_cHRM, PNG_INFO_PLTE, PNG_INFO_tRNS, PNG_INFO_bKGD, + PNG_INFO_eXIf, PNG_INFO_hIST, PNG_INFO_pHYs, PNG_INFO_oFFs, PNG_INFO_tIME, PNG_INFO_pCAL, PNG_INFO_sRGB, @@ -3575,6 +3631,11 @@ width, height, bit_depth, and color_type must be the same in each call. single transparent color for non-paletted images (PNG_INFO_tRNS) + png_set_eXIf_1(png_ptr, info_ptr, num_exif, exif); + + exif - Exif profile (array of + png_byte) (PNG_INFO_eXIf) + png_set_hIST(png_ptr, info_ptr, hist); hist - histogram of palette (array of @@ -4330,7 +4391,7 @@ PNG_FORMAT_FLAG_LINEAR flag below. When the simplified API needs to convert between sRGB and linear colorspaces, the actual sRGB transfer curve defined in the sRGB specification (see the -article at http://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2 +article at https://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2 approximation used elsewhere in libpng. When an alpha channel is present it is expected to denote pixel coverage @@ -4594,7 +4655,7 @@ READ APIs When the simplified API needs to convert between sRGB and linear colorspaces, the actual sRGB transfer curve defined in the sRGB specification (see the -article at http://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2 +article at https://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2 approximation used elsewhere in libpng. WRITE APIS @@ -4752,8 +4813,6 @@ functions after png_create_*_struct() has been called by calling: png_voidp error_ptr, png_error_ptr error_fn, png_error_ptr warning_fn); - png_voidp error_ptr = png_get_error_ptr(png_ptr); - If NULL is supplied for either error_fn or warning_fn, then the libpng default function will be used, calling fprintf() and/or longjmp() if a problem is encountered. The replacement error functions should have @@ -4765,6 +4824,11 @@ parameters as follows: void user_warning_fn(png_structp png_ptr, png_const_charp warning_msg); +Then, within your user_error_fn or user_warning_fn, you can retrieve +the error_ptr if you need it, by calling + + png_voidp error_ptr = png_get_error_ptr(png_ptr); + The motivation behind using setjmp() and longjmp() is the C++ throw and catch exception handling methods. This makes the code much easier to write, as there is no need to check every return code of every function call. @@ -4772,7 +4836,7 @@ However, there are some uncertainties about the status of local variables after a longjmp, so the user may want to be careful about doing anything after setjmp returns non-zero besides returning itself. Consult your compiler documentation for more details. For an alternative approach, you -may wish to use the "cexcept" facility (see http://cexcept.sourceforge.net), +may wish to use the "cexcept" facility (see https://cexcept.sourceforge.io/), which is illustrated in pngvalid.c and in contrib/visupng. Beginning in libpng-1.4.0, the png_set_benign_errors() API became available. @@ -5000,7 +5064,7 @@ in a MNG datastream. As a minimum, it must have the MNG 8-byte signature and the MHDR and MEND chunks. Libpng does not provide support for these or any other MNG chunks; your application must provide its own support for them. You may wish to consider using libmng (available at -http://www.libmng.com) instead. +https://www.libmng.com/) instead. .SH VIII. Changes to Libpng from version 0.88 @@ -5423,18 +5487,14 @@ PNG_USER_WIDTH_MAX and PNG_USER_HEIGHT_MAX, although this document said that it could be used to override them. Now this function will reduce or increase the limits. -Starting in libpng-1.5.10, the user limits can be set en masse with the -configuration option PNG_SAFE_LIMITS_SUPPORTED. If this option is enabled, -a set of "safe" limits is applied in pngpriv.h. These can be overridden by -application calls to png_set_user_limits(), png_set_user_chunk_cache_max(), -and/or png_set_user_malloc_max() that increase or decrease the limits. Also, -in libpng-1.5.10 the default width and height limits were increased -from 1,000,000 to 0x7fffffff (i.e., made unlimited). Therefore, the -limits are now - default safe +Starting in libpng-1.5.22, default user limits were established. These +can be overridden by application calls to png_set_user_limits(), +png_set_user_chunk_cache_max(), and/or png_set_user_malloc_max(). +The limits are now + max possible default png_user_width_max 0x7fffffff 1,000,000 png_user_height_max 0x7fffffff 1,000,000 - png_user_chunk_cache_max 0 (unlimited) 128 + png_user_chunk_cache_max 0 (unlimited) 1000 png_user_chunk_malloc_max 0 (unlimited) 8,000,000 The png_set_option() function (and the "options" member of the png struct) was @@ -5684,6 +5744,11 @@ is an error. Previously this requirement of the PNG specification was not enforced, and the palette was always limited to 256 entries. An over-length PLTE chunk found in an input PNG is silently truncated. +Starting with libpng-1.6.31, the eXIf chunk is supported. Libpng does not +attempt to decode the Exif profile; it simply returns a byte array +containing the profile to the calling application which must do its own +decoding. + .SH XIII. Detecting libpng The png_get_io_ptr() function has been present since libpng-0.88, has never @@ -5700,27 +5765,33 @@ control. The git repository was built from old libpng-x.y.z.tar.gz files going back to version 0.70. You can access the git repository (read only) at - git://git.code.sf.net/p/libpng/code + https://github.com/glennrp/libpng or + https://git.code.sf.net/p/libpng/code.git -or you can browse it with a web browser by selecting the "code" button at +or you can browse it with a web browser at - https://sourceforge.net/projects/libpng + https://github.com/glennrp/libpng or + https://sourceforge.net/p/libpng/code/ci/libpng16/tree/ Patches can be sent to glennrp at users.sourceforge.net or to png-mng-implement at lists.sourceforge.net or you can upload them to the libpng bug tracker at - http://libpng.sourceforge.net + https://libpng.sourceforge.io/ + +or as a "pull request" to + + https://github.com/glennrp/libpng/pulls We also accept patches built from the tar or zip distributions, and simple verbal discriptions of bug fixes, reported either to the SourceForge bug tracker, to the png-mng-implement at lists.sf.net -mailing list, or directly to glennrp. +mailing list, as github issues, or directly to glennrp. .SH XV. Coding style Our coding style is similar to the "Allman" style -(See http://en.wikipedia.org/wiki/Indent_style#Allman_style), with curly +(See https://en.wikipedia.org/wiki/Indent_style#Allman_style), with curly braces on separate lines: if (condition) @@ -5821,7 +5892,7 @@ Prior to libpng-1.6.0 we used a "png_sizeof()" macro, formatted as though it were a function. Control keywords if, for, while, and switch are always followed by a space -to distinguish them from function calls, which have no trailing space. +to distinguish them from function calls, which have no trailing space. We put a space after each comma and after each semicolon in "for" statements, and we put spaces before and after each @@ -5845,8 +5916,9 @@ with an even number of lower-case hex digits, and to make them unsigned We prefer to use underscores rather than camelCase in names, except for a few type names that we inherit from zlib.h. -We prefer "if (something != 0)" and "if (something == 0)" -over "if (something)" and if "(!something)", respectively. +We prefer "if (something != 0)" and "if (something == 0)" over +"if (something)" and if "(!something)", respectively, and for pointers +we prefer "if (some_pointer != NULL)" or "if (some_pointer == NULL)". We do not use the TAB character for indentation in the C sources. @@ -5860,7 +5932,7 @@ Since the PNG Development group is an ad-hoc body, we can't make an official declaration. This is your unofficial assurance that libpng from version 0.71 and -upward through 1.6.25 are Y2K compliant. It is my belief that earlier +upward through 1.6.34 are Y2K compliant. It is my belief that earlier versions were also Y2K compliant. Libpng only has two year fields. One is a 2-byte unsigned integer @@ -5958,11 +6030,11 @@ the first widely used release: ... 1.0.19 10 10019 10.so.0.19[.0] ... - 1.2.56 13 10256 12.so.0.56[.0] + 1.2.59 13 10259 12.so.0.59[.0] ... - 1.5.27 15 10527 15.so.15.27[.0] + 1.5.30 15 10530 15.so.15.30[.0] ... - 1.6.25 16 10625 16.so.16.25[.0] + 1.6.34 16 10634 16.so.16.34[.0] Henceforth the source version will match the shared-library minor and patch numbers; the shared-library major version number will be @@ -5979,7 +6051,7 @@ release number plus "betaNN" or "rcNN". .LP .IR libpng : .IP -http://libpng.sourceforge.net (follow the [DOWNLOAD] link) +https://libpng.sourceforge.io/ (follow the [DOWNLOAD] link) http://www.libpng.org/pub/png .LP @@ -5989,7 +6061,7 @@ http://www.libpng.org/pub/png .I libpng or at .br -ftp://ftp.info-zip.org/pub/infozip/zlib +https://zlib.net/ .LP .IR PNG specification: RFC 2083 @@ -5998,11 +6070,11 @@ ftp://ftp.info-zip.org/pub/infozip/zlib .I libpng or at .br -ftp://ftp.rfc-editor.org:/in-notes/rfc2083.txt +https://www.ietf.org/rfc/rfc2083.txt .br or (as a W3C Recommendation) at .br -http://www.w3.org/TR/REC-png.html +https://www.w3.org/TR/REC-png.html .LP In the case of any inconsistency between the PNG specification @@ -6018,7 +6090,7 @@ possible without all of you. Thanks to Frank J. T. Wojcik for helping with the documentation. -Libpng version 1.6.25 - September 1, 2016: +Libpng version 1.6.34 - September 29, 2017: Initially created in 1995 by Guy Eric Schalnat, then of Group 42, Inc. Currently maintained by Glenn Randers-Pehrson (glennrp at users.sourceforge.net). @@ -6043,8 +6115,8 @@ this sentence. This code is released under the libpng license. -libpng versions 1.0.7, July 1, 2000 through 1.6.25, September 1, 2016 are -Copyright (c) 2000-2002, 2004, 2006-2016 Glenn Randers-Pehrson, are +libpng versions 1.0.7, July 1, 2000 through 1.6.34, September 29, 2017 are +Copyright (c) 2000-2002, 2004, 2006-2017 Glenn Randers-Pehrson, are derived from libpng-1.0.6, and are distributed according to the same disclaimer and license as libpng-1.0.6 with the following individuals added to the list of Contributing Authors: @@ -6055,6 +6127,9 @@ added to the list of Contributing Authors: Cosmin Truta Gilles Vollant James Yu + Mandar Sahastrabuddhe + Google Inc. + Vadim Barkov and with the following additions to the disclaimer: @@ -6168,7 +6243,7 @@ files "pngbar.png" and "pngbar.jpg (88x31) and "pngnow.png" (98x31). Glenn Randers-Pehrson glennrp at users.sourceforge.net -September 1, 2016 +September 29, 2017 .\" end of man page |