VirtualBox

source: vbox/trunk/src/libs/libpng-1.6.37/libpng.3@ 103025

最後變更 在這個檔案從103025是 96425,由 vboxsync 提交於 2 年 前

src/libs: Switch to libpng-1.6.37, bugref:8515 [re-export]

  • 屬性 svn:eol-style 設為 native
檔案大小: 259.9 KB
 
1.TH LIBPNG 3 "April 14, 2019"
2.SH NAME
3libpng \- Portable Network Graphics (PNG) Reference Library 1.6.37
4
5.SH SYNOPSIS
6\fB#include <png.h>\fP
7
8\fBpng_uint_32 png_access_version_number (void);\fP
9
10\fBvoid png_benign_error (png_structp \fP\fIpng_ptr\fP\fB, png_const_charp \fIerror\fP\fB);\fP
11
12\fBvoid png_build_grayscale_palette (int \fP\fIbit_depth\fP\fB, png_colorp \fIpalette\fP\fB);\fP
13
14\fBpng_voidp png_calloc (png_structp \fP\fIpng_ptr\fP\fB, png_alloc_size_t \fIsize\fP\fB);\fP
15
16\fBvoid png_chunk_benign_error (png_structp \fP\fIpng_ptr\fP\fB, png_const_charp \fIerror\fP\fB);\fP
17
18\fBvoid png_chunk_error (png_structp \fP\fIpng_ptr\fP\fB, png_const_charp \fIerror\fP\fB);\fP
19
20\fBvoid png_chunk_warning (png_structp \fP\fIpng_ptr\fP\fB, png_const_charp \fImessage\fP\fB);\fP
21
22\fBvoid png_convert_from_struct_tm (png_timep \fP\fIptime\fP\fB, struct tm FAR * \fIttime\fP\fB);\fP
23
24\fBvoid png_convert_from_time_t (png_timep \fP\fIptime\fP\fB, time_t \fIttime\fP\fB);\fP
25
26\fBpng_charp png_convert_to_rfc1123 (png_structp \fP\fIpng_ptr\fP\fB, png_timep \fIptime\fP\fB);\fP
27
28\fBpng_infop png_create_info_struct (png_structp \fIpng_ptr\fP\fB);\fP
29
30\fBpng_structp png_create_read_struct (png_const_charp \fP\fIuser_png_ver\fP\fB, png_voidp \fP\fIerror_ptr\fP\fB, png_error_ptr \fP\fIerror_fn\fP\fB, png_error_ptr \fIwarn_fn\fP\fB);\fP
31
32\fBpng_structp png_create_read_struct_2 (png_const_charp \fP\fIuser_png_ver\fP\fB, png_voidp \fP\fIerror_ptr\fP\fB, png_error_ptr \fP\fIerror_fn\fP\fB, png_error_ptr \fP\fIwarn_fn\fP\fB, png_voidp \fP\fImem_ptr\fP\fB, png_malloc_ptr \fP\fImalloc_fn\fP\fB, png_free_ptr \fIfree_fn\fP\fB);\fP
33
34\fBpng_structp png_create_write_struct (png_const_charp \fP\fIuser_png_ver\fP\fB, png_voidp \fP\fIerror_ptr\fP\fB, png_error_ptr \fP\fIerror_fn\fP\fB, png_error_ptr \fIwarn_fn\fP\fB);\fP
35
36\fBpng_structp png_create_write_struct_2 (png_const_charp \fP\fIuser_png_ver\fP\fB, png_voidp \fP\fIerror_ptr\fP\fB, png_error_ptr \fP\fIerror_fn\fP\fB, png_error_ptr \fP\fIwarn_fn\fP\fB, png_voidp \fP\fImem_ptr\fP\fB, png_malloc_ptr \fP\fImalloc_fn\fP\fB, png_free_ptr \fIfree_fn\fP\fB);\fP
37
38\fBvoid png_data_freer (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fP\fIfreer\fP\fB, png_uint_32 \fImask\fP\fB);\fP
39
40\fBvoid png_destroy_info_struct (png_structp \fP\fIpng_ptr\fP\fB, png_infopp \fIinfo_ptr_ptr\fP\fB);\fP
41
42\fBvoid png_destroy_read_struct (png_structpp \fP\fIpng_ptr_ptr\fP\fB, png_infopp \fP\fIinfo_ptr_ptr\fP\fB, png_infopp \fIend_info_ptr_ptr\fP\fB);\fP
43
44\fBvoid png_destroy_write_struct (png_structpp \fP\fIpng_ptr_ptr\fP\fB, png_infopp \fIinfo_ptr_ptr\fP\fB);\fP
45
46\fBvoid png_err (png_structp \fIpng_ptr\fP\fB);\fP
47
48\fBvoid png_error (png_structp \fP\fIpng_ptr\fP\fB, png_const_charp \fIerror\fP\fB);\fP
49
50\fBvoid png_free (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fIptr\fP\fB);\fP
51
52\fBvoid png_free_chunk_list (png_structp \fIpng_ptr\fP\fB);\fP
53
54\fBvoid png_free_default (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fIptr\fP\fB);\fP
55
56\fBvoid png_free_data (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fInum\fP\fB);\fP
57
58\fBpng_byte png_get_bit_depth (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
59
60\fBpng_uint_32 png_get_bKGD (png_const_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_color_16p \fI*background\fP\fB);\fP
61
62\fBpng_byte png_get_channels (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
63
64\fBpng_uint_32 png_get_cHRM (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, double \fP\fI*white_x\fP\fB, double \fP\fI*white_y\fP\fB, double \fP\fI*red_x\fP\fB, double \fP\fI*red_y\fP\fB, double \fP\fI*green_x\fP\fB, double \fP\fI*green_y\fP\fB, double \fP\fI*blue_x\fP\fB, double \fI*blue_y\fP\fB);\fP
65
66\fBpng_uint_32 png_get_cHRM_fixed (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fI*white_x\fP\fB, png_uint_32 \fP\fI*white_y\fP\fB, png_uint_32 \fP\fI*red_x\fP\fB, png_uint_32 \fP\fI*red_y\fP\fB, png_uint_32 \fP\fI*green_x\fP\fB, png_uint_32 \fP\fI*green_y\fP\fB, png_uint_32 \fP\fI*blue_x\fP\fB, png_uint_32 \fI*blue_y\fP\fB);\fP
67
68\fBpng_uint_32 png_get_cHRM_XYZ (png_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, double \fP\fI*red_X\fP\fB, double \fP\fI*red_Y\fP\fB, double \fP\fI*red_Z\fP\fB, double \fP\fI*green_X\fP\fB, double \fP\fI*green_Y\fP\fB, double \fP\fI*green_Z\fP\fB, double \fP\fI*blue_X\fP\fB, double \fP\fI*blue_Y\fP\fB, double \fI*blue_Z\fP\fB);\fP
69
70\fBpng_uint_32 png_get_cHRM_XYZ_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_fixed_point \fP\fI*int_red_X\fP\fB, png_fixed_point \fP\fI*int_red_Y\fP\fB, png_fixed_point \fP\fI*int_red_Z\fP\fB, png_fixed_point \fP\fI*int_green_X\fP\fB, png_fixed_point \fP\fI*int_green_Y\fP\fB, png_fixed_point \fP\fI*int_green_Z\fP\fB, png_fixed_point \fP\fI*int_blue_X\fP\fB, png_fixed_point \fP\fI*int_blue_Y\fP\fB, png_fixed_point \fI*int_blue_Z\fP\fB);\fP
71
72\fBpng_uint_32 png_get_chunk_cache_max (png_const_structp \fIpng_ptr\fP\fB);\fP
73
74\fBpng_alloc_size_t png_get_chunk_malloc_max (png_const_structp \fIpng_ptr\fP\fB);\fP
75
76\fBpng_byte png_get_color_type (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
77
78\fBpng_uint_32 png_get_compression_buffer_size (png_const_structp \fIpng_ptr\fP\fB);\fP
79
80\fBpng_byte png_get_compression_type (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
81
82\fBpng_byte png_get_copyright (png_const_structp \fIpng_ptr\fP\fB);\fP
83
84\fBpng_uint_32 png_get_current_row_number \fI(png_const_structp\fP\fB);\fP
85
86\fBpng_byte png_get_current_pass_number \fI(png_const_structp\fP\fB);\fP
87
88\fBpng_voidp png_get_error_ptr (png_const_structp \fIpng_ptr\fP\fB);\fP
89
90\fBpng_byte png_get_filter_type (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
91
92\fBpng_uint_32 png_get_gAMA (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, double \fI*file_gamma\fP\fB);\fP
93
94\fBpng_uint_32 png_get_gAMA_fixed (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fI*int_file_gamma\fP\fB);\fP
95
96\fBpng_byte png_get_header_ver (png_const_structp \fIpng_ptr\fP\fB);\fP
97
98\fBpng_byte png_get_header_version (png_const_structp \fIpng_ptr\fP\fB);\fP
99
100\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
101
102\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
103
104\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
105
106\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
107
108\fBpng_uint_32 png_get_IHDR (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fI*width\fP\fB, png_uint_32 \fP\fI*height\fP\fB, int \fP\fI*bit_depth\fP\fB, int \fP\fI*color_type\fP\fB, int \fP\fI*interlace_type\fP\fB, int \fP\fI*compression_type\fP\fB, int \fI*filter_type\fP\fB);\fP
109
110\fBpng_uint_32 png_get_image_height (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
111
112\fBpng_uint_32 png_get_image_width (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
113
114\fBpng_int_32 png_get_int_32 (png_bytep \fIbuf\fP\fB);\fP
115
116\fBpng_byte png_get_interlace_type (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
117
118\fBpng_uint_32 png_get_io_chunk_type (png_const_structp \fIpng_ptr\fP\fB);\fP
119
120\fBpng_voidp png_get_io_ptr (png_structp \fIpng_ptr\fP\fB);\fP
121
122\fBpng_uint_32 png_get_io_state (png_structp \fIpng_ptr\fP\fB);\fP
123
124\fBpng_byte png_get_libpng_ver (png_const_structp \fIpng_ptr\fP\fB);\fP
125
126\fBint png_get_palette_max(png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
127
128\fBpng_voidp png_get_mem_ptr (png_const_structp \fIpng_ptr\fP\fB);\fP
129
130\fBpng_uint_32 png_get_oFFs (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fI*offset_x\fP\fB, png_uint_32 \fP\fI*offset_y\fP\fB, int \fI*unit_type\fP\fB);\fP
131
132\fBpng_uint_32 png_get_pCAL (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_charp \fP\fI*purpose\fP\fB, png_int_32 \fP\fI*X0\fP\fB, png_int_32 \fP\fI*X1\fP\fB, int \fP\fI*type\fP\fB, int \fP\fI*nparams\fP\fB, png_charp \fP\fI*units\fP\fB, png_charpp \fI*params\fP\fB);\fP
133
134\fBpng_uint_32 png_get_pHYs (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fI*res_x\fP\fB, png_uint_32 \fP\fI*res_y\fP\fB, int \fI*unit_type\fP\fB);\fP
135
136\fBfloat png_get_pixel_aspect_ratio (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
137
138\fBpng_uint_32 png_get_pHYs_dpi (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fI*res_x\fP\fB, png_uint_32 \fP\fI*res_y\fP\fB, int \fI*unit_type\fP\fB);\fP
139
140\fBpng_fixed_point png_get_pixel_aspect_ratio_fixed (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
141
142\fBpng_uint_32 png_get_pixels_per_inch (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
143
144\fBpng_uint_32 png_get_pixels_per_meter (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
145
146\fBpng_voidp png_get_progressive_ptr (png_const_structp \fIpng_ptr\fP\fB);\fP
147
148\fBpng_uint_32 png_get_PLTE (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_colorp \fP\fI*palette\fP\fB, int \fI*num_palette\fP\fB);\fP
149
150\fBpng_byte png_get_rgb_to_gray_status (png_const_structp \fIpng_ptr\fP\fB);\fP
151
152\fBpng_uint_32 png_get_rowbytes (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
153
154\fBpng_bytepp png_get_rows (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
155
156\fBpng_uint_32 png_get_sBIT (png_const_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_color_8p \fI*sig_bit\fP\fB);\fP
157
158\fBvoid png_get_sCAL (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, int* \fP\fIunit\fP\fB, double* \fP\fIwidth\fP\fB, double* \fIheight\fP\fB);\fP
159
160\fBvoid png_get_sCAL_fixed (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, int* \fP\fIunit\fP\fB, png_fixed_pointp \fP\fIwidth\fP\fB, png_fixed_pointp \fIheight\fP\fB);\fP
161
162\fBvoid png_get_sCAL_s (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, int* \fP\fIunit\fP\fB, png_charpp \fP\fIwidth\fP\fB, png_charpp \fIheight\fP\fB);\fP
163
164\fBpng_bytep png_get_signature (png_const_structp \fP\fIpng_ptr\fP\fB, png_infop \fIinfo_ptr\fP\fB);\fP
165
166\fBpng_uint_32 png_get_sPLT (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_spalette_p \fI*splt_ptr\fP\fB);\fP
167
168\fBpng_uint_32 png_get_sRGB (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, int \fI*file_srgb_intent\fP\fB);\fP
169
170\fBpng_uint_32 png_get_text (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_textp \fP\fI*text_ptr\fP\fB, int \fI*num_text\fP\fB);\fP
171
172\fBpng_uint_32 png_get_tIME (png_const_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_timep \fI*mod_time\fP\fB);\fP
173
174\fBpng_uint_32 png_get_tRNS (png_const_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_bytep \fP\fI*trans_alpha\fP\fB, int \fP\fI*num_trans\fP\fB, png_color_16p \fI*trans_color\fP\fB);\fP
175
176\fB/* This function is really an inline macro. \fI*/
177
178\fBpng_uint_16 png_get_uint_16 (png_bytep \fIbuf\fP\fB);\fP
179
180\fBpng_uint_32 png_get_uint_31 (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fIbuf\fP\fB);\fP
181
182\fB/* This function is really an inline macro. \fI*/
183
184\fBpng_uint_32 png_get_uint_32 (png_bytep \fIbuf\fP\fB);\fP
185
186\fBpng_uint_32 png_get_unknown_chunks (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_unknown_chunkpp \fIunknowns\fP\fB);\fP
187
188\fBpng_voidp png_get_user_chunk_ptr (png_const_structp \fIpng_ptr\fP\fB);\fP
189
190\fBpng_uint_32 png_get_user_height_max (png_const_structp \fIpng_ptr\fP\fB);\fP
191
192\fBpng_voidp png_get_user_transform_ptr (png_const_structp \fIpng_ptr\fP\fB);\fP
193
194\fBpng_uint_32 png_get_user_width_max (png_const_structp \fIpng_ptr\fP\fB);\fP
195
196\fBpng_uint_32 png_get_valid (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fIflag\fP\fB);\fP
197
198\fBfloat png_get_x_offset_inches (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
199
200\fBpng_fixed_point png_get_x_offset_inches_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
201
202\fBpng_int_32 png_get_x_offset_microns (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
203
204\fBpng_int_32 png_get_x_offset_pixels (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
205
206\fBpng_uint_32 png_get_x_pixels_per_inch (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
207
208\fBpng_uint_32 png_get_x_pixels_per_meter (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
209
210\fBfloat png_get_y_offset_inches (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
211
212\fBpng_fixed_point png_get_y_offset_inches_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
213
214\fBpng_int_32 png_get_y_offset_microns (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
215
216\fBpng_int_32 png_get_y_offset_pixels (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
217
218\fBpng_uint_32 png_get_y_pixels_per_inch (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
219
220\fBpng_uint_32 png_get_y_pixels_per_meter (png_const_structp \fP\fIpng_ptr\fP\fB, png_const_infop \fIinfo_ptr\fP\fB);\fP
221
222\fBint png_handle_as_unknown (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fIchunk_name\fP\fB);\fP
223
224\fBint png_image_begin_read_from_file (png_imagep \fP\fIimage\fP\fB, const char \fI*file_name\fP\fB);\fP
225
226\fBint png_image_begin_read_from_stdio (png_imagep \fP\fIimage\fP\fB, FILE* \fIfile\fP\fB);\fP
227
228\fBint, png_image_begin_read_from_memory (png_imagep \fP\fIimage\fP\fB, png_const_voidp \fP\fImemory\fP\fB, size_t \fIsize\fP\fB);\fP
229
230\fBint png_image_finish_read (png_imagep \fP\fIimage\fP\fB, png_colorp \fP\fIbackground\fP\fB, void \fP\fI*buffer\fP\fB, png_int_32 \fP\fIrow_stride\fP\fB, void \fI*colormap\fP\fB);\fP
231
232\fBvoid png_image_free (png_imagep \fIimage\fP\fB);\fP
233
234\fBint png_image_write_to_file (png_imagep \fP\fIimage\fP\fB, const char \fP\fI*file\fP\fB, int \fP\fIconvert_to_8bit\fP\fB, const void \fP\fI*buffer\fP\fB, png_int_32 \fP\fIrow_stride\fP\fB, void \fI*colormap\fP\fB);\fP
235
236\fBint png_image_write_to_memory (png_imagep \fP\fIimage\fP\fB, void \fP\fI*memory\fP\fB, png_alloc_size_t * PNG_RESTRICT \fP\fImemory_bytes\fP\fB, int \fP\fIconvert_to_8_bit\fP\fB, const void \fP\fI*buffer\fP\fB, png_int_32 \fP\fIrow_stride\fP\fB, const void \fI*colormap\fP\fB);\fP
237
238\fBint png_image_write_to_stdio (png_imagep \fP\fIimage\fP\fB, FILE \fP\fI*file\fP\fB, int \fP\fIconvert_to_8_bit\fP\fB, const void \fP\fI*buffer\fP\fB, png_int_32 \fP\fIrow_stride\fP\fB, void \fI*colormap\fP\fB);\fP
239
240\fBvoid png_info_init_3 (png_infopp \fP\fIinfo_ptr\fP\fB, size_t \fIpng_info_struct_size\fP\fB);\fP
241
242\fBvoid png_init_io (png_structp \fP\fIpng_ptr\fP\fB, FILE \fI*fp\fP\fB);\fP
243
244\fBvoid png_longjmp (png_structp \fP\fIpng_ptr\fP\fB, int \fIval\fP\fB);\fP
245
246\fBpng_voidp png_malloc (png_structp \fP\fIpng_ptr\fP\fB, png_alloc_size_t \fIsize\fP\fB);\fP
247
248\fBpng_voidp png_malloc_default (png_structp \fP\fIpng_ptr\fP\fB, png_alloc_size_t \fIsize\fP\fB);\fP
249
250\fBpng_voidp png_malloc_warn (png_structp \fP\fIpng_ptr\fP\fB, png_alloc_size_t \fIsize\fP\fB);\fP
251
252\fBpng_uint_32 png_permit_mng_features (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fImng_features_permitted\fP\fB);\fP
253
254\fBvoid png_process_data (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_bytep \fP\fIbuffer\fP\fB, size_t \fIbuffer_size\fP\fB);\fP
255
256\fBsize_t png_process_data_pause (png_structp \fP\fIpng_ptr\fP\fB, int \fIsave\fP\fB);\fP
257
258\fBpng_uint_32 png_process_data_skip (png_structp \fP\fIpng_ptr\fP\fB);\fP
259
260\fBvoid png_progressive_combine_row (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fP\fIold_row\fP\fB, png_bytep \fInew_row\fP\fB);\fP
261
262\fBvoid png_read_end (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fIinfo_ptr\fP\fB);\fP
263
264\fBvoid png_read_image (png_structp \fP\fIpng_ptr\fP\fB, png_bytepp \fIimage\fP\fB);\fP
265
266\fBvoid png_read_info (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fIinfo_ptr\fP\fB);\fP
267
268\fBvoid png_read_png (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fP\fItransforms\fP\fB, png_voidp \fIparams\fP\fB);\fP
269
270\fBvoid png_read_row (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fP\fIrow\fP\fB, png_bytep \fIdisplay_row\fP\fB);\fP
271
272\fBvoid png_read_rows (png_structp \fP\fIpng_ptr\fP\fB, png_bytepp \fP\fIrow\fP\fB, png_bytepp \fP\fIdisplay_row\fP\fB, png_uint_32 \fInum_rows\fP\fB);\fP
273
274\fBvoid png_read_update_info (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fIinfo_ptr\fP\fB);\fP
275
276\fBint png_reset_zstream (png_structp \fIpng_ptr\fP\fB);\fP
277
278\fBvoid png_save_int_32 (png_bytep \fP\fIbuf\fP\fB, png_int_32 \fIi\fP\fB);\fP
279
280\fBvoid png_save_uint_16 (png_bytep \fP\fIbuf\fP\fB, unsigned int \fIi\fP\fB);\fP
281
282\fBvoid png_save_uint_32 (png_bytep \fP\fIbuf\fP\fB, png_uint_32 \fIi\fP\fB);\fP
283
284\fBvoid png_set_add_alpha (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fP\fIfiller\fP\fB, int \fIflags\fP\fB);\fP
285
286\fBvoid png_set_alpha_mode (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fImode\fP\fB, double \fIoutput_gamma\fP\fB);\fP
287
288\fBvoid png_set_alpha_mode_fixed (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fImode\fP\fB, png_fixed_point \fIoutput_gamma\fP\fB);\fP
289
290\fBvoid png_set_background (png_structp \fP\fIpng_ptr\fP\fB, png_color_16p \fP\fIbackground_color\fP\fB, int \fP\fIbackground_gamma_code\fP\fB, int \fP\fIneed_expand\fP\fB, double \fIbackground_gamma\fP\fB);\fP
291
292\fBvoid png_set_background_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_color_16p \fP\fIbackground_color\fP\fB, int \fP\fIbackground_gamma_code\fP\fB, int \fP\fIneed_expand\fP\fB, png_uint_32 \fIbackground_gamma\fP\fB);\fP
293
294\fBvoid png_set_benign_errors (png_structp \fP\fIpng_ptr\fP\fB, int \fIallowed\fP\fB);\fP
295
296\fBvoid png_set_bgr (png_structp \fIpng_ptr\fP\fB);\fP
297
298\fBvoid png_set_bKGD (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_color_16p \fIbackground\fP\fB);\fP
299
300\fBvoid png_set_check_for_invalid_index (png_structrp \fP\fIpng_ptr\fP\fB, int \fIallowed\fP\fB);\fP
301
302\fBvoid png_set_cHRM (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, double \fP\fIwhite_x\fP\fB, double \fP\fIwhite_y\fP\fB, double \fP\fIred_x\fP\fB, double \fP\fIred_y\fP\fB, double \fP\fIgreen_x\fP\fB, double \fP\fIgreen_y\fP\fB, double \fP\fIblue_x\fP\fB, double \fIblue_y\fP\fB);\fP
303
304\fBvoid png_set_cHRM_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fIwhite_x\fP\fB, png_uint_32 \fP\fIwhite_y\fP\fB, png_uint_32 \fP\fIred_x\fP\fB, png_uint_32 \fP\fIred_y\fP\fB, png_uint_32 \fP\fIgreen_x\fP\fB, png_uint_32 \fP\fIgreen_y\fP\fB, png_uint_32 \fP\fIblue_x\fP\fB, png_uint_32 \fIblue_y\fP\fB);\fP
305
306\fBvoid png_set_cHRM_XYZ (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, double \fP\fIred_X\fP\fB, double \fP\fIred_Y\fP\fB, double \fP\fIred_Z\fP\fB, double \fP\fIgreen_X\fP\fB, double \fP\fIgreen_Y\fP\fB, double \fP\fIgreen_Z\fP\fB, double \fP\fIblue_X\fP\fB, double \fP\fIblue_Y\fP\fB, double \fIblue_Z\fP\fB);\fP
307
308\fBvoid png_set_cHRM_XYZ_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_fixed_point \fP\fIint_red_X\fP\fB, png_fixed_point \fP\fIint_red_Y\fP\fB, png_fixed_point \fP\fIint_red_Z\fP\fB, png_fixed_point \fP\fIint_green_X\fP\fB, png_fixed_point \fP\fIint_green_Y\fP\fB, png_fixed_point \fP\fIint_green_Z\fP\fB, png_fixed_point \fP\fIint_blue_X\fP\fB, png_fixed_point \fP\fIint_blue_Y\fP\fB, png_fixed_point \fIint_blue_Z\fP\fB);\fP
309
310\fBvoid png_set_chunk_cache_max (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fIuser_chunk_cache_max\fP\fB);\fP
311
312\fBvoid png_set_compression_level (png_structp \fP\fIpng_ptr\fP\fB, int \fIlevel\fP\fB);\fP
313
314\fBvoid png_set_compression_mem_level (png_structp \fP\fIpng_ptr\fP\fB, int \fImem_level\fP\fB);\fP
315
316\fBvoid png_set_compression_method (png_structp \fP\fIpng_ptr\fP\fB, int \fImethod\fP\fB);\fP
317
318\fBvoid png_set_compression_strategy (png_structp \fP\fIpng_ptr\fP\fB, int \fIstrategy\fP\fB);\fP
319
320\fBvoid png_set_compression_window_bits (png_structp \fP\fIpng_ptr\fP\fB, int \fIwindow_bits\fP\fB);\fP
321
322\fBvoid png_set_crc_action (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fIcrit_action\fP\fB, int \fIancil_action\fP\fB);\fP
323
324\fBvoid png_set_error_fn (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fP\fIerror_ptr\fP\fB, png_error_ptr \fP\fIerror_fn\fP\fB, png_error_ptr \fIwarning_fn\fP\fB);\fP
325
326\fBvoid png_set_expand (png_structp \fIpng_ptr\fP\fB);\fP
327
328\fBvoid png_set_expand_16 (png_structp \fIpng_ptr\fP\fB);\fP
329
330\fBvoid png_set_expand_gray_1_2_4_to_8 (png_structp \fIpng_ptr\fP\fB);\fP
331
332\fBvoid png_set_filler (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fP\fIfiller\fP\fB, int \fIflags\fP\fB);\fP
333
334\fBvoid png_set_filter (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fImethod\fP\fB, int \fIfilters\fP\fB);\fP
335
336\fBvoid png_set_filter_heuristics (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fIheuristic_method\fP\fB, int \fP\fInum_weights\fP\fB, png_doublep \fP\fIfilter_weights\fP\fB, png_doublep \fIfilter_costs\fP\fB);\fP
337
338\fBvoid png_set_filter_heuristics_fixed (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fIheuristic_method\fP\fB, int \fP\fInum_weights\fP\fB, png_fixed_point_p \fP\fIfilter_weights\fP\fB, png_fixed_point_p \fIfilter_costs\fP\fB);\fP
339
340\fBvoid png_set_flush (png_structp \fP\fIpng_ptr\fP\fB, int \fInrows\fP\fB);\fP
341
342\fBvoid png_set_gamma (png_structp \fP\fIpng_ptr\fP\fB, double \fP\fIscreen_gamma\fP\fB, double \fIdefault_file_gamma\fP\fB);\fP
343
344\fBvoid png_set_gamma_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fP\fIscreen_gamma\fP\fB, png_uint_32 \fIdefault_file_gamma\fP\fB);\fP
345
346\fBvoid png_set_gAMA (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, double \fIfile_gamma\fP\fB);\fP
347
348\fBvoid png_set_gAMA_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fIfile_gamma\fP\fB);\fP
349
350\fBvoid png_set_gray_1_2_4_to_8 (png_structp \fIpng_ptr\fP\fB);\fP
351
352\fBvoid png_set_gray_to_rgb (png_structp \fIpng_ptr\fP\fB);\fP
353
354\fBvoid png_set_eXIf (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_bytep \fIexif\fP\fB);\fP
355
356\fBvoid png_set_eXIf_1 (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fInum_exif\fP\fB, png_bytep \fIexif\fP\fB);\fP
357
358\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
359
360\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
361
362\fBint png_set_interlace_handling (png_structp \fIpng_ptr\fP\fB);\fP
363
364\fBvoid png_set_invalid (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fImask\fP\fB);\fP
365
366\fBvoid png_set_invert_alpha (png_structp \fIpng_ptr\fP\fB);\fP
367
368\fBvoid png_set_invert_mono (png_structp \fIpng_ptr\fP\fB);\fP
369
370\fBvoid png_set_IHDR (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fIwidth\fP\fB, png_uint_32 \fP\fIheight\fP\fB, int \fP\fIbit_depth\fP\fB, int \fP\fIcolor_type\fP\fB, int \fP\fIinterlace_type\fP\fB, int \fP\fIcompression_type\fP\fB, int \fIfilter_type\fP\fB);\fP
371
372\fBvoid png_set_keep_unknown_chunks (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fIkeep\fP\fB, png_bytep \fP\fIchunk_list\fP\fB, int \fInum_chunks\fP\fB);\fP
373
374\fBjmp_buf* png_set_longjmp_fn (png_structp \fP\fIpng_ptr\fP\fB, png_longjmp_ptr \fP\fIlongjmp_fn\fP\fB, size_t \fIjmp_buf_size\fP\fB);\fP
375
376\fBvoid png_set_chunk_malloc_max (png_structp \fP\fIpng_ptr\fP\fB, png_alloc_size_t \fIuser_chunk_cache_max\fP\fB);\fP
377
378\fBvoid png_set_compression_buffer_size (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fIsize\fP\fB);\fP
379
380\fBvoid png_set_mem_fn (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fP\fImem_ptr\fP\fB, png_malloc_ptr \fP\fImalloc_fn\fP\fB, png_free_ptr \fIfree_fn\fP\fB);\fP
381
382\fBvoid png_set_oFFs (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fIoffset_x\fP\fB, png_uint_32 \fP\fIoffset_y\fP\fB, int \fIunit_type\fP\fB);\fP
383
384\fBint png_set_option(png_structrp \fP\fIpng_ptr\fP\fB, int \fP\fIoption\fP\fB, int \fIonoff\fP\fB);\fP
385
386\fBvoid png_set_packing (png_structp \fIpng_ptr\fP\fB);\fP
387
388\fBvoid png_set_packswap (png_structp \fIpng_ptr\fP\fB);\fP
389
390\fBvoid png_set_palette_to_rgb (png_structp \fIpng_ptr\fP\fB);\fP
391
392\fBvoid png_set_pCAL (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_charp \fP\fIpurpose\fP\fB, png_int_32 \fP\fIX0\fP\fB, png_int_32 \fP\fIX1\fP\fB, int \fP\fItype\fP\fB, int \fP\fInparams\fP\fB, png_charp \fP\fIunits\fP\fB, png_charpp \fIparams\fP\fB);\fP
393
394\fBvoid png_set_pHYs (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_uint_32 \fP\fIres_x\fP\fB, png_uint_32 \fP\fIres_y\fP\fB, int \fIunit_type\fP\fB);\fP
395
396\fBvoid png_set_progressive_read_fn (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fP\fIprogressive_ptr\fP\fB, png_progressive_info_ptr \fP\fIinfo_fn\fP\fB, png_progressive_row_ptr \fP\fIrow_fn\fP\fB, png_progressive_end_ptr \fIend_fn\fP\fB);\fP
397
398\fBvoid png_set_PLTE (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_colorp \fP\fIpalette\fP\fB, int \fInum_palette\fP\fB);\fP
399
400\fBvoid png_set_quantize (png_structp \fP\fIpng_ptr\fP\fB, png_colorp \fP\fIpalette\fP\fB, int \fP\fInum_palette\fP\fB, int \fP\fImaximum_colors\fP\fB, png_uint_16p \fP\fIhistogram\fP\fB, int \fIfull_quantize\fP\fB);\fP
401
402\fBvoid png_set_read_fn (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fP\fIio_ptr\fP\fB, png_rw_ptr \fIread_data_fn\fP\fB);\fP
403
404\fBvoid png_set_read_status_fn (png_structp \fP\fIpng_ptr\fP\fB, png_read_status_ptr \fIread_row_fn\fP\fB);\fP
405
406\fBvoid png_set_read_user_chunk_fn (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fP\fIuser_chunk_ptr\fP\fB, png_user_chunk_ptr \fIread_user_chunk_fn\fP\fB);\fP
407
408\fBvoid png_set_read_user_transform_fn (png_structp \fP\fIpng_ptr\fP\fB, png_user_transform_ptr \fIread_user_transform_fn\fP\fB);\fP
409
410\fBvoid png_set_rgb_to_gray (png_structp \fP\fIpng_ptr\fP\fB, int \fP\fIerror_action\fP\fB, double \fP\fIred\fP\fB, double \fIgreen\fP\fB);\fP
411
412\fBvoid png_set_rgb_to_gray_fixed (png_structp \fP\fIpng_ptr\fP\fB, int error_action png_uint_32 \fP\fIred\fP\fB, png_uint_32 \fIgreen\fP\fB);\fP
413
414\fBvoid png_set_rows (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_bytepp \fIrow_pointers\fP\fB);\fP
415
416\fBvoid png_set_sBIT (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_color_8p \fIsig_bit\fP\fB);\fP
417
418\fBvoid png_set_sCAL (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fP\fIunit\fP\fB, double \fP\fIwidth\fP\fB, double \fIheight\fP\fB);\fP
419
420\fBvoid png_set_sCAL_fixed (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fP\fIunit\fP\fB, png_fixed_point \fP\fIwidth\fP\fB, png_fixed_point \fIheight\fP\fB);\fP
421
422\fBvoid png_set_sCAL_s (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fP\fIunit\fP\fB, png_charp \fP\fIwidth\fP\fB, png_charp \fIheight\fP\fB);\fP
423
424\fBvoid png_set_scale_16 (png_structp \fIpng_ptr\fP\fB);\fP
425
426\fBvoid png_set_shift (png_structp \fP\fIpng_ptr\fP\fB, png_color_8p \fItrue_bits\fP\fB);\fP
427
428\fBvoid png_set_sig_bytes (png_structp \fP\fIpng_ptr\fP\fB, int \fInum_bytes\fP\fB);\fP
429
430\fBvoid png_set_sPLT (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_spalette_p \fP\fIsplt_ptr\fP\fB, int \fInum_spalettes\fP\fB);\fP
431
432\fBvoid png_set_sRGB (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fIsrgb_intent\fP\fB);\fP
433
434\fBvoid png_set_sRGB_gAMA_and_cHRM (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fIsrgb_intent\fP\fB);\fP
435
436\fBvoid png_set_strip_16 (png_structp \fIpng_ptr\fP\fB);\fP
437
438\fBvoid png_set_strip_alpha (png_structp \fIpng_ptr\fP\fB);\fP
439
440\fBvoid png_set_strip_error_numbers (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fIstrip_mode\fP\fB);\fP
441
442\fBvoid png_set_swap (png_structp \fIpng_ptr\fP\fB);\fP
443
444\fBvoid png_set_swap_alpha (png_structp \fIpng_ptr\fP\fB);\fP
445
446\fBvoid png_set_text (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_textp \fP\fItext_ptr\fP\fB, int \fInum_text\fP\fB);\fP
447
448\fBvoid png_set_text_compression_level (png_structp \fP\fIpng_ptr\fP\fB, int \fIlevel\fP\fB);\fP
449
450\fBvoid png_set_text_compression_mem_level (png_structp \fP\fIpng_ptr\fP\fB, int \fImem_level\fP\fB);\fP
451
452\fBvoid png_set_text_compression_strategy (png_structp \fP\fIpng_ptr\fP\fB, int \fIstrategy\fP\fB);\fP
453
454\fBvoid png_set_text_compression_window_bits (png_structp \fP\fIpng_ptr\fP\fB, int \fIwindow_bits\fP\fB);\fP
455
456\fBvoid png_set_text_compression_method (png_structp \fP\fIpng_ptr\fP\fB, int \fImethod\fP\fB);\fP
457
458\fBvoid png_set_tIME (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_timep \fImod_time\fP\fB);\fP
459
460\fBvoid png_set_tRNS (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_bytep \fP\fItrans_alpha\fP\fB, int \fP\fInum_trans\fP\fB, png_color_16p \fItrans_color\fP\fB);\fP
461
462\fBvoid png_set_tRNS_to_alpha (png_structp \fIpng_ptr\fP\fB);\fP
463
464\fBpng_uint_32 png_set_unknown_chunks (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, png_unknown_chunkp \fP\fIunknowns\fP\fB, int \fP\fInum\fP\fB, int \fIlocation\fP\fB);\fP
465
466\fBvoid png_set_unknown_chunk_location (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fP\fIchunk\fP\fB, int \fIlocation\fP\fB);\fP
467
468\fBvoid png_set_user_limits (png_structp \fP\fIpng_ptr\fP\fB, png_uint_32 \fP\fIuser_width_max\fP\fB, png_uint_32 \fIuser_height_max\fP\fB);\fP
469
470\fBvoid png_set_user_transform_info (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fP\fIuser_transform_ptr\fP\fB, int \fP\fIuser_transform_depth\fP\fB, int \fIuser_transform_channels\fP\fB);\fP
471
472\fBvoid png_set_write_fn (png_structp \fP\fIpng_ptr\fP\fB, png_voidp \fP\fIio_ptr\fP\fB, png_rw_ptr \fP\fIwrite_data_fn\fP\fB, png_flush_ptr \fIoutput_flush_fn\fP\fB);\fP
473
474\fBvoid png_set_write_status_fn (png_structp \fP\fIpng_ptr\fP\fB, png_write_status_ptr \fIwrite_row_fn\fP\fB);\fP
475
476\fBvoid png_set_write_user_transform_fn (png_structp \fP\fIpng_ptr\fP\fB, png_user_transform_ptr \fIwrite_user_transform_fn\fP\fB);\fP
477
478\fBint png_sig_cmp (png_bytep \fP\fIsig\fP\fB, size_t \fP\fIstart\fP\fB, size_t \fInum_to_check\fP\fB);\fP
479
480\fBvoid png_start_read_image (png_structp \fIpng_ptr\fP\fB);\fP
481
482\fBvoid png_warning (png_structp \fP\fIpng_ptr\fP\fB, png_const_charp \fImessage\fP\fB);\fP
483
484\fBvoid png_write_chunk (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fP\fIchunk_name\fP\fB, png_bytep \fP\fIdata\fP\fB, size_t \fIlength\fP\fB);\fP
485
486\fBvoid png_write_chunk_data (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fP\fIdata\fP\fB, size_t \fIlength\fP\fB);\fP
487
488\fBvoid png_write_chunk_end (png_structp \fIpng_ptr\fP\fB);\fP
489
490\fBvoid png_write_chunk_start (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fP\fIchunk_name\fP\fB, png_uint_32 \fIlength\fP\fB);\fP
491
492\fBvoid png_write_end (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fIinfo_ptr\fP\fB);\fP
493
494\fBvoid png_write_flush (png_structp \fIpng_ptr\fP\fB);\fP
495
496\fBvoid png_write_image (png_structp \fP\fIpng_ptr\fP\fB, png_bytepp \fIimage\fP\fB);\fP
497
498\fBvoid png_write_info (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fIinfo_ptr\fP\fB);\fP
499
500\fBvoid png_write_info_before_PLTE (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fIinfo_ptr\fP\fB);\fP
501
502\fBvoid png_write_png (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, int \fP\fItransforms\fP\fB, png_voidp \fIparams\fP\fB);\fP
503
504\fBvoid png_write_row (png_structp \fP\fIpng_ptr\fP\fB, png_bytep \fIrow\fP\fB);\fP
505
506\fBvoid png_write_rows (png_structp \fP\fIpng_ptr\fP\fB, png_bytepp \fP\fIrow\fP\fB, png_uint_32 \fInum_rows\fP\fB);\fP
507
508\fBvoid png_write_sig (png_structp \fIpng_ptr\fP\fB);\fP
509
510.SH DESCRIPTION
511The
512.I libpng
513library supports encoding, decoding, and various manipulations of
514the Portable Network Graphics (PNG) format image files. It uses the
515.IR zlib(3)
516compression library.
517Following is a copy of the libpng-manual.txt file that accompanies libpng.
518
519.SH LIBPNG.TXT
520libpng-manual.txt - A description on how to use and modify libpng
521
522 Copyright (c) 2018-2019 Cosmin Truta
523 Copyright (c) 1998-2018 Glenn Randers-Pehrson
524
525 This document is released under the libpng license.
526 For conditions of distribution and use, see the disclaimer
527 and license in png.h
528
529 Based on:
530
531 libpng version 1.6.36, December 2018, through 1.6.37 - April 2019
532 Updated and distributed by Cosmin Truta
533 Copyright (c) 2018-2019 Cosmin Truta
534
535 libpng versions 0.97, January 1998, through 1.6.35 - July 2018
536 Updated and distributed by Glenn Randers-Pehrson
537 Copyright (c) 1998-2018 Glenn Randers-Pehrson
538
539 libpng 1.0 beta 6 - version 0.96 - May 28, 1997
540 Updated and distributed by Andreas Dilger
541 Copyright (c) 1996, 1997 Andreas Dilger
542
543 libpng 1.0 beta 2 - version 0.88 - January 26, 1996
544 For conditions of distribution and use, see copyright
545 notice in png.h. Copyright (c) 1995, 1996 Guy Eric
546 Schalnat, Group 42, Inc.
547
548 Updated/rewritten per request in the libpng FAQ
549 Copyright (c) 1995, 1996 Frank J. T. Wojcik
550 December 18, 1995 & January 20, 1996
551
552 TABLE OF CONTENTS
553
554 I. Introduction
555 II. Structures
556 III. Reading
557 IV. Writing
558 V. Simplified API
559 VI. Modifying/Customizing libpng
560 VII. MNG support
561 VIII. Changes to Libpng from version 0.88
562 IX. Changes to Libpng from version 1.0.x to 1.2.x
563 X. Changes to Libpng from version 1.0.x/1.2.x to 1.4.x
564 XI. Changes to Libpng from version 1.4.x to 1.5.x
565 XII. Changes to Libpng from version 1.5.x to 1.6.x
566 XIII. Detecting libpng
567 XIV. Source code repository
568 XV. Coding style
569
570.SH I. Introduction
571
572This file describes how to use and modify the PNG reference library
573(known as libpng) for your own use. In addition to this
574file, example.c is a good starting point for using the library, as
575it is heavily commented and should include everything most people
576will need. We assume that libpng is already installed; see the
577INSTALL file for instructions on how to configure and install libpng.
578
579For examples of libpng usage, see the files "example.c", "pngtest.c",
580and the files in the "contrib" directory, all of which are included in
581the libpng distribution.
582
583Libpng was written as a companion to the PNG specification, as a way
584of reducing the amount of time and effort it takes to support the PNG
585file format in application programs.
586
587The PNG specification (second edition), November 2003, is available as
588a W3C Recommendation and as an ISO Standard (ISO/IEC 15948:2004 (E)) at
589<https://www.w3.org/TR/2003/REC-PNG-20031110/>.
590The W3C and ISO documents have identical technical content.
591
592The PNG-1.2 specification is available at
593<https://png-mng.sourceforge.io/pub/png/spec/1.2/>.
594It is technically equivalent
595to the PNG specification (second edition) but has some additional material.
596
597The PNG-1.0 specification is available as RFC 2083 at
598<https://png-mng.sourceforge.io/pub/png/spec/1.0/> and as a
599W3C Recommendation at <https://www.w3.org/TR/REC-png-961001>.
600
601Some additional chunks are described in the special-purpose public chunks
602documents at <http://www.libpng.org/pub/png/spec/register/>
603
604Other information
605about PNG, and the latest version of libpng, can be found at the PNG home
606page, <http://www.libpng.org/pub/png/>.
607
608Most users will not have to modify the library significantly; advanced
609users may want to modify it more. All attempts were made to make it as
610complete as possible, while keeping the code easy to understand.
611Currently, this library only supports C. Support for other languages
612is being considered.
613
614Libpng has been designed to handle multiple sessions at one time,
615to be easily modifiable, to be portable to the vast majority of
616machines (ANSI, K&R, 16-, 32-, and 64-bit) available, and to be easy
617to use. The ultimate goal of libpng is to promote the acceptance of
618the PNG file format in whatever way possible. While there is still
619work to be done (see the TODO file), libpng should cover the
620majority of the needs of its users.
621
622Libpng uses zlib for its compression and decompression of PNG files.
623Further information about zlib, and the latest version of zlib, can
624be found at the zlib home page, <https://zlib.net/>.
625The zlib compression utility is a general purpose utility that is
626useful for more than PNG files, and can be used without libpng.
627See the documentation delivered with zlib for more details.
628You can usually find the source files for the zlib utility wherever you
629find the libpng source files.
630
631Libpng is thread safe, provided the threads are using different
632instances of the structures. Each thread should have its own
633png_struct and png_info instances, and thus its own image.
634Libpng does not protect itself against two threads using the
635same instance of a structure.
636
637.SH II. Structures
638
639There are two main structures that are important to libpng, png_struct
640and png_info. Both are internal structures that are no longer exposed
641in the libpng interface (as of libpng 1.5.0).
642
643The png_info structure is designed to provide information about the
644PNG file. At one time, the fields of png_info were intended to be
645directly accessible to the user. However, this tended to cause problems
646with applications using dynamically loaded libraries, and as a result
647a set of interface functions for png_info (the png_get_*() and png_set_*()
648functions) was developed, and direct access to the png_info fields was
649deprecated..
650
651The png_struct structure is the object used by the library to decode a
652single image. As of 1.5.0 this structure is also not exposed.
653
654Almost all libpng APIs require a pointer to a png_struct as the first argument.
655Many (in particular the png_set and png_get APIs) also require a pointer
656to png_info as the second argument. Some application visible macros
657defined in png.h designed for basic data access (reading and writing
658integers in the PNG format) don't take a png_info pointer, but it's almost
659always safe to assume that a (png_struct*) has to be passed to call an API
660function.
661
662You can have more than one png_info structure associated with an image,
663as illustrated in pngtest.c, one for information valid prior to the
664IDAT chunks and another (called "end_info" below) for things after them.
665
666The png.h header file is an invaluable reference for programming with libpng.
667And while I'm on the topic, make sure you include the libpng header file:
668
669#include <png.h>
670
671and also (as of libpng-1.5.0) the zlib header file, if you need it:
672
673#include <zlib.h>
674
675.SS Types
676
677The png.h header file defines a number of integral types used by the
678APIs. Most of these are fairly obvious; for example types corresponding
679to integers of particular sizes and types for passing color values.
680
681One exception is how non-integral numbers are handled. For application
682convenience most APIs that take such numbers have C (double) arguments;
683however, internally PNG, and libpng, use 32 bit signed integers and encode
684the value by multiplying by 100,000. As of libpng 1.5.0 a convenience
685macro PNG_FP_1 is defined in png.h along with a type (png_fixed_point)
686which is simply (png_int_32).
687
688All APIs that take (double) arguments also have a matching API that
689takes the corresponding fixed point integer arguments. The fixed point
690API has the same name as the floating point one with "_fixed" appended.
691The actual range of values permitted in the APIs is frequently less than
692the full range of (png_fixed_point) (\-21474 to +21474). When APIs require
693a non-negative argument the type is recorded as png_uint_32 above. Consult
694the header file and the text below for more information.
695
696Special care must be take with sCAL chunk handling because the chunk itself
697uses non-integral values encoded as strings containing decimal floating point
698numbers. See the comments in the header file.
699
700.SS Configuration
701
702The main header file function declarations are frequently protected by C
703preprocessing directives of the form:
704
705 #ifdef PNG_feature_SUPPORTED
706 declare-function
707 #endif
708 ...
709 #ifdef PNG_feature_SUPPORTED
710 use-function
711 #endif
712
713The library can be built without support for these APIs, although a
714standard build will have all implemented APIs. Application programs
715should check the feature macros before using an API for maximum
716portability. From libpng 1.5.0 the feature macros set during the build
717of libpng are recorded in the header file "pnglibconf.h" and this file
718is always included by png.h.
719
720If you don't need to change the library configuration from the default, skip to
721the next section ("Reading").
722
723Notice that some of the makefiles in the 'scripts' directory and (in 1.5.0) all
724of the build project files in the 'projects' directory simply copy
725scripts/pnglibconf.h.prebuilt to pnglibconf.h. This means that these build
726systems do not permit easy auto-configuration of the library - they only
727support the default configuration.
728
729The easiest way to make minor changes to the libpng configuration when
730auto-configuration is supported is to add definitions to the command line
731using (typically) CPPFLAGS. For example:
732
733CPPFLAGS=\-DPNG_NO_FLOATING_ARITHMETIC
734
735will change the internal libpng math implementation for gamma correction and
736other arithmetic calculations to fixed point, avoiding the need for fast
737floating point support. The result can be seen in the generated pnglibconf.h -
738make sure it contains the changed feature macro setting.
739
740If you need to make more extensive configuration changes - more than one or two
741feature macro settings - you can either add \-DPNG_USER_CONFIG to the build
742command line and put a list of feature macro settings in pngusr.h or you can set
743DFA_XTRA (a makefile variable) to a file containing the same information in the
744form of 'option' settings.
745
746A. Changing pnglibconf.h
747
748A variety of methods exist to build libpng. Not all of these support
749reconfiguration of pnglibconf.h. To reconfigure pnglibconf.h it must either be
750rebuilt from scripts/pnglibconf.dfa using awk or it must be edited by hand.
751
752Hand editing is achieved by copying scripts/pnglibconf.h.prebuilt to
753pnglibconf.h and changing the lines defining the supported features, paying
754very close attention to the 'option' information in scripts/pnglibconf.dfa
755that describes those features and their requirements. This is easy to get
756wrong.
757
758B. Configuration using DFA_XTRA
759
760Rebuilding from pnglibconf.dfa is easy if a functioning 'awk', or a later
761variant such as 'nawk' or 'gawk', is available. The configure build will
762automatically find an appropriate awk and build pnglibconf.h.
763The scripts/pnglibconf.mak file contains a set of make rules for doing the
764same thing if configure is not used, and many of the makefiles in the scripts
765directory use this approach.
766
767When rebuilding simply write a new file containing changed options and set
768DFA_XTRA to the name of this file. This causes the build to append the new file
769to the end of scripts/pnglibconf.dfa. The pngusr.dfa file should contain lines
770of the following forms:
771
772everything = off
773
774This turns all optional features off. Include it at the start of pngusr.dfa to
775make it easier to build a minimal configuration. You will need to turn at least
776some features on afterward to enable either reading or writing code, or both.
777
778option feature on
779option feature off
780
781Enable or disable a single feature. This will automatically enable other
782features required by a feature that is turned on or disable other features that
783require a feature which is turned off. Conflicting settings will cause an error
784message to be emitted by awk.
785
786setting feature default value
787
788Changes the default value of setting 'feature' to 'value'. There are a small
789number of settings listed at the top of pnglibconf.h, they are documented in the
790source code. Most of these values have performance implications for the library
791but most of them have no visible effect on the API. Some can also be overridden
792from the API.
793
794This method of building a customized pnglibconf.h is illustrated in
795contrib/pngminim/*. See the "$(PNGCONF):" target in the makefile and
796pngusr.dfa in these directories.
797
798C. Configuration using PNG_USER_CONFIG
799
800If \-DPNG_USER_CONFIG is added to the CPPFLAGS when pnglibconf.h is built,
801the file pngusr.h will automatically be included before the options in
802scripts/pnglibconf.dfa are processed. Your pngusr.h file should contain only
803macro definitions turning features on or off or setting settings.
804
805Apart from the global setting "everything = off" all the options listed above
806can be set using macros in pngusr.h:
807
808#define PNG_feature_SUPPORTED
809
810is equivalent to:
811
812option feature on
813
814#define PNG_NO_feature
815
816is equivalent to:
817
818option feature off
819
820#define PNG_feature value
821
822is equivalent to:
823
824setting feature default value
825
826Notice that in both cases, pngusr.dfa and pngusr.h, the contents of the
827pngusr file you supply override the contents of scripts/pnglibconf.dfa
828
829If confusing or incomprehensible behavior results it is possible to
830examine the intermediate file pnglibconf.dfn to find the full set of
831dependency information for each setting and option. Simply locate the
832feature in the file and read the C comments that precede it.
833
834This method is also illustrated in the contrib/pngminim/* makefiles and
835pngusr.h.
836
837.SH III. Reading
838
839We'll now walk you through the possible functions to call when reading
840in a PNG file sequentially, briefly explaining the syntax and purpose
841of each one. See example.c and png.h for more detail. While
842progressive reading is covered in the next section, you will still
843need some of the functions discussed in this section to read a PNG
844file.
845
846.SS Setup
847
848You will want to do the I/O initialization(*) before you get into libpng,
849so if it doesn't work, you don't have much to undo. Of course, you
850will also want to insure that you are, in fact, dealing with a PNG
851file. Libpng provides a simple check to see if a file is a PNG file.
852To use it, pass in the first 1 to 8 bytes of the file to the function
853png_sig_cmp(), and it will return 0 (false) if the bytes match the
854corresponding bytes of the PNG signature, or nonzero (true) otherwise.
855Of course, the more bytes you pass in, the greater the accuracy of the
856prediction.
857
858If you are intending to keep the file pointer open for use in libpng,
859you must ensure you don't read more than 8 bytes from the beginning
860of the file, and you also have to make a call to png_set_sig_bytes()
861with the number of bytes you read from the beginning. Libpng will
862then only check the bytes (if any) that your program didn't read.
863
864(*): If you are not using the standard I/O functions, you will need
865to replace them with custom functions. See the discussion under
866Customizing libpng.
867
868 FILE *fp = fopen(file_name, "rb");
869 if (!fp)
870 {
871 return ERROR;
872 }
873
874 if (fread(header, 1, number, fp) != number)
875 {
876 return ERROR;
877 }
878
879 is_png = !png_sig_cmp(header, 0, number);
880 if (!is_png)
881 {
882 return NOT_PNG;
883 }
884
885Next, png_struct and png_info need to be allocated and initialized. In
886order to ensure that the size of these structures is correct even with a
887dynamically linked libpng, there are functions to initialize and
888allocate the structures. We also pass the library version, optional
889pointers to error handling functions, and a pointer to a data struct for
890use by the error functions, if necessary (the pointer and functions can
891be NULL if the default error handlers are to be used). See the section
892on Changes to Libpng below regarding the old initialization functions.
893The structure allocation functions quietly return NULL if they fail to
894create the structure, so your application should check for that.
895
896 png_structp png_ptr = png_create_read_struct
897 (PNG_LIBPNG_VER_STRING, (png_voidp)user_error_ptr,
898 user_error_fn, user_warning_fn);
899
900 if (!png_ptr)
901 return ERROR;
902
903 png_infop info_ptr = png_create_info_struct(png_ptr);
904
905 if (!info_ptr)
906 {
907 png_destroy_read_struct(&png_ptr,
908 (png_infopp)NULL, (png_infopp)NULL);
909 return ERROR;
910 }
911
912If you want to use your own memory allocation routines,
913use a libpng that was built with PNG_USER_MEM_SUPPORTED defined, and use
914png_create_read_struct_2() instead of png_create_read_struct():
915
916 png_structp png_ptr = png_create_read_struct_2
917 (PNG_LIBPNG_VER_STRING, (png_voidp)user_error_ptr,
918 user_error_fn, user_warning_fn, (png_voidp)
919 user_mem_ptr, user_malloc_fn, user_free_fn);
920
921The error handling routines passed to png_create_read_struct()
922and the memory alloc/free routines passed to png_create_struct_2()
923are only necessary if you are not using the libpng supplied error
924handling and memory alloc/free functions.
925
926When libpng encounters an error, it expects to longjmp back
927to your routine. Therefore, you will need to call setjmp and pass
928your png_jmpbuf(png_ptr). If you read the file from different
929routines, you will need to update the longjmp buffer every time you enter
930a new routine that will call a png_*() function.
931
932See your documentation of setjmp/longjmp for your compiler for more
933information on setjmp/longjmp. See the discussion on libpng error
934handling in the Customizing Libpng section below for more information
935on the libpng error handling. If an error occurs, and libpng longjmp's
936back to your setjmp, you will want to call png_destroy_read_struct() to
937free any memory.
938
939 if (setjmp(png_jmpbuf(png_ptr)))
940 {
941 png_destroy_read_struct(&png_ptr, &info_ptr,
942 &end_info);
943 fclose(fp);
944 return ERROR;
945 }
946
947Pass (png_infopp)NULL instead of &end_info if you didn't create
948an end_info structure.
949
950If you would rather avoid the complexity of setjmp/longjmp issues,
951you can compile libpng with PNG_NO_SETJMP, in which case
952errors will result in a call to PNG_ABORT() which defaults to abort().
953
954You can #define PNG_ABORT() to a function that does something
955more useful than abort(), as long as your function does not
956return.
957
958Now you need to set up the input code. The default for libpng is to
959use the C function fread(). If you use this, you will need to pass a
960valid FILE * in the function png_init_io(). Be sure that the file is
961opened in binary mode. If you wish to handle reading data in another
962way, you need not call the png_init_io() function, but you must then
963implement the libpng I/O methods discussed in the Customizing Libpng
964section below.
965
966 png_init_io(png_ptr, fp);
967
968If you had previously opened the file and read any of the signature from
969the beginning in order to see if this was a PNG file, you need to let
970libpng know that there are some bytes missing from the start of the file.
971
972 png_set_sig_bytes(png_ptr, number);
973
974You can change the zlib compression buffer size to be used while
975reading compressed data with
976
977 png_set_compression_buffer_size(png_ptr, buffer_size);
978
979where the default size is 8192 bytes. Note that the buffer size
980is changed immediately and the buffer is reallocated immediately,
981instead of setting a flag to be acted upon later.
982
983If you want CRC errors to be handled in a different manner than
984the default, use
985
986 png_set_crc_action(png_ptr, crit_action, ancil_action);
987
988The values for png_set_crc_action() say how libpng is to handle CRC errors in
989ancillary and critical chunks, and whether to use the data contained
990therein. Starting with libpng-1.6.26, this also governs how an ADLER32 error
991is handled while reading the IDAT chunk. Note that it is impossible to
992"discard" data in a critical chunk.
993
994Choices for (int) crit_action are
995 PNG_CRC_DEFAULT 0 error/quit
996 PNG_CRC_ERROR_QUIT 1 error/quit
997 PNG_CRC_WARN_USE 3 warn/use data
998 PNG_CRC_QUIET_USE 4 quiet/use data
999 PNG_CRC_NO_CHANGE 5 use the current value
1000
1001Choices for (int) ancil_action are
1002 PNG_CRC_DEFAULT 0 error/quit
1003 PNG_CRC_ERROR_QUIT 1 error/quit
1004 PNG_CRC_WARN_DISCARD 2 warn/discard data
1005 PNG_CRC_WARN_USE 3 warn/use data
1006 PNG_CRC_QUIET_USE 4 quiet/use data
1007 PNG_CRC_NO_CHANGE 5 use the current value
1008
1009When the setting for crit_action is PNG_CRC_QUIET_USE, the CRC and ADLER32
1010checksums are not only ignored, but they are not evaluated.
1011
1012.SS Setting up callback code
1013
1014You can set up a callback function to handle any unknown chunks in the
1015input stream. You must supply the function
1016
1017 read_chunk_callback(png_structp png_ptr,
1018 png_unknown_chunkp chunk);
1019 {
1020 /* The unknown chunk structure contains your
1021 chunk data, along with similar data for any other
1022 unknown chunks: */
1023
1024 png_byte name[5];
1025 png_byte *data;
1026 size_t size;
1027
1028 /* Note that libpng has already taken care of
1029 the CRC handling */
1030
1031 /* put your code here. Search for your chunk in the
1032 unknown chunk structure, process it, and return one
1033 of the following: */
1034
1035 return \-n; /* chunk had an error */
1036 return 0; /* did not recognize */
1037 return n; /* success */
1038 }
1039
1040(You can give your function another name that you like instead of
1041"read_chunk_callback")
1042
1043To inform libpng about your function, use
1044
1045 png_set_read_user_chunk_fn(png_ptr, user_chunk_ptr,
1046 read_chunk_callback);
1047
1048This names not only the callback function, but also a user pointer that
1049you can retrieve with
1050
1051 png_get_user_chunk_ptr(png_ptr);
1052
1053If you call the png_set_read_user_chunk_fn() function, then all unknown
1054chunks which the callback does not handle will be saved when read. You can
1055cause them to be discarded by returning '1' ("handled") instead of '0'. This
1056behavior will change in libpng 1.7 and the default handling set by the
1057png_set_keep_unknown_chunks() function, described below, will be used when the
1058callback returns 0. If you want the existing behavior you should set the global
1059default to PNG_HANDLE_CHUNK_IF_SAFE now; this is compatible with all current
1060versions of libpng and with 1.7. Libpng 1.6 issues a warning if you keep the
1061default, or PNG_HANDLE_CHUNK_NEVER, and the callback returns 0.
1062
1063At this point, you can set up a callback function that will be
1064called after each row has been read, which you can use to control
1065a progress meter or the like. It's demonstrated in pngtest.c.
1066You must supply a function
1067
1068 void read_row_callback(png_structp png_ptr,
1069 png_uint_32 row, int pass);
1070 {
1071 /* put your code here */
1072 }
1073
1074(You can give it another name that you like instead of "read_row_callback")
1075
1076To inform libpng about your function, use
1077
1078 png_set_read_status_fn(png_ptr, read_row_callback);
1079
1080When this function is called the row has already been completely processed and
1081the 'row' and 'pass' refer to the next row to be handled. For the
1082non-interlaced case the row that was just handled is simply one less than the
1083passed in row number, and pass will always be 0. For the interlaced case the
1084same applies unless the row value is 0, in which case the row just handled was
1085the last one from one of the preceding passes. Because interlacing may skip a
1086pass you cannot be sure that the preceding pass is just 'pass\-1'; if you really
1087need to know what the last pass is record (row,pass) from the callback and use
1088the last recorded value each time.
1089
1090As with the user transform you can find the output row using the
1091PNG_ROW_FROM_PASS_ROW macro.
1092
1093.SS Unknown-chunk handling
1094
1095Now you get to set the way the library processes unknown chunks in the
1096input PNG stream. Both known and unknown chunks will be read. Normal
1097behavior is that known chunks will be parsed into information in
1098various info_ptr members while unknown chunks will be discarded. This
1099behavior can be wasteful if your application will never use some known
1100chunk types. To change this, you can call:
1101
1102 png_set_keep_unknown_chunks(png_ptr, keep,
1103 chunk_list, num_chunks);
1104
1105 keep - 0: default unknown chunk handling
1106 1: ignore; do not keep
1107 2: keep only if safe-to-copy
1108 3: keep even if unsafe-to-copy
1109
1110 You can use these definitions:
1111 PNG_HANDLE_CHUNK_AS_DEFAULT 0
1112 PNG_HANDLE_CHUNK_NEVER 1
1113 PNG_HANDLE_CHUNK_IF_SAFE 2
1114 PNG_HANDLE_CHUNK_ALWAYS 3
1115
1116 chunk_list - list of chunks affected (a byte string,
1117 five bytes per chunk, NULL or '\0' if
1118 num_chunks is positive; ignored if
1119 numchunks <= 0).
1120
1121 num_chunks - number of chunks affected; if 0, all
1122 unknown chunks are affected. If positive,
1123 only the chunks in the list are affected,
1124 and if negative all unknown chunks and
1125 all known chunks except for the IHDR,
1126 PLTE, tRNS, IDAT, and IEND chunks are
1127 affected.
1128
1129Unknown chunks declared in this way will be saved as raw data onto a
1130list of png_unknown_chunk structures. If a chunk that is normally
1131known to libpng is named in the list, it will be handled as unknown,
1132according to the "keep" directive. If a chunk is named in successive
1133instances of png_set_keep_unknown_chunks(), the final instance will
1134take precedence. The IHDR and IEND chunks should not be named in
1135chunk_list; if they are, libpng will process them normally anyway.
1136If you know that your application will never make use of some particular
1137chunks, use PNG_HANDLE_CHUNK_NEVER (or 1) as demonstrated below.
1138
1139Here is an example of the usage of png_set_keep_unknown_chunks(),
1140where the private "vpAg" chunk will later be processed by a user chunk
1141callback function:
1142
1143 png_byte vpAg[5]={118, 112, 65, 103, (png_byte) '\0'};
1144
1145 #if defined(PNG_UNKNOWN_CHUNKS_SUPPORTED)
1146 png_byte unused_chunks[]=
1147 {
1148 104, 73, 83, 84, (png_byte) '\0', /* hIST */
1149 105, 84, 88, 116, (png_byte) '\0', /* iTXt */
1150 112, 67, 65, 76, (png_byte) '\0', /* pCAL */
1151 115, 67, 65, 76, (png_byte) '\0', /* sCAL */
1152 115, 80, 76, 84, (png_byte) '\0', /* sPLT */
1153 116, 73, 77, 69, (png_byte) '\0', /* tIME */
1154 };
1155 #endif
1156
1157 ...
1158
1159 #if defined(PNG_UNKNOWN_CHUNKS_SUPPORTED)
1160 /* ignore all unknown chunks
1161 * (use global setting "2" for libpng16 and earlier):
1162 */
1163 png_set_keep_unknown_chunks(read_ptr, 2, NULL, 0);
1164
1165 /* except for vpAg: */
1166 png_set_keep_unknown_chunks(read_ptr, 2, vpAg, 1);
1167
1168 /* also ignore unused known chunks: */
1169 png_set_keep_unknown_chunks(read_ptr, 1, unused_chunks,
1170 (int)(sizeof unused_chunks)/5);
1171 #endif
1172
1173.SS User limits
1174
1175The PNG specification allows the width and height of an image to be as
1176large as 2^(31\-1 (0x7fffffff), or about 2.147 billion rows and columns.
1177For safety, libpng imposes a default limit of 1 million rows and columns.
1178Larger images will be rejected immediately with a png_error() call. If
1179you wish to change these limits, you can use
1180
1181 png_set_user_limits(png_ptr, width_max, height_max);
1182
1183to set your own limits (libpng may reject some very wide images
1184anyway because of potential buffer overflow conditions).
1185
1186You should put this statement after you create the PNG structure and
1187before calling png_read_info(), png_read_png(), or png_process_data().
1188
1189When writing a PNG datastream, put this statement before calling
1190png_write_info() or png_write_png().
1191
1192If you need to retrieve the limits that are being applied, use
1193
1194 width_max = png_get_user_width_max(png_ptr);
1195 height_max = png_get_user_height_max(png_ptr);
1196
1197The PNG specification sets no limit on the number of ancillary chunks
1198allowed in a PNG datastream. By default, libpng imposes a limit of
1199a total of 1000 sPLT, tEXt, iTXt, zTXt, and unknown chunks to be stored.
1200If you have set up both info_ptr and end_info_ptr, the limit applies
1201separately to each. You can change the limit on the total number of such
1202chunks that will be stored, with
1203
1204 png_set_chunk_cache_max(png_ptr, user_chunk_cache_max);
1205
1206where 0x7fffffffL means unlimited. You can retrieve this limit with
1207
1208 chunk_cache_max = png_get_chunk_cache_max(png_ptr);
1209
1210Libpng imposes a limit of 8 Megabytes (8,000,000 bytes) on the amount of
1211memory that any chunk other than IDAT can occupy, originally or when
1212decompressed (prior to libpng-1.6.32 the limit was only applied to compressed
1213chunks after decompression). You can change this limit with
1214
1215 png_set_chunk_malloc_max(png_ptr, user_chunk_malloc_max);
1216
1217and you can retrieve the limit with
1218
1219 chunk_malloc_max = png_get_chunk_malloc_max(png_ptr);
1220
1221Any chunks that would cause either of these limits to be exceeded will
1222be ignored.
1223
1224.SS Information about your system
1225
1226If you intend to display the PNG or to incorporate it in other image data you
1227need to tell libpng information about your display or drawing surface so that
1228libpng can convert the values in the image to match the display.
1229
1230From libpng-1.5.4 this information can be set before reading the PNG file
1231header. In earlier versions png_set_gamma() existed but behaved incorrectly if
1232called before the PNG file header had been read and png_set_alpha_mode() did not
1233exist.
1234
1235If you need to support versions prior to libpng-1.5.4 test the version number
1236as illustrated below using "PNG_LIBPNG_VER >= 10504" and follow the procedures
1237described in the appropriate manual page.
1238
1239You give libpng the encoding expected by your system expressed as a 'gamma'
1240value. You can also specify a default encoding for the PNG file in
1241case the required information is missing from the file. By default libpng
1242assumes that the PNG data matches your system, to keep this default call:
1243
1244 png_set_gamma(png_ptr, screen_gamma, output_gamma);
1245
1246or you can use the fixed point equivalent:
1247
1248 png_set_gamma_fixed(png_ptr, PNG_FP_1*screen_gamma,
1249 PNG_FP_1*output_gamma);
1250
1251If you don't know the gamma for your system it is probably 2.2 - a good
1252approximation to the IEC standard for display systems (sRGB). If images are
1253too contrasty or washed out you got the value wrong - check your system
1254documentation!
1255
1256Many systems permit the system gamma to be changed via a lookup table in the
1257display driver, a few systems, including older Macs, change the response by
1258default. As of 1.5.4 three special values are available to handle common
1259situations:
1260
1261 PNG_DEFAULT_sRGB: Indicates that the system conforms to the
1262 IEC 61966-2-1 standard. This matches almost
1263 all systems.
1264 PNG_GAMMA_MAC_18: Indicates that the system is an older
1265 (pre Mac OS 10.6) Apple Macintosh system with
1266 the default settings.
1267 PNG_GAMMA_LINEAR: Just the fixed point value for 1.0 - indicates
1268 that the system expects data with no gamma
1269 encoding.
1270
1271You would use the linear (unencoded) value if you need to process the pixel
1272values further because this avoids the need to decode and re-encode each
1273component value whenever arithmetic is performed. A lot of graphics software
1274uses linear values for this reason, often with higher precision component values
1275to preserve overall accuracy.
1276
1277
1278The output_gamma value expresses how to decode the output values, not how
1279they are encoded. The values used correspond to the normal numbers used to
1280describe the overall gamma of a computer display system; for example 2.2 for
1281an sRGB conformant system. The values are scaled by 100000 in the _fixed
1282version of the API (so 220000 for sRGB.)
1283
1284The inverse of the value is always used to provide a default for the PNG file
1285encoding if it has no gAMA chunk and if png_set_gamma() has not been called
1286to override the PNG gamma information.
1287
1288When the ALPHA_OPTIMIZED mode is selected the output gamma is used to encode
1289opaque pixels however pixels with lower alpha values are not encoded,
1290regardless of the output gamma setting.
1291
1292When the standard Porter Duff handling is requested with mode 1 the output
1293encoding is set to be linear and the output_gamma value is only relevant
1294as a default for input data that has no gamma information. The linear output
1295encoding will be overridden if png_set_gamma() is called - the results may be
1296highly unexpected!
1297
1298The following numbers are derived from the sRGB standard and the research
1299behind it. sRGB is defined to be approximated by a PNG gAMA chunk value of
13000.45455 (1/2.2) for PNG. The value implicitly includes any viewing
1301correction required to take account of any differences in the color
1302environment of the original scene and the intended display environment; the
1303value expresses how to *decode* the image for display, not how the original
1304data was *encoded*.
1305
1306sRGB provides a peg for the PNG standard by defining a viewing environment.
1307sRGB itself, and earlier TV standards, actually use a more complex transform
1308(a linear portion then a gamma 2.4 power law) than PNG can express. (PNG is
1309limited to simple power laws.) By saying that an image for direct display on
1310an sRGB conformant system should be stored with a gAMA chunk value of 45455
1311(11.3.3.2 and 11.3.3.5 of the ISO PNG specification) the PNG specification
1312makes it possible to derive values for other display systems and
1313environments.
1314
1315The Mac value is deduced from the sRGB based on an assumption that the actual
1316extra viewing correction used in early Mac display systems was implemented as
1317a power 1.45 lookup table.
1318
1319Any system where a programmable lookup table is used or where the behavior of
1320the final display device characteristics can be changed requires system
1321specific code to obtain the current characteristic. However this can be
1322difficult and most PNG gamma correction only requires an approximate value.
1323
1324By default, if png_set_alpha_mode() is not called, libpng assumes that all
1325values are unencoded, linear, values and that the output device also has a
1326linear characteristic. This is only very rarely correct - it is invariably
1327better to call png_set_alpha_mode() with PNG_DEFAULT_sRGB than rely on the
1328default if you don't know what the right answer is!
1329
1330The special value PNG_GAMMA_MAC_18 indicates an older Mac system (pre Mac OS
133110.6) which used a correction table to implement a somewhat lower gamma on an
1332otherwise sRGB system.
1333
1334Both these values are reserved (not simple gamma values) in order to allow
1335more precise correction internally in the future.
1336
1337NOTE: the values can be passed to either the fixed or floating
1338point APIs, but the floating point API will also accept floating point
1339values.
1340
1341The second thing you may need to tell libpng about is how your system handles
1342alpha channel information. Some, but not all, PNG files contain an alpha
1343channel. To display these files correctly you need to compose the data onto a
1344suitable background, as described in the PNG specification.
1345
1346Libpng only supports composing onto a single color (using png_set_background;
1347see below). Otherwise you must do the composition yourself and, in this case,
1348you may need to call png_set_alpha_mode:
1349
1350 #if PNG_LIBPNG_VER >= 10504
1351 png_set_alpha_mode(png_ptr, mode, screen_gamma);
1352 #else
1353 png_set_gamma(png_ptr, screen_gamma, 1.0/screen_gamma);
1354 #endif
1355
1356The screen_gamma value is the same as the argument to png_set_gamma; however,
1357how it affects the output depends on the mode. png_set_alpha_mode() sets the
1358file gamma default to 1/screen_gamma, so normally you don't need to call
1359png_set_gamma. If you need different defaults call png_set_gamma() before
1360png_set_alpha_mode() - if you call it after it will override the settings made
1361by png_set_alpha_mode().
1362
1363The mode is as follows:
1364
1365 PNG_ALPHA_PNG: The data is encoded according to the PNG
1366specification. Red, green and blue, or gray, components are
1367gamma encoded color values and are not premultiplied by the
1368alpha value. The alpha value is a linear measure of the
1369contribution of the pixel to the corresponding final output pixel.
1370
1371You should normally use this format if you intend to perform
1372color correction on the color values; most, maybe all, color
1373correction software has no handling for the alpha channel and,
1374anyway, the math to handle pre-multiplied component values is
1375unnecessarily complex.
1376
1377Before you do any arithmetic on the component values you need
1378to remove the gamma encoding and multiply out the alpha
1379channel. See the PNG specification for more detail. It is
1380important to note that when an image with an alpha channel is
1381scaled, linear encoded, pre-multiplied component values must
1382be used!
1383
1384The remaining modes assume you don't need to do any further color correction or
1385that if you do, your color correction software knows all about alpha (it
1386probably doesn't!). They 'associate' the alpha with the color information by
1387storing color channel values that have been scaled by the alpha. The
1388advantage is that the color channels can be resampled (the image can be
1389scaled) in this form. The disadvantage is that normal practice is to store
1390linear, not (gamma) encoded, values and this requires 16-bit channels for
1391still images rather than the 8-bit channels that are just about sufficient if
1392gamma encoding is used. In addition all non-transparent pixel values,
1393including completely opaque ones, must be gamma encoded to produce the final
1394image. These are the 'STANDARD', 'ASSOCIATED' or 'PREMULTIPLIED' modes
1395described below (the latter being the two common names for associated alpha
1396color channels). Note that PNG files always contain non-associated color
1397channels; png_set_alpha_mode() with one of the modes causes the decoder to
1398convert the pixels to an associated form before returning them to your
1399application.
1400
1401Since it is not necessary to perform arithmetic on opaque color values so
1402long as they are not to be resampled and are in the final color space it is
1403possible to optimize the handling of alpha by storing the opaque pixels in
1404the PNG format (adjusted for the output color space) while storing partially
1405opaque pixels in the standard, linear, format. The accuracy required for
1406standard alpha composition is relatively low, because the pixels are
1407isolated, therefore typically the accuracy loss in storing 8-bit linear
1408values is acceptable. (This is not true if the alpha channel is used to
1409simulate transparency over large areas - use 16 bits or the PNG mode in
1410this case!) This is the 'OPTIMIZED' mode. For this mode a pixel is
1411treated as opaque only if the alpha value is equal to the maximum value.
1412
1413 PNG_ALPHA_STANDARD: The data libpng produces is encoded in the
1414standard way assumed by most correctly written graphics software.
1415The gamma encoding will be removed by libpng and the
1416linear component values will be pre-multiplied by the
1417alpha channel.
1418
1419With this format the final image must be re-encoded to
1420match the display gamma before the image is displayed.
1421If your system doesn't do that, yet still seems to
1422perform arithmetic on the pixels without decoding them,
1423it is broken - check out the modes below.
1424
1425With PNG_ALPHA_STANDARD libpng always produces linear
1426component values, whatever screen_gamma you supply. The
1427screen_gamma value is, however, used as a default for
1428the file gamma if the PNG file has no gamma information.
1429
1430If you call png_set_gamma() after png_set_alpha_mode() you
1431will override the linear encoding. Instead the
1432pre-multiplied pixel values will be gamma encoded but
1433the alpha channel will still be linear. This may
1434actually match the requirements of some broken software,
1435but it is unlikely.
1436
1437While linear 8-bit data is often used it has
1438insufficient precision for any image with a reasonable
1439dynamic range. To avoid problems, and if your software
1440supports it, use png_set_expand_16() to force all
1441components to 16 bits.
1442
1443 PNG_ALPHA_OPTIMIZED: This mode is the same as PNG_ALPHA_STANDARD
1444except that completely opaque pixels are gamma encoded according to
1445the screen_gamma value. Pixels with alpha less than 1.0
1446will still have linear components.
1447
1448Use this format if you have control over your
1449compositing software and so don't do other arithmetic
1450(such as scaling) on the data you get from libpng. Your
1451compositing software can simply copy opaque pixels to
1452the output but still has linear values for the
1453non-opaque pixels.
1454
1455In normal compositing, where the alpha channel encodes
1456partial pixel coverage (as opposed to broad area
1457translucency), the inaccuracies of the 8-bit
1458representation of non-opaque pixels are irrelevant.
1459
1460You can also try this format if your software is broken;
1461it might look better.
1462
1463 PNG_ALPHA_BROKEN: This is PNG_ALPHA_STANDARD; however, all component
1464values, including the alpha channel are gamma encoded. This is
1465broken because, in practice, no implementation that uses this choice
1466correctly undoes the encoding before handling alpha composition. Use this
1467choice only if other serious errors in the software or hardware you use
1468mandate it. In most cases of broken software or hardware the bug in the
1469final display manifests as a subtle halo around composited parts of the
1470image. You may not even perceive this as a halo; the composited part of
1471the image may simply appear separate from the background, as though it had
1472been cut out of paper and pasted on afterward.
1473
1474If you don't have to deal with bugs in software or hardware, or if you can fix
1475them, there are three recommended ways of using png_set_alpha_mode():
1476
1477 png_set_alpha_mode(png_ptr, PNG_ALPHA_PNG,
1478 screen_gamma);
1479
1480You can do color correction on the result (libpng does not currently
1481support color correction internally). When you handle the alpha channel
1482you need to undo the gamma encoding and multiply out the alpha.
1483
1484 png_set_alpha_mode(png_ptr, PNG_ALPHA_STANDARD,
1485 screen_gamma);
1486 png_set_expand_16(png_ptr);
1487
1488If you are using the high level interface, don't call png_set_expand_16();
1489instead pass PNG_TRANSFORM_EXPAND_16 to the interface.
1490
1491With this mode you can't do color correction, but you can do arithmetic,
1492including composition and scaling, on the data without further processing.
1493
1494 png_set_alpha_mode(png_ptr, PNG_ALPHA_OPTIMIZED,
1495 screen_gamma);
1496
1497You can avoid the expansion to 16-bit components with this mode, but you
1498lose the ability to scale the image or perform other linear arithmetic.
1499All you can do is compose the result onto a matching output. Since this
1500mode is libpng-specific you also need to write your own composition
1501software.
1502
1503The following are examples of calls to png_set_alpha_mode to achieve the
1504required overall gamma correction and, where necessary, alpha
1505premultiplication.
1506
1507 png_set_alpha_mode(pp, PNG_ALPHA_PNG, PNG_DEFAULT_sRGB);
1508
1509Choices for the alpha_mode are
1510
1511 PNG_ALPHA_PNG 0 /* according to the PNG standard */
1512 PNG_ALPHA_STANDARD 1 /* according to Porter/Duff */
1513 PNG_ALPHA_ASSOCIATED 1 /* as above; this is the normal practice */
1514 PNG_ALPHA_PREMULTIPLIED 1 /* as above */
1515 PNG_ALPHA_OPTIMIZED 2 /* 'PNG' for opaque pixels, else 'STANDARD' */
1516 PNG_ALPHA_BROKEN 3 /* the alpha channel is gamma encoded */
1517
1518PNG_ALPHA_PNG is the default libpng handling of the alpha channel. It is not
1519pre-multiplied into the color components. In addition the call states
1520that the output is for a sRGB system and causes all PNG files without gAMA
1521chunks to be assumed to be encoded using sRGB.
1522
1523 png_set_alpha_mode(pp, PNG_ALPHA_PNG, PNG_GAMMA_MAC);
1524
1525In this case the output is assumed to be something like an sRGB conformant
1526display preceded by a power-law lookup table of power 1.45. This is how
1527early Mac systems behaved.
1528
1529 png_set_alpha_mode(pp, PNG_ALPHA_STANDARD, PNG_GAMMA_LINEAR);
1530
1531This is the classic Jim Blinn approach and will work in academic
1532environments where everything is done by the book. It has the shortcoming
1533of assuming that input PNG data with no gamma information is linear - this
1534is unlikely to be correct unless the PNG files were generated locally.
1535Most of the time the output precision will be so low as to show
1536significant banding in dark areas of the image.
1537
1538 png_set_expand_16(pp);
1539 png_set_alpha_mode(pp, PNG_ALPHA_STANDARD, PNG_DEFAULT_sRGB);
1540
1541This is a somewhat more realistic Jim Blinn inspired approach. PNG files
1542are assumed to have the sRGB encoding if not marked with a gamma value and
1543the output is always 16 bits per component. This permits accurate scaling
1544and processing of the data. If you know that your input PNG files were
1545generated locally you might need to replace PNG_DEFAULT_sRGB with the
1546correct value for your system.
1547
1548 png_set_alpha_mode(pp, PNG_ALPHA_OPTIMIZED, PNG_DEFAULT_sRGB);
1549
1550If you just need to composite the PNG image onto an existing background
1551and if you control the code that does this you can use the optimization
1552setting. In this case you just copy completely opaque pixels to the
1553output. For pixels that are not completely transparent (you just skip
1554those) you do the composition math using png_composite or png_composite_16
1555below then encode the resultant 8-bit or 16-bit values to match the output
1556encoding.
1557
1558 Other cases
1559
1560If neither the PNG nor the standard linear encoding work for you because
1561of the software or hardware you use then you have a big problem. The PNG
1562case will probably result in halos around the image. The linear encoding
1563will probably result in a washed out, too bright, image (it's actually too
1564contrasty.) Try the ALPHA_OPTIMIZED mode above - this will probably
1565substantially reduce the halos. Alternatively try:
1566
1567 png_set_alpha_mode(pp, PNG_ALPHA_BROKEN, PNG_DEFAULT_sRGB);
1568
1569This option will also reduce the halos, but there will be slight dark
1570halos round the opaque parts of the image where the background is light.
1571In the OPTIMIZED mode the halos will be light halos where the background
1572is dark. Take your pick - the halos are unavoidable unless you can get
1573your hardware/software fixed! (The OPTIMIZED approach is slightly
1574faster.)
1575
1576When the default gamma of PNG files doesn't match the output gamma.
1577If you have PNG files with no gamma information png_set_alpha_mode allows
1578you to provide a default gamma, but it also sets the output gamma to the
1579matching value. If you know your PNG files have a gamma that doesn't
1580match the output you can take advantage of the fact that
1581png_set_alpha_mode always sets the output gamma but only sets the PNG
1582default if it is not already set:
1583
1584 png_set_alpha_mode(pp, PNG_ALPHA_PNG, PNG_DEFAULT_sRGB);
1585 png_set_alpha_mode(pp, PNG_ALPHA_PNG, PNG_GAMMA_MAC);
1586
1587The first call sets both the default and the output gamma values, the
1588second call overrides the output gamma without changing the default. This
1589is easier than achieving the same effect with png_set_gamma. You must use
1590PNG_ALPHA_PNG for the first call - internal checking in png_set_alpha will
1591fire if more than one call to png_set_alpha_mode and png_set_background is
1592made in the same read operation, however multiple calls with PNG_ALPHA_PNG
1593are ignored.
1594
1595If you don't need, or can't handle, the alpha channel you can call
1596png_set_background() to remove it by compositing against a fixed color. Don't
1597call png_set_strip_alpha() to do this - it will leave spurious pixel values in
1598transparent parts of this image.
1599
1600 png_set_background(png_ptr, &background_color,
1601 PNG_BACKGROUND_GAMMA_SCREEN, 0, 1);
1602
1603The background_color is an RGB or grayscale value according to the data format
1604libpng will produce for you. Because you don't yet know the format of the PNG
1605file, if you call png_set_background at this point you must arrange for the
1606format produced by libpng to always have 8-bit or 16-bit components and then
1607store the color as an 8-bit or 16-bit color as appropriate. The color contains
1608separate gray and RGB component values, so you can let libpng produce gray or
1609RGB output according to the input format, but low bit depth grayscale images
1610must always be converted to at least 8-bit format. (Even though low bit depth
1611grayscale images can't have an alpha channel they can have a transparent
1612color!)
1613
1614You set the transforms you need later, either as flags to the high level
1615interface or libpng API calls for the low level interface. For reference the
1616settings and API calls required are:
1617
16188-bit values:
1619 PNG_TRANSFORM_SCALE_16 | PNG_EXPAND
1620 png_set_expand(png_ptr); png_set_scale_16(png_ptr);
1621
1622 If you must get exactly the same inaccurate results
1623 produced by default in versions prior to libpng-1.5.4,
1624 use PNG_TRANSFORM_STRIP_16 and png_set_strip_16(png_ptr)
1625 instead.
1626
162716-bit values:
1628 PNG_TRANSFORM_EXPAND_16
1629 png_set_expand_16(png_ptr);
1630
1631In either case palette image data will be expanded to RGB. If you just want
1632color data you can add PNG_TRANSFORM_GRAY_TO_RGB or png_set_gray_to_rgb(png_ptr)
1633to the list.
1634
1635Calling png_set_background before the PNG file header is read will not work
1636prior to libpng-1.5.4. Because the failure may result in unexpected warnings or
1637errors it is therefore much safer to call png_set_background after the head has
1638been read. Unfortunately this means that prior to libpng-1.5.4 it cannot be
1639used with the high level interface.
1640
1641.SS The high-level read interface
1642
1643At this point there are two ways to proceed; through the high-level
1644read interface, or through a sequence of low-level read operations.
1645You can use the high-level interface if (a) you are willing to read
1646the entire image into memory, and (b) the input transformations
1647you want to do are limited to the following set:
1648
1649 PNG_TRANSFORM_IDENTITY No transformation
1650 PNG_TRANSFORM_SCALE_16 Strip 16-bit samples to
1651 8-bit accurately
1652 PNG_TRANSFORM_STRIP_16 Chop 16-bit samples to
1653 8-bit less accurately
1654 PNG_TRANSFORM_STRIP_ALPHA Discard the alpha channel
1655 PNG_TRANSFORM_PACKING Expand 1, 2 and 4-bit
1656 samples to bytes
1657 PNG_TRANSFORM_PACKSWAP Change order of packed
1658 pixels to LSB first
1659 PNG_TRANSFORM_EXPAND Perform set_expand()
1660 PNG_TRANSFORM_INVERT_MONO Invert monochrome images
1661 PNG_TRANSFORM_SHIFT Normalize pixels to the
1662 sBIT depth
1663 PNG_TRANSFORM_BGR Flip RGB to BGR, RGBA
1664 to BGRA
1665 PNG_TRANSFORM_SWAP_ALPHA Flip RGBA to ARGB or GA
1666 to AG
1667 PNG_TRANSFORM_INVERT_ALPHA Change alpha from opacity
1668 to transparency
1669 PNG_TRANSFORM_SWAP_ENDIAN Byte-swap 16-bit samples
1670 PNG_TRANSFORM_GRAY_TO_RGB Expand grayscale samples
1671 to RGB (or GA to RGBA)
1672 PNG_TRANSFORM_EXPAND_16 Expand samples to 16 bits
1673
1674(This excludes setting a background color, doing gamma transformation,
1675quantizing, and setting filler.) If this is the case, simply do this:
1676
1677 png_read_png(png_ptr, info_ptr, png_transforms, NULL)
1678
1679where png_transforms is an integer containing the bitwise OR of some
1680set of transformation flags. This call is equivalent to png_read_info(),
1681followed the set of transformations indicated by the transform mask,
1682then png_read_image(), and finally png_read_end().
1683
1684(The final parameter of this call is not yet used. Someday it might point
1685to transformation parameters required by some future input transform.)
1686
1687You must use png_transforms and not call any png_set_transform() functions
1688when you use png_read_png().
1689
1690After you have called png_read_png(), you can retrieve the image data
1691with
1692
1693 row_pointers = png_get_rows(png_ptr, info_ptr);
1694
1695where row_pointers is an array of pointers to the pixel data for each row:
1696
1697 png_bytep row_pointers[height];
1698
1699If you know your image size and pixel size ahead of time, you can allocate
1700row_pointers prior to calling png_read_png() with
1701
1702 if (height > PNG_UINT_32_MAX/(sizeof (png_byte)))
1703 png_error (png_ptr,
1704 "Image is too tall to process in memory");
1705
1706 if (width > PNG_UINT_32_MAX/pixel_size)
1707 png_error (png_ptr,
1708 "Image is too wide to process in memory");
1709
1710 row_pointers = png_malloc(png_ptr,
1711 height*(sizeof (png_bytep)));
1712
1713 for (int i=0; i<height, i++)
1714 row_pointers[i]=NULL; /* security precaution */
1715
1716 for (int i=0; i<height, i++)
1717 row_pointers[i]=png_malloc(png_ptr,
1718 width*pixel_size);
1719
1720 png_set_rows(png_ptr, info_ptr, &row_pointers);
1721
1722Alternatively you could allocate your image in one big block and define
1723row_pointers[i] to point into the proper places in your block, but first
1724be sure that your platform is able to allocate such a large buffer:
1725
1726 /* Guard against integer overflow */
1727 if (height > PNG_SIZE_MAX/(width*pixel_size)) {
1728 png_error(png_ptr,"image_data buffer would be too large");
1729 }
1730
1731 png_bytep buffer=png_malloc(png_ptr,height*width*pixel_size);
1732
1733 for (int i=0; i<height, i++)
1734 row_pointers[i]=buffer+i*width*pixel_size;
1735
1736 png_set_rows(png_ptr, info_ptr, &row_pointers);
1737
1738If you use png_set_rows(), the application is responsible for freeing
1739row_pointers (and row_pointers[i], if they were separately allocated).
1740
1741If you don't allocate row_pointers ahead of time, png_read_png() will
1742do it, and it'll be free'ed by libpng when you call png_destroy_*().
1743
1744.SS The low-level read interface
1745
1746If you are going the low-level route, you are now ready to read all
1747the file information up to the actual image data. You do this with a
1748call to png_read_info().
1749
1750 png_read_info(png_ptr, info_ptr);
1751
1752This will process all chunks up to but not including the image data.
1753
1754This also copies some of the data from the PNG file into the decode structure
1755for use in later transformations. Important information copied in is:
1756
17571) The PNG file gamma from the gAMA chunk. This overwrites the default value
1758provided by an earlier call to png_set_gamma or png_set_alpha_mode.
1759
17602) Prior to libpng-1.5.4 the background color from a bKGd chunk. This
1761damages the information provided by an earlier call to png_set_background
1762resulting in unexpected behavior. Libpng-1.5.4 no longer does this.
1763
17643) The number of significant bits in each component value. Libpng uses this to
1765optimize gamma handling by reducing the internal lookup table sizes.
1766
17674) The transparent color information from a tRNS chunk. This can be modified by
1768a later call to png_set_tRNS.
1769
1770.SS Querying the info structure
1771
1772Functions are used to get the information from the info_ptr once it
1773has been read. Note that these fields may not be completely filled
1774in until png_read_end() has read the chunk data following the image.
1775
1776 png_get_IHDR(png_ptr, info_ptr, &width, &height,
1777 &bit_depth, &color_type, &interlace_type,
1778 &compression_type, &filter_method);
1779
1780 width - holds the width of the image
1781 in pixels (up to 2^31).
1782
1783 height - holds the height of the image
1784 in pixels (up to 2^31).
1785
1786 bit_depth - holds the bit depth of one of the
1787 image channels. (valid values are
1788 1, 2, 4, 8, 16 and depend also on
1789 the color_type. See also
1790 significant bits (sBIT) below).
1791
1792 color_type - describes which color/alpha channels
1793 are present.
1794 PNG_COLOR_TYPE_GRAY
1795 (bit depths 1, 2, 4, 8, 16)
1796 PNG_COLOR_TYPE_GRAY_ALPHA
1797 (bit depths 8, 16)
1798 PNG_COLOR_TYPE_PALETTE
1799 (bit depths 1, 2, 4, 8)
1800 PNG_COLOR_TYPE_RGB
1801 (bit_depths 8, 16)
1802 PNG_COLOR_TYPE_RGB_ALPHA
1803 (bit_depths 8, 16)
1804
1805 PNG_COLOR_MASK_PALETTE
1806 PNG_COLOR_MASK_COLOR
1807 PNG_COLOR_MASK_ALPHA
1808
1809 interlace_type - (PNG_INTERLACE_NONE or
1810 PNG_INTERLACE_ADAM7)
1811
1812 compression_type - (must be PNG_COMPRESSION_TYPE_BASE
1813 for PNG 1.0)
1814
1815 filter_method - (must be PNG_FILTER_TYPE_BASE
1816 for PNG 1.0, and can also be
1817 PNG_INTRAPIXEL_DIFFERENCING if
1818 the PNG datastream is embedded in
1819 a MNG-1.0 datastream)
1820
1821 Any of width, height, color_type, bit_depth,
1822 interlace_type, compression_type, or filter_method can
1823 be NULL if you are not interested in their values.
1824
1825 Note that png_get_IHDR() returns 32-bit data into
1826 the application's width and height variables.
1827 This is an unsafe situation if these are not png_uint_32
1828 variables. In such situations, the
1829 png_get_image_width() and png_get_image_height()
1830 functions described below are safer.
1831
1832 width = png_get_image_width(png_ptr,
1833 info_ptr);
1834
1835 height = png_get_image_height(png_ptr,
1836 info_ptr);
1837
1838 bit_depth = png_get_bit_depth(png_ptr,
1839 info_ptr);
1840
1841 color_type = png_get_color_type(png_ptr,
1842 info_ptr);
1843
1844 interlace_type = png_get_interlace_type(png_ptr,
1845 info_ptr);
1846
1847 compression_type = png_get_compression_type(png_ptr,
1848 info_ptr);
1849
1850 filter_method = png_get_filter_type(png_ptr,
1851 info_ptr);
1852
1853 channels = png_get_channels(png_ptr, info_ptr);
1854
1855 channels - number of channels of info for the
1856 color type (valid values are 1 (GRAY,
1857 PALETTE), 2 (GRAY_ALPHA), 3 (RGB),
1858 4 (RGB_ALPHA or RGB + filler byte))
1859
1860 rowbytes = png_get_rowbytes(png_ptr, info_ptr);
1861
1862 rowbytes - number of bytes needed to hold a row
1863 This value, the bit_depth, color_type,
1864 and the number of channels can change
1865 if you use transforms such as
1866 png_set_expand(). See
1867 png_read_update_info(), below.
1868
1869 signature = png_get_signature(png_ptr, info_ptr);
1870
1871 signature - holds the signature read from the
1872 file (if any). The data is kept in
1873 the same offset it would be if the
1874 whole signature were read (i.e. if an
1875 application had already read in 4
1876 bytes of signature before starting
1877 libpng, the remaining 4 bytes would
1878 be in signature[4] through signature[7]
1879 (see png_set_sig_bytes())).
1880
1881These are also important, but their validity depends on whether the chunk
1882has been read. The png_get_valid(png_ptr, info_ptr, PNG_INFO_<chunk>) and
1883png_get_<chunk>(png_ptr, info_ptr, ...) functions return non-zero if the
1884data has been read, or zero if it is missing. The parameters to the
1885png_get_<chunk> are set directly if they are simple data types, or a
1886pointer into the info_ptr is returned for any complex types.
1887
1888The colorspace data from gAMA, cHRM, sRGB, iCCP, and sBIT chunks
1889is simply returned to give the application information about how the
1890image was encoded. Libpng itself only does transformations using the file
1891gamma when combining semitransparent pixels with the background color, and,
1892since libpng-1.6.0, when converting between 8-bit sRGB and 16-bit linear pixels
1893within the simplified API. Libpng also uses the file gamma when converting
1894RGB to gray, beginning with libpng-1.0.5, if the application calls
1895png_set_rgb_to_gray()).
1896
1897 png_get_PLTE(png_ptr, info_ptr, &palette,
1898 &num_palette);
1899
1900 palette - the palette for the file
1901 (array of png_color)
1902
1903 num_palette - number of entries in the palette
1904
1905 png_get_gAMA(png_ptr, info_ptr, &file_gamma);
1906 png_get_gAMA_fixed(png_ptr, info_ptr, &int_file_gamma);
1907
1908 file_gamma - the gamma at which the file is
1909 written (PNG_INFO_gAMA)
1910
1911 int_file_gamma - 100,000 times the gamma at which the
1912 file is written
1913
1914 png_get_cHRM(png_ptr, info_ptr, &white_x, &white_y, &red_x,
1915 &red_y, &green_x, &green_y, &blue_x, &blue_y)
1916 png_get_cHRM_XYZ(png_ptr, info_ptr, &red_X, &red_Y, &red_Z,
1917 &green_X, &green_Y, &green_Z, &blue_X, &blue_Y,
1918 &blue_Z)
1919 png_get_cHRM_fixed(png_ptr, info_ptr, &int_white_x,
1920 &int_white_y, &int_red_x, &int_red_y,
1921 &int_green_x, &int_green_y, &int_blue_x,
1922 &int_blue_y)
1923 png_get_cHRM_XYZ_fixed(png_ptr, info_ptr, &int_red_X, &int_red_Y,
1924 &int_red_Z, &int_green_X, &int_green_Y,
1925 &int_green_Z, &int_blue_X, &int_blue_Y,
1926 &int_blue_Z)
1927
1928 {white,red,green,blue}_{x,y}
1929 A color space encoding specified using the
1930 chromaticities of the end points and the
1931 white point. (PNG_INFO_cHRM)
1932
1933 {red,green,blue}_{X,Y,Z}
1934 A color space encoding specified using the
1935 encoding end points - the CIE tristimulus
1936 specification of the intended color of the red,
1937 green and blue channels in the PNG RGB data.
1938 The white point is simply the sum of the three
1939 end points. (PNG_INFO_cHRM)
1940
1941 png_get_sRGB(png_ptr, info_ptr, &srgb_intent);
1942
1943 srgb_intent - the rendering intent (PNG_INFO_sRGB)
1944 The presence of the sRGB chunk
1945 means that the pixel data is in the
1946 sRGB color space. This chunk also
1947 implies specific values of gAMA and
1948 cHRM.
1949
1950 png_get_iCCP(png_ptr, info_ptr, &name,
1951 &compression_type, &profile, &proflen);
1952
1953 name - The profile name.
1954
1955 compression_type - The compression type; always
1956 PNG_COMPRESSION_TYPE_BASE for PNG 1.0.
1957 You may give NULL to this argument to
1958 ignore it.
1959
1960 profile - International Color Consortium color
1961 profile data. May contain NULs.
1962
1963 proflen - length of profile data in bytes.
1964
1965 png_get_sBIT(png_ptr, info_ptr, &sig_bit);
1966
1967 sig_bit - the number of significant bits for
1968 (PNG_INFO_sBIT) each of the gray,
1969 red, green, and blue channels,
1970 whichever are appropriate for the
1971 given color type (png_color_16)
1972
1973 png_get_tRNS(png_ptr, info_ptr, &trans_alpha,
1974 &num_trans, &trans_color);
1975
1976 trans_alpha - array of alpha (transparency)
1977 entries for palette (PNG_INFO_tRNS)
1978
1979 num_trans - number of transparent entries
1980 (PNG_INFO_tRNS)
1981
1982 trans_color - graylevel or color sample values of
1983 the single transparent color for
1984 non-paletted images (PNG_INFO_tRNS)
1985
1986 png_get_eXIf_1(png_ptr, info_ptr, &num_exif, &exif);
1987 (PNG_INFO_eXIf)
1988
1989 exif - Exif profile (array of png_byte)
1990
1991 png_get_hIST(png_ptr, info_ptr, &hist);
1992 (PNG_INFO_hIST)
1993
1994 hist - histogram of palette (array of
1995 png_uint_16)
1996
1997 png_get_tIME(png_ptr, info_ptr, &mod_time);
1998
1999 mod_time - time image was last modified
2000 (PNG_VALID_tIME)
2001
2002 png_get_bKGD(png_ptr, info_ptr, &background);
2003
2004 background - background color (of type
2005 png_color_16p) (PNG_VALID_bKGD)
2006 valid 16-bit red, green and blue
2007 values, regardless of color_type
2008
2009 num_comments = png_get_text(png_ptr, info_ptr,
2010 &text_ptr, &num_text);
2011
2012 num_comments - number of comments
2013
2014 text_ptr - array of png_text holding image
2015 comments
2016
2017 text_ptr[i].compression - type of compression used
2018 on "text" PNG_TEXT_COMPRESSION_NONE
2019 PNG_TEXT_COMPRESSION_zTXt
2020 PNG_ITXT_COMPRESSION_NONE
2021 PNG_ITXT_COMPRESSION_zTXt
2022
2023 text_ptr[i].key - keyword for comment. Must contain
2024 1-79 characters.
2025
2026 text_ptr[i].text - text comments for current
2027 keyword. Can be empty.
2028
2029 text_ptr[i].text_length - length of text string,
2030 after decompression, 0 for iTXt
2031
2032 text_ptr[i].itxt_length - length of itxt string,
2033 after decompression, 0 for tEXt/zTXt
2034
2035 text_ptr[i].lang - language of comment (empty
2036 string for unknown).
2037
2038 text_ptr[i].lang_key - keyword in UTF-8
2039 (empty string for unknown).
2040
2041 Note that the itxt_length, lang, and lang_key
2042 members of the text_ptr structure only exist when the
2043 library is built with iTXt chunk support. Prior to
2044 libpng-1.4.0 the library was built by default without
2045 iTXt support. Also note that when iTXt is supported,
2046 they contain NULL pointers when the "compression"
2047 field contains PNG_TEXT_COMPRESSION_NONE or
2048 PNG_TEXT_COMPRESSION_zTXt.
2049
2050 num_text - number of comments (same as
2051 num_comments; you can put NULL here
2052 to avoid the duplication)
2053
2054 Note while png_set_text() will accept text, language,
2055 and translated keywords that can be NULL pointers, the
2056 structure returned by png_get_text will always contain
2057 regular zero-terminated C strings. They might be
2058 empty strings but they will never be NULL pointers.
2059
2060 num_spalettes = png_get_sPLT(png_ptr, info_ptr,
2061 &palette_ptr);
2062
2063 num_spalettes - number of sPLT chunks read.
2064
2065 palette_ptr - array of palette structures holding
2066 contents of one or more sPLT chunks
2067 read.
2068
2069 png_get_oFFs(png_ptr, info_ptr, &offset_x, &offset_y,
2070 &unit_type);
2071
2072 offset_x - positive offset from the left edge
2073 of the screen (can be negative)
2074
2075 offset_y - positive offset from the top edge
2076 of the screen (can be negative)
2077
2078 unit_type - PNG_OFFSET_PIXEL, PNG_OFFSET_MICROMETER
2079
2080 png_get_pHYs(png_ptr, info_ptr, &res_x, &res_y,
2081 &unit_type);
2082
2083 res_x - pixels/unit physical resolution in
2084 x direction
2085
2086 res_y - pixels/unit physical resolution in
2087 x direction
2088
2089 unit_type - PNG_RESOLUTION_UNKNOWN,
2090 PNG_RESOLUTION_METER
2091
2092 png_get_sCAL(png_ptr, info_ptr, &unit, &width,
2093 &height)
2094
2095 unit - physical scale units (an integer)
2096
2097 width - width of a pixel in physical scale units
2098
2099 height - height of a pixel in physical scale units
2100 (width and height are doubles)
2101
2102 png_get_sCAL_s(png_ptr, info_ptr, &unit, &width,
2103 &height)
2104
2105 unit - physical scale units (an integer)
2106
2107 width - width of a pixel in physical scale units
2108 (expressed as a string)
2109
2110 height - height of a pixel in physical scale units
2111 (width and height are strings like "2.54")
2112
2113 num_unknown_chunks = png_get_unknown_chunks(png_ptr,
2114 info_ptr, &unknowns)
2115
2116 unknowns - array of png_unknown_chunk
2117 structures holding unknown chunks
2118
2119 unknowns[i].name - name of unknown chunk
2120
2121 unknowns[i].data - data of unknown chunk
2122
2123 unknowns[i].size - size of unknown chunk's data
2124
2125 unknowns[i].location - position of chunk in file
2126
2127 The value of "i" corresponds to the order in which the
2128 chunks were read from the PNG file or inserted with the
2129 png_set_unknown_chunks() function.
2130
2131 The value of "location" is a bitwise "or" of
2132
2133 PNG_HAVE_IHDR (0x01)
2134 PNG_HAVE_PLTE (0x02)
2135 PNG_AFTER_IDAT (0x08)
2136
2137The data from the pHYs chunk can be retrieved in several convenient
2138forms:
2139
2140 res_x = png_get_x_pixels_per_meter(png_ptr,
2141 info_ptr)
2142
2143 res_y = png_get_y_pixels_per_meter(png_ptr,
2144 info_ptr)
2145
2146 res_x_and_y = png_get_pixels_per_meter(png_ptr,
2147 info_ptr)
2148
2149 res_x = png_get_x_pixels_per_inch(png_ptr,
2150 info_ptr)
2151
2152 res_y = png_get_y_pixels_per_inch(png_ptr,
2153 info_ptr)
2154
2155 res_x_and_y = png_get_pixels_per_inch(png_ptr,
2156 info_ptr)
2157
2158 aspect_ratio = png_get_pixel_aspect_ratio(png_ptr,
2159 info_ptr)
2160
2161 Each of these returns 0 [signifying "unknown"] if
2162 the data is not present or if res_x is 0;
2163 res_x_and_y is 0 if res_x != res_y
2164
2165 Note that because of the way the resolutions are
2166 stored internally, the inch conversions won't
2167 come out to exactly even number. For example,
2168 72 dpi is stored as 0.28346 pixels/meter, and
2169 when this is retrieved it is 71.9988 dpi, so
2170 be sure to round the returned value appropriately
2171 if you want to display a reasonable-looking result.
2172
2173The data from the oFFs chunk can be retrieved in several convenient
2174forms:
2175
2176 x_offset = png_get_x_offset_microns(png_ptr, info_ptr);
2177
2178 y_offset = png_get_y_offset_microns(png_ptr, info_ptr);
2179
2180 x_offset = png_get_x_offset_inches(png_ptr, info_ptr);
2181
2182 y_offset = png_get_y_offset_inches(png_ptr, info_ptr);
2183
2184 Each of these returns 0 [signifying "unknown" if both
2185 x and y are 0] if the data is not present or if the
2186 chunk is present but the unit is the pixel. The
2187 remark about inexact inch conversions applies here
2188 as well, because a value in inches can't always be
2189 converted to microns and back without some loss
2190 of precision.
2191
2192For more information, see the
2193PNG specification for chunk contents. Be careful with trusting
2194rowbytes, as some of the transformations could increase the space
2195needed to hold a row (expand, filler, gray_to_rgb, etc.).
2196See png_read_update_info(), below.
2197
2198A quick word about text_ptr and num_text. PNG stores comments in
2199keyword/text pairs, one pair per chunk, with no limit on the number
2200of text chunks, and a 2^31 byte limit on their size. While there are
2201suggested keywords, there is no requirement to restrict the use to these
2202strings. It is strongly suggested that keywords and text be sensible
2203to humans (that's the point), so don't use abbreviations. Non-printing
2204symbols are not allowed. See the PNG specification for more details.
2205There is also no requirement to have text after the keyword.
2206
2207Keywords should be limited to 79 Latin-1 characters without leading or
2208trailing spaces, but non-consecutive spaces are allowed within the
2209keyword. It is possible to have the same keyword any number of times.
2210The text_ptr is an array of png_text structures, each holding a
2211pointer to a language string, a pointer to a keyword and a pointer to
2212a text string. The text string, language code, and translated
2213keyword may be empty or NULL pointers. The keyword/text
2214pairs are put into the array in the order that they are received.
2215However, some or all of the text chunks may be after the image, so, to
2216make sure you have read all the text chunks, don't mess with these
2217until after you read the stuff after the image. This will be
2218mentioned again below in the discussion that goes with png_read_end().
2219
2220.SS Input transformations
2221
2222After you've read the header information, you can set up the library
2223to handle any special transformations of the image data. The various
2224ways to transform the data will be described in the order that they
2225should occur. This is important, as some of these change the color
2226type and/or bit depth of the data, and some others only work on
2227certain color types and bit depths.
2228
2229Transformations you request are ignored if they don't have any meaning for a
2230particular input data format. However some transformations can have an effect
2231as a result of a previous transformation. If you specify a contradictory set of
2232transformations, for example both adding and removing the alpha channel, you
2233cannot predict the final result.
2234
2235The color used for the transparency values should be supplied in the same
2236format/depth as the current image data. It is stored in the same format/depth
2237as the image data in a tRNS chunk, so this is what libpng expects for this data.
2238
2239The color used for the background value depends on the need_expand argument as
2240described below.
2241
2242Data will be decoded into the supplied row buffers packed into bytes
2243unless the library has been told to transform it into another format.
2244For example, 4 bit/pixel paletted or grayscale data will be returned
22452 pixels/byte with the leftmost pixel in the high-order bits of the byte,
2246unless png_set_packing() is called. 8-bit RGB data will be stored
2247in RGB RGB RGB format unless png_set_filler() or png_set_add_alpha()
2248is called to insert filler bytes, either before or after each RGB triplet.
2249
225016-bit RGB data will be returned RRGGBB RRGGBB, with the most significant
2251byte of the color value first, unless png_set_scale_16() is called to
2252transform it to regular RGB RGB triplets, or png_set_filler() or
2253png_set_add alpha() is called to insert two filler bytes, either before
2254or after each RRGGBB triplet. Similarly, 8-bit or 16-bit grayscale data can
2255be modified with png_set_filler(), png_set_add_alpha(), png_set_strip_16(),
2256or png_set_scale_16().
2257
2258The following code transforms grayscale images of less than 8 to 8 bits,
2259changes paletted images to RGB, and adds a full alpha channel if there is
2260transparency information in a tRNS chunk. This is most useful on
2261grayscale images with bit depths of 2 or 4 or if there is a multiple-image
2262viewing application that wishes to treat all images in the same way.
2263
2264 if (color_type == PNG_COLOR_TYPE_PALETTE)
2265 png_set_palette_to_rgb(png_ptr);
2266
2267 if (png_get_valid(png_ptr, info_ptr,
2268 PNG_INFO_tRNS)) png_set_tRNS_to_alpha(png_ptr);
2269
2270 if (color_type == PNG_COLOR_TYPE_GRAY &&
2271 bit_depth < 8) png_set_expand_gray_1_2_4_to_8(png_ptr);
2272
2273The first two functions are actually aliases for png_set_expand(), added
2274in libpng version 1.0.4, with the function names expanded to improve code
2275readability. In some future version they may actually do different
2276things.
2277
2278As of libpng version 1.2.9, png_set_expand_gray_1_2_4_to_8() was
2279added. It expands the sample depth without changing tRNS to alpha.
2280
2281As of libpng version 1.5.2, png_set_expand_16() was added. It behaves as
2282png_set_expand(); however, the resultant channels have 16 bits rather than 8.
2283Use this when the output color or gray channels are made linear to avoid fairly
2284severe accuracy loss.
2285
2286 if (bit_depth < 16)
2287 png_set_expand_16(png_ptr);
2288
2289PNG can have files with 16 bits per channel. If you only can handle
22908 bits per channel, this will strip the pixels down to 8-bit.
2291
2292 if (bit_depth == 16)
2293#if PNG_LIBPNG_VER >= 10504
2294 png_set_scale_16(png_ptr);
2295#else
2296 png_set_strip_16(png_ptr);
2297#endif
2298
2299(The more accurate "png_set_scale_16()" API became available in libpng version
23001.5.4).
2301
2302If you need to process the alpha channel on the image separately from the image
2303data (for example if you convert it to a bitmap mask) it is possible to have
2304libpng strip the channel leaving just RGB or gray data:
2305
2306 if (color_type & PNG_COLOR_MASK_ALPHA)
2307 png_set_strip_alpha(png_ptr);
2308
2309If you strip the alpha channel you need to find some other way of dealing with
2310the information. If, instead, you want to convert the image to an opaque
2311version with no alpha channel use png_set_background; see below.
2312
2313As of libpng version 1.5.2, almost all useful expansions are supported, the
2314major ommissions are conversion of grayscale to indexed images (which can be
2315done trivially in the application) and conversion of indexed to grayscale (which
2316can be done by a trivial manipulation of the palette.)
2317
2318In the following table, the 01 means grayscale with depth<8, 31 means
2319indexed with depth<8, other numerals represent the color type, "T" means
2320the tRNS chunk is present, A means an alpha channel is present, and O
2321means tRNS or alpha is present but all pixels in the image are opaque.
2322
2323 FROM 01 31 0 0T 0O 2 2T 2O 3 3T 3O 4A 4O 6A 6O
2324 TO
2325 01 - [G] - - - - - - - - - - - - -
2326 31 [Q] Q [Q] [Q] [Q] Q Q Q Q Q Q [Q] [Q] Q Q
2327 0 1 G + . . G G G G G G B B GB GB
2328 0T lt Gt t + . Gt G G Gt G G Bt Bt GBt GBt
2329 0O lt Gt t . + Gt Gt G Gt Gt G Bt Bt GBt GBt
2330 2 C P C C C + . . C - - CB CB B B
2331 2T Ct - Ct C C t + t - - - CBt CBt Bt Bt
2332 2O Ct - Ct C C t t + - - - CBt CBt Bt Bt
2333 3 [Q] p [Q] [Q] [Q] Q Q Q + . . [Q] [Q] Q Q
2334 3T [Qt] p [Qt][Q] [Q] Qt Qt Qt t + t [Qt][Qt] Qt Qt
2335 3O [Qt] p [Qt][Q] [Q] Qt Qt Qt t t + [Qt][Qt] Qt Qt
2336 4A lA G A T T GA GT GT GA GT GT + BA G GBA
2337 4O lA GBA A T T GA GT GT GA GT GT BA + GBA G
2338 6A CA PA CA C C A T tT PA P P C CBA + BA
2339 6O CA PBA CA C C A tT T PA P P CBA C BA +
2340
2341Within the matrix,
2342 "+" identifies entries where 'from' and 'to' are the same.
2343 "-" means the transformation is not supported.
2344 "." means nothing is necessary (a tRNS chunk can just be ignored).
2345 "t" means the transformation is obtained by png_set_tRNS.
2346 "A" means the transformation is obtained by png_set_add_alpha().
2347 "X" means the transformation is obtained by png_set_expand().
2348 "1" means the transformation is obtained by
2349 png_set_expand_gray_1_2_4_to_8() (and by png_set_expand()
2350 if there is no transparency in the original or the final
2351 format).
2352 "C" means the transformation is obtained by png_set_gray_to_rgb().
2353 "G" means the transformation is obtained by png_set_rgb_to_gray().
2354 "P" means the transformation is obtained by
2355 png_set_expand_palette_to_rgb().
2356 "p" means the transformation is obtained by png_set_packing().
2357 "Q" means the transformation is obtained by png_set_quantize().
2358 "T" means the transformation is obtained by
2359 png_set_tRNS_to_alpha().
2360 "B" means the transformation is obtained by
2361 png_set_background(), or png_strip_alpha().
2362
2363When an entry has multiple transforms listed all are required to cause the
2364right overall transformation. When two transforms are separated by a comma
2365either will do the job. When transforms are enclosed in [] the transform should
2366do the job but this is currently unimplemented - a different format will result
2367if the suggested transformations are used.
2368
2369In PNG files, the alpha channel in an image
2370is the level of opacity. If you need the alpha channel in an image to
2371be the level of transparency instead of opacity, you can invert the
2372alpha channel (or the tRNS chunk data) after it's read, so that 0 is
2373fully opaque and 255 (in 8-bit or paletted images) or 65535 (in 16-bit
2374images) is fully transparent, with
2375
2376 png_set_invert_alpha(png_ptr);
2377
2378PNG files pack pixels of bit depths 1, 2, and 4 into bytes as small as
2379they can, resulting in, for example, 8 pixels per byte for 1 bit
2380files. This code expands to 1 pixel per byte without changing the
2381values of the pixels:
2382
2383 if (bit_depth < 8)
2384 png_set_packing(png_ptr);
2385
2386PNG files have possible bit depths of 1, 2, 4, 8, and 16. All pixels
2387stored in a PNG image have been "scaled" or "shifted" up to the next
2388higher possible bit depth (e.g. from 5 bits/sample in the range [0,31]
2389to 8 bits/sample in the range [0, 255]). However, it is also possible
2390to convert the PNG pixel data back to the original bit depth of the
2391image. This call reduces the pixels back down to the original bit depth:
2392
2393 png_color_8p sig_bit;
2394
2395 if (png_get_sBIT(png_ptr, info_ptr, &sig_bit))
2396 png_set_shift(png_ptr, sig_bit);
2397
2398PNG files store 3-color pixels in red, green, blue order. This code
2399changes the storage of the pixels to blue, green, red:
2400
2401 if (color_type == PNG_COLOR_TYPE_RGB ||
2402 color_type == PNG_COLOR_TYPE_RGB_ALPHA)
2403 png_set_bgr(png_ptr);
2404
2405PNG files store RGB pixels packed into 3 or 6 bytes. This code expands them
2406into 4 or 8 bytes for windowing systems that need them in this format:
2407
2408 if (color_type == PNG_COLOR_TYPE_RGB)
2409 png_set_filler(png_ptr, filler, PNG_FILLER_BEFORE);
2410
2411where "filler" is the 8-bit or 16-bit number to fill with, and the location
2412is either PNG_FILLER_BEFORE or PNG_FILLER_AFTER, depending upon whether
2413you want the filler before the RGB or after. When filling an 8-bit pixel,
2414the least significant 8 bits of the number are used, if a 16-bit number is
2415supplied. This transformation does not affect images that already have full
2416alpha channels. To add an opaque alpha channel, use filler=0xffff and
2417PNG_FILLER_AFTER which will generate RGBA pixels.
2418
2419Note that png_set_filler() does not change the color type. If you want
2420to do that, you can add a true alpha channel with
2421
2422 if (color_type == PNG_COLOR_TYPE_RGB ||
2423 color_type == PNG_COLOR_TYPE_GRAY)
2424 png_set_add_alpha(png_ptr, filler, PNG_FILLER_AFTER);
2425
2426where "filler" contains the alpha value to assign to each pixel.
2427The png_set_add_alpha() function was added in libpng-1.2.7.
2428
2429If you are reading an image with an alpha channel, and you need the
2430data as ARGB instead of the normal PNG format RGBA:
2431
2432 if (color_type == PNG_COLOR_TYPE_RGB_ALPHA)
2433 png_set_swap_alpha(png_ptr);
2434
2435For some uses, you may want a grayscale image to be represented as
2436RGB. This code will do that conversion:
2437
2438 if (color_type == PNG_COLOR_TYPE_GRAY ||
2439 color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
2440 png_set_gray_to_rgb(png_ptr);
2441
2442Conversely, you can convert an RGB or RGBA image to grayscale or grayscale
2443with alpha.
2444
2445 if (color_type == PNG_COLOR_TYPE_RGB ||
2446 color_type == PNG_COLOR_TYPE_RGB_ALPHA)
2447 png_set_rgb_to_gray(png_ptr, error_action,
2448 double red_weight, double green_weight);
2449
2450 error_action = 1: silently do the conversion
2451
2452 error_action = 2: issue a warning if the original
2453 image has any pixel where
2454 red != green or red != blue
2455
2456 error_action = 3: issue an error and abort the
2457 conversion if the original
2458 image has any pixel where
2459 red != green or red != blue
2460
2461 red_weight: weight of red component
2462
2463 green_weight: weight of green component
2464 If either weight is negative, default
2465 weights are used.
2466
2467In the corresponding fixed point API the red_weight and green_weight values are
2468simply scaled by 100,000:
2469
2470 png_set_rgb_to_gray(png_ptr, error_action,
2471 png_fixed_point red_weight,
2472 png_fixed_point green_weight);
2473
2474If you have set error_action = 1 or 2, you can
2475later check whether the image really was gray, after processing
2476the image rows, with the png_get_rgb_to_gray_status(png_ptr) function.
2477It will return a png_byte that is zero if the image was gray or
24781 if there were any non-gray pixels. Background and sBIT data
2479will be silently converted to grayscale, using the green channel
2480data for sBIT, regardless of the error_action setting.
2481
2482The default values come from the PNG file cHRM chunk if present; otherwise, the
2483defaults correspond to the ITU-R recommendation 709, and also the sRGB color
2484space, as recommended in the Charles Poynton's Colour FAQ,
2485Copyright (c) 2006-11-28 Charles Poynton, in section 9:
2486
2487<http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC9>
2488
2489 Y = 0.2126 * R + 0.7152 * G + 0.0722 * B
2490
2491Previous versions of this document, 1998 through 2002, recommended a slightly
2492different formula:
2493
2494 Y = 0.212671 * R + 0.715160 * G + 0.072169 * B
2495
2496Libpng uses an integer approximation:
2497
2498 Y = (6968 * R + 23434 * G + 2366 * B)/32768
2499
2500The calculation is done in a linear colorspace, if the image gamma
2501can be determined.
2502
2503The png_set_background() function has been described already; it tells libpng to
2504composite images with alpha or simple transparency against the supplied
2505background color. For compatibility with versions of libpng earlier than
2506libpng-1.5.4 it is recommended that you call the function after reading the file
2507header, even if you don't want to use the color in a bKGD chunk, if one exists.
2508
2509If the PNG file contains a bKGD chunk (PNG_INFO_bKGD valid),
2510you may use this color, or supply another color more suitable for
2511the current display (e.g., the background color from a web page). You
2512need to tell libpng how the color is represented, both the format of the
2513component values in the color (the number of bits) and the gamma encoding of the
2514color. The function takes two arguments, background_gamma_mode and need_expand
2515to convey this information; however, only two combinations are likely to be
2516useful:
2517
2518 png_color_16 my_background;
2519 png_color_16p image_background;
2520
2521 if (png_get_bKGD(png_ptr, info_ptr, &image_background))
2522 png_set_background(png_ptr, image_background,
2523 PNG_BACKGROUND_GAMMA_FILE, 1/*needs to be expanded*/, 1);
2524 else
2525 png_set_background(png_ptr, &my_background,
2526 PNG_BACKGROUND_GAMMA_SCREEN, 0/*do not expand*/, 1);
2527
2528The second call was described above - my_background is in the format of the
2529final, display, output produced by libpng. Because you now know the format of
2530the PNG it is possible to avoid the need to choose either 8-bit or 16-bit
2531output and to retain palette images (the palette colors will be modified
2532appropriately and the tRNS chunk removed.) However, if you are doing this,
2533take great care not to ask for transformations without checking first that
2534they apply!
2535
2536In the first call the background color has the original bit depth and color type
2537of the PNG file. So, for palette images the color is supplied as a palette
2538index and for low bit greyscale images the color is a reduced bit value in
2539image_background->gray.
2540
2541If you didn't call png_set_gamma() before reading the file header, for example
2542if you need your code to remain compatible with older versions of libpng prior
2543to libpng-1.5.4, this is the place to call it.
2544
2545Do not call it if you called png_set_alpha_mode(); doing so will damage the
2546settings put in place by png_set_alpha_mode(). (If png_set_alpha_mode() is
2547supported then you can certainly do png_set_gamma() before reading the PNG
2548header.)
2549
2550This API unconditionally sets the screen and file gamma values, so it will
2551override the value in the PNG file unless it is called before the PNG file
2552reading starts. For this reason you must always call it with the PNG file
2553value when you call it in this position:
2554
2555 if (png_get_gAMA(png_ptr, info_ptr, &file_gamma))
2556 png_set_gamma(png_ptr, screen_gamma, file_gamma);
2557
2558 else
2559 png_set_gamma(png_ptr, screen_gamma, 0.45455);
2560
2561If you need to reduce an RGB file to a paletted file, or if a paletted
2562file has more entries than will fit on your screen, png_set_quantize()
2563will do that. Note that this is a simple match quantization that merely
2564finds the closest color available. This should work fairly well with
2565optimized palettes, but fairly badly with linear color cubes. If you
2566pass a palette that is larger than maximum_colors, the file will
2567reduce the number of colors in the palette so it will fit into
2568maximum_colors. If there is a histogram, libpng will use it to make
2569more intelligent choices when reducing the palette. If there is no
2570histogram, it may not do as good a job.
2571
2572 if (color_type & PNG_COLOR_MASK_COLOR)
2573 {
2574 if (png_get_valid(png_ptr, info_ptr,
2575 PNG_INFO_PLTE))
2576 {
2577 png_uint_16p histogram = NULL;
2578
2579 png_get_hIST(png_ptr, info_ptr,
2580 &histogram);
2581 png_set_quantize(png_ptr, palette, num_palette,
2582 max_screen_colors, histogram, 1);
2583 }
2584
2585 else
2586 {
2587 png_color std_color_cube[MAX_SCREEN_COLORS] =
2588 { ... colors ... };
2589
2590 png_set_quantize(png_ptr, std_color_cube,
2591 MAX_SCREEN_COLORS, MAX_SCREEN_COLORS,
2592 NULL,0);
2593 }
2594 }
2595
2596PNG files describe monochrome as black being zero and white being one.
2597The following code will reverse this (make black be one and white be
2598zero):
2599
2600 if (bit_depth == 1 && color_type == PNG_COLOR_TYPE_GRAY)
2601 png_set_invert_mono(png_ptr);
2602
2603This function can also be used to invert grayscale and gray-alpha images:
2604
2605 if (color_type == PNG_COLOR_TYPE_GRAY ||
2606 color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
2607 png_set_invert_mono(png_ptr);
2608
2609PNG files store 16-bit pixels in network byte order (big-endian,
2610ie. most significant bits first). This code changes the storage to the
2611other way (little-endian, i.e. least significant bits first, the
2612way PCs store them):
2613
2614 if (bit_depth == 16)
2615 png_set_swap(png_ptr);
2616
2617If you are using packed-pixel images (1, 2, or 4 bits/pixel), and you
2618need to change the order the pixels are packed into bytes, you can use:
2619
2620 if (bit_depth < 8)
2621 png_set_packswap(png_ptr);
2622
2623Finally, you can write your own transformation function if none of
2624the existing ones meets your needs. This is done by setting a callback
2625with
2626
2627 png_set_read_user_transform_fn(png_ptr,
2628 read_transform_fn);
2629
2630You must supply the function
2631
2632 void read_transform_fn(png_structp png_ptr, png_row_infop
2633 row_info, png_bytep data)
2634
2635See pngtest.c for a working example. Your function will be called
2636after all of the other transformations have been processed. Take care with
2637interlaced images if you do the interlace yourself - the width of the row is the
2638width in 'row_info', not the overall image width.
2639
2640If supported, libpng provides two information routines that you can use to find
2641where you are in processing the image:
2642
2643 png_get_current_pass_number(png_structp png_ptr);
2644 png_get_current_row_number(png_structp png_ptr);
2645
2646Don't try using these outside a transform callback - firstly they are only
2647supported if user transforms are supported, secondly they may well return
2648unexpected results unless the row is actually being processed at the moment they
2649are called.
2650
2651With interlaced
2652images the value returned is the row in the input sub-image image. Use
2653PNG_ROW_FROM_PASS_ROW(row, pass) and PNG_COL_FROM_PASS_COL(col, pass) to
2654find the output pixel (x,y) given an interlaced sub-image pixel (row,col,pass).
2655
2656The discussion of interlace handling above contains more information on how to
2657use these values.
2658
2659You can also set up a pointer to a user structure for use by your
2660callback function, and you can inform libpng that your transform
2661function will change the number of channels or bit depth with the
2662function
2663
2664 png_set_user_transform_info(png_ptr, user_ptr,
2665 user_depth, user_channels);
2666
2667The user's application, not libpng, is responsible for allocating and
2668freeing any memory required for the user structure.
2669
2670You can retrieve the pointer via the function
2671png_get_user_transform_ptr(). For example:
2672
2673 voidp read_user_transform_ptr =
2674 png_get_user_transform_ptr(png_ptr);
2675
2676The last thing to handle is interlacing; this is covered in detail below,
2677but you must call the function here if you want libpng to handle expansion
2678of the interlaced image.
2679
2680 number_of_passes = png_set_interlace_handling(png_ptr);
2681
2682After setting the transformations, libpng can update your png_info
2683structure to reflect any transformations you've requested with this
2684call.
2685
2686 png_read_update_info(png_ptr, info_ptr);
2687
2688This is most useful to update the info structure's rowbytes
2689field so you can use it to allocate your image memory. This function
2690will also update your palette with the correct screen_gamma and
2691background if these have been given with the calls above. You may
2692only call png_read_update_info() once with a particular info_ptr.
2693
2694After you call png_read_update_info(), you can allocate any
2695memory you need to hold the image. The row data is simply
2696raw byte data for all forms of images. As the actual allocation
2697varies among applications, no example will be given. If you
2698are allocating one large chunk, you will need to build an
2699array of pointers to each row, as it will be needed for some
2700of the functions below.
2701
2702Be sure that your platform can allocate the buffer that you'll need.
2703libpng internally checks for oversize width, but you'll need to
2704do your own check for number_of_rows*width*pixel_size if you are using
2705a multiple-row buffer:
2706
2707 /* Guard against integer overflow */
2708 if (number_of_rows > PNG_SIZE_MAX/(width*pixel_size)) {
2709 png_error(png_ptr,"image_data buffer would be too large");
2710 }
2711
2712Remember: Before you call png_read_update_info(), the png_get_*()
2713functions return the values corresponding to the original PNG image.
2714After you call png_read_update_info the values refer to the image
2715that libpng will output. Consequently you must call all the png_set_
2716functions before you call png_read_update_info(). This is particularly
2717important for png_set_interlace_handling() - if you are going to call
2718png_read_update_info() you must call png_set_interlace_handling() before
2719it unless you want to receive interlaced output.
2720
2721.SS Reading image data
2722
2723After you've allocated memory, you can read the image data.
2724The simplest way to do this is in one function call. If you are
2725allocating enough memory to hold the whole image, you can just
2726call png_read_image() and libpng will read in all the image data
2727and put it in the memory area supplied. You will need to pass in
2728an array of pointers to each row.
2729
2730This function automatically handles interlacing, so you don't
2731need to call png_set_interlace_handling() (unless you call
2732png_read_update_info()) or call this function multiple times, or any
2733of that other stuff necessary with png_read_rows().
2734
2735 png_read_image(png_ptr, row_pointers);
2736
2737where row_pointers is:
2738
2739 png_bytep row_pointers[height];
2740
2741You can point to void or char or whatever you use for pixels.
2742
2743If you don't want to read in the whole image at once, you can
2744use png_read_rows() instead. If there is no interlacing (check
2745interlace_type == PNG_INTERLACE_NONE), this is simple:
2746
2747 png_read_rows(png_ptr, row_pointers, NULL,
2748 number_of_rows);
2749
2750where row_pointers is the same as in the png_read_image() call.
2751
2752If you are doing this just one row at a time, you can do this with
2753a single row_pointer instead of an array of row_pointers:
2754
2755 png_bytep row_pointer = row;
2756 png_read_row(png_ptr, row_pointer, NULL);
2757
2758If the file is interlaced (interlace_type != 0 in the IHDR chunk), things
2759get somewhat harder. The only current (PNG Specification version 1.2)
2760interlacing type for PNG is (interlace_type == PNG_INTERLACE_ADAM7);
2761a somewhat complicated 2D interlace scheme, known as Adam7, that
2762breaks down an image into seven smaller images of varying size, based
2763on an 8x8 grid. This number is defined (from libpng 1.5) as
2764PNG_INTERLACE_ADAM7_PASSES in png.h
2765
2766libpng can fill out those images or it can give them to you "as is".
2767It is almost always better to have libpng handle the interlacing for you.
2768If you want the images filled out, there are two ways to do that. The one
2769mentioned in the PNG specification is to expand each pixel to cover
2770those pixels that have not been read yet (the "rectangle" method).
2771This results in a blocky image for the first pass, which gradually
2772smooths out as more pixels are read. The other method is the "sparkle"
2773method, where pixels are drawn only in their final locations, with the
2774rest of the image remaining whatever colors they were initialized to
2775before the start of the read. The first method usually looks better,
2776but tends to be slower, as there are more pixels to put in the rows.
2777
2778If, as is likely, you want libpng to expand the images, call this before
2779calling png_start_read_image() or png_read_update_info():
2780
2781 if (interlace_type == PNG_INTERLACE_ADAM7)
2782 number_of_passes
2783 = png_set_interlace_handling(png_ptr);
2784
2785This will return the number of passes needed. Currently, this is seven,
2786but may change if another interlace type is added. This function can be
2787called even if the file is not interlaced, where it will return one pass.
2788You then need to read the whole image 'number_of_passes' times. Each time
2789will distribute the pixels from the current pass to the correct place in
2790the output image, so you need to supply the same rows to png_read_rows in
2791each pass.
2792
2793If you are not going to display the image after each pass, but are
2794going to wait until the entire image is read in, use the sparkle
2795effect. This effect is faster and the end result of either method
2796is exactly the same. If you are planning on displaying the image
2797after each pass, the "rectangle" effect is generally considered the
2798better looking one.
2799
2800If you only want the "sparkle" effect, just call png_read_row() or
2801png_read_rows() as
2802normal, with the third parameter NULL. Make sure you make pass over
2803the image number_of_passes times, and you don't change the data in the
2804rows between calls. You can change the locations of the data, just
2805not the data. Each pass only writes the pixels appropriate for that
2806pass, and assumes the data from previous passes is still valid.
2807
2808 png_read_rows(png_ptr, row_pointers, NULL,
2809 number_of_rows);
2810 or
2811 png_read_row(png_ptr, row_pointers, NULL);
2812
2813If you only want the first effect (the rectangles), do the same as
2814before except pass the row buffer in the third parameter, and leave
2815the second parameter NULL.
2816
2817 png_read_rows(png_ptr, NULL, row_pointers,
2818 number_of_rows);
2819 or
2820 png_read_row(png_ptr, NULL, row_pointers);
2821
2822If you don't want libpng to handle the interlacing details, just call
2823png_read_rows() PNG_INTERLACE_ADAM7_PASSES times to read in all the images.
2824Each of the images is a valid image by itself; however, you will almost
2825certainly need to distribute the pixels from each sub-image to the
2826correct place. This is where everything gets very tricky.
2827
2828If you want to retrieve the separate images you must pass the correct
2829number of rows to each successive call of png_read_rows(). The calculation
2830gets pretty complicated for small images, where some sub-images may
2831not even exist because either their width or height ends up zero.
2832libpng provides two macros to help you in 1.5 and later versions:
2833
2834 png_uint_32 width = PNG_PASS_COLS(image_width, pass_number);
2835 png_uint_32 height = PNG_PASS_ROWS(image_height, pass_number);
2836
2837Respectively these tell you the width and height of the sub-image
2838corresponding to the numbered pass. 'pass' is in in the range 0 to 6 -
2839this can be confusing because the specification refers to the same passes
2840as 1 to 7! Be careful, you must check both the width and height before
2841calling png_read_rows() and not call it for that pass if either is zero.
2842
2843You can, of course, read each sub-image row by row. If you want to
2844produce optimal code to make a pixel-by-pixel transformation of an
2845interlaced image this is the best approach; read each row of each pass,
2846transform it, and write it out to a new interlaced image.
2847
2848If you want to de-interlace the image yourself libpng provides further
2849macros to help that tell you where to place the pixels in the output image.
2850Because the interlacing scheme is rectangular - sub-image pixels are always
2851arranged on a rectangular grid - all you need to know for each pass is the
2852starting column and row in the output image of the first pixel plus the
2853spacing between each pixel. As of libpng 1.5 there are four macros to
2854retrieve this information:
2855
2856 png_uint_32 x = PNG_PASS_START_COL(pass);
2857 png_uint_32 y = PNG_PASS_START_ROW(pass);
2858 png_uint_32 xStep = 1U << PNG_PASS_COL_SHIFT(pass);
2859 png_uint_32 yStep = 1U << PNG_PASS_ROW_SHIFT(pass);
2860
2861These allow you to write the obvious loop:
2862
2863 png_uint_32 input_y = 0;
2864 png_uint_32 output_y = PNG_PASS_START_ROW(pass);
2865
2866 while (output_y < output_image_height)
2867 {
2868 png_uint_32 input_x = 0;
2869 png_uint_32 output_x = PNG_PASS_START_COL(pass);
2870
2871 while (output_x < output_image_width)
2872 {
2873 image[output_y][output_x] =
2874 subimage[pass][input_y][input_x++];
2875
2876 output_x += xStep;
2877 }
2878
2879 ++input_y;
2880 output_y += yStep;
2881 }
2882
2883Notice that the steps between successive output rows and columns are
2884returned as shifts. This is possible because the pixels in the subimages
2885are always a power of 2 apart - 1, 2, 4 or 8 pixels - in the original
2886image. In practice you may need to directly calculate the output coordinate
2887given an input coordinate. libpng provides two further macros for this
2888purpose:
2889
2890 png_uint_32 output_x = PNG_COL_FROM_PASS_COL(input_x, pass);
2891 png_uint_32 output_y = PNG_ROW_FROM_PASS_ROW(input_y, pass);
2892
2893Finally a pair of macros are provided to tell you if a particular image
2894row or column appears in a given pass:
2895
2896 int col_in_pass = PNG_COL_IN_INTERLACE_PASS(output_x, pass);
2897 int row_in_pass = PNG_ROW_IN_INTERLACE_PASS(output_y, pass);
2898
2899Bear in mind that you will probably also need to check the width and height
2900of the pass in addition to the above to be sure the pass even exists!
2901
2902With any luck you are convinced by now that you don't want to do your own
2903interlace handling. In reality normally the only good reason for doing this
2904is if you are processing PNG files on a pixel-by-pixel basis and don't want
2905to load the whole file into memory when it is interlaced.
2906
2907libpng includes a test program, pngvalid, that illustrates reading and
2908writing of interlaced images. If you can't get interlacing to work in your
2909code and don't want to leave it to libpng (the recommended approach), see
2910how pngvalid.c does it.
2911
2912.SS Finishing a sequential read
2913
2914After you are finished reading the image through the
2915low-level interface, you can finish reading the file.
2916
2917If you want to use a different crc action for handling CRC errors in
2918chunks after the image data, you can call png_set_crc_action()
2919again at this point.
2920
2921If you are interested in comments or time, which may be stored either
2922before or after the image data, you should pass the separate png_info
2923struct if you want to keep the comments from before and after the image
2924separate.
2925
2926 png_infop end_info = png_create_info_struct(png_ptr);
2927
2928 if (!end_info)
2929 {
2930 png_destroy_read_struct(&png_ptr, &info_ptr,
2931 (png_infopp)NULL);
2932 return ERROR;
2933 }
2934
2935 png_read_end(png_ptr, end_info);
2936
2937If you are not interested, you should still call png_read_end()
2938but you can pass NULL, avoiding the need to create an end_info structure.
2939If you do this, libpng will not process any chunks after IDAT other than
2940skipping over them and perhaps (depending on whether you have called
2941png_set_crc_action) checking their CRCs while looking for the IEND chunk.
2942
2943 png_read_end(png_ptr, (png_infop)NULL);
2944
2945If you don't call png_read_end(), then your file pointer will be
2946left pointing to the first chunk after the last IDAT, which is probably
2947not what you want if you expect to read something beyond the end of
2948the PNG datastream.
2949
2950When you are done, you can free all memory allocated by libpng like this:
2951
2952 png_destroy_read_struct(&png_ptr, &info_ptr,
2953 &end_info);
2954
2955or, if you didn't create an end_info structure,
2956
2957 png_destroy_read_struct(&png_ptr, &info_ptr,
2958 (png_infopp)NULL);
2959
2960It is also possible to individually free the info_ptr members that
2961point to libpng-allocated storage with the following function:
2962
2963 png_free_data(png_ptr, info_ptr, mask, seq)
2964
2965 mask - identifies data to be freed, a mask
2966 containing the bitwise OR of one or
2967 more of
2968 PNG_FREE_PLTE, PNG_FREE_TRNS,
2969 PNG_FREE_HIST, PNG_FREE_ICCP,
2970 PNG_FREE_PCAL, PNG_FREE_ROWS,
2971 PNG_FREE_SCAL, PNG_FREE_SPLT,
2972 PNG_FREE_TEXT, PNG_FREE_UNKN,
2973 or simply PNG_FREE_ALL
2974
2975 seq - sequence number of item to be freed
2976 (\-1 for all items)
2977
2978This function may be safely called when the relevant storage has
2979already been freed, or has not yet been allocated, or was allocated
2980by the user and not by libpng, and will in those cases do nothing.
2981The "seq" parameter is ignored if only one item of the selected data
2982type, such as PLTE, is allowed. If "seq" is not \-1, and multiple items
2983are allowed for the data type identified in the mask, such as text or
2984sPLT, only the n'th item in the structure is freed, where n is "seq".
2985
2986The default behavior is only to free data that was allocated internally
2987by libpng. This can be changed, so that libpng will not free the data,
2988or so that it will free data that was allocated by the user with png_malloc()
2989or png_calloc() and passed in via a png_set_*() function, with
2990
2991 png_data_freer(png_ptr, info_ptr, freer, mask)
2992
2993 freer - one of
2994 PNG_DESTROY_WILL_FREE_DATA
2995 PNG_SET_WILL_FREE_DATA
2996 PNG_USER_WILL_FREE_DATA
2997
2998 mask - which data elements are affected
2999 same choices as in png_free_data()
3000
3001This function only affects data that has already been allocated.
3002You can call this function after reading the PNG data but before calling
3003any png_set_*() functions, to control whether the user or the png_set_*()
3004function is responsible for freeing any existing data that might be present,
3005and again after the png_set_*() functions to control whether the user
3006or png_destroy_*() is supposed to free the data. When the user assumes
3007responsibility for libpng-allocated data, the application must use
3008png_free() to free it, and when the user transfers responsibility to libpng
3009for data that the user has allocated, the user must have used png_malloc()
3010or png_calloc() to allocate it.
3011
3012If you allocated your row_pointers in a single block, as suggested above in
3013the description of the high level read interface, you must not transfer
3014responsibility for freeing it to the png_set_rows or png_read_destroy function,
3015because they would also try to free the individual row_pointers[i].
3016
3017If you allocated text_ptr.text, text_ptr.lang, and text_ptr.translated_keyword
3018separately, do not transfer responsibility for freeing text_ptr to libpng,
3019because when libpng fills a png_text structure it combines these members with
3020the key member, and png_free_data() will free only text_ptr.key. Similarly,
3021if you transfer responsibility for free'ing text_ptr from libpng to your
3022application, your application must not separately free those members.
3023
3024The png_free_data() function will turn off the "valid" flag for anything
3025it frees. If you need to turn the flag off for a chunk that was freed by
3026your application instead of by libpng, you can use
3027
3028 png_set_invalid(png_ptr, info_ptr, mask);
3029
3030 mask - identifies the chunks to be made invalid,
3031 containing the bitwise OR of one or
3032 more of
3033 PNG_INFO_gAMA, PNG_INFO_sBIT,
3034 PNG_INFO_cHRM, PNG_INFO_PLTE,
3035 PNG_INFO_tRNS, PNG_INFO_bKGD,
3036 PNG_INFO_eXIf,
3037 PNG_INFO_hIST, PNG_INFO_pHYs,
3038 PNG_INFO_oFFs, PNG_INFO_tIME,
3039 PNG_INFO_pCAL, PNG_INFO_sRGB,
3040 PNG_INFO_iCCP, PNG_INFO_sPLT,
3041 PNG_INFO_sCAL, PNG_INFO_IDAT
3042
3043For a more compact example of reading a PNG image, see the file example.c.
3044
3045.SS Reading PNG files progressively
3046
3047The progressive reader is slightly different from the non-progressive
3048reader. Instead of calling png_read_info(), png_read_rows(), and
3049png_read_end(), you make one call to png_process_data(), which calls
3050callbacks when it has the info, a row, or the end of the image. You
3051set up these callbacks with png_set_progressive_read_fn(). You don't
3052have to worry about the input/output functions of libpng, as you are
3053giving the library the data directly in png_process_data(). I will
3054assume that you have read the section on reading PNG files above,
3055so I will only highlight the differences (although I will show
3056all of the code).
3057
3058png_structp png_ptr;
3059png_infop info_ptr;
3060
3061 /* An example code fragment of how you would
3062 initialize the progressive reader in your
3063 application. */
3064 int
3065 initialize_png_reader()
3066 {
3067 png_ptr = png_create_read_struct
3068 (PNG_LIBPNG_VER_STRING, (png_voidp)user_error_ptr,
3069 user_error_fn, user_warning_fn);
3070
3071 if (!png_ptr)
3072 return ERROR;
3073
3074 info_ptr = png_create_info_struct(png_ptr);
3075
3076 if (!info_ptr)
3077 {
3078 png_destroy_read_struct(&png_ptr,
3079 (png_infopp)NULL, (png_infopp)NULL);
3080 return ERROR;
3081 }
3082
3083 if (setjmp(png_jmpbuf(png_ptr)))
3084 {
3085 png_destroy_read_struct(&png_ptr, &info_ptr,
3086 (png_infopp)NULL);
3087 return ERROR;
3088 }
3089
3090 /* This one's new. You can provide functions
3091 to be called when the header info is valid,
3092 when each row is completed, and when the image
3093 is finished. If you aren't using all functions,
3094 you can specify NULL parameters. Even when all
3095 three functions are NULL, you need to call
3096 png_set_progressive_read_fn(). You can use
3097 any struct as the user_ptr (cast to a void pointer
3098 for the function call), and retrieve the pointer
3099 from inside the callbacks using the function
3100
3101 png_get_progressive_ptr(png_ptr);
3102
3103 which will return a void pointer, which you have
3104 to cast appropriately.
3105 */
3106 png_set_progressive_read_fn(png_ptr, (void *)user_ptr,
3107 info_callback, row_callback, end_callback);
3108
3109 return 0;
3110 }
3111
3112 /* A code fragment that you call as you receive blocks
3113 of data */
3114 int
3115 process_data(png_bytep buffer, png_uint_32 length)
3116 {
3117 if (setjmp(png_jmpbuf(png_ptr)))
3118 {
3119 png_destroy_read_struct(&png_ptr, &info_ptr,
3120 (png_infopp)NULL);
3121 return ERROR;
3122 }
3123
3124 /* This one's new also. Simply give it a chunk
3125 of data from the file stream (in order, of
3126 course). On machines with segmented memory
3127 models machines, don't give it any more than
3128 64K. The library seems to run fine with sizes
3129 of 4K. Although you can give it much less if
3130 necessary (I assume you can give it chunks of
3131 1 byte, I haven't tried less than 256 bytes
3132 yet). When this function returns, you may
3133 want to display any rows that were generated
3134 in the row callback if you don't already do
3135 so there.
3136 */
3137 png_process_data(png_ptr, info_ptr, buffer, length);
3138
3139 /* At this point you can call png_process_data_skip if
3140 you want to handle data the library will skip yourself;
3141 it simply returns the number of bytes to skip (and stops
3142 libpng skipping that number of bytes on the next
3143 png_process_data call).
3144 return 0;
3145 }
3146
3147 /* This function is called (as set by
3148 png_set_progressive_read_fn() above) when enough data
3149 has been supplied so all of the header has been
3150 read.
3151 */
3152 void
3153 info_callback(png_structp png_ptr, png_infop info)
3154 {
3155 /* Do any setup here, including setting any of
3156 the transformations mentioned in the Reading
3157 PNG files section. For now, you _must_ call
3158 either png_start_read_image() or
3159 png_read_update_info() after all the
3160 transformations are set (even if you don't set
3161 any). You may start getting rows before
3162 png_process_data() returns, so this is your
3163 last chance to prepare for that.
3164
3165 This is where you turn on interlace handling,
3166 assuming you don't want to do it yourself.
3167
3168 If you need to you can stop the processing of
3169 your original input data at this point by calling
3170 png_process_data_pause. This returns the number
3171 of unprocessed bytes from the last png_process_data
3172 call - it is up to you to ensure that the next call
3173 sees these bytes again. If you don't want to bother
3174 with this you can get libpng to cache the unread
3175 bytes by setting the 'save' parameter (see png.h) but
3176 then libpng will have to copy the data internally.
3177 */
3178 }
3179
3180 /* This function is called when each row of image
3181 data is complete */
3182 void
3183 row_callback(png_structp png_ptr, png_bytep new_row,
3184 png_uint_32 row_num, int pass)
3185 {
3186 /* If the image is interlaced, and you turned
3187 on the interlace handler, this function will
3188 be called for every row in every pass. Some
3189 of these rows will not be changed from the
3190 previous pass. When the row is not changed,
3191 the new_row variable will be NULL. The rows
3192 and passes are called in order, so you don't
3193 really need the row_num and pass, but I'm
3194 supplying them because it may make your life
3195 easier.
3196
3197 If you did not turn on interlace handling then
3198 the callback is called for each row of each
3199 sub-image when the image is interlaced. In this
3200 case 'row_num' is the row in the sub-image, not
3201 the row in the output image as it is in all other
3202 cases.
3203
3204 For the non-NULL rows of interlaced images when
3205 you have switched on libpng interlace handling,
3206 you must call png_progressive_combine_row()
3207 passing in the row and the old row. You can
3208 call this function for NULL rows (it will just
3209 return) and for non-interlaced images (it just
3210 does the memcpy for you) if it will make the
3211 code easier. Thus, you can just do this for
3212 all cases if you switch on interlace handling;
3213 */
3214
3215 png_progressive_combine_row(png_ptr, old_row,
3216 new_row);
3217
3218 /* where old_row is what was displayed
3219 previously for the row. Note that the first
3220 pass (pass == 0, really) will completely cover
3221 the old row, so the rows do not have to be
3222 initialized. After the first pass (and only
3223 for interlaced images), you will have to pass
3224 the current row, and the function will combine
3225 the old row and the new row.
3226
3227 You can also call png_process_data_pause in this
3228 callback - see above.
3229 */
3230 }
3231
3232 void
3233 end_callback(png_structp png_ptr, png_infop info)
3234 {
3235 /* This function is called after the whole image
3236 has been read, including any chunks after the
3237 image (up to and including the IEND). You
3238 will usually have the same info chunk as you
3239 had in the header, although some data may have
3240 been added to the comments and time fields.
3241
3242 Most people won't do much here, perhaps setting
3243 a flag that marks the image as finished.
3244 */
3245 }
3246
3247
3248
3249.SH IV. Writing
3250
3251Much of this is very similar to reading. However, everything of
3252importance is repeated here, so you won't have to constantly look
3253back up in the reading section to understand writing.
3254
3255.SS Setup
3256
3257You will want to do the I/O initialization before you get into libpng,
3258so if it doesn't work, you don't have anything to undo. If you are not
3259using the standard I/O functions, you will need to replace them with
3260custom writing functions. See the discussion under Customizing libpng.
3261
3262 FILE *fp = fopen(file_name, "wb");
3263
3264 if (!fp)
3265 return ERROR;
3266
3267Next, png_struct and png_info need to be allocated and initialized.
3268As these can be both relatively large, you may not want to store these
3269on the stack, unless you have stack space to spare. Of course, you
3270will want to check if they return NULL. If you are also reading,
3271you won't want to name your read structure and your write structure
3272both "png_ptr"; you can call them anything you like, such as
3273"read_ptr" and "write_ptr". Look at pngtest.c, for example.
3274
3275 png_structp png_ptr = png_create_write_struct
3276 (PNG_LIBPNG_VER_STRING, (png_voidp)user_error_ptr,
3277 user_error_fn, user_warning_fn);
3278
3279 if (!png_ptr)
3280 return ERROR;
3281
3282 png_infop info_ptr = png_create_info_struct(png_ptr);
3283 if (!info_ptr)
3284 {
3285 png_destroy_write_struct(&png_ptr,
3286 (png_infopp)NULL);
3287 return ERROR;
3288 }
3289
3290If you want to use your own memory allocation routines,
3291define PNG_USER_MEM_SUPPORTED and use
3292png_create_write_struct_2() instead of png_create_write_struct():
3293
3294 png_structp png_ptr = png_create_write_struct_2
3295 (PNG_LIBPNG_VER_STRING, (png_voidp)user_error_ptr,
3296 user_error_fn, user_warning_fn, (png_voidp)
3297 user_mem_ptr, user_malloc_fn, user_free_fn);
3298
3299After you have these structures, you will need to set up the
3300error handling. When libpng encounters an error, it expects to
3301longjmp() back to your routine. Therefore, you will need to call
3302setjmp() and pass the png_jmpbuf(png_ptr). If you
3303write the file from different routines, you will need to update
3304the png_jmpbuf(png_ptr) every time you enter a new routine that will
3305call a png_*() function. See your documentation of setjmp/longjmp
3306for your compiler for more information on setjmp/longjmp. See
3307the discussion on libpng error handling in the Customizing Libpng
3308section below for more information on the libpng error handling.
3309
3310 if (setjmp(png_jmpbuf(png_ptr)))
3311 {
3312 png_destroy_write_struct(&png_ptr, &info_ptr);
3313 fclose(fp);
3314 return ERROR;
3315 }
3316 ...
3317 return;
3318
3319If you would rather avoid the complexity of setjmp/longjmp issues,
3320you can compile libpng with PNG_NO_SETJMP, in which case
3321errors will result in a call to PNG_ABORT() which defaults to abort().
3322
3323You can #define PNG_ABORT() to a function that does something
3324more useful than abort(), as long as your function does not
3325return.
3326
3327Checking for invalid palette index on write was added at libpng
33281.5.10. If a pixel contains an invalid (out-of-range) index libpng issues
3329a benign error. This is enabled by default because this condition is an
3330error according to the PNG specification, Clause 11.3.2, but the error can
3331be ignored in each png_ptr with
3332
3333 png_set_check_for_invalid_index(png_ptr, 0);
3334
3335If the error is ignored, or if png_benign_error() treats it as a warning,
3336any invalid pixels are written as-is by the encoder, resulting in an
3337invalid PNG datastream as output. In this case the application is
3338responsible for ensuring that the pixel indexes are in range when it writes
3339a PLTE chunk with fewer entries than the bit depth would allow.
3340
3341Now you need to set up the output code. The default for libpng is to
3342use the C function fwrite(). If you use this, you will need to pass a
3343valid FILE * in the function png_init_io(). Be sure that the file is
3344opened in binary mode. Again, if you wish to handle writing data in
3345another way, see the discussion on libpng I/O handling in the Customizing
3346Libpng section below.
3347
3348 png_init_io(png_ptr, fp);
3349
3350If you are embedding your PNG into a datastream such as MNG, and don't
3351want libpng to write the 8-byte signature, or if you have already
3352written the signature in your application, use
3353
3354 png_set_sig_bytes(png_ptr, 8);
3355
3356to inform libpng that it should not write a signature.
3357
3358.SS Write callbacks
3359
3360At this point, you can set up a callback function that will be
3361called after each row has been written, which you can use to control
3362a progress meter or the like. It's demonstrated in pngtest.c.
3363You must supply a function
3364
3365 void write_row_callback(png_structp png_ptr, png_uint_32 row,
3366 int pass);
3367 {
3368 /* put your code here */
3369 }
3370
3371(You can give it another name that you like instead of "write_row_callback")
3372
3373To inform libpng about your function, use
3374
3375 png_set_write_status_fn(png_ptr, write_row_callback);
3376
3377When this function is called the row has already been completely processed and
3378it has also been written out. The 'row' and 'pass' refer to the next row to be
3379handled. For the
3380non-interlaced case the row that was just handled is simply one less than the
3381passed in row number, and pass will always be 0. For the interlaced case the
3382same applies unless the row value is 0, in which case the row just handled was
3383the last one from one of the preceding passes. Because interlacing may skip a
3384pass you cannot be sure that the preceding pass is just 'pass\-1', if you really
3385need to know what the last pass is record (row,pass) from the callback and use
3386the last recorded value each time.
3387
3388As with the user transform you can find the output row using the
3389PNG_ROW_FROM_PASS_ROW macro.
3390
3391You now have the option of modifying how the compression library will
3392run. The following functions are mainly for testing, but may be useful
3393in some cases, like if you need to write PNG files extremely fast and
3394are willing to give up some compression, or if you want to get the
3395maximum possible compression at the expense of slower writing. If you
3396have no special needs in this area, let the library do what it wants by
3397not calling this function at all, as it has been tuned to deliver a good
3398speed/compression ratio. The second parameter to png_set_filter() is
3399the filter method, for which the only valid values are 0 (as of the
3400July 1999 PNG specification, version 1.2) or 64 (if you are writing
3401a PNG datastream that is to be embedded in a MNG datastream). The third
3402parameter is a flag that indicates which filter type(s) are to be tested
3403for each scanline. See the PNG specification for details on the specific
3404filter types.
3405
3406
3407 /* turn on or off filtering, and/or choose
3408 specific filters. You can use either a single
3409 PNG_FILTER_VALUE_NAME or the bitwise OR of one
3410 or more PNG_FILTER_NAME masks.
3411 */
3412 png_set_filter(png_ptr, 0,
3413 PNG_FILTER_NONE | PNG_FILTER_VALUE_NONE |
3414 PNG_FILTER_SUB | PNG_FILTER_VALUE_SUB |
3415 PNG_FILTER_UP | PNG_FILTER_VALUE_UP |
3416 PNG_FILTER_AVG | PNG_FILTER_VALUE_AVG |
3417 PNG_FILTER_PAETH | PNG_FILTER_VALUE_PAETH|
3418 PNG_ALL_FILTERS | PNG_FAST_FILTERS);
3419
3420If an application wants to start and stop using particular filters during
3421compression, it should start out with all of the filters (to ensure that
3422the previous row of pixels will be stored in case it's needed later),
3423and then add and remove them after the start of compression.
3424
3425If you are writing a PNG datastream that is to be embedded in a MNG
3426datastream, the second parameter can be either 0 or 64.
3427
3428The png_set_compression_*() functions interface to the zlib compression
3429library, and should mostly be ignored unless you really know what you are
3430doing. The only generally useful call is png_set_compression_level()
3431which changes how much time zlib spends on trying to compress the image
3432data. See the Compression Library (zlib.h and algorithm.txt, distributed
3433with zlib) for details on the compression levels.
3434
3435 #include zlib.h
3436
3437 /* Set the zlib compression level */
3438 png_set_compression_level(png_ptr,
3439 Z_BEST_COMPRESSION);
3440
3441 /* Set other zlib parameters for compressing IDAT */
3442 png_set_compression_mem_level(png_ptr, 8);
3443 png_set_compression_strategy(png_ptr,
3444 Z_DEFAULT_STRATEGY);
3445 png_set_compression_window_bits(png_ptr, 15);
3446 png_set_compression_method(png_ptr, 8);
3447 png_set_compression_buffer_size(png_ptr, 8192)
3448
3449 /* Set zlib parameters for text compression
3450 * If you don't call these, the parameters
3451 * fall back on those defined for IDAT chunks
3452 */
3453 png_set_text_compression_mem_level(png_ptr, 8);
3454 png_set_text_compression_strategy(png_ptr,
3455 Z_DEFAULT_STRATEGY);
3456 png_set_text_compression_window_bits(png_ptr, 15);
3457 png_set_text_compression_method(png_ptr, 8);
3458
3459.SS Setting the contents of info for output
3460
3461You now need to fill in the png_info structure with all the data you
3462wish to write before the actual image. Note that the only thing you
3463are allowed to write after the image is the text chunks and the time
3464chunk (as of PNG Specification 1.2, anyway). See png_write_end() and
3465the latest PNG specification for more information on that. If you
3466wish to write them before the image, fill them in now, and flag that
3467data as being valid. If you want to wait until after the data, don't
3468fill them until png_write_end(). For all the fields in png_info and
3469their data types, see png.h. For explanations of what the fields
3470contain, see the PNG specification.
3471
3472Some of the more important parts of the png_info are:
3473
3474 png_set_IHDR(png_ptr, info_ptr, width, height,
3475 bit_depth, color_type, interlace_type,
3476 compression_type, filter_method)
3477
3478 width - holds the width of the image
3479 in pixels (up to 2^31).
3480
3481 height - holds the height of the image
3482 in pixels (up to 2^31).
3483
3484 bit_depth - holds the bit depth of one of the
3485 image channels.
3486 (valid values are 1, 2, 4, 8, 16
3487 and depend also on the
3488 color_type. See also significant
3489 bits (sBIT) below).
3490
3491 color_type - describes which color/alpha
3492 channels are present.
3493 PNG_COLOR_TYPE_GRAY
3494 (bit depths 1, 2, 4, 8, 16)
3495 PNG_COLOR_TYPE_GRAY_ALPHA
3496 (bit depths 8, 16)
3497 PNG_COLOR_TYPE_PALETTE
3498 (bit depths 1, 2, 4, 8)
3499 PNG_COLOR_TYPE_RGB
3500 (bit_depths 8, 16)
3501 PNG_COLOR_TYPE_RGB_ALPHA
3502 (bit_depths 8, 16)
3503
3504 PNG_COLOR_MASK_PALETTE
3505 PNG_COLOR_MASK_COLOR
3506 PNG_COLOR_MASK_ALPHA
3507
3508 interlace_type - PNG_INTERLACE_NONE or
3509 PNG_INTERLACE_ADAM7
3510
3511 compression_type - (must be
3512 PNG_COMPRESSION_TYPE_DEFAULT)
3513
3514 filter_method - (must be PNG_FILTER_TYPE_DEFAULT
3515 or, if you are writing a PNG to
3516 be embedded in a MNG datastream,
3517 can also be
3518 PNG_INTRAPIXEL_DIFFERENCING)
3519
3520If you call png_set_IHDR(), the call must appear before any of the
3521other png_set_*() functions, because they might require access to some of
3522the IHDR settings. The remaining png_set_*() functions can be called
3523in any order.
3524
3525If you wish, you can reset the compression_type, interlace_type, or
3526filter_method later by calling png_set_IHDR() again; if you do this, the
3527width, height, bit_depth, and color_type must be the same in each call.
3528
3529 png_set_PLTE(png_ptr, info_ptr, palette,
3530 num_palette);
3531
3532 palette - the palette for the file
3533 (array of png_color)
3534 num_palette - number of entries in the palette
3535
3536
3537 png_set_gAMA(png_ptr, info_ptr, file_gamma);
3538 png_set_gAMA_fixed(png_ptr, info_ptr, int_file_gamma);
3539
3540 file_gamma - the gamma at which the image was
3541 created (PNG_INFO_gAMA)
3542
3543 int_file_gamma - 100,000 times the gamma at which
3544 the image was created
3545
3546 png_set_cHRM(png_ptr, info_ptr, white_x, white_y, red_x, red_y,
3547 green_x, green_y, blue_x, blue_y)
3548 png_set_cHRM_XYZ(png_ptr, info_ptr, red_X, red_Y, red_Z, green_X,
3549 green_Y, green_Z, blue_X, blue_Y, blue_Z)
3550 png_set_cHRM_fixed(png_ptr, info_ptr, int_white_x, int_white_y,
3551 int_red_x, int_red_y, int_green_x, int_green_y,
3552 int_blue_x, int_blue_y)
3553 png_set_cHRM_XYZ_fixed(png_ptr, info_ptr, int_red_X, int_red_Y,
3554 int_red_Z, int_green_X, int_green_Y, int_green_Z,
3555 int_blue_X, int_blue_Y, int_blue_Z)
3556
3557 {white,red,green,blue}_{x,y}
3558 A color space encoding specified using the chromaticities
3559 of the end points and the white point.
3560
3561 {red,green,blue}_{X,Y,Z}
3562 A color space encoding specified using the encoding end
3563 points - the CIE tristimulus specification of the intended
3564 color of the red, green and blue channels in the PNG RGB
3565 data. The white point is simply the sum of the three end
3566 points.
3567
3568 png_set_sRGB(png_ptr, info_ptr, srgb_intent);
3569
3570 srgb_intent - the rendering intent
3571 (PNG_INFO_sRGB) The presence of
3572 the sRGB chunk means that the pixel
3573 data is in the sRGB color space.
3574 This chunk also implies specific
3575 values of gAMA and cHRM. Rendering
3576 intent is the CSS-1 property that
3577 has been defined by the International
3578 Color Consortium
3579 (http://www.color.org).
3580 It can be one of
3581 PNG_sRGB_INTENT_SATURATION,
3582 PNG_sRGB_INTENT_PERCEPTUAL,
3583 PNG_sRGB_INTENT_ABSOLUTE, or
3584 PNG_sRGB_INTENT_RELATIVE.
3585
3586
3587 png_set_sRGB_gAMA_and_cHRM(png_ptr, info_ptr,
3588 srgb_intent);
3589
3590 srgb_intent - the rendering intent
3591 (PNG_INFO_sRGB) The presence of the
3592 sRGB chunk means that the pixel
3593 data is in the sRGB color space.
3594 This function also causes gAMA and
3595 cHRM chunks with the specific values
3596 that are consistent with sRGB to be
3597 written.
3598
3599 png_set_iCCP(png_ptr, info_ptr, name, compression_type,
3600 profile, proflen);
3601
3602 name - The profile name.
3603
3604 compression_type - The compression type; always
3605 PNG_COMPRESSION_TYPE_BASE for PNG 1.0.
3606 You may give NULL to this argument to
3607 ignore it.
3608
3609 profile - International Color Consortium color
3610 profile data. May contain NULs.
3611
3612 proflen - length of profile data in bytes.
3613
3614 png_set_sBIT(png_ptr, info_ptr, sig_bit);
3615
3616 sig_bit - the number of significant bits for
3617 (PNG_INFO_sBIT) each of the gray, red,
3618 green, and blue channels, whichever are
3619 appropriate for the given color type
3620 (png_color_16)
3621
3622 png_set_tRNS(png_ptr, info_ptr, trans_alpha,
3623 num_trans, trans_color);
3624
3625 trans_alpha - array of alpha (transparency)
3626 entries for palette (PNG_INFO_tRNS)
3627
3628 num_trans - number of transparent entries
3629 (PNG_INFO_tRNS)
3630
3631 trans_color - graylevel or color sample values
3632 (in order red, green, blue) of the
3633 single transparent color for
3634 non-paletted images (PNG_INFO_tRNS)
3635
3636 png_set_eXIf_1(png_ptr, info_ptr, num_exif, exif);
3637
3638 exif - Exif profile (array of
3639 png_byte) (PNG_INFO_eXIf)
3640
3641 png_set_hIST(png_ptr, info_ptr, hist);
3642
3643 hist - histogram of palette (array of
3644 png_uint_16) (PNG_INFO_hIST)
3645
3646 png_set_tIME(png_ptr, info_ptr, mod_time);
3647
3648 mod_time - time image was last modified
3649 (PNG_VALID_tIME)
3650
3651 png_set_bKGD(png_ptr, info_ptr, background);
3652
3653 background - background color (of type
3654 png_color_16p) (PNG_VALID_bKGD)
3655
3656 png_set_text(png_ptr, info_ptr, text_ptr, num_text);
3657
3658 text_ptr - array of png_text holding image
3659 comments
3660
3661 text_ptr[i].compression - type of compression used
3662 on "text" PNG_TEXT_COMPRESSION_NONE
3663 PNG_TEXT_COMPRESSION_zTXt
3664 PNG_ITXT_COMPRESSION_NONE
3665 PNG_ITXT_COMPRESSION_zTXt
3666 text_ptr[i].key - keyword for comment. Must contain
3667 1-79 characters.
3668 text_ptr[i].text - text comments for current
3669 keyword. Can be NULL or empty.
3670 text_ptr[i].text_length - length of text string,
3671 after decompression, 0 for iTXt
3672 text_ptr[i].itxt_length - length of itxt string,
3673 after decompression, 0 for tEXt/zTXt
3674 text_ptr[i].lang - language of comment (NULL or
3675 empty for unknown).
3676 text_ptr[i].translated_keyword - keyword in UTF-8 (NULL
3677 or empty for unknown).
3678
3679 Note that the itxt_length, lang, and lang_key
3680 members of the text_ptr structure only exist when the
3681 library is built with iTXt chunk support. Prior to
3682 libpng-1.4.0 the library was built by default without
3683 iTXt support. Also note that when iTXt is supported,
3684 they contain NULL pointers when the "compression"
3685 field contains PNG_TEXT_COMPRESSION_NONE or
3686 PNG_TEXT_COMPRESSION_zTXt.
3687
3688 num_text - number of comments
3689
3690 png_set_sPLT(png_ptr, info_ptr, &palette_ptr,
3691 num_spalettes);
3692
3693 palette_ptr - array of png_sPLT_struct structures
3694 to be added to the list of palettes
3695 in the info structure.
3696 num_spalettes - number of palette structures to be
3697 added.
3698
3699 png_set_oFFs(png_ptr, info_ptr, offset_x, offset_y,
3700 unit_type);
3701
3702 offset_x - positive offset from the left
3703 edge of the screen
3704
3705 offset_y - positive offset from the top
3706 edge of the screen
3707
3708 unit_type - PNG_OFFSET_PIXEL, PNG_OFFSET_MICROMETER
3709
3710 png_set_pHYs(png_ptr, info_ptr, res_x, res_y,
3711 unit_type);
3712
3713 res_x - pixels/unit physical resolution
3714 in x direction
3715
3716 res_y - pixels/unit physical resolution
3717 in y direction
3718
3719 unit_type - PNG_RESOLUTION_UNKNOWN,
3720 PNG_RESOLUTION_METER
3721
3722 png_set_sCAL(png_ptr, info_ptr, unit, width, height)
3723
3724 unit - physical scale units (an integer)
3725
3726 width - width of a pixel in physical scale units
3727
3728 height - height of a pixel in physical scale units
3729 (width and height are doubles)
3730
3731 png_set_sCAL_s(png_ptr, info_ptr, unit, width, height)
3732
3733 unit - physical scale units (an integer)
3734
3735 width - width of a pixel in physical scale units
3736 expressed as a string
3737
3738 height - height of a pixel in physical scale units
3739 (width and height are strings like "2.54")
3740
3741 png_set_unknown_chunks(png_ptr, info_ptr, &unknowns,
3742 num_unknowns)
3743
3744 unknowns - array of png_unknown_chunk
3745 structures holding unknown chunks
3746 unknowns[i].name - name of unknown chunk
3747 unknowns[i].data - data of unknown chunk
3748 unknowns[i].size - size of unknown chunk's data
3749 unknowns[i].location - position to write chunk in file
3750 0: do not write chunk
3751 PNG_HAVE_IHDR: before PLTE
3752 PNG_HAVE_PLTE: before IDAT
3753 PNG_AFTER_IDAT: after IDAT
3754
3755The "location" member is set automatically according to
3756what part of the output file has already been written.
3757You can change its value after calling png_set_unknown_chunks()
3758as demonstrated in pngtest.c. Within each of the "locations",
3759the chunks are sequenced according to their position in the
3760structure (that is, the value of "i", which is the order in which
3761the chunk was either read from the input file or defined with
3762png_set_unknown_chunks).
3763
3764A quick word about text and num_text. text is an array of png_text
3765structures. num_text is the number of valid structures in the array.
3766Each png_text structure holds a language code, a keyword, a text value,
3767and a compression type.
3768
3769The compression types have the same valid numbers as the compression
3770types of the image data. Currently, the only valid number is zero.
3771However, you can store text either compressed or uncompressed, unlike
3772images, which always have to be compressed. So if you don't want the
3773text compressed, set the compression type to PNG_TEXT_COMPRESSION_NONE.
3774Because tEXt and zTXt chunks don't have a language field, if you
3775specify PNG_TEXT_COMPRESSION_NONE or PNG_TEXT_COMPRESSION_zTXt
3776any language code or translated keyword will not be written out.
3777
3778Until text gets around a few hundred bytes, it is not worth compressing it.
3779After the text has been written out to the file, the compression type
3780is set to PNG_TEXT_COMPRESSION_NONE_WR or PNG_TEXT_COMPRESSION_zTXt_WR,
3781so that it isn't written out again at the end (in case you are calling
3782png_write_end() with the same struct).
3783
3784The keywords that are given in the PNG Specification are:
3785
3786 Title Short (one line) title or
3787 caption for image
3788
3789 Author Name of image's creator
3790
3791 Description Description of image (possibly long)
3792
3793 Copyright Copyright notice
3794
3795 Creation Time Time of original image creation
3796 (usually RFC 1123 format, see below)
3797
3798 Software Software used to create the image
3799
3800 Disclaimer Legal disclaimer
3801
3802 Warning Warning of nature of content
3803
3804 Source Device used to create the image
3805
3806 Comment Miscellaneous comment; conversion
3807 from other image format
3808
3809The keyword-text pairs work like this. Keywords should be short
3810simple descriptions of what the comment is about. Some typical
3811keywords are found in the PNG specification, as is some recommendations
3812on keywords. You can repeat keywords in a file. You can even write
3813some text before the image and some after. For example, you may want
3814to put a description of the image before the image, but leave the
3815disclaimer until after, so viewers working over modem connections
3816don't have to wait for the disclaimer to go over the modem before
3817they start seeing the image. Finally, keywords should be full
3818words, not abbreviations. Keywords and text are in the ISO 8859-1
3819(Latin-1) character set (a superset of regular ASCII) and can not
3820contain NUL characters, and should not contain control or other
3821unprintable characters. To make the comments widely readable, stick
3822with basic ASCII, and avoid machine specific character set extensions
3823like the IBM-PC character set. The keyword must be present, but
3824you can leave off the text string on non-compressed pairs.
3825Compressed pairs must have a text string, as only the text string
3826is compressed anyway, so the compression would be meaningless.
3827
3828PNG supports modification time via the png_time structure. Two
3829conversion routines are provided, png_convert_from_time_t() for
3830time_t and png_convert_from_struct_tm() for struct tm. The
3831time_t routine uses gmtime(). You don't have to use either of
3832these, but if you wish to fill in the png_time structure directly,
3833you should provide the time in universal time (GMT) if possible
3834instead of your local time. Note that the year number is the full
3835year (e.g. 1998, rather than 98 - PNG is year 2000 compliant!), and
3836that months start with 1.
3837
3838If you want to store the time of the original image creation, you should
3839use a plain tEXt chunk with the "Creation Time" keyword. This is
3840necessary because the "creation time" of a PNG image is somewhat vague,
3841depending on whether you mean the PNG file, the time the image was
3842created in a non-PNG format, a still photo from which the image was
3843scanned, or possibly the subject matter itself. In order to facilitate
3844machine-readable dates, it is recommended that the "Creation Time"
3845tEXt chunk use RFC 1123 format dates (e.g. "22 May 1997 18:07:10 GMT"),
3846although this isn't a requirement. Unlike the tIME chunk, the
3847"Creation Time" tEXt chunk is not expected to be automatically changed
3848by the software. To facilitate the use of RFC 1123 dates, a function
3849png_convert_to_rfc1123_buffer(buffer, png_timep) is provided to
3850convert from PNG time to an RFC 1123 format string. The caller must provide
3851a writeable buffer of at least 29 bytes.
3852
3853.SS Writing unknown chunks
3854
3855You can use the png_set_unknown_chunks function to queue up private chunks
3856for writing. You give it a chunk name, location, raw data, and a size. You
3857also must use png_set_keep_unknown_chunks() to ensure that libpng will
3858handle them. That's all there is to it. The chunks will be written by the
3859next following png_write_info_before_PLTE, png_write_info, or png_write_end
3860function, depending upon the specified location. Any chunks previously
3861read into the info structure's unknown-chunk list will also be written out
3862in a sequence that satisfies the PNG specification's ordering rules.
3863
3864Here is an example of writing two private chunks, prVt and miNE:
3865
3866 #ifdef PNG_WRITE_UNKNOWN_CHUNKS_SUPPORTED
3867 /* Set unknown chunk data */
3868 png_unknown_chunk unk_chunk[2];
3869 strcpy((char *) unk_chunk[0].name, "prVt";
3870 unk_chunk[0].data = (unsigned char *) "PRIVATE DATA";
3871 unk_chunk[0].size = strlen(unk_chunk[0].data)+1;
3872 unk_chunk[0].location = PNG_HAVE_IHDR;
3873 strcpy((char *) unk_chunk[1].name, "miNE";
3874 unk_chunk[1].data = (unsigned char *) "MY CHUNK DATA";
3875 unk_chunk[1].size = strlen(unk_chunk[0].data)+1;
3876 unk_chunk[1].location = PNG_AFTER_IDAT;
3877 png_set_unknown_chunks(write_ptr, write_info_ptr,
3878 unk_chunk, 2);
3879 /* Needed because miNE is not safe-to-copy */
3880 png_set_keep_unknown_chunks(png, PNG_HANDLE_CHUNK_ALWAYS,
3881 (png_bytep) "miNE", 1);
3882 # if PNG_LIBPNG_VER < 10600
3883 /* Deal with unknown chunk location bug in 1.5.x and earlier */
3884 png_set_unknown_chunk_location(png, info, 0, PNG_HAVE_IHDR);
3885 png_set_unknown_chunk_location(png, info, 1, PNG_AFTER_IDAT);
3886 # endif
3887 # if PNG_LIBPNG_VER < 10500
3888 /* PNG_AFTER_IDAT writes two copies of the chunk prior to libpng-1.5.0,
3889 * one before IDAT and another after IDAT, so don't use it; only use
3890 * PNG_HAVE_IHDR location. This call resets the location previously
3891 * set by assignment and png_set_unknown_chunk_location() for chunk 1.
3892 */
3893 png_set_unknown_chunk_location(png, info, 1, PNG_HAVE_IHDR);
3894 # endif
3895 #endif
3896
3897.SS The high-level write interface
3898
3899At this point there are two ways to proceed; through the high-level
3900write interface, or through a sequence of low-level write operations.
3901You can use the high-level interface if your image data is present
3902in the info structure. All defined output
3903transformations are permitted, enabled by the following masks.
3904
3905 PNG_TRANSFORM_IDENTITY No transformation
3906 PNG_TRANSFORM_PACKING Pack 1, 2 and 4-bit samples
3907 PNG_TRANSFORM_PACKSWAP Change order of packed
3908 pixels to LSB first
3909 PNG_TRANSFORM_INVERT_MONO Invert monochrome images
3910 PNG_TRANSFORM_SHIFT Normalize pixels to the
3911 sBIT depth
3912 PNG_TRANSFORM_BGR Flip RGB to BGR, RGBA
3913 to BGRA
3914 PNG_TRANSFORM_SWAP_ALPHA Flip RGBA to ARGB or GA
3915 to AG
3916 PNG_TRANSFORM_INVERT_ALPHA Change alpha from opacity
3917 to transparency
3918 PNG_TRANSFORM_SWAP_ENDIAN Byte-swap 16-bit samples
3919 PNG_TRANSFORM_STRIP_FILLER Strip out filler
3920 bytes (deprecated).
3921 PNG_TRANSFORM_STRIP_FILLER_BEFORE Strip out leading
3922 filler bytes
3923 PNG_TRANSFORM_STRIP_FILLER_AFTER Strip out trailing
3924 filler bytes
3925
3926If you have valid image data in the info structure (you can use
3927png_set_rows() to put image data in the info structure), simply do this:
3928
3929 png_write_png(png_ptr, info_ptr, png_transforms, NULL)
3930
3931where png_transforms is an integer containing the bitwise OR of some set of
3932transformation flags. This call is equivalent to png_write_info(),
3933followed the set of transformations indicated by the transform mask,
3934then png_write_image(), and finally png_write_end().
3935
3936(The final parameter of this call is not yet used. Someday it might point
3937to transformation parameters required by some future output transform.)
3938
3939You must use png_transforms and not call any png_set_transform() functions
3940when you use png_write_png().
3941
3942.SS The low-level write interface
3943
3944If you are going the low-level route instead, you are now ready to
3945write all the file information up to the actual image data. You do
3946this with a call to png_write_info().
3947
3948 png_write_info(png_ptr, info_ptr);
3949
3950Note that there is one transformation you may need to do before
3951png_write_info(). In PNG files, the alpha channel in an image is the
3952level of opacity. If your data is supplied as a level of transparency,
3953you can invert the alpha channel before you write it, so that 0 is
3954fully transparent and 255 (in 8-bit or paletted images) or 65535
3955(in 16-bit images) is fully opaque, with
3956
3957 png_set_invert_alpha(png_ptr);
3958
3959This must appear before png_write_info() instead of later with the
3960other transformations because in the case of paletted images the tRNS
3961chunk data has to be inverted before the tRNS chunk is written. If
3962your image is not a paletted image, the tRNS data (which in such cases
3963represents a single color to be rendered as transparent) won't need to
3964be changed, and you can safely do this transformation after your
3965png_write_info() call.
3966
3967If you need to write a private chunk that you want to appear before
3968the PLTE chunk when PLTE is present, you can write the PNG info in
3969two steps, and insert code to write your own chunk between them:
3970
3971 png_write_info_before_PLTE(png_ptr, info_ptr);
3972 png_set_unknown_chunks(png_ptr, info_ptr, ...);
3973 png_write_info(png_ptr, info_ptr);
3974
3975After you've written the file information, you can set up the library
3976to handle any special transformations of the image data. The various
3977ways to transform the data will be described in the order that they
3978should occur. This is important, as some of these change the color
3979type and/or bit depth of the data, and some others only work on
3980certain color types and bit depths. Even though each transformation
3981checks to see if it has data that it can do something with, you should
3982make sure to only enable a transformation if it will be valid for the
3983data. For example, don't swap red and blue on grayscale data.
3984
3985PNG files store RGB pixels packed into 3 or 6 bytes. This code tells
3986the library to strip input data that has 4 or 8 bytes per pixel down
3987to 3 or 6 bytes (or strip 2 or 4-byte grayscale+filler data to 1 or 2
3988bytes per pixel).
3989
3990 png_set_filler(png_ptr, 0, PNG_FILLER_BEFORE);
3991
3992where the 0 is unused, and the location is either PNG_FILLER_BEFORE or
3993PNG_FILLER_AFTER, depending upon whether the filler byte in the pixel
3994is stored XRGB or RGBX.
3995
3996PNG files pack pixels of bit depths 1, 2, and 4 into bytes as small as
3997they can, resulting in, for example, 8 pixels per byte for 1 bit files.
3998If the data is supplied at 1 pixel per byte, use this code, which will
3999correctly pack the pixels into a single byte:
4000
4001 png_set_packing(png_ptr);
4002
4003PNG files reduce possible bit depths to 1, 2, 4, 8, and 16. If your
4004data is of another bit depth, you can write an sBIT chunk into the
4005file so that decoders can recover the original data if desired.
4006
4007 /* Set the true bit depth of the image data */
4008 if (color_type & PNG_COLOR_MASK_COLOR)
4009 {
4010 sig_bit.red = true_bit_depth;
4011 sig_bit.green = true_bit_depth;
4012 sig_bit.blue = true_bit_depth;
4013 }
4014
4015 else
4016 {
4017 sig_bit.gray = true_bit_depth;
4018 }
4019
4020 if (color_type & PNG_COLOR_MASK_ALPHA)
4021 {
4022 sig_bit.alpha = true_bit_depth;
4023 }
4024
4025 png_set_sBIT(png_ptr, info_ptr, &sig_bit);
4026
4027If the data is stored in the row buffer in a bit depth other than
4028one supported by PNG (e.g. 3 bit data in the range 0-7 for a 4-bit PNG),
4029this will scale the values to appear to be the correct bit depth as
4030is required by PNG.
4031
4032 png_set_shift(png_ptr, &sig_bit);
4033
4034PNG files store 16-bit pixels in network byte order (big-endian,
4035ie. most significant bits first). This code would be used if they are
4036supplied the other way (little-endian, i.e. least significant bits
4037first, the way PCs store them):
4038
4039 if (bit_depth > 8)
4040 png_set_swap(png_ptr);
4041
4042If you are using packed-pixel images (1, 2, or 4 bits/pixel), and you
4043need to change the order the pixels are packed into bytes, you can use:
4044
4045 if (bit_depth < 8)
4046 png_set_packswap(png_ptr);
4047
4048PNG files store 3 color pixels in red, green, blue order. This code
4049would be used if they are supplied as blue, green, red:
4050
4051 png_set_bgr(png_ptr);
4052
4053PNG files describe monochrome as black being zero and white being
4054one. This code would be used if the pixels are supplied with this reversed
4055(black being one and white being zero):
4056
4057 png_set_invert_mono(png_ptr);
4058
4059Finally, you can write your own transformation function if none of
4060the existing ones meets your needs. This is done by setting a callback
4061with
4062
4063 png_set_write_user_transform_fn(png_ptr,
4064 write_transform_fn);
4065
4066You must supply the function
4067
4068 void write_transform_fn(png_structp png_ptr, png_row_infop
4069 row_info, png_bytep data)
4070
4071See pngtest.c for a working example. Your function will be called
4072before any of the other transformations are processed. If supported
4073libpng also supplies an information routine that may be called from
4074your callback:
4075
4076 png_get_current_row_number(png_ptr);
4077 png_get_current_pass_number(png_ptr);
4078
4079This returns the current row passed to the transform. With interlaced
4080images the value returned is the row in the input sub-image image. Use
4081PNG_ROW_FROM_PASS_ROW(row, pass) and PNG_COL_FROM_PASS_COL(col, pass) to
4082find the output pixel (x,y) given an interlaced sub-image pixel (row,col,pass).
4083
4084The discussion of interlace handling above contains more information on how to
4085use these values.
4086
4087You can also set up a pointer to a user structure for use by your
4088callback function.
4089
4090 png_set_user_transform_info(png_ptr, user_ptr, 0, 0);
4091
4092The user_channels and user_depth parameters of this function are ignored
4093when writing; you can set them to zero as shown.
4094
4095You can retrieve the pointer via the function png_get_user_transform_ptr().
4096For example:
4097
4098 voidp write_user_transform_ptr =
4099 png_get_user_transform_ptr(png_ptr);
4100
4101It is possible to have libpng flush any pending output, either manually,
4102or automatically after a certain number of lines have been written. To
4103flush the output stream a single time call:
4104
4105 png_write_flush(png_ptr);
4106
4107and to have libpng flush the output stream periodically after a certain
4108number of scanlines have been written, call:
4109
4110 png_set_flush(png_ptr, nrows);
4111
4112Note that the distance between rows is from the last time png_write_flush()
4113was called, or the first row of the image if it has never been called.
4114So if you write 50 lines, and then png_set_flush 25, it will flush the
4115output on the next scanline, and every 25 lines thereafter, unless
4116png_write_flush() is called before 25 more lines have been written.
4117If nrows is too small (less than about 10 lines for a 640 pixel wide
4118RGB image) the image compression may decrease noticeably (although this
4119may be acceptable for real-time applications). Infrequent flushing will
4120only degrade the compression performance by a few percent over images
4121that do not use flushing.
4122
4123.SS Writing the image data
4124
4125That's it for the transformations. Now you can write the image data.
4126The simplest way to do this is in one function call. If you have the
4127whole image in memory, you can just call png_write_image() and libpng
4128will write the image. You will need to pass in an array of pointers to
4129each row. This function automatically handles interlacing, so you don't
4130need to call png_set_interlace_handling() or call this function multiple
4131times, or any of that other stuff necessary with png_write_rows().
4132
4133 png_write_image(png_ptr, row_pointers);
4134
4135where row_pointers is:
4136
4137 png_byte *row_pointers[height];
4138
4139You can point to void or char or whatever you use for pixels.
4140
4141If you don't want to write the whole image at once, you can
4142use png_write_rows() instead. If the file is not interlaced,
4143this is simple:
4144
4145 png_write_rows(png_ptr, row_pointers,
4146 number_of_rows);
4147
4148row_pointers is the same as in the png_write_image() call.
4149
4150If you are just writing one row at a time, you can do this with
4151a single row_pointer instead of an array of row_pointers:
4152
4153 png_bytep row_pointer = row;
4154
4155 png_write_row(png_ptr, row_pointer);
4156
4157When the file is interlaced, things can get a good deal more complicated.
4158The only currently (as of the PNG Specification version 1.2, dated July
41591999) defined interlacing scheme for PNG files is the "Adam7" interlace
4160scheme, that breaks down an image into seven smaller images of varying
4161size. libpng will build these images for you, or you can do them
4162yourself. If you want to build them yourself, see the PNG specification
4163for details of which pixels to write when.
4164
4165If you don't want libpng to handle the interlacing details, just
4166use png_set_interlace_handling() and call png_write_rows() the
4167correct number of times to write all the sub-images
4168(png_set_interlace_handling() returns the number of sub-images.)
4169
4170If you want libpng to build the sub-images, call this before you start
4171writing any rows:
4172
4173 number_of_passes = png_set_interlace_handling(png_ptr);
4174
4175This will return the number of passes needed. Currently, this is seven,
4176but may change if another interlace type is added.
4177
4178Then write the complete image number_of_passes times.
4179
4180 png_write_rows(png_ptr, row_pointers, number_of_rows);
4181
4182Think carefully before you write an interlaced image. Typically code that
4183reads such images reads all the image data into memory, uncompressed, before
4184doing any processing. Only code that can display an image on the fly can
4185take advantage of the interlacing and even then the image has to be exactly
4186the correct size for the output device, because scaling an image requires
4187adjacent pixels and these are not available until all the passes have been
4188read.
4189
4190If you do write an interlaced image you will hardly ever need to handle
4191the interlacing yourself. Call png_set_interlace_handling() and use the
4192approach described above.
4193
4194The only time it is conceivable that you will really need to write an
4195interlaced image pass-by-pass is when you have read one pass by pass and
4196made some pixel-by-pixel transformation to it, as described in the read
4197code above. In this case use the PNG_PASS_ROWS and PNG_PASS_COLS macros
4198to determine the size of each sub-image in turn and simply write the rows
4199you obtained from the read code.
4200
4201.SS Finishing a sequential write
4202
4203After you are finished writing the image, you should finish writing
4204the file. If you are interested in writing comments or time, you should
4205pass an appropriately filled png_info pointer. If you are not interested,
4206you can pass NULL.
4207
4208 png_write_end(png_ptr, info_ptr);
4209
4210When you are done, you can free all memory used by libpng like this:
4211
4212 png_destroy_write_struct(&png_ptr, &info_ptr);
4213
4214It is also possible to individually free the info_ptr members that
4215point to libpng-allocated storage with the following function:
4216
4217 png_free_data(png_ptr, info_ptr, mask, seq)
4218
4219 mask - identifies data to be freed, a mask
4220 containing the bitwise OR of one or
4221 more of
4222 PNG_FREE_PLTE, PNG_FREE_TRNS,
4223 PNG_FREE_HIST, PNG_FREE_ICCP,
4224 PNG_FREE_PCAL, PNG_FREE_ROWS,
4225 PNG_FREE_SCAL, PNG_FREE_SPLT,
4226 PNG_FREE_TEXT, PNG_FREE_UNKN,
4227 or simply PNG_FREE_ALL
4228
4229 seq - sequence number of item to be freed
4230 (\-1 for all items)
4231
4232This function may be safely called when the relevant storage has
4233already been freed, or has not yet been allocated, or was allocated
4234by the user and not by libpng, and will in those cases do nothing.
4235The "seq" parameter is ignored if only one item of the selected data
4236type, such as PLTE, is allowed. If "seq" is not \-1, and multiple items
4237are allowed for the data type identified in the mask, such as text or
4238sPLT, only the n'th item in the structure is freed, where n is "seq".
4239
4240If you allocated data such as a palette that you passed in to libpng
4241with png_set_*, you must not free it until just before the call to
4242png_destroy_write_struct().
4243
4244The default behavior is only to free data that was allocated internally
4245by libpng. This can be changed, so that libpng will not free the data,
4246or so that it will free data that was allocated by the user with png_malloc()
4247or png_calloc() and passed in via a png_set_*() function, with
4248
4249 png_data_freer(png_ptr, info_ptr, freer, mask)
4250
4251 freer - one of
4252 PNG_DESTROY_WILL_FREE_DATA
4253 PNG_SET_WILL_FREE_DATA
4254 PNG_USER_WILL_FREE_DATA
4255
4256 mask - which data elements are affected
4257 same choices as in png_free_data()
4258
4259For example, to transfer responsibility for some data from a read structure
4260to a write structure, you could use
4261
4262 png_data_freer(read_ptr, read_info_ptr,
4263 PNG_USER_WILL_FREE_DATA,
4264 PNG_FREE_PLTE|PNG_FREE_tRNS|PNG_FREE_hIST)
4265
4266 png_data_freer(write_ptr, write_info_ptr,
4267 PNG_DESTROY_WILL_FREE_DATA,
4268 PNG_FREE_PLTE|PNG_FREE_tRNS|PNG_FREE_hIST)
4269
4270thereby briefly reassigning responsibility for freeing to the user but
4271immediately afterwards reassigning it once more to the write_destroy
4272function. Having done this, it would then be safe to destroy the read
4273structure and continue to use the PLTE, tRNS, and hIST data in the write
4274structure.
4275
4276This function only affects data that has already been allocated.
4277You can call this function before calling after the png_set_*() functions
4278to control whether the user or png_destroy_*() is supposed to free the data.
4279When the user assumes responsibility for libpng-allocated data, the
4280application must use
4281png_free() to free it, and when the user transfers responsibility to libpng
4282for data that the user has allocated, the user must have used png_malloc()
4283or png_calloc() to allocate it.
4284
4285If you allocated text_ptr.text, text_ptr.lang, and text_ptr.translated_keyword
4286separately, do not transfer responsibility for freeing text_ptr to libpng,
4287because when libpng fills a png_text structure it combines these members with
4288the key member, and png_free_data() will free only text_ptr.key. Similarly,
4289if you transfer responsibility for free'ing text_ptr from libpng to your
4290application, your application must not separately free those members.
4291For a more compact example of writing a PNG image, see the file example.c.
4292
4293.SH V. Simplified API
4294
4295The simplified API, which became available in libpng-1.6.0, hides the details
4296of both libpng and the PNG file format itself.
4297It allows PNG files to be read into a very limited number of
4298in-memory bitmap formats or to be written from the same formats. If these
4299formats do not accommodate your needs then you can, and should, use the more
4300sophisticated APIs above - these support a wide variety of in-memory formats
4301and a wide variety of sophisticated transformations to those formats as well
4302as a wide variety of APIs to manipulate ancillary information.
4303
4304To read a PNG file using the simplified API:
4305
4306 1) Declare a 'png_image' structure (see below) on the stack, set the
4307 version field to PNG_IMAGE_VERSION and the 'opaque' pointer to NULL
4308 (this is REQUIRED, your program may crash if you don't do it.)
4309
4310 2) Call the appropriate png_image_begin_read... function.
4311
4312 3) Set the png_image 'format' member to the required sample format.
4313
4314 4) Allocate a buffer for the image and, if required, the color-map.
4315
4316 5) Call png_image_finish_read to read the image and, if required, the
4317 color-map into your buffers.
4318
4319There are no restrictions on the format of the PNG input itself; all valid
4320color types, bit depths, and interlace methods are acceptable, and the
4321input image is transformed as necessary to the requested in-memory format
4322during the png_image_finish_read() step. The only caveat is that if you
4323request a color-mapped image from a PNG that is full-color or makes
4324complex use of an alpha channel the transformation is extremely lossy and the
4325result may look terrible.
4326
4327To write a PNG file using the simplified API:
4328
4329 1) Declare a 'png_image' structure on the stack and memset()
4330 it to all zero.
4331
4332 2) Initialize the members of the structure that describe the
4333 image, setting the 'format' member to the format of the
4334 image samples.
4335
4336 3) Call the appropriate png_image_write... function with a
4337 pointer to the image and, if necessary, the color-map to write
4338 the PNG data.
4339
4340png_image is a structure that describes the in-memory format of an image
4341when it is being read or defines the in-memory format of an image that you
4342need to write. The "png_image" structure contains the following members:
4343
4344 png_controlp opaque Initialize to NULL, free with png_image_free
4345 png_uint_32 version Set to PNG_IMAGE_VERSION
4346 png_uint_32 width Image width in pixels (columns)
4347 png_uint_32 height Image height in pixels (rows)
4348 png_uint_32 format Image format as defined below
4349 png_uint_32 flags A bit mask containing informational flags
4350 png_uint_32 colormap_entries; Number of entries in the color-map
4351 png_uint_32 warning_or_error;
4352 char message[64];
4353
4354In the event of an error or warning the "warning_or_error"
4355field will be set to a non-zero value and the 'message' field will contain
4356a '\0' terminated string with the libpng error or warning message. If both
4357warnings and an error were encountered, only the error is recorded. If there
4358are multiple warnings, only the first one is recorded.
4359
4360The upper 30 bits of the "warning_or_error" value are reserved; the low two
4361bits contain a two bit code such that a value more than 1 indicates a failure
4362in the API just called:
4363
4364 0 - no warning or error
4365 1 - warning
4366 2 - error
4367 3 - error preceded by warning
4368
4369The pixels (samples) of the image have one to four channels whose components
4370have original values in the range 0 to 1.0:
4371
4372 1: A single gray or luminance channel (G).
4373 2: A gray/luminance channel and an alpha channel (GA).
4374 3: Three red, green, blue color channels (RGB).
4375 4: Three color channels and an alpha channel (RGBA).
4376
4377The channels are encoded in one of two ways:
4378
4379 a) As a small integer, value 0..255, contained in a single byte. For the
4380alpha channel the original value is simply value/255. For the color or
4381luminance channels the value is encoded according to the sRGB specification
4382and matches the 8-bit format expected by typical display devices.
4383
4384The color/gray channels are not scaled (pre-multiplied) by the alpha
4385channel and are suitable for passing to color management software.
4386
4387 b) As a value in the range 0..65535, contained in a 2-byte integer, in
4388the native byte order of the platform on which the application is running.
4389All channels can be converted to the original value by dividing by 65535; all
4390channels are linear. Color channels use the RGB encoding (RGB end-points) of
4391the sRGB specification. This encoding is identified by the
4392PNG_FORMAT_FLAG_LINEAR flag below.
4393
4394When the simplified API needs to convert between sRGB and linear colorspaces,
4395the actual sRGB transfer curve defined in the sRGB specification (see the
4396article at https://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2
4397approximation used elsewhere in libpng.
4398
4399When an alpha channel is present it is expected to denote pixel coverage
4400of the color or luminance channels and is returned as an associated alpha
4401channel: the color/gray channels are scaled (pre-multiplied) by the alpha
4402value.
4403
4404The samples are either contained directly in the image data, between 1 and 8
4405bytes per pixel according to the encoding, or are held in a color-map indexed
4406by bytes in the image data. In the case of a color-map the color-map entries
4407are individual samples, encoded as above, and the image data has one byte per
4408pixel to select the relevant sample from the color-map.
4409
4410PNG_FORMAT_*
4411
4412The #defines to be used in png_image::format. Each #define identifies a
4413particular layout of channel data and, if present, alpha values. There are
4414separate defines for each of the two component encodings.
4415
4416A format is built up using single bit flag values. All combinations are
4417valid. Formats can be built up from the flag values or you can use one of
4418the predefined values below. When testing formats always use the FORMAT_FLAG
4419macros to test for individual features - future versions of the library may
4420add new flags.
4421
4422When reading or writing color-mapped images the format should be set to the
4423format of the entries in the color-map then png_image_{read,write}_colormap
4424called to read or write the color-map and set the format correctly for the
4425image data. Do not set the PNG_FORMAT_FLAG_COLORMAP bit directly!
4426
4427NOTE: libpng can be built with particular features disabled. If you see
4428compiler errors because the definition of one of the following flags has been
4429compiled out it is because libpng does not have the required support. It is
4430possible, however, for the libpng configuration to enable the format on just
4431read or just write; in that case you may see an error at run time.
4432You can guard against this by checking for the definition of the
4433appropriate "_SUPPORTED" macro, one of:
4434
4435 PNG_SIMPLIFIED_{READ,WRITE}_{BGR,AFIRST}_SUPPORTED
4436
4437 PNG_FORMAT_FLAG_ALPHA format with an alpha channel
4438 PNG_FORMAT_FLAG_COLOR color format: otherwise grayscale
4439 PNG_FORMAT_FLAG_LINEAR 2-byte channels else 1-byte
4440 PNG_FORMAT_FLAG_COLORMAP image data is color-mapped
4441 PNG_FORMAT_FLAG_BGR BGR colors, else order is RGB
4442 PNG_FORMAT_FLAG_AFIRST alpha channel comes first
4443
4444Supported formats are as follows. Future versions of libpng may support more
4445formats; for compatibility with older versions simply check if the format
4446macro is defined using #ifdef. These defines describe the in-memory layout
4447of the components of the pixels of the image.
4448
4449First the single byte (sRGB) formats:
4450
4451 PNG_FORMAT_GRAY
4452 PNG_FORMAT_GA
4453 PNG_FORMAT_AG
4454 PNG_FORMAT_RGB
4455 PNG_FORMAT_BGR
4456 PNG_FORMAT_RGBA
4457 PNG_FORMAT_ARGB
4458 PNG_FORMAT_BGRA
4459 PNG_FORMAT_ABGR
4460
4461Then the linear 2-byte formats. When naming these "Y" is used to
4462indicate a luminance (gray) channel. The component order within the pixel
4463is always the same - there is no provision for swapping the order of the
4464components in the linear format. The components are 16-bit integers in
4465the native byte order for your platform, and there is no provision for
4466swapping the bytes to a different endian condition.
4467
4468 PNG_FORMAT_LINEAR_Y
4469 PNG_FORMAT_LINEAR_Y_ALPHA
4470 PNG_FORMAT_LINEAR_RGB
4471 PNG_FORMAT_LINEAR_RGB_ALPHA
4472
4473With color-mapped formats the image data is one byte for each pixel. The byte
4474is an index into the color-map which is formatted as above. To obtain a
4475color-mapped format it is sufficient just to add the PNG_FOMAT_FLAG_COLORMAP
4476to one of the above definitions, or you can use one of the definitions below.
4477
4478 PNG_FORMAT_RGB_COLORMAP
4479 PNG_FORMAT_BGR_COLORMAP
4480 PNG_FORMAT_RGBA_COLORMAP
4481 PNG_FORMAT_ARGB_COLORMAP
4482 PNG_FORMAT_BGRA_COLORMAP
4483 PNG_FORMAT_ABGR_COLORMAP
4484
4485PNG_IMAGE macros
4486
4487These are convenience macros to derive information from a png_image
4488structure. The PNG_IMAGE_SAMPLE_ macros return values appropriate to the
4489actual image sample values - either the entries in the color-map or the
4490pixels in the image. The PNG_IMAGE_PIXEL_ macros return corresponding values
4491for the pixels and will always return 1 for color-mapped formats. The
4492remaining macros return information about the rows in the image and the
4493complete image.
4494
4495NOTE: All the macros that take a png_image::format parameter are compile time
4496constants if the format parameter is, itself, a constant. Therefore these
4497macros can be used in array declarations and case labels where required.
4498Similarly the macros are also pre-processor constants (sizeof is not used) so
4499they can be used in #if tests.
4500
4501 PNG_IMAGE_SAMPLE_CHANNELS(fmt)
4502 Returns the total number of channels in a given format: 1..4
4503
4504 PNG_IMAGE_SAMPLE_COMPONENT_SIZE(fmt)
4505 Returns the size in bytes of a single component of a pixel or color-map
4506 entry (as appropriate) in the image: 1 or 2.
4507
4508 PNG_IMAGE_SAMPLE_SIZE(fmt)
4509 This is the size of the sample data for one sample. If the image is
4510 color-mapped it is the size of one color-map entry (and image pixels are
4511 one byte in size), otherwise it is the size of one image pixel.
4512
4513 PNG_IMAGE_MAXIMUM_COLORMAP_COMPONENTS(fmt)
4514 The maximum size of the color-map required by the format expressed in a
4515 count of components. This can be used to compile-time allocate a
4516 color-map:
4517
4518 png_uint_16 colormap[PNG_IMAGE_MAXIMUM_COLORMAP_COMPONENTS(linear_fmt)];
4519
4520 png_byte colormap[PNG_IMAGE_MAXIMUM_COLORMAP_COMPONENTS(sRGB_fmt)];
4521
4522 Alternatively use the PNG_IMAGE_COLORMAP_SIZE macro below to use the
4523 information from one of the png_image_begin_read_ APIs and dynamically
4524 allocate the required memory.
4525
4526 PNG_IMAGE_COLORMAP_SIZE(fmt)
4527 The size of the color-map required by the format; this is the size of the
4528 color-map buffer passed to the png_image_{read,write}_colormap APIs. It is
4529 a fixed number determined by the format so can easily be allocated on the
4530 stack if necessary.
4531
4532Corresponding information about the pixels
4533
4534 PNG_IMAGE_PIXEL_CHANNELS(fmt)
4535 The number of separate channels (components) in a pixel; 1 for a
4536 color-mapped image.
4537
4538 PNG_IMAGE_PIXEL_COMPONENT_SIZE(fmt)\
4539 The size, in bytes, of each component in a pixel; 1 for a color-mapped
4540 image.
4541
4542 PNG_IMAGE_PIXEL_SIZE(fmt)
4543 The size, in bytes, of a complete pixel; 1 for a color-mapped image.
4544
4545Information about the whole row, or whole image
4546
4547 PNG_IMAGE_ROW_STRIDE(image)
4548 Returns the total number of components in a single row of the image; this
4549 is the minimum 'row stride', the minimum count of components between each
4550 row. For a color-mapped image this is the minimum number of bytes in a
4551 row.
4552
4553 If you need the stride measured in bytes, row_stride_bytes is
4554 PNG_IMAGE_ROW_STRIDE(image) * PNG_IMAGE_PIXEL_COMPONENT_SIZE(fmt)
4555 plus any padding bytes that your application might need, for example
4556 to start the next row on a 4-byte boundary.
4557
4558 PNG_IMAGE_BUFFER_SIZE(image, row_stride)
4559 Return the size, in bytes, of an image buffer given a png_image and a row
4560 stride - the number of components to leave space for in each row.
4561
4562 PNG_IMAGE_SIZE(image)
4563 Return the size, in bytes, of the image in memory given just a png_image;
4564 the row stride is the minimum stride required for the image.
4565
4566 PNG_IMAGE_COLORMAP_SIZE(image)
4567 Return the size, in bytes, of the color-map of this image. If the image
4568 format is not a color-map format this will return a size sufficient for
4569 256 entries in the given format; check PNG_FORMAT_FLAG_COLORMAP if
4570 you don't want to allocate a color-map in this case.
4571
4572PNG_IMAGE_FLAG_*
4573
4574Flags containing additional information about the image are held in
4575the 'flags' field of png_image.
4576
4577 PNG_IMAGE_FLAG_COLORSPACE_NOT_sRGB == 0x01
4578 This indicates that the RGB values of the in-memory bitmap do not
4579 correspond to the red, green and blue end-points defined by sRGB.
4580
4581 PNG_IMAGE_FLAG_FAST == 0x02
4582 On write emphasise speed over compression; the resultant PNG file will be
4583 larger but will be produced significantly faster, particular for large
4584 images. Do not use this option for images which will be distributed, only
4585 used it when producing intermediate files that will be read back in
4586 repeatedly. For a typical 24-bit image the option will double the read
4587 speed at the cost of increasing the image size by 25%, however for many
4588 more compressible images the PNG file can be 10 times larger with only a
4589 slight speed gain.
4590
4591 PNG_IMAGE_FLAG_16BIT_sRGB == 0x04
4592 On read if the image is a 16-bit per component image and there is no gAMA
4593 or sRGB chunk assume that the components are sRGB encoded. Notice that
4594 images output by the simplified API always have gamma information; setting
4595 this flag only affects the interpretation of 16-bit images from an
4596 external source. It is recommended that the application expose this flag
4597 to the user; the user can normally easily recognize the difference between
4598 linear and sRGB encoding. This flag has no effect on write - the data
4599 passed to the write APIs must have the correct encoding (as defined
4600 above.)
4601
4602 If the flag is not set (the default) input 16-bit per component data is
4603 assumed to be linear.
4604
4605 NOTE: the flag can only be set after the png_image_begin_read_ call,
4606 because that call initializes the 'flags' field.
4607
4608READ APIs
4609
4610 The png_image passed to the read APIs must have been initialized by setting
4611 the png_controlp field 'opaque' to NULL (or, better, memset the whole thing.)
4612
4613 int png_image_begin_read_from_file( png_imagep image,
4614 const char *file_name)
4615
4616 The named file is opened for read and the image header
4617 is filled in from the PNG header in the file.
4618
4619 int png_image_begin_read_from_stdio (png_imagep image,
4620 FILE* file)
4621
4622 The PNG header is read from the stdio FILE object.
4623
4624 int png_image_begin_read_from_memory(png_imagep image,
4625 png_const_voidp memory, size_t size)
4626
4627 The PNG header is read from the given memory buffer.
4628
4629 int png_image_finish_read(png_imagep image,
4630 png_colorp background, void *buffer,
4631 png_int_32 row_stride, void *colormap));
4632
4633 Finish reading the image into the supplied buffer and
4634 clean up the png_image structure.
4635
4636 row_stride is the step, in png_byte or png_uint_16 units
4637 as appropriate, between adjacent rows. A positive stride
4638 indicates that the top-most row is first in the buffer -
4639 the normal top-down arrangement. A negative stride
4640 indicates that the bottom-most row is first in the buffer.
4641
4642 background need only be supplied if an alpha channel must
4643 be removed from a png_byte format and the removal is to be
4644 done by compositing on a solid color; otherwise it may be
4645 NULL and any composition will be done directly onto the
4646 buffer. The value is an sRGB color to use for the
4647 background, for grayscale output the green channel is used.
4648
4649 For linear output removing the alpha channel is always done
4650 by compositing on black.
4651
4652 void png_image_free(png_imagep image)
4653
4654 Free any data allocated by libpng in image->opaque,
4655 setting the pointer to NULL. May be called at any time
4656 after the structure is initialized.
4657
4658When the simplified API needs to convert between sRGB and linear colorspaces,
4659the actual sRGB transfer curve defined in the sRGB specification (see the
4660article at https://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2
4661approximation used elsewhere in libpng.
4662
4663WRITE APIS
4664
4665For write you must initialize a png_image structure to describe the image to
4666be written:
4667
4668 version: must be set to PNG_IMAGE_VERSION
4669 opaque: must be initialized to NULL
4670 width: image width in pixels
4671 height: image height in rows
4672 format: the format of the data you wish to write
4673 flags: set to 0 unless one of the defined flags applies; set
4674 PNG_IMAGE_FLAG_COLORSPACE_NOT_sRGB for color format images
4675 where the RGB values do not correspond to the colors in sRGB.
4676 colormap_entries: set to the number of entries in the color-map (0 to 256)
4677
4678 int png_image_write_to_file, (png_imagep image,
4679 const char *file, int convert_to_8bit, const void *buffer,
4680 png_int_32 row_stride, const void *colormap));
4681
4682 Write the image to the named file.
4683
4684 int png_image_write_to_memory (png_imagep image, void *memory,
4685 png_alloc_size_t * PNG_RESTRICT memory_bytes,
4686 int convert_to_8_bit, const void *buffer, ptrdiff_t row_stride,
4687 const void *colormap));
4688
4689 Write the image to memory.
4690
4691 int png_image_write_to_stdio(png_imagep image, FILE *file,
4692 int convert_to_8_bit, const void *buffer,
4693 png_int_32 row_stride, const void *colormap)
4694
4695 Write the image to the given (FILE*).
4696
4697With all write APIs if image is in one of the linear formats with
4698(png_uint_16) data then setting convert_to_8_bit will cause the output to be
4699a (png_byte) PNG gamma encoded according to the sRGB specification, otherwise
4700a 16-bit linear encoded PNG file is written.
4701
4702With all APIs row_stride is handled as in the read APIs - it is the spacing
4703from one row to the next in component sized units (float) and if negative
4704indicates a bottom-up row layout in the buffer. If you pass zero, libpng will
4705calculate the row_stride for you from the width and number of channels.
4706
4707Note that the write API does not support interlacing, sub-8-bit pixels,
4708indexed (paletted) images, or most ancillary chunks.
4709
4710.SH VI. Modifying/Customizing libpng
4711
4712There are two issues here. The first is changing how libpng does
4713standard things like memory allocation, input/output, and error handling.
4714The second deals with more complicated things like adding new chunks,
4715adding new transformations, and generally changing how libpng works.
4716Both of those are compile-time issues; that is, they are generally
4717determined at the time the code is written, and there is rarely a need
4718to provide the user with a means of changing them.
4719
4720Memory allocation, input/output, and error handling
4721
4722All of the memory allocation, input/output, and error handling in libpng
4723goes through callbacks that are user-settable. The default routines are
4724in pngmem.c, pngrio.c, pngwio.c, and pngerror.c, respectively. To change
4725these functions, call the appropriate png_set_*_fn() function.
4726
4727Memory allocation is done through the functions png_malloc(), png_calloc(),
4728and png_free(). The png_malloc() and png_free() functions currently just
4729call the standard C functions and png_calloc() calls png_malloc() and then
4730clears the newly allocated memory to zero; note that png_calloc(png_ptr, size)
4731is not the same as the calloc(number, size) function provided by stdlib.h.
4732There is limited support for certain systems with segmented memory
4733architectures and the types of pointers declared by png.h match this; you
4734will have to use appropriate pointers in your application. If you prefer
4735to use a different method of allocating and freeing data, you can use
4736png_create_read_struct_2() or png_create_write_struct_2() to register your
4737own functions as described above. These functions also provide a void
4738pointer that can be retrieved via
4739
4740 mem_ptr=png_get_mem_ptr(png_ptr);
4741
4742Your replacement memory functions must have prototypes as follows:
4743
4744 png_voidp malloc_fn(png_structp png_ptr,
4745 png_alloc_size_t size);
4746
4747 void free_fn(png_structp png_ptr, png_voidp ptr);
4748
4749Your malloc_fn() must return NULL in case of failure. The png_malloc()
4750function will normally call png_error() if it receives a NULL from the
4751system memory allocator or from your replacement malloc_fn().
4752
4753Your free_fn() will never be called with a NULL ptr, since libpng's
4754png_free() checks for NULL before calling free_fn().
4755
4756Input/Output in libpng is done through png_read() and png_write(),
4757which currently just call fread() and fwrite(). The FILE * is stored in
4758png_struct and is initialized via png_init_io(). If you wish to change
4759the method of I/O, the library supplies callbacks that you can set
4760through the function png_set_read_fn() and png_set_write_fn() at run
4761time, instead of calling the png_init_io() function. These functions
4762also provide a void pointer that can be retrieved via the function
4763png_get_io_ptr(). For example:
4764
4765 png_set_read_fn(png_structp read_ptr,
4766 voidp read_io_ptr, png_rw_ptr read_data_fn)
4767
4768 png_set_write_fn(png_structp write_ptr,
4769 voidp write_io_ptr, png_rw_ptr write_data_fn,
4770 png_flush_ptr output_flush_fn);
4771
4772 voidp read_io_ptr = png_get_io_ptr(read_ptr);
4773 voidp write_io_ptr = png_get_io_ptr(write_ptr);
4774
4775The replacement I/O functions must have prototypes as follows:
4776
4777 void user_read_data(png_structp png_ptr,
4778 png_bytep data, size_t length);
4779
4780 void user_write_data(png_structp png_ptr,
4781 png_bytep data, size_t length);
4782
4783 void user_flush_data(png_structp png_ptr);
4784
4785The user_read_data() function is responsible for detecting and
4786handling end-of-data errors.
4787
4788Supplying NULL for the read, write, or flush functions sets them back
4789to using the default C stream functions, which expect the io_ptr to
4790point to a standard *FILE structure. It is probably a mistake
4791to use NULL for one of write_data_fn and output_flush_fn but not both
4792of them, unless you have built libpng with PNG_NO_WRITE_FLUSH defined.
4793It is an error to read from a write stream, and vice versa.
4794
4795Error handling in libpng is done through png_error() and png_warning().
4796Errors handled through png_error() are fatal, meaning that png_error()
4797should never return to its caller. Currently, this is handled via
4798setjmp() and longjmp() (unless you have compiled libpng with
4799PNG_NO_SETJMP, in which case it is handled via PNG_ABORT()),
4800but you could change this to do things like exit() if you should wish,
4801as long as your function does not return.
4802
4803On non-fatal errors, png_warning() is called
4804to print a warning message, and then control returns to the calling code.
4805By default png_error() and png_warning() print a message on stderr via
4806fprintf() unless the library is compiled with PNG_NO_CONSOLE_IO defined
4807(because you don't want the messages) or PNG_NO_STDIO defined (because
4808fprintf() isn't available). If you wish to change the behavior of the error
4809functions, you will need to set up your own message callbacks. These
4810functions are normally supplied at the time that the png_struct is created.
4811It is also possible to redirect errors and warnings to your own replacement
4812functions after png_create_*_struct() has been called by calling:
4813
4814 png_set_error_fn(png_structp png_ptr,
4815 png_voidp error_ptr, png_error_ptr error_fn,
4816 png_error_ptr warning_fn);
4817
4818If NULL is supplied for either error_fn or warning_fn, then the libpng
4819default function will be used, calling fprintf() and/or longjmp() if a
4820problem is encountered. The replacement error functions should have
4821parameters as follows:
4822
4823 void user_error_fn(png_structp png_ptr,
4824 png_const_charp error_msg);
4825
4826 void user_warning_fn(png_structp png_ptr,
4827 png_const_charp warning_msg);
4828
4829Then, within your user_error_fn or user_warning_fn, you can retrieve
4830the error_ptr if you need it, by calling
4831
4832 png_voidp error_ptr = png_get_error_ptr(png_ptr);
4833
4834The motivation behind using setjmp() and longjmp() is the C++ throw and
4835catch exception handling methods. This makes the code much easier to write,
4836as there is no need to check every return code of every function call.
4837However, there are some uncertainties about the status of local variables
4838after a longjmp, so the user may want to be careful about doing anything
4839after setjmp returns non-zero besides returning itself. Consult your
4840compiler documentation for more details. For an alternative approach, you
4841may wish to use the "cexcept" facility (see https://cexcept.sourceforge.io/),
4842which is illustrated in pngvalid.c and in contrib/visupng.
4843
4844Beginning in libpng-1.4.0, the png_set_benign_errors() API became available.
4845You can use this to handle certain errors (normally handled as errors)
4846as warnings.
4847
4848 png_set_benign_errors (png_ptr, int allowed);
4849
4850 allowed: 0: treat png_benign_error() as an error.
4851 1: treat png_benign_error() as a warning.
4852
4853As of libpng-1.6.0, the default condition is to treat benign errors as
4854warnings while reading and as errors while writing.
4855
4856.SS Custom chunks
4857
4858If you need to read or write custom chunks, you may need to get deeper
4859into the libpng code. The library now has mechanisms for storing
4860and writing chunks of unknown type; you can even declare callbacks
4861for custom chunks. However, this may not be good enough if the
4862library code itself needs to know about interactions between your
4863chunk and existing `intrinsic' chunks.
4864
4865If you need to write a new intrinsic chunk, first read the PNG
4866specification. Acquire a first level of understanding of how it works.
4867Pay particular attention to the sections that describe chunk names,
4868and look at how other chunks were designed, so you can do things
4869similarly. Second, check out the sections of libpng that read and
4870write chunks. Try to find a chunk that is similar to yours and use
4871it as a template. More details can be found in the comments inside
4872the code. It is best to handle private or unknown chunks in a generic method,
4873via callback functions, instead of by modifying libpng functions. This
4874is illustrated in pngtest.c, which uses a callback function to handle a
4875private "vpAg" chunk and the new "sTER" chunk, which are both unknown to
4876libpng.
4877
4878If you wish to write your own transformation for the data, look through
4879the part of the code that does the transformations, and check out some of
4880the simpler ones to get an idea of how they work. Try to find a similar
4881transformation to the one you want to add and copy off of it. More details
4882can be found in the comments inside the code itself.
4883
4884.SS Configuring for gui/windowing platforms:
4885
4886You will need to write new error and warning functions that use the GUI
4887interface, as described previously, and set them to be the error and
4888warning functions at the time that png_create_*_struct() is called,
4889in order to have them available during the structure initialization.
4890They can be changed later via png_set_error_fn(). On some compilers,
4891you may also have to change the memory allocators (png_malloc, etc.).
4892
4893.SS Configuring zlib:
4894
4895There are special functions to configure the compression. Perhaps the
4896most useful one changes the compression level, which currently uses
4897input compression values in the range 0 - 9. The library normally
4898uses the default compression level (Z_DEFAULT_COMPRESSION = 6). Tests
4899have shown that for a large majority of images, compression values in
4900the range 3-6 compress nearly as well as higher levels, and do so much
4901faster. For online applications it may be desirable to have maximum speed
4902(Z_BEST_SPEED = 1). With versions of zlib after v0.99, you can also
4903specify no compression (Z_NO_COMPRESSION = 0), but this would create
4904files larger than just storing the raw bitmap. You can specify the
4905compression level by calling:
4906
4907 #include zlib.h
4908 png_set_compression_level(png_ptr, level);
4909
4910Another useful one is to reduce the memory level used by the library.
4911The memory level defaults to 8, but it can be lowered if you are
4912short on memory (running DOS, for example, where you only have 640K).
4913Note that the memory level does have an effect on compression; among
4914other things, lower levels will result in sections of incompressible
4915data being emitted in smaller stored blocks, with a correspondingly
4916larger relative overhead of up to 15% in the worst case.
4917
4918 #include zlib.h
4919 png_set_compression_mem_level(png_ptr, level);
4920
4921The other functions are for configuring zlib. They are not recommended
4922for normal use and may result in writing an invalid PNG file. See
4923zlib.h for more information on what these mean.
4924
4925 #include zlib.h
4926 png_set_compression_strategy(png_ptr,
4927 strategy);
4928
4929 png_set_compression_window_bits(png_ptr,
4930 window_bits);
4931
4932 png_set_compression_method(png_ptr, method);
4933
4934This controls the size of the IDAT chunks (default 8192):
4935
4936 png_set_compression_buffer_size(png_ptr, size);
4937
4938As of libpng version 1.5.4, additional APIs became
4939available to set these separately for non-IDAT
4940compressed chunks such as zTXt, iTXt, and iCCP:
4941
4942 #include zlib.h
4943 #if PNG_LIBPNG_VER >= 10504
4944 png_set_text_compression_level(png_ptr, level);
4945
4946 png_set_text_compression_mem_level(png_ptr, level);
4947
4948 png_set_text_compression_strategy(png_ptr,
4949 strategy);
4950
4951 png_set_text_compression_window_bits(png_ptr,
4952 window_bits);
4953
4954 png_set_text_compression_method(png_ptr, method);
4955 #endif
4956
4957.SS Controlling row filtering
4958
4959If you want to control whether libpng uses filtering or not, which
4960filters are used, and how it goes about picking row filters, you
4961can call one of these functions. The selection and configuration
4962of row filters can have a significant impact on the size and
4963encoding speed and a somewhat lesser impact on the decoding speed
4964of an image. Filtering is enabled by default for RGB and grayscale
4965images (with and without alpha), but not for paletted images nor
4966for any images with bit depths less than 8 bits/pixel.
4967
4968The 'method' parameter sets the main filtering method, which is
4969currently only '0' in the PNG 1.2 specification. The 'filters'
4970parameter sets which filter(s), if any, should be used for each
4971scanline. Possible values are PNG_ALL_FILTERS, PNG_NO_FILTERS,
4972or PNG_FAST_FILTERS to turn filtering on and off, or to turn on
4973just the fast-decoding subset of filters, respectively.
4974
4975Individual filter types are PNG_FILTER_NONE, PNG_FILTER_SUB,
4976PNG_FILTER_UP, PNG_FILTER_AVG, PNG_FILTER_PAETH, which can be bitwise
4977ORed together with '|' to specify one or more filters to use.
4978These filters are described in more detail in the PNG specification.
4979If you intend to change the filter type during the course of writing
4980the image, you should start with flags set for all of the filters
4981you intend to use so that libpng can initialize its internal
4982structures appropriately for all of the filter types. (Note that this
4983means the first row must always be adaptively filtered, because libpng
4984currently does not allocate the filter buffers until png_write_row()
4985is called for the first time.)
4986
4987 filters = PNG_NO_FILTERS;
4988 filters = PNG_ALL_FILTERS;
4989 filters = PNG_FAST_FILTERS;
4990
4991 or
4992
4993 filters = PNG_FILTER_NONE | PNG_FILTER_SUB |
4994 PNG_FILTER_UP | PNG_FILTER_AVG |
4995 PNG_FILTER_PAETH;
4996
4997 png_set_filter(png_ptr, PNG_FILTER_TYPE_BASE,
4998 filters);
4999
5000 The second parameter can also be
5001 PNG_INTRAPIXEL_DIFFERENCING if you are
5002 writing a PNG to be embedded in a MNG
5003 datastream. This parameter must be the
5004 same as the value of filter_method used
5005 in png_set_IHDR().
5006
5007.SS Requesting debug printout
5008
5009The macro definition PNG_DEBUG can be used to request debugging
5010printout. Set it to an integer value in the range 0 to 3. Higher
5011numbers result in increasing amounts of debugging information. The
5012information is printed to the "stderr" file, unless another file
5013name is specified in the PNG_DEBUG_FILE macro definition.
5014
5015When PNG_DEBUG > 0, the following functions (macros) become available:
5016
5017 png_debug(level, message)
5018 png_debug1(level, message, p1)
5019 png_debug2(level, message, p1, p2)
5020
5021in which "level" is compared to PNG_DEBUG to decide whether to print
5022the message, "message" is the formatted string to be printed,
5023and p1 and p2 are parameters that are to be embedded in the string
5024according to printf-style formatting directives. For example,
5025
5026 png_debug1(2, "foo=%d", foo);
5027
5028is expanded to
5029
5030 if (PNG_DEBUG > 2)
5031 fprintf(PNG_DEBUG_FILE, "foo=%d\en", foo);
5032
5033When PNG_DEBUG is defined but is zero, the macros aren't defined, but you
5034can still use PNG_DEBUG to control your own debugging:
5035
5036 #ifdef PNG_DEBUG
5037 fprintf(stderr, ...
5038 #endif
5039
5040When PNG_DEBUG = 1, the macros are defined, but only png_debug statements
5041having level = 0 will be printed. There aren't any such statements in
5042this version of libpng, but if you insert some they will be printed.
5043
5044.SH VII. MNG support
5045
5046The MNG specification (available at http://www.libpng.org/pub/mng) allows
5047certain extensions to PNG for PNG images that are embedded in MNG datastreams.
5048Libpng can support some of these extensions. To enable them, use the
5049png_permit_mng_features() function:
5050
5051 feature_set = png_permit_mng_features(png_ptr, mask)
5052
5053 mask is a png_uint_32 containing the bitwise OR of the
5054 features you want to enable. These include
5055 PNG_FLAG_MNG_EMPTY_PLTE
5056 PNG_FLAG_MNG_FILTER_64
5057 PNG_ALL_MNG_FEATURES
5058
5059 feature_set is a png_uint_32 that is the bitwise AND of
5060 your mask with the set of MNG features that is
5061 supported by the version of libpng that you are using.
5062
5063It is an error to use this function when reading or writing a standalone
5064PNG file with the PNG 8-byte signature. The PNG datastream must be wrapped
5065in a MNG datastream. As a minimum, it must have the MNG 8-byte signature
5066and the MHDR and MEND chunks. Libpng does not provide support for these
5067or any other MNG chunks; your application must provide its own support for
5068them. You may wish to consider using libmng (available at
5069https://www.libmng.com/) instead.
5070
5071.SH VIII. Changes to Libpng from version 0.88
5072
5073It should be noted that versions of libpng later than 0.96 are not
5074distributed by the original libpng author, Guy Schalnat, nor by
5075Andreas Dilger, who had taken over from Guy during 1996 and 1997, and
5076distributed versions 0.89 through 0.96, but rather by another member
5077of the original PNG Group, Glenn Randers-Pehrson. Guy and Andreas are
5078still alive and well, but they have moved on to other things.
5079
5080The old libpng functions png_read_init(), png_write_init(),
5081png_info_init(), png_read_destroy(), and png_write_destroy() have been
5082moved to PNG_INTERNAL in version 0.95 to discourage their use. These
5083functions will be removed from libpng version 1.4.0.
5084
5085The preferred method of creating and initializing the libpng structures is
5086via the png_create_read_struct(), png_create_write_struct(), and
5087png_create_info_struct() because they isolate the size of the structures
5088from the application, allow version error checking, and also allow the
5089use of custom error handling routines during the initialization, which
5090the old functions do not. The functions png_read_destroy() and
5091png_write_destroy() do not actually free the memory that libpng
5092allocated for these structs, but just reset the data structures, so they
5093can be used instead of png_destroy_read_struct() and
5094png_destroy_write_struct() if you feel there is too much system overhead
5095allocating and freeing the png_struct for each image read.
5096
5097Setting the error callbacks via png_set_message_fn() before
5098png_read_init() as was suggested in libpng-0.88 is no longer supported
5099because this caused applications that do not use custom error functions
5100to fail if the png_ptr was not initialized to zero. It is still possible
5101to set the error callbacks AFTER png_read_init(), or to change them with
5102png_set_error_fn(), which is essentially the same function, but with a new
5103name to force compilation errors with applications that try to use the old
5104method.
5105
5106Support for the sCAL, iCCP, iTXt, and sPLT chunks was added at libpng-1.0.6;
5107however, iTXt support was not enabled by default.
5108
5109Starting with version 1.0.7, you can find out which version of the library
5110you are using at run-time:
5111
5112 png_uint_32 libpng_vn = png_access_version_number();
5113
5114The number libpng_vn is constructed from the major version, minor
5115version with leading zero, and release number with leading zero,
5116(e.g., libpng_vn for version 1.0.7 is 10007).
5117
5118Note that this function does not take a png_ptr, so you can call it
5119before you've created one.
5120
5121You can also check which version of png.h you used when compiling your
5122application:
5123
5124 png_uint_32 application_vn = PNG_LIBPNG_VER;
5125
5126.SH IX. Changes to Libpng from version 1.0.x to 1.2.x
5127
5128Support for user memory management was enabled by default. To
5129accomplish this, the functions png_create_read_struct_2(),
5130png_create_write_struct_2(), png_set_mem_fn(), png_get_mem_ptr(),
5131png_malloc_default(), and png_free_default() were added.
5132
5133Support for the iTXt chunk has been enabled by default as of
5134version 1.2.41.
5135
5136Support for certain MNG features was enabled.
5137
5138Support for numbered error messages was added. However, we never got
5139around to actually numbering the error messages. The function
5140png_set_strip_error_numbers() was added (Note: the prototype for this
5141function was inadvertently removed from png.h in PNG_NO_ASSEMBLER_CODE
5142builds of libpng-1.2.15. It was restored in libpng-1.2.36).
5143
5144The png_malloc_warn() function was added at libpng-1.2.3. This issues
5145a png_warning and returns NULL instead of aborting when it fails to
5146acquire the requested memory allocation.
5147
5148Support for setting user limits on image width and height was enabled
5149by default. The functions png_set_user_limits(), png_get_user_width_max(),
5150and png_get_user_height_max() were added at libpng-1.2.6.
5151
5152The png_set_add_alpha() function was added at libpng-1.2.7.
5153
5154The function png_set_expand_gray_1_2_4_to_8() was added at libpng-1.2.9.
5155Unlike png_set_gray_1_2_4_to_8(), the new function does not expand the
5156tRNS chunk to alpha. The png_set_gray_1_2_4_to_8() function is
5157deprecated.
5158
5159A number of macro definitions in support of runtime selection of
5160assembler code features (especially Intel MMX code support) were
5161added at libpng-1.2.0:
5162
5163 PNG_ASM_FLAG_MMX_SUPPORT_COMPILED
5164 PNG_ASM_FLAG_MMX_SUPPORT_IN_CPU
5165 PNG_ASM_FLAG_MMX_READ_COMBINE_ROW
5166 PNG_ASM_FLAG_MMX_READ_INTERLACE
5167 PNG_ASM_FLAG_MMX_READ_FILTER_SUB
5168 PNG_ASM_FLAG_MMX_READ_FILTER_UP
5169 PNG_ASM_FLAG_MMX_READ_FILTER_AVG
5170 PNG_ASM_FLAG_MMX_READ_FILTER_PAETH
5171 PNG_ASM_FLAGS_INITIALIZED
5172 PNG_MMX_READ_FLAGS
5173 PNG_MMX_FLAGS
5174 PNG_MMX_WRITE_FLAGS
5175 PNG_MMX_FLAGS
5176
5177We added the following functions in support of runtime
5178selection of assembler code features:
5179
5180 png_get_mmx_flagmask()
5181 png_set_mmx_thresholds()
5182 png_get_asm_flags()
5183 png_get_mmx_bitdepth_threshold()
5184 png_get_mmx_rowbytes_threshold()
5185 png_set_asm_flags()
5186
5187We replaced all of these functions with simple stubs in libpng-1.2.20,
5188when the Intel assembler code was removed due to a licensing issue.
5189
5190These macros are deprecated:
5191
5192 PNG_READ_TRANSFORMS_NOT_SUPPORTED
5193 PNG_PROGRESSIVE_READ_NOT_SUPPORTED
5194 PNG_NO_SEQUENTIAL_READ_SUPPORTED
5195 PNG_WRITE_TRANSFORMS_NOT_SUPPORTED
5196 PNG_READ_ANCILLARY_CHUNKS_NOT_SUPPORTED
5197 PNG_WRITE_ANCILLARY_CHUNKS_NOT_SUPPORTED
5198
5199They have been replaced, respectively, by:
5200
5201 PNG_NO_READ_TRANSFORMS
5202 PNG_NO_PROGRESSIVE_READ
5203 PNG_NO_SEQUENTIAL_READ
5204 PNG_NO_WRITE_TRANSFORMS
5205 PNG_NO_READ_ANCILLARY_CHUNKS
5206 PNG_NO_WRITE_ANCILLARY_CHUNKS
5207
5208PNG_MAX_UINT was replaced with PNG_UINT_31_MAX. It has been
5209deprecated since libpng-1.0.16 and libpng-1.2.6.
5210
5211The function
5212 png_check_sig(sig, num)
5213was replaced with
5214 !png_sig_cmp(sig, 0, num)
5215It has been deprecated since libpng-0.90.
5216
5217The function
5218 png_set_gray_1_2_4_to_8()
5219which also expands tRNS to alpha was replaced with
5220 png_set_expand_gray_1_2_4_to_8()
5221which does not. It has been deprecated since libpng-1.0.18 and 1.2.9.
5222
5223.SH X. Changes to Libpng from version 1.0.x/1.2.x to 1.4.x
5224
5225Private libpng prototypes and macro definitions were moved from
5226png.h and pngconf.h into a new pngpriv.h header file.
5227
5228Functions png_set_benign_errors(), png_benign_error(), and
5229png_chunk_benign_error() were added.
5230
5231Support for setting the maximum amount of memory that the application
5232will allocate for reading chunks was added, as a security measure.
5233The functions png_set_chunk_cache_max() and png_get_chunk_cache_max()
5234were added to the library.
5235
5236We implemented support for I/O states by adding png_ptr member io_state
5237and functions png_get_io_chunk_name() and png_get_io_state() in pngget.c
5238
5239We added PNG_TRANSFORM_GRAY_TO_RGB to the available high-level
5240input transforms.
5241
5242Checking for and reporting of errors in the IHDR chunk is more thorough.
5243
5244Support for global arrays was removed, to improve thread safety.
5245
5246Some obsolete/deprecated macros and functions have been removed.
5247
5248Typecasted NULL definitions such as
5249 #define png_voidp_NULL (png_voidp)NULL
5250were eliminated. If you used these in your application, just use
5251NULL instead.
5252
5253The png_struct and info_struct members "trans" and "trans_values" were
5254changed to "trans_alpha" and "trans_color", respectively.
5255
5256The obsolete, unused pnggccrd.c and pngvcrd.c files and related makefiles
5257were removed.
5258
5259The PNG_1_0_X and PNG_1_2_X macros were eliminated.
5260
5261The PNG_LEGACY_SUPPORTED macro was eliminated.
5262
5263Many WIN32_WCE #ifdefs were removed.
5264
5265The functions png_read_init(info_ptr), png_write_init(info_ptr),
5266png_info_init(info_ptr), png_read_destroy(), and png_write_destroy()
5267have been removed. They have been deprecated since libpng-0.95.
5268
5269The png_permit_empty_plte() was removed. It has been deprecated
5270since libpng-1.0.9. Use png_permit_mng_features() instead.
5271
5272We removed the obsolete stub functions png_get_mmx_flagmask(),
5273png_set_mmx_thresholds(), png_get_asm_flags(),
5274png_get_mmx_bitdepth_threshold(), png_get_mmx_rowbytes_threshold(),
5275png_set_asm_flags(), and png_mmx_supported()
5276
5277We removed the obsolete png_check_sig(), png_memcpy_check(), and
5278png_memset_check() functions. Instead use !png_sig_cmp(), memcpy(),
5279and memset(), respectively.
5280
5281The function png_set_gray_1_2_4_to_8() was removed. It has been
5282deprecated since libpng-1.0.18 and 1.2.9, when it was replaced with
5283png_set_expand_gray_1_2_4_to_8() because the former function also
5284expanded any tRNS chunk to an alpha channel.
5285
5286Macros for png_get_uint_16, png_get_uint_32, and png_get_int_32
5287were added and are used by default instead of the corresponding
5288functions. Unfortunately,
5289from libpng-1.4.0 until 1.4.4, the png_get_uint_16 macro (but not the
5290function) incorrectly returned a value of type png_uint_32.
5291
5292We changed the prototype for png_malloc() from
5293 png_malloc(png_structp png_ptr, png_uint_32 size)
5294to
5295 png_malloc(png_structp png_ptr, png_alloc_size_t size)
5296
5297This also applies to the prototype for the user replacement malloc_fn().
5298
5299The png_calloc() function was added and is used in place of
5300of "png_malloc(); memset();" except in the case in png_read_png()
5301where the array consists of pointers; in this case a "for" loop is used
5302after the png_malloc() to set the pointers to NULL, to give robust.
5303behavior in case the application runs out of memory part-way through
5304the process.
5305
5306We changed the prototypes of png_get_compression_buffer_size() and
5307png_set_compression_buffer_size() to work with size_t instead of
5308png_uint_32.
5309
5310Support for numbered error messages was removed by default, since we
5311never got around to actually numbering the error messages. The function
5312png_set_strip_error_numbers() was removed from the library by default.
5313
5314The png_zalloc() and png_zfree() functions are no longer exported.
5315The png_zalloc() function no longer zeroes out the memory that it
5316allocates. Applications that called png_zalloc(png_ptr, number, size)
5317can call png_calloc(png_ptr, number*size) instead, and can call
5318png_free() instead of png_zfree().
5319
5320Support for dithering was disabled by default in libpng-1.4.0, because
5321it has not been well tested and doesn't actually "dither".
5322The code was not
5323removed, however, and could be enabled by building libpng with
5324PNG_READ_DITHER_SUPPORTED defined. In libpng-1.4.2, this support
5325was re-enabled, but the function was renamed png_set_quantize() to
5326reflect more accurately what it actually does. At the same time,
5327the PNG_DITHER_[RED,GREEN_BLUE]_BITS macros were also renamed to
5328PNG_QUANTIZE_[RED,GREEN,BLUE]_BITS, and PNG_READ_DITHER_SUPPORTED
5329was renamed to PNG_READ_QUANTIZE_SUPPORTED.
5330
5331We removed the trailing '.' from the warning and error messages.
5332
5333.SH XI. Changes to Libpng from version 1.4.x to 1.5.x
5334
5335From libpng-1.4.0 until 1.4.4, the png_get_uint_16 macro (but not the
5336function) incorrectly returned a value of type png_uint_32.
5337The incorrect macro was removed from libpng-1.4.5.
5338
5339Checking for invalid palette index on write was added at libpng
53401.5.10. If a pixel contains an invalid (out-of-range) index libpng issues
5341a benign error. This is enabled by default because this condition is an
5342error according to the PNG specification, Clause 11.3.2, but the error can
5343be ignored in each png_ptr with
5344
5345 png_set_check_for_invalid_index(png_ptr, allowed);
5346
5347 allowed - one of
5348 0: disable benign error (accept the
5349 invalid data without warning).
5350 1: enable benign error (treat the
5351 invalid data as an error or a
5352 warning).
5353
5354If the error is ignored, or if png_benign_error() treats it as a warning,
5355any invalid pixels are decoded as opaque black by the decoder and written
5356as-is by the encoder.
5357
5358Retrieving the maximum palette index found was added at libpng-1.5.15.
5359This statement must appear after png_read_png() or png_read_image() while
5360reading, and after png_write_png() or png_write_image() while writing.
5361
5362 int max_palette = png_get_palette_max(png_ptr, info_ptr);
5363
5364This will return the maximum palette index found in the image, or "\-1" if
5365the palette was not checked, or "0" if no palette was found. Note that this
5366does not account for any palette index used by ancillary chunks such as the
5367bKGD chunk; you must check those separately to determine the maximum
5368palette index actually used.
5369
5370There are no substantial API changes between the non-deprecated parts of
5371the 1.4.5 API and the 1.5.0 API; however, the ability to directly access
5372members of the main libpng control structures, png_struct and png_info,
5373deprecated in earlier versions of libpng, has been completely removed from
5374libpng 1.5, and new private "pngstruct.h", "pnginfo.h", and "pngdebug.h"
5375header files were created.
5376
5377We no longer include zlib.h in png.h. The include statement has been moved
5378to pngstruct.h, where it is not accessible by applications. Applications that
5379need access to information in zlib.h will need to add the '#include "zlib.h"'
5380directive. It does not matter whether this is placed prior to or after
5381the '"#include png.h"' directive.
5382
5383The png_sprintf(), png_strcpy(), and png_strncpy() macros are no longer used
5384and were removed.
5385
5386We moved the png_strlen(), png_memcpy(), png_memset(), and png_memcmp()
5387macros into a private header file (pngpriv.h) that is not accessible to
5388applications.
5389
5390In png_get_iCCP, the type of "profile" was changed from png_charpp
5391to png_bytepp, and in png_set_iCCP, from png_charp to png_const_bytep.
5392
5393There are changes of form in png.h, including new and changed macros to
5394declare parts of the API. Some API functions with arguments that are
5395pointers to data not modified within the function have been corrected to
5396declare these arguments with const.
5397
5398Much of the internal use of C macros to control the library build has also
5399changed and some of this is visible in the exported header files, in
5400particular the use of macros to control data and API elements visible
5401during application compilation may require significant revision to
5402application code. (It is extremely rare for an application to do this.)
5403
5404Any program that compiled against libpng 1.4 and did not use deprecated
5405features or access internal library structures should compile and work
5406against libpng 1.5, except for the change in the prototype for
5407png_get_iCCP() and png_set_iCCP() API functions mentioned above.
5408
5409libpng 1.5.0 adds PNG_ PASS macros to help in the reading and writing of
5410interlaced images. The macros return the number of rows and columns in
5411each pass and information that can be used to de-interlace and (if
5412absolutely necessary) interlace an image.
5413
5414libpng 1.5.0 adds an API png_longjmp(png_ptr, value). This API calls
5415the application-provided png_longjmp_ptr on the internal, but application
5416initialized, longjmp buffer. It is provided as a convenience to avoid
5417the need to use the png_jmpbuf macro, which had the unnecessary side
5418effect of resetting the internal png_longjmp_ptr value.
5419
5420libpng 1.5.0 includes a complete fixed point API. By default this is
5421present along with the corresponding floating point API. In general the
5422fixed point API is faster and smaller than the floating point one because
5423the PNG file format used fixed point, not floating point. This applies
5424even if the library uses floating point in internal calculations. A new
5425macro, PNG_FLOATING_ARITHMETIC_SUPPORTED, reveals whether the library
5426uses floating point arithmetic (the default) or fixed point arithmetic
5427internally for performance critical calculations such as gamma correction.
5428In some cases, the gamma calculations may produce slightly different
5429results. This has changed the results in png_rgb_to_gray and in alpha
5430composition (png_set_background for example). This applies even if the
5431original image was already linear (gamma == 1.0) and, therefore, it is
5432not necessary to linearize the image. This is because libpng has *not*
5433been changed to optimize that case correctly, yet.
5434
5435Fixed point support for the sCAL chunk comes with an important caveat;
5436the sCAL specification uses a decimal encoding of floating point values
5437and the accuracy of PNG fixed point values is insufficient for
5438representation of these values. Consequently a "string" API
5439(png_get_sCAL_s and png_set_sCAL_s) is the only reliable way of reading
5440arbitrary sCAL chunks in the absence of either the floating point API or
5441internal floating point calculations. Starting with libpng-1.5.0, both
5442of these functions are present when PNG_sCAL_SUPPORTED is defined. Prior
5443to libpng-1.5.0, their presence also depended upon PNG_FIXED_POINT_SUPPORTED
5444being defined and PNG_FLOATING_POINT_SUPPORTED not being defined.
5445
5446Applications no longer need to include the optional distribution header
5447file pngusr.h or define the corresponding macros during application
5448build in order to see the correct variant of the libpng API. From 1.5.0
5449application code can check for the corresponding _SUPPORTED macro:
5450
5451#ifdef PNG_INCH_CONVERSIONS_SUPPORTED
5452 /* code that uses the inch conversion APIs. */
5453#endif
5454
5455This macro will only be defined if the inch conversion functions have been
5456compiled into libpng. The full set of macros, and whether or not support
5457has been compiled in, are available in the header file pnglibconf.h.
5458This header file is specific to the libpng build. Notice that prior to
54591.5.0 the _SUPPORTED macros would always have the default definition unless
5460reset by pngusr.h or by explicit settings on the compiler command line.
5461These settings may produce compiler warnings or errors in 1.5.0 because
5462of macro redefinition.
5463
5464Applications can now choose whether to use these macros or to call the
5465corresponding function by defining PNG_USE_READ_MACROS or
5466PNG_NO_USE_READ_MACROS before including png.h. Notice that this is
5467only supported from 1.5.0; defining PNG_NO_USE_READ_MACROS prior to 1.5.0
5468will lead to a link failure.
5469
5470Prior to libpng-1.5.4, the zlib compressor used the same set of parameters
5471when compressing the IDAT data and textual data such as zTXt and iCCP.
5472In libpng-1.5.4 we reinitialized the zlib stream for each type of data.
5473We added five png_set_text_*() functions for setting the parameters to
5474use with textual data.
5475
5476Prior to libpng-1.5.4, the PNG_READ_16_TO_8_ACCURATE_SCALE_SUPPORTED
5477option was off by default, and slightly inaccurate scaling occurred.
5478This option can no longer be turned off, and the choice of accurate
5479or inaccurate 16-to-8 scaling is by using the new png_set_scale_16_to_8()
5480API for accurate scaling or the old png_set_strip_16_to_8() API for simple
5481chopping. In libpng-1.5.4, the PNG_READ_16_TO_8_ACCURATE_SCALE_SUPPORTED
5482macro became PNG_READ_SCALE_16_TO_8_SUPPORTED, and the PNG_READ_16_TO_8
5483macro became PNG_READ_STRIP_16_TO_8_SUPPORTED, to enable the two
5484png_set_*_16_to_8() functions separately.
5485
5486Prior to libpng-1.5.4, the png_set_user_limits() function could only be
5487used to reduce the width and height limits from the value of
5488PNG_USER_WIDTH_MAX and PNG_USER_HEIGHT_MAX, although this document said
5489that it could be used to override them. Now this function will reduce or
5490increase the limits.
5491
5492Starting in libpng-1.5.22, default user limits were established. These
5493can be overridden by application calls to png_set_user_limits(),
5494png_set_user_chunk_cache_max(), and/or png_set_user_malloc_max().
5495The limits are now
5496 max possible default
5497 png_user_width_max 0x7fffffff 1,000,000
5498 png_user_height_max 0x7fffffff 1,000,000
5499 png_user_chunk_cache_max 0 (unlimited) 1000
5500 png_user_chunk_malloc_max 0 (unlimited) 8,000,000
5501
5502The png_set_option() function (and the "options" member of the png struct) was
5503added to libpng-1.5.15, with option PNG_ARM_NEON.
5504
5505The library now supports a complete fixed point implementation and can
5506thus be used on systems that have no floating point support or very
5507limited or slow support. Previously gamma correction, an essential part
5508of complete PNG support, required reasonably fast floating point.
5509
5510As part of this the choice of internal implementation has been made
5511independent of the choice of fixed versus floating point APIs and all the
5512missing fixed point APIs have been implemented.
5513
5514The exact mechanism used to control attributes of API functions has
5515changed, as described in the INSTALL file.
5516
5517A new test program, pngvalid, is provided in addition to pngtest.
5518pngvalid validates the arithmetic accuracy of the gamma correction
5519calculations and includes a number of validations of the file format.
5520A subset of the full range of tests is run when "make check" is done
5521(in the 'configure' build.) pngvalid also allows total allocated memory
5522usage to be evaluated and performs additional memory overwrite validation.
5523
5524Many changes to individual feature macros have been made. The following
5525are the changes most likely to be noticed by library builders who
5526configure libpng:
5527
55281) All feature macros now have consistent naming:
5529
5530#define PNG_NO_feature turns the feature off
5531#define PNG_feature_SUPPORTED turns the feature on
5532
5533pnglibconf.h contains one line for each feature macro which is either:
5534
5535#define PNG_feature_SUPPORTED
5536
5537if the feature is supported or:
5538
5539/*#undef PNG_feature_SUPPORTED*/
5540
5541if it is not. Library code consistently checks for the 'SUPPORTED' macro.
5542It does not, and libpng applications should not, check for the 'NO' macro
5543which will not normally be defined even if the feature is not supported.
5544The 'NO' macros are only used internally for setting or not setting the
5545corresponding 'SUPPORTED' macros.
5546
5547Compatibility with the old names is provided as follows:
5548
5549PNG_INCH_CONVERSIONS turns on PNG_INCH_CONVERSIONS_SUPPORTED
5550
5551And the following definitions disable the corresponding feature:
5552
5553PNG_SETJMP_NOT_SUPPORTED disables SETJMP
5554PNG_READ_TRANSFORMS_NOT_SUPPORTED disables READ_TRANSFORMS
5555PNG_NO_READ_COMPOSITED_NODIV disables READ_COMPOSITE_NODIV
5556PNG_WRITE_TRANSFORMS_NOT_SUPPORTED disables WRITE_TRANSFORMS
5557PNG_READ_ANCILLARY_CHUNKS_NOT_SUPPORTED disables READ_ANCILLARY_CHUNKS
5558PNG_WRITE_ANCILLARY_CHUNKS_NOT_SUPPORTED disables WRITE_ANCILLARY_CHUNKS
5559
5560Library builders should remove use of the above, inconsistent, names.
5561
55622) Warning and error message formatting was previously conditional on
5563the STDIO feature. The library has been changed to use the
5564CONSOLE_IO feature instead. This means that if CONSOLE_IO is disabled
5565the library no longer uses the printf(3) functions, even though the
5566default read/write implementations use (FILE) style stdio.h functions.
5567
55683) Three feature macros now control the fixed/floating point decisions:
5569
5570PNG_FLOATING_POINT_SUPPORTED enables the floating point APIs
5571
5572PNG_FIXED_POINT_SUPPORTED enables the fixed point APIs; however, in
5573practice these are normally required internally anyway (because the PNG
5574file format is fixed point), therefore in most cases PNG_NO_FIXED_POINT
5575merely stops the function from being exported.
5576
5577PNG_FLOATING_ARITHMETIC_SUPPORTED chooses between the internal floating
5578point implementation or the fixed point one. Typically the fixed point
5579implementation is larger and slower than the floating point implementation
5580on a system that supports floating point; however, it may be faster on a
5581system which lacks floating point hardware and therefore uses a software
5582emulation.
5583
55844) Added PNG_{READ,WRITE}_INT_FUNCTIONS_SUPPORTED. This allows the
5585functions to read and write ints to be disabled independently of
5586PNG_USE_READ_MACROS, which allows libpng to be built with the functions
5587even though the default is to use the macros - this allows applications
5588to choose at app buildtime whether or not to use macros (previously
5589impossible because the functions weren't in the default build.)
5590
5591.SH XII. Changes to Libpng from version 1.5.x to 1.6.x
5592
5593A "simplified API" has been added (see documentation in png.h and a simple
5594example in contrib/examples/pngtopng.c). The new publicly visible API
5595includes the following:
5596
5597 macros:
5598 PNG_FORMAT_*
5599 PNG_IMAGE_*
5600 structures:
5601 png_control
5602 png_image
5603 read functions
5604 png_image_begin_read_from_file()
5605 png_image_begin_read_from_stdio()
5606 png_image_begin_read_from_memory()
5607 png_image_finish_read()
5608 png_image_free()
5609 write functions
5610 png_image_write_to_file()
5611 png_image_write_to_memory()
5612 png_image_write_to_stdio()
5613
5614Starting with libpng-1.6.0, you can configure libpng to prefix all exported
5615symbols, using the PNG_PREFIX macro.
5616
5617We no longer include string.h in png.h. The include statement has been moved
5618to pngpriv.h, where it is not accessible by applications. Applications that
5619need access to information in string.h must add an '#include <string.h>'
5620directive. It does not matter whether this is placed prior to or after
5621the '#include "png.h"' directive.
5622
5623The following API are now DEPRECATED:
5624 png_info_init_3()
5625 png_convert_to_rfc1123() which has been replaced
5626 with png_convert_to_rfc1123_buffer()
5627 png_malloc_default()
5628 png_free_default()
5629 png_reset_zstream()
5630
5631The following have been removed:
5632 png_get_io_chunk_name(), which has been replaced
5633 with png_get_io_chunk_type(). The new
5634 function returns a 32-bit integer instead of
5635 a string.
5636 The png_sizeof(), png_strlen(), png_memcpy(), png_memcmp(), and
5637 png_memset() macros are no longer used in the libpng sources and
5638 have been removed. These had already been made invisible to applications
5639 (i.e., defined in the private pngpriv.h header file) since libpng-1.5.0.
5640
5641The signatures of many exported functions were changed, such that
5642 png_structp became png_structrp or png_const_structrp
5643 png_infop became png_inforp or png_const_inforp
5644where "rp" indicates a "restricted pointer".
5645
5646Dropped support for 16-bit platforms. The support for FAR/far types has
5647been eliminated and the definition of png_alloc_size_t is now controlled
5648by a flag so that 'small size_t' systems can select it if necessary.
5649
5650Error detection in some chunks has improved; in particular the iCCP chunk
5651reader now does pretty complete validation of the basic format. Some bad
5652profiles that were previously accepted are now accepted with a warning or
5653rejected, depending upon the png_set_benign_errors() setting, in particular
5654the very old broken Microsoft/HP 3144-byte sRGB profile. Starting with
5655libpng-1.6.11, recognizing and checking sRGB profiles can be avoided by
5656means of
5657
5658 #if defined(PNG_SKIP_sRGB_CHECK_PROFILE) && \
5659 defined(PNG_SET_OPTION_SUPPORTED)
5660 png_set_option(png_ptr, PNG_SKIP_sRGB_CHECK_PROFILE,
5661 PNG_OPTION_ON);
5662 #endif
5663
5664It's not a good idea to do this if you are using the "simplified API",
5665which needs to be able to recognize sRGB profiles conveyed via the iCCP
5666chunk.
5667
5668The PNG spec requirement that only grayscale profiles may appear in images
5669with color type 0 or 4 and that even if the image only contains gray pixels,
5670only RGB profiles may appear in images with color type 2, 3, or 6, is now
5671enforced. The sRGB chunk is allowed to appear in images with any color type
5672and is interpreted by libpng to convey a one-tracer-curve gray profile or a
5673three-tracer-curve RGB profile as appropriate.
5674
5675Libpng 1.5.x erroneously used /MD for Debug DLL builds; if you used the debug
5676builds in your app and you changed your app to use /MD you will need to
5677change it back to /MDd for libpng 1.6.x.
5678
5679Prior to libpng-1.6.0 a warning would be issued if the iTXt chunk contained
5680an empty language field or an empty translated keyword. Both of these
5681are allowed by the PNG specification, so these warnings are no longer issued.
5682
5683The library now issues an error if the application attempts to set a
5684transform after it calls png_read_update_info() or if it attempts to call
5685both png_read_update_info() and png_start_read_image() or to call either
5686of them more than once.
5687
5688The default condition for benign_errors is now to treat benign errors as
5689warnings while reading and as errors while writing.
5690
5691The library now issues a warning if both background processing and RGB to
5692gray are used when gamma correction happens. As with previous versions of
5693the library the results are numerically very incorrect in this case.
5694
5695There are some minor arithmetic changes in some transforms such as
5696png_set_background(), that might be detected by certain regression tests.
5697
5698Unknown chunk handling has been improved internally, without any API change.
5699This adds more correct option control of the unknown handling, corrects
5700a pre-existing bug where the per-chunk 'keep' setting is ignored, and makes
5701it possible to skip IDAT chunks in the sequential reader.
5702
5703The machine-generated configure files are no longer included in branches
5704libpng16 and later of the GIT repository. They continue to be included
5705in the tarball releases, however.
5706
5707Libpng-1.6.0 through 1.6.2 used the CMF bytes at the beginning of the IDAT
5708stream to set the size of the sliding window for reading instead of using the
5709default 32-kbyte sliding window size. It was discovered that there are
5710hundreds of PNG files in the wild that have incorrect CMF bytes that caused
5711zlib to issue the "invalid distance too far back" error and reject the file.
5712Libpng-1.6.3 and later calculate their own safe CMF from the image dimensions,
5713provide a way to revert to the libpng-1.5.x behavior (ignoring the CMF bytes
5714and using a 32-kbyte sliding window), by using
5715
5716 png_set_option(png_ptr, PNG_MAXIMUM_INFLATE_WINDOW,
5717 PNG_OPTION_ON);
5718
5719and provide a tool (contrib/tools/pngfix) for rewriting a PNG file while
5720optimizing the CMF bytes in its IDAT chunk correctly.
5721
5722Libpng-1.6.0 and libpng-1.6.1 wrote uncompressed iTXt chunks with the wrong
5723length, which resulted in PNG files that cannot be read beyond the bad iTXt
5724chunk. This error was fixed in libpng-1.6.3, and a tool (called
5725contrib/tools/png-fix-itxt) has been added to the libpng distribution.
5726
5727Starting with libpng-1.6.17, the PNG_SAFE_LIMITS macro was eliminated
5728and safe limits are used by default (users who need larger limits
5729can still override them at compile time or run time, as described above).
5730
5731The new limits are
5732 default spec limit
5733 png_user_width_max 1,000,000 2,147,483,647
5734 png_user_height_max 1,000,000 2,147,483,647
5735 png_user_chunk_cache_max 128 unlimited
5736 png_user_chunk_malloc_max 8,000,000 unlimited
5737
5738Starting with libpng-1.6.18, a PNG_RELEASE_BUILD macro was added, which allows
5739library builders to control compilation for an installed system (a release build).
5740It can be set for testing debug or beta builds to ensure that they will compile
5741when the build type is switched to RC or STABLE. In essence this overrides the
5742PNG_LIBPNG_BUILD_BASE_TYPE definition which is not directly user controllable.
5743
5744Starting with libpng-1.6.19, attempting to set an over-length PLTE chunk
5745is an error. Previously this requirement of the PNG specification was not
5746enforced, and the palette was always limited to 256 entries. An over-length
5747PLTE chunk found in an input PNG is silently truncated.
5748
5749Starting with libpng-1.6.31, the eXIf chunk is supported. Libpng does not
5750attempt to decode the Exif profile; it simply returns a byte array
5751containing the profile to the calling application which must do its own
5752decoding.
5753
5754.SH XIII. Detecting libpng
5755
5756The png_get_io_ptr() function has been present since libpng-0.88, has never
5757changed, and is unaffected by conditional compilation macros. It is the
5758best choice for use in configure scripts for detecting the presence of any
5759libpng version since 0.88. In an autoconf "configure.in" you could use
5760
5761 AC_CHECK_LIB(png, png_get_io_ptr, ...
5762
5763.SH XV. Source code repository
5764
5765Since about February 2009, version 1.2.34, libpng has been under "git" source
5766control. The git repository was built from old libpng-x.y.z.tar.gz files
5767going back to version 0.70. You can access the git repository (read only)
5768at
5769
5770 https://github.com/glennrp/libpng or
5771 https://git.code.sf.net/p/libpng/code.git
5772
5773or you can browse it with a web browser at
5774
5775 https://github.com/glennrp/libpng or
5776 https://sourceforge.net/p/libpng/code/ci/libpng16/tree/
5777
5778Patches can be sent to png-mng-implement at lists.sourceforge.net or
5779uploaded to the libpng bug tracker at
5780
5781 https://libpng.sourceforge.io/
5782
5783or as a "pull request" to
5784
5785 https://github.com/glennrp/libpng/pulls
5786
5787We also accept patches built from the tar or zip distributions, and
5788simple verbal descriptions of bug fixes, reported either to the
5789SourceForge bug tracker, to the png-mng-implement at lists.sf.net
5790mailing list, as github issues.
5791
5792.SH XV. Coding style
5793
5794Our coding style is similar to the "Allman" style
5795(See https://en.wikipedia.org/wiki/Indent_style#Allman_style), with curly
5796braces on separate lines:
5797
5798 if (condition)
5799 {
5800 action;
5801 }
5802
5803 else if (another condition)
5804 {
5805 another action;
5806 }
5807
5808The braces can be omitted from simple one-line actions:
5809
5810 if (condition)
5811 return 0;
5812
5813We use 3-space indentation, except for continued statements which
5814are usually indented the same as the first line of the statement
5815plus four more spaces.
5816
5817For macro definitions we use 2-space indentation, always leaving the "#"
5818in the first column.
5819
5820 #ifndef PNG_NO_FEATURE
5821 # ifndef PNG_FEATURE_SUPPORTED
5822 # define PNG_FEATURE_SUPPORTED
5823 # endif
5824 #endif
5825
5826Comments appear with the leading "/*" at the same indentation as
5827the statement that follows the comment:
5828
5829 /* Single-line comment */
5830 statement;
5831
5832 /* This is a multiple-line
5833 * comment.
5834 */
5835 statement;
5836
5837Very short comments can be placed after the end of the statement
5838to which they pertain:
5839
5840 statement; /* comment */
5841
5842We don't use C++ style ("//") comments. We have, however,
5843used them in the past in some now-abandoned MMX assembler
5844code.
5845
5846Functions and their curly braces are not indented, and
5847exported functions are marked with PNGAPI:
5848
5849 /* This is a public function that is visible to
5850 * application programmers. It does thus-and-so.
5851 */
5852 void PNGAPI
5853 png_exported_function(png_ptr, png_info, foo)
5854 {
5855 body;
5856 }
5857
5858The return type and decorations are placed on a separate line
5859ahead of the function name, as illustrated above.
5860
5861The prototypes for all exported functions appear in png.h,
5862above the comment that says
5863
5864 /* Maintainer: Put new public prototypes here ... */
5865
5866We mark all non-exported functions with "/* PRIVATE */"":
5867
5868 void /* PRIVATE */
5869 png_non_exported_function(png_ptr, png_info, foo)
5870 {
5871 body;
5872 }
5873
5874The prototypes for non-exported functions (except for those in
5875pngtest) appear in pngpriv.h above the comment that says
5876
5877 /* Maintainer: Put new private prototypes here ^ */
5878
5879To avoid polluting the global namespace, the names of all exported
5880functions and variables begin with "png_", and all publicly visible C
5881preprocessor macros begin with "PNG". We request that applications that
5882use libpng *not* begin any of their own symbols with either of these strings.
5883
5884We put a space after the "sizeof" operator and we omit the
5885optional parentheses around its argument when the argument
5886is an expression, not a type name, and we always enclose the
5887sizeof operator, with its argument, in parentheses:
5888
5889 (sizeof (png_uint_32))
5890 (sizeof array)
5891
5892Prior to libpng-1.6.0 we used a "png_sizeof()" macro, formatted as
5893though it were a function.
5894
5895Control keywords if, for, while, and switch are always followed by a space
5896to distinguish them from function calls, which have no trailing space.
5897
5898We put a space after each comma and after each semicolon
5899in "for" statements, and we put spaces before and after each
5900C binary operator and after "for" or "while", and before
5901"?". We don't put a space between a typecast and the expression
5902being cast, nor do we put one between a function name and the
5903left parenthesis that follows it:
5904
5905 for (i = 2; i > 0; \-\-i)
5906 y[i] = a(x) + (int)b;
5907
5908We prefer #ifdef and #ifndef to #if defined() and #if !defined()
5909when there is only one macro being tested. We always use parentheses
5910with "defined".
5911
5912We express integer constants that are used as bit masks in hex format,
5913with an even number of lower-case hex digits, and to make them unsigned
5914(e.g., 0x00U, 0xffU, 0x0100U) and long if they are greater than 0x7fff
5915(e.g., 0xffffUL).
5916
5917We prefer to use underscores rather than camelCase in names, except
5918for a few type names that we inherit from zlib.h.
5919
5920We prefer "if (something != 0)" and "if (something == 0)" over
5921"if (something)" and if "(!something)", respectively, and for pointers
5922we prefer "if (some_pointer != NULL)" or "if (some_pointer == NULL)".
5923
5924We do not use the TAB character for indentation in the C sources.
5925
5926Lines do not exceed 80 characters.
5927
5928Other rules can be inferred by inspecting the libpng source.
5929
5930.SH NOTE
5931
5932Note about libpng version numbers:
5933
5934Due to various miscommunications, unforeseen code incompatibilities
5935and occasional factors outside the authors' control, version numbering
5936on the library has not always been consistent and straightforward.
5937The following table summarizes matters since version 0.89c, which was
5938the first widely used release:
5939
5940 source png.h png.h shared-lib
5941 version string int version
5942 ------- ------ ----- ----------
5943 0.89c "1.0 beta 3" 0.89 89 1.0.89
5944 0.90 "1.0 beta 4" 0.90 90 0.90 [should have been 2.0.90]
5945 0.95 "1.0 beta 5" 0.95 95 0.95 [should have been 2.0.95]
5946 0.96 "1.0 beta 6" 0.96 96 0.96 [should have been 2.0.96]
5947 0.97b "1.00.97 beta 7" 1.00.97 97 1.0.1 [should have been 2.0.97]
5948 0.97c 0.97 97 2.0.97
5949 0.98 0.98 98 2.0.98
5950 0.99 0.99 98 2.0.99
5951 0.99a-m 0.99 99 2.0.99
5952 1.00 1.00 100 2.1.0 [100 should be 10000]
5953 1.0.0 (from here on, the 100 2.1.0 [100 should be 10000]
5954 1.0.1 png.h string is 10001 2.1.0
5955 1.0.1a-e identical to the 10002 from here on, the shared library
5956 1.0.2 source version) 10002 is 2.V where V is the source code
5957 1.0.2a-b 10003 version, except as noted.
5958 1.0.3 10003
5959 1.0.3a-d 10004
5960 1.0.4 10004
5961 1.0.4a-f 10005
5962 1.0.5 (+ 2 patches) 10005
5963 1.0.5a-d 10006
5964 1.0.5e-r 10100 (not source compatible)
5965 1.0.5s-v 10006 (not binary compatible)
5966 1.0.6 (+ 3 patches) 10006 (still binary incompatible)
5967 1.0.6d-f 10007 (still binary incompatible)
5968 1.0.6g 10007
5969 1.0.6h 10007 10.6h (testing xy.z so-numbering)
5970 1.0.6i 10007 10.6i
5971 1.0.6j 10007 2.1.0.6j (incompatible with 1.0.0)
5972 1.0.7beta11-14 DLLNUM 10007 2.1.0.7beta11-14 (binary compatible)
5973 1.0.7beta15-18 1 10007 2.1.0.7beta15-18 (binary compatible)
5974 1.0.7rc1-2 1 10007 2.1.0.7rc1-2 (binary compatible)
5975 1.0.7 1 10007 (still compatible)
5976 ...
5977 1.0.69 10 10069 10.so.0.69[.0]
5978 ...
5979 1.2.59 13 10259 12.so.0.59[.0]
5980 ...
5981 1.4.20 14 10420 14.so.0.20[.0]
5982 ...
5983 1.5.30 15 10530 15.so.15.30[.0]
5984 ...
5985 1.6.35 16 10635 16.so.16.35[.0]
5986
5987Henceforth the source version will match the shared-library minor and
5988patch numbers; the shared-library major version number will be used for
5989changes in backward compatibility, as it is intended.
5990The PNG_PNGLIB_VER macro, which is not used within libpng but is
5991available for applications, is an unsigned integer of the form XYYZZ
5992corresponding to the source version X.Y.Z (leading zeros in Y and Z).
5993Beta versions were given the previous public release number plus a
5994letter, until version 1.0.6j; from then on they were given the upcoming
5995public release number plus "betaNN" or "rcNN".
5996
5997.SH "SEE ALSO"
5998.IR libpngpf(3) ", " png(5)
5999.LP
6000.IR libpng :
6001.IP
6002https://libpng.sourceforge.io/ (follow the [DOWNLOAD] link)
6003http://www.libpng.org/pub/png
6004
6005.LP
6006.IR zlib :
6007.IP
6008(generally) at the same location as
6009.I libpng
6010or at
6011.br
6012https://zlib.net/
6013
6014.LP
6015.IR PNG specification: RFC 2083
6016.IP
6017(generally) at the same location as
6018.I libpng
6019or at
6020.br
6021https://www.ietf.org/rfc/rfc2083.txt
6022.br
6023or (as a W3C Recommendation) at
6024.br
6025https://www.w3.org/TR/REC-png.html
6026
6027.LP
6028In the case of any inconsistency between the PNG specification
6029and this library, the specification takes precedence.
6030
6031.SH AUTHORS
6032This man page:
6033Initially created by Glenn Randers-Pehrson.
6034Maintained by Cosmin Truta.
6035
6036The contributing authors would like to thank all those who helped
6037with testing, bug fixes, and patience. This wouldn't have been
6038possible without all of you.
6039
6040Thanks to Frank J. T. Wojcik for helping with the documentation.
6041
6042Libpng:
6043Initially created in 1995 by Guy Eric Schalnat, then of Group 42, Inc.
6044Maintained by Cosmin Truta.
6045
6046Supported by the PNG development group
6047.br
6048png-mng-implement at lists.sourceforge.net (subscription required; visit
6049https://lists.sourceforge.net/lists/listinfo/png-mng-implement
6050to subscribe).
6051
6052.\" end of man page
注意: 瀏覽 TracBrowser 來幫助您使用儲存庫瀏覽器

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette