Rev 6881 | Go to most recent revision | Details | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
6733 | IgorA | 1 | |
2 | |||
3 | |||
4 | ; Copyright (c) 1998-2002,2004,2006-2013 Glenn Randers-Pehrson |
||
5 | ; (Version 0.96 Copyright (c) 1996, 1997 Andreas Dilger) |
||
6 | ; (Version 0.88 Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.) |
||
7 | |||
8 | |||
9 | ; For conditions of distribution and use, see the disclaimer |
||
10 | ; and license in png.inc |
||
11 | |||
12 | |||
13 | ; that the application can find out the characteristics of the image. |
||
14 | ; If you are reading the file, this structure will tell you what is |
||
15 | ; in the PNG file. If you are writing the file, fill in the information |
||
16 | ; you want to put into the PNG file, using png_set_*() functions, then |
||
17 | ; call png_write_info(). |
||
18 | |||
19 | |||
20 | ; consult that document for information about the meaning of each field. |
||
21 | |||
22 | |||
23 | ; the values in the png_info_struct, which meant that the contents and |
||
24 | ; order of the values had to remain fixed. With libpng 0.95 and later, |
||
25 | ; however, there are now functions that abstract the contents of |
||
26 | ; png_info_struct from the application, so this makes it easier to use |
||
27 | ; libpng with dynamic libraries, and even makes it possible to use |
||
28 | ; libraries that don't have all of the libpng ancillary chunk-handing |
||
29 | ; functionality. In libpng-1.5.0 this was moved into a separate private |
||
30 | ; file that is not visible to applications. |
||
31 | |||
32 | |||
33 | ; cleaned up before the structure is discarded: palette, trans, text, |
||
34 | ; pcal_purpose, pcal_units, pcal_params, hist, iccp_name, iccp_profile, |
||
35 | ; splt_palettes, scal_unit, row_pointers, and unknowns. By default, these |
||
36 | ; are automatically freed when the info structure is deallocated, if they were |
||
37 | ; allocated internally by libpng. This behavior can be changed by means |
||
38 | ; of the png_data_freer() function. |
||
39 | |||
40 | |||
41 | ; change these members go through the corresponding png_set_* |
||
42 | ; functions. A function to clear these members is available: see |
||
43 | ; png_free_data(). The png_set_* functions do not depend on being |
||
44 | ; able to point info structure members to any of the storage they are |
||
45 | ; passed (they make their own copies), EXCEPT that the png_set_text |
||
46 | ; functions use the same storage passed to them in the text_ptr or |
||
47 | ; itxt_ptr structure argument, and the png_set_rows and png_set_unknowns |
||
48 | ; functions do not make their own copies. |
||
49 | |||
50 | |||
51 | |||
52 | ; The following are necessary for every PNG file |
||
53 | width dd ? ;uint_32 ;width of image in pixels (from IHDR) |
||
54 | height dd ? ;uint_32 ;height of image in pixels (from IHDR) |
||
55 | valid dd ? ;uint_32 ;valid chunk data (see PNG_INFO_ below) |
||
56 | rowbytes dd ? ;png_size_t ;bytes needed to hold an untransformed row |
||
57 | palette dd ? ;png_colorp ; array of color values (valid & PNG_INFO_PLTE) |
||
58 | num_palette dw ? ;uint_16 ;number of color entries in "palette" (PLTE) |
||
59 | num_trans dw ? ;uint_16 ;number of transparent palette color (tRNS) |
||
60 | bit_depth db ? ;byte ;1, 2, 4, 8, or 16 bits/channel (from IHDR) |
||
61 | color_type db ? ;byte ;see PNG_COLOR_TYPE_ below (from IHDR) |
||
62 | ; The following three should have been named *_method not *_type |
||
63 | compression_type db ? ;byte ;must be PNG_COMPRESSION_TYPE_BASE (IHDR) |
||
64 | filter_type db ? ;byte ;must be PNG_FILTER_TYPE_BASE (from IHDR) |
||
65 | interlace_type db ? ;byte ;One of PNG_INTERLACE_NONE, PNG_INTERLACE_ADAM7 |
||
66 | |||
67 | |||
68 | ; write, but the are never actually used by the write code. |
||
69 | |||
70 | |||
71 | pixel_depth db ? ;byte ;number of bits per pixel |
||
72 | spare_byte db ? ;byte ;to align the data, and for future use |
||
73 | |||
74 | |||
75 | ; This is never set during write |
||
76 | signature db 8 ;byte[8] ;magic bytes read by libpng from start of file |
||
77 | end if |
||
78 | |||
79 | |||
80 | ; valid field to see if the information in these are valid. If you |
||
81 | ; are writing, set the valid field to those chunks you want written, |
||
82 | ; and initialize the appropriate fields below. |
||
83 | |||
84 | |||
85 | |||
86 | ; png_colorspace only contains 'flags' if neither GAMMA or COLORSPACE are |
||
87 | ; defined. When COLORSPACE is switched on all the colorspace-defining |
||
88 | ; chunks should be enabled, when GAMMA is switched on all the gamma-defining |
||
89 | ; chunks should be enabled. If this is not done it becomes possible to read |
||
90 | ; inconsistent PNG files and assign a probably incorrect interpretation to |
||
91 | ; the information. (In other words, by carefully choosing which chunks to |
||
92 | ; recognize the system configuration can select an interpretation for PNG |
||
93 | ; files containing ambiguous data and this will result in inconsistent |
||
94 | ; behavior between different libpng builds!) |
||
95 | |||
96 | |||
97 | end if |
||
98 | |||
99 | |||
100 | ; iCCP chunk data. |
||
101 | iccp_name dd ? ;charp ;profile name |
||
102 | iccp_profile dd ? ;bytep ;International Color Consortium profile data |
||
103 | iccp_proflen dd ? ;uint_32 ;ICC profile data length |
||
104 | end if |
||
105 | |||
106 | |||
107 | ; The tEXt, and zTXt chunks contain human-readable textual data in |
||
108 | ; uncompressed, compressed, and optionally compressed forms, respectively. |
||
109 | ; The data in "text" is an array of pointers to uncompressed, |
||
110 | ; null-terminated C strings. Each chunk has a keyword that describes the |
||
111 | ; textual data contained in that chunk. Keywords are not required to be |
||
112 | ; unique, and the text string may be empty. Any number of text chunks may |
||
113 | ; be in an image. |
||
114 | |||
115 | |||
116 | max_text dd ? ;int ;current size of text array |
||
117 | text dd ? ;png_textp ;array of comments read or comments to write |
||
118 | end if ;TEXT |
||
119 | |||
120 | |||
121 | ; The tIME chunk holds the last time the displayed image data was |
||
122 | ; modified. See the png_time struct for the contents of this struct. |
||
123 | |||
124 | |||
125 | end if |
||
126 | |||
127 | |||
128 | ; The sBIT chunk specifies the number of significant high-order bits |
||
129 | ; in the pixel data. Values are in the range [1, bit_depth], and are |
||
130 | ; only specified for the channels in the pixel data. The contents of |
||
131 | ; the low-order bits is not specified. Data is valid if |
||
132 | ; (valid & PNG_INFO_sBIT) is non-zero. |
||
133 | |||
134 | |||
135 | end if |
||
136 | |||
137 | |||
138 | ;defined(PNG_READ_BACKGROUND_SUPPORTED) |
||
139 | ; The tRNS chunk supplies transparency data for paletted images and |
||
140 | ; other image types that don't need a full alpha channel. There are |
||
141 | ; "num_trans" transparency values for a paletted image, stored in the |
||
142 | ; same order as the palette colors, starting from index 0. Values |
||
143 | ; for the data are in the range [0, 255], ranging from fully transparent |
||
144 | ; to fully opaque, respectively. For non-paletted images, there is a |
||
145 | ; single color specified that should be treated as fully transparent. |
||
146 | ; Data is valid if (valid & PNG_INFO_tRNS) is non-zero. |
||
147 | |||
148 | |||
149 | trans_color png_color_16 ;transparent color for non-palette image |
||
150 | ;end if |
||
151 | |||
152 | |||
153 | ; The bKGD chunk gives the suggested image background color if the |
||
154 | ; display program does not have its own background color and the image |
||
155 | ; is needs to composited onto a background before display. The colors |
||
156 | ; in "background" are normally in the same color space/depth as the |
||
157 | ; pixel data. Data is valid if (valid & PNG_INFO_bKGD) is non-zero. |
||
158 | |||
159 | |||
160 | end if |
||
161 | |||
162 | |||
163 | ; The oFFs chunk gives the offset in "offset_unit_type" units rightwards |
||
164 | ; and downwards from the top-left corner of the display, page, or other |
||
165 | ; application-specific co-ordinate space. See the PNG_OFFSET_ defines |
||
166 | ; below for the unit types. Valid if (valid & PNG_INFO_oFFs) non-zero. |
||
167 | |||
168 | |||
169 | y_offset dd ? ;int_32 ;y offset on page |
||
170 | offset_unit_type db ? ;byte ;offset units type |
||
171 | end if |
||
172 | |||
173 | |||
174 | ; The pHYs chunk gives the physical pixel density of the image for |
||
175 | ; display or printing in "phys_unit_type" units (see PNG_RESOLUTION_ |
||
176 | ; defines below). Data is valid if (valid & PNG_INFO_pHYs) is non-zero. |
||
177 | |||
178 | |||
179 | y_pixels_per_unit dd ? ;uint_32 ;vertical pixel density |
||
180 | phys_unit_type db ? ;byte ;resolution type (see PNG_RESOLUTION_ below) |
||
181 | end if |
||
182 | |||
183 | |||
184 | ; The hIST chunk contains the relative frequency or importance of the |
||
185 | ; various palette entries, so that a viewer can intelligently select a |
||
186 | ; reduced-color palette, if required. Data is an array of "num_palette" |
||
187 | ; values in the range [0,65535]. Data valid if (valid & PNG_INFO_hIST) |
||
188 | ; is non-zero. |
||
189 | |||
190 | |||
191 | end if |
||
192 | |||
193 | |||
194 | ; The pCAL chunk describes a transformation between the stored pixel |
||
195 | ; values and original physical data values used to create the image. |
||
196 | ; The integer range [0, 2^bit_depth - 1] maps to the floating-point |
||
197 | ; range given by [pcal_X0, pcal_X1], and are further transformed by a |
||
198 | ; (possibly non-linear) transformation function given by "pcal_type" |
||
199 | ; and "pcal_params" into "pcal_units". Please see the PNG_EQUATION_ |
||
200 | ; defines below, and the PNG-Group's PNG extensions document for a |
||
201 | ; complete description of the transformations and how they should be |
||
202 | ; implemented, and for a description of the ASCII parameter strings. |
||
203 | ; Data values are valid if (valid & PNG_INFO_pCAL) non-zero. |
||
204 | |||
205 | |||
206 | pcal_X0 dd ? ;int_32 ;minimum value |
||
207 | pcal_X1 dd ? ;int_32 ;maximum value |
||
208 | pcal_units dd ? ;charp ;Latin-1 string giving physical units |
||
209 | pcal_params dd ? ;charpp ;ASCII strings containing parameter values |
||
210 | pcal_type db ? ;byte ;equation type (see PNG_EQUATION_ below) |
||
211 | pcal_nparams db ? ;byte ;number of parameters given in pcal_params |
||
212 | end if |
||
213 | |||
214 | |||
215 | free_me dd ? ;uint_32 ;flags items libpng is responsible for freeing |
||
216 | |||
217 | |||
218 | ; Storage for unknown chunks that the library doesn't recognize. |
||
219 | unknown_chunks dd ? ;png_unknown_chunkp |
||
220 | |||
221 | |||
222 | ; png_struct::user_chunk_cache_max, else overflow can occur. |
||
223 | |||
224 | |||
225 | end if |
||
226 | |||
227 | |||
228 | ; Data on sPLT chunks (there may be more than one). |
||
229 | splt_palettes dd ? ;png_sPLT_tp |
||
230 | splt_palettes_num dd ? ;int ;Match type returned by png_get API |
||
231 | end if |
||
232 | |||
233 | |||
234 | ; The sCAL chunk describes the actual physical dimensions of the |
||
235 | ; subject matter of the graphic. The chunk contains a unit specification |
||
236 | ; a byte value, and two ASCII strings representing floating-point |
||
237 | ; values. The values are width and height corresponsing to one pixel |
||
238 | ; in the image. Data values are valid if (valid & PNG_INFO_sCAL) is |
||
239 | ; non-zero. |
||
240 | |||
241 | |||
242 | scal_s_width dd ? ;charp ;string containing height |
||
243 | scal_s_height dd ? ;charp ;string containing width |
||
244 | end if |
||
245 | |||
246 | |||
247 | ; Memory has been allocated if (valid & PNG_ALLOCATED_INFO_ROWS) |
||
248 | ; non-zero |
||
249 | ; Data valid if (valid & PNG_INFO_IDAT) non-zero |
||
250 | row_pointers dd ? ;bytepp ;the image bits |
||
251 | end if |
||
252 | |||
253 | |||
254 |