Rev 6779 | Rev 6881 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
6733 | IgorA | 1 | |
2 | |||
3 | |||
4 | |||
5 | |||
6 | ; (Version 0.96 Copyright (c) 1996, 1997 Andreas Dilger) |
||
7 | ; (Version 0.88 Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.) |
||
8 | |||
9 | |||
10 | |||
11 | |||
12 | ; libpng versions 0.71, May 1995, through 0.88, January 1996: Guy Schalnat |
||
13 | ; libpng versions 0.89, June 1996, through 0.96, May 1997: Andreas Dilger |
||
14 | ; libpng versions 0.97, January 1998, through 1.6.25, September 1, 2016: |
||
15 | ; Glenn Randers-Pehrson. |
||
16 | ; See also "Contributing Authors", below. |
||
17 | |||
18 | |||
19 | |||
20 | |||
21 | |||
22 | |||
23 | ; this sentence. |
||
24 | |||
25 | |||
26 | |||
27 | |||
28 | ; files that are distributed with libpng have other copyright owners and |
||
29 | ; are released under other open source licenses. |
||
30 | |||
31 | |||
32 | ; Copyright (c) 2000-2002, 2004, 2006-2016 Glenn Randers-Pehrson, are |
||
33 | ; derived from libpng-1.0.6, and are distributed according to the same |
||
34 | ; disclaimer and license as libpng-1.0.6 with the following individuals |
||
35 | ; added to the list of Contributing Authors: |
||
36 | |||
37 | |||
38 | ; Eric S. Raymond |
||
39 | ; Mans Rullgard |
||
40 | ; Cosmin Truta |
||
41 | ; Gilles Vollant |
||
42 | ; James Yu |
||
43 | ; Mandar Sahastrabuddhe |
||
44 | |||
45 | |||
46 | |||
47 | |||
48 | ; library or against infringement. There is no warranty that our |
||
49 | ; efforts or the library will fulfill any of your particular purposes |
||
50 | ; or needs. This library is provided with all faults, and the entire |
||
51 | ; risk of satisfactory quality, performance, accuracy, and effort is with |
||
52 | ; the user. |
||
53 | |||
54 | |||
55 | ; are released under other open source licenses. |
||
56 | |||
57 | |||
58 | |||
59 | ; Copyright (c) 1998-2000 Glenn Randers-Pehrson, are derived from |
||
60 | ; libpng-0.96, and are distributed according to the same disclaimer and |
||
61 | ; license as libpng-0.96, with the following individuals added to the list |
||
62 | ; of Contributing Authors: |
||
63 | |||
64 | |||
65 | ; Glenn Randers-Pehrson |
||
66 | ; Willem van Schaik |
||
67 | |||
68 | |||
69 | ; but are also released under this license. |
||
70 | |||
71 | |||
72 | ; Copyright (c) 1996-1997 Andreas Dilger, are derived from libpng-0.88, |
||
73 | ; and are distributed according to the same disclaimer and license as |
||
74 | ; libpng-0.88, with the following individuals added to the list of |
||
75 | ; Contributing Authors: |
||
76 | |||
77 | |||
78 | ; Kevin Bracey |
||
79 | ; Sam Bushell |
||
80 | ; Magnus Holmgren |
||
81 | ; Greg Roelofs |
||
82 | ; Tom Tanner |
||
83 | |||
84 | |||
85 | ; but are released under this license. |
||
86 | |||
87 | |||
88 | ; Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc. |
||
89 | |||
90 | |||
91 | ; is defined as the following set of individuals: |
||
92 | |||
93 | |||
94 | ; Dave Martindale |
||
95 | ; Guy Eric Schalnat |
||
96 | ; Paul Schmidt |
||
97 | ; Tim Wegner |
||
98 | |||
99 | |||
100 | ; and Group 42, Inc. disclaim all warranties, expressed or implied, |
||
101 | ; including, without limitation, the warranties of merchantability and of |
||
102 | ; fitness for any purpose. The Contributing Authors and Group 42, Inc. |
||
103 | ; assume no liability for direct, indirect, incidental, special, exemplary, |
||
104 | ; or consequential damages, which may result from the use of the PNG |
||
105 | ; Reference Library, even if advised of the possibility of such damage. |
||
106 | |||
107 | |||
108 | ; source code, or portions hereof, for any purpose, without fee, subject |
||
109 | ; to the following restrictions: |
||
110 | |||
111 | |||
112 | |||
113 | |||
114 | ; be misrepresented as being the original source. |
||
115 | |||
116 | |||
117 | ; source or altered source distribution. |
||
118 | |||
119 | |||
120 | ; fee, and encourage the use of this source code as a component to |
||
121 | ; supporting the PNG file format in commercial products. If you use this |
||
122 | ; source code in a product, acknowledgment is not required but would be |
||
123 | ; appreciated. |
||
124 | |||
125 | |||
126 | |||
127 | |||
128 | |||
129 | |||
130 | ; as a trademark in any jurisdiction. However, because libpng has |
||
131 | ; been distributed and maintained world-wide, continually since 1995, |
||
132 | ; the Copyright owner claims "common-law trademark protection" in any |
||
133 | ; jurisdiction where common-law trademark is recognized. |
||
134 | |||
135 | |||
136 | |||
137 | |||
138 | ; a certification mark of the Open Source Initiative. OSI has not addressed |
||
139 | ; the additional disclaimers inserted at version 1.0.7. |
||
140 | |||
141 | |||
142 | |||
143 | |||
144 | ; Number (ECCN) for libpng is EAR99, which means not subject to export |
||
145 | ; controls or International Traffic in Arms Regulations (ITAR) because |
||
146 | ; it is open source, publicly available software, that does not contain |
||
147 | ; any encryption software. See the EAR, paragraphs 734.3(b)(3) and |
||
148 | ; 734.7(b). |
||
149 | |||
150 | |||
151 | |||
152 | |||
153 | ; boxes and the like: |
||
154 | |||
155 | |||
156 | |||
157 | |||
158 | ; files "pngbar.png" and "pngbar.jpg (88x31) and "pngnow.png" (98x31). |
||
159 | |||
160 | |||
161 | |||
162 | |||
163 | ; with testing, bug fixes, and patience. This wouldn't have been |
||
164 | ; possible without all of you. |
||
165 | |||
166 | |||
167 | |||
168 | |||
169 | ; Note about libpng version numbers: |
||
170 | ; |
||
171 | ; Due to various miscommunications, unforeseen code incompatibilities |
||
172 | ; and occasional factors outside the authors' control, version numbering |
||
173 | ; on the library has not always been consistent and straightforward. |
||
174 | ; The following table summarizes matters since version 0.89c, which was |
||
175 | ; the first widely used release: |
||
176 | ; |
||
177 | ; source png.h png.h shared-lib |
||
178 | ; version string int version |
||
179 | ; ------- ------ ----- ---------- |
||
180 | ; ... |
||
181 | ; 1.2.56 13 10256 12.so.0.56[.0] |
||
182 | ; ... |
||
183 | ; 1.5.27 15 10527 15.so.15.27[.0] |
||
184 | ; ... |
||
185 | ; 1.6.25 16 10625 16.so.16.25[.0] |
||
186 | |||
187 | |||
188 | ; and minor numbers; the shared-library major version number will be |
||
189 | ; used for changes in backward compatibility, as it is intended. The |
||
190 | ; PNG_LIBPNG_VER macro, which is not used within libpng but is available |
||
191 | ; for applications, is an unsigned integer of the form xyyzz corresponding |
||
192 | ; to the source version x.y.z (leading zeros in y and z). Beta versions |
||
193 | ; were given the previous public release number plus a letter, until |
||
194 | ; version 1.0.6j; from then on they were given the upcoming public |
||
195 | ; release number plus "betaNN" or "rcNN". |
||
196 | |||
197 | |||
198 | ; to the info_ptr or png_ptr members through png.h, and the compiled |
||
199 | ; application is loaded with a different version of the library. |
||
200 | |||
201 | |||
202 | ; in binary compatibility (e.g., when a new feature is added). |
||
203 | |||
204 | |||
205 | ; is available as a W3C Recommendation and as an ISO Specification, |
||
206 | ; |
||
207 | |||
208 | |||
209 | |||
210 | |||
211 | ; ========================= |
||
212 | |||
213 | |||
214 | |||
215 | |||
216 | ; an official declaration. |
||
217 | |||
218 | |||
219 | ; upward through 1.6.25 are Y2K compliant. It is my belief that |
||
220 | ; earlier versions were also Y2K compliant. |
||
221 | |||
222 | |||
223 | ; that will hold years up to 65535. The other, which is deprecated, |
||
224 | ; holds the date in text format, and will hold years up to 9999. |
||
225 | |||
226 | |||
227 | ; "uint_16 year" in png_time_struct. |
||
228 | |||
229 | |||
230 | ; "char time_buffer[29]" in png_struct. This is no longer used |
||
231 | ; in libpng-1.6.x and will be removed from libpng-1.7.0. |
||
232 | |||
233 | |||
234 | ; png.asm: png_convert_to_rfc_1123_buffer() in png.asm |
||
235 | ; (formerly png_convert_to_rfc_1123() prior to libpng-1.5.x and |
||
236 | ; png_convert_to_rfc_1152() in error prior to libpng-0.98) |
||
237 | ; png_convert_from_struct_tm() in pngwrite.asm, called in pngwrite.asm |
||
238 | ; png_convert_from_time_t() in pngwrite.asm |
||
239 | ; png_get_tIME() in pngget.asm |
||
240 | ; png_handle_tIME() in pngrutil.asm, called in pngread.asm |
||
241 | ; png_set_tIME() in pngset.asm |
||
242 | ; png_write_tIME() in pngwutil.asm, called in pngwrite.asm |
||
243 | |||
244 | |||
245 | ; png_convert_from_time_t() function calls gmtime() to convert from system |
||
246 | ; clock time, which returns (year - 1900), which we properly convert to |
||
247 | ; the full 4-digit year. There is a possibility that libpng applications |
||
248 | ; are not passing 4-digit years into the png_convert_to_rfc_1123_buffer() |
||
249 | ; function, or that they are incorrectly passing only a 2-digit year |
||
250 | ; instead of "year - 1900" into the png_convert_from_struct_tm() function, |
||
251 | ; but this is not under our control. The libpng documentation has always |
||
252 | ; stated that it works with 4-digit years, and the APIs have been |
||
253 | ; documented as such. |
||
254 | |||
255 | |||
256 | ; integer to hold the year, and can hold years as large as 65535. |
||
257 | |||
258 | |||
259 | ; no date-related code. |
||
260 | |||
261 | |||
262 | ; libpng maintainer |
||
263 | ; PNG Development Group |
||
264 | |||
265 | |||
266 | |||
267 | ; describes how to use libpng, and the file example.c summarizes it |
||
268 | ; with some code on which to build. This file is useful for looking |
||
269 | ; at the actual function definitions and structure components. If that |
||
270 | ; file has been stripped from your copy of libpng, you can find it at |
||
271 | ; |
||
272 | |||
273 | |||
274 | ; skip to the end of this file and read the section entitled 'simplified API'. |
||
275 | |||
276 | |||
277 | |||
278 | PNG_LIBPNG_VER_STRING db '1.6.25',0 |
||
279 | PNG_HEADER_VERSION_STRING db ' libpng version 1.6.25 - September 1, 2016',13,10,0 |
||
280 | |||
281 | |||
282 | PNG_LIBPNG_VER_DLLNUM equ 16 |
||
283 | |||
284 | |||
285 | PNG_LIBPNG_VER_MAJOR equ 1 |
||
286 | PNG_LIBPNG_VER_MINOR equ 6 |
||
287 | PNG_LIBPNG_VER_RELEASE equ 25 |
||
288 | |||
289 | |||
290 | ; PNG_LIBPNG_VER_STRING, omitting any leading zero: |
||
291 | |||
292 | |||
293 | |||
294 | |||
295 | |||
296 | PNG_LIBPNG_BUILD_ALPHA equ 1 |
||
297 | PNG_LIBPNG_BUILD_BETA equ 2 |
||
298 | PNG_LIBPNG_BUILD_RC equ 3 |
||
299 | PNG_LIBPNG_BUILD_STABLE equ 4 |
||
300 | PNG_LIBPNG_BUILD_RELEASE_STATUS_MASK equ 7 |
||
301 | |||
302 | |||
303 | PNG_LIBPNG_BUILD_PATCH equ 8 ;Can be OR'ed with PNG_LIBPNG_BUILD_STABLE only |
||
304 | PNG_LIBPNG_BUILD_PRIVATE equ 16 ;Cannot be OR'ed with PNG_LIBPNG_BUILD_SPECIAL |
||
305 | PNG_LIBPNG_BUILD_SPECIAL equ 32 ;Cannot be OR'ed with PNG_LIBPNG_BUILD_PRIVATE |
||
306 | |||
307 | |||
308 | |||
309 | |||
310 | ; We must not include leading zeros. |
||
311 | ; Versions 0.7 through 1.0.0 were in the range 0 to 100 here (only |
||
312 | ; version 1.0.0 was mis-numbered 100 instead of 10000). From |
||
313 | ; version 1.0.1 it's xxyyzz, where x=major, y=minor, z=release |
||
314 | |||
315 | |||
316 | |||
317 | |||
318 | ; the library has been built. |
||
319 | |||
320 | |||
321 | |||
322 | |||
323 | |||
324 | ; VS_FF_PRIVATEBUILD File *was not* built using standard release |
||
325 | ; procedures. If this value is given, the StringFileInfo block must |
||
326 | ; contain a PrivateBuild string. |
||
327 | |||
328 | |||
329 | ; standard release procedures but is a variation of the standard |
||
330 | ; file of the same version number. If this value is given, the |
||
331 | ; StringFileInfo block must contain a SpecialBuild string. |
||
332 | |||
333 | |||
334 | ;# define PNG_LIBPNG_BUILD_TYPE \ |
||
335 | ; (PNG_LIBPNG_BUILD_BASE_TYPE | PNG_LIBPNG_BUILD_PRIVATE) |
||
336 | ;#else |
||
337 | ;# ifdef PNG_LIBPNG_SPECIALBUILD |
||
338 | ;# define PNG_LIBPNG_BUILD_TYPE \ |
||
339 | ; (PNG_LIBPNG_BUILD_BASE_TYPE | PNG_LIBPNG_BUILD_SPECIAL) |
||
340 | ;# else |
||
341 | ;# define PNG_LIBPNG_BUILD_TYPE (PNG_LIBPNG_BUILD_BASE_TYPE) |
||
342 | ;# endif |
||
343 | ;end if |
||
344 | |||
345 | |||
346 | |||
347 | |||
348 | ; the version above. |
||
349 | |||
350 | |||
351 | |||
352 | |||
353 | |||
354 | |||
355 | ; 2. Any configuration options that can be specified by for the application |
||
356 | ; code when it is built. (Build time configuration is in pnglibconf.h) |
||
357 | ; 3. Type definitions (base types are defined in pngconf.h), structure |
||
358 | ; definitions. |
||
359 | ; 4. Exported library functions. |
||
360 | ; 5. Simplified API. |
||
361 | ; 6. Implementation options. |
||
362 | |||
363 | |||
364 | ; allow configuration of the library. |
||
365 | |||
366 | |||
367 | |||
368 | |||
369 | |||
370 | ; See pnglibconf.h for build time configuration |
||
371 | |||
372 | |||
373 | ; implementations of certain arithmetic APIs. The default is set |
||
374 | ; at build time and recorded in pnglibconf.h, but it is safe to |
||
375 | ; override these (and only these) settings. Note that this won't |
||
376 | ; change what the library does, only application code, and the |
||
377 | ; settings can (and probably should) be made on a per-file basis |
||
378 | ; by setting the #defines before including png.h |
||
379 | |||
380 | |||
381 | ; functions? |
||
382 | ; PNG_USE_READ_MACROS: use the macros (see below) Note that |
||
383 | ; the macros evaluate their argument multiple times. |
||
384 | ; PNG_NO_USE_READ_MACROS: call the relevant library function. |
||
385 | |||
386 | |||
387 | ; does not use division? |
||
388 | ; PNG_READ_COMPOSITE_NODIV_SUPPORTED: use the 'no division' |
||
389 | ; algorithm. |
||
390 | ; PNG_NO_READ_COMPOSITE_NODIV: use the 'division' algorithm. |
||
391 | |||
392 | |||
393 | ; false? |
||
394 | ; PNG_ALLOW_BENIGN_ERRORS: map calls to the benign error |
||
395 | ; APIs to png_warning. |
||
396 | ; Otherwise the calls are mapped to png_error. |
||
397 | |||
398 | |||
399 | |||
400 | ; constants. |
||
401 | ; See pngconf.h for base types that vary by machine/system |
||
402 | |||
403 | |||
404 | |||
405 | ; do not agree upon the version number. |
||
406 | |||
407 | |||
408 | |||
409 | |||
410 | |||
411 | |||
412 | ; PNG file. One of these is always required, although the simplified API |
||
413 | ; (below) hides the creation and destruction of it. |
||
414 | |||
415 | |||
416 | ; or more of these must exist while reading or creating a PNG file. The |
||
417 | ; information is not used by libpng during read but is used to control what |
||
418 | ; gets written when a PNG file is created. "png_get_" function calls read |
||
419 | ; information during read and "png_set_" functions calls write information |
||
420 | ; when creating a PNG. |
||
421 | ; been moved into a separate header file that is not accessible to |
||
422 | ; applications. Read libpng-manual.txt or libpng.3 for more info. |
||
423 | |||
424 | |||
425 | ; names ending 'rp' are identical pointer types except that the pointer is |
||
426 | ; marked 'restrict', which means that it is the only pointer to the object |
||
427 | ; passed to the function. Applications should not use the 'restrict' types; |
||
428 | ; it is always valid to pass 'p' to a pointer with a function argument of the |
||
429 | ; corresponding 'rp' type. Different compilers have different rules with |
||
430 | ; regard to type matching in the presence of 'restrict'. For backward |
||
431 | ; compatibility libpng callbacks never have 'restrict' in their parameters and, |
||
432 | ; consequentially, writing portable application code is extremely difficult if |
||
433 | ; an attempt is made to use 'restrict'. |
||
434 | |||
435 | |||
436 | ; exact size) is not important, although the size of the fields need to |
||
437 | ; be byte or uint_16 (as defined below). |
||
438 | |||
439 | |||
440 | red db ? ;byte |
||
441 | green db ? ;byte |
||
442 | blue db ? ;byte |
||
443 | ends |
||
444 | |||
445 | |||
446 | index db ? ;byte ;used for palette files |
||
447 | red dw ? ;uint_16 ;for use in red green blue files |
||
448 | green dw ? ;uint_16 |
||
449 | blue dw ? ;uint_16 |
||
450 | gray dw ? ;uint_16 ;for use in grayscale files |
||
451 | ends |
||
452 | |||
453 | |||
454 | red db ? ;byte ;for use in red green blue files |
||
455 | green db ? ;byte |
||
456 | blue db ? ;byte |
||
457 | gray db ? ;byte ;for use in grayscale files |
||
458 | alpha db ? ;byte ;for alpha channel files |
||
459 | ends |
||
460 | |||
461 | |||
462 | |||
463 | ; of sPLT chunks. |
||
464 | |||
465 | |||
466 | red dw ? ;uint_16 |
||
467 | green dw ? ;uint_16 |
||
468 | blue dw ? ;uint_16 |
||
469 | alpha dw ? ;uint_16 |
||
470 | frequency dw ? ;uint_16 |
||
471 | ends |
||
472 | |||
473 | |||
474 | ; occupy the LSB of their respective members, and the MSB of each member |
||
475 | ; is zero-filled. The frequency member always occupies the full 16 bits. |
||
476 | |||
477 | |||
478 | |||
479 | name dd ? ;charp ;palette name |
||
480 | depth db ? ;byte ;depth of palette samples |
||
481 | entries dd ? ;png_sPLT_entryp ;palette entries |
||
482 | nentries dd ? ;int_32 ;number of palette entries |
||
483 | ends |
||
484 | |||
485 | |||
486 | ; png_text holds the contents of a text/ztxt/itxt chunk in a PNG file, |
||
487 | ; and whether that contents is compressed or not. The "key" field |
||
488 | ; points to a regular zero-terminated C string. The "text" fields can be a |
||
489 | ; regular C string, an empty string, or a NULL pointer. |
||
490 | ; However, the structure returned by png_get_text() will always contain |
||
491 | ; the "text" field as a regular zero-terminated C string (possibly |
||
492 | ; empty), never a NULL pointer, so it can be safely used in printf() and |
||
493 | ; other string-handling functions. Note that the "itxt_length", "lang", and |
||
494 | ; "lang_key" members of the structure only exist when the library is built |
||
495 | ; with iTXt chunk support. Prior to libpng-1.4.0 the library was built by |
||
496 | ; default without iTXt support. Also note that when iTXt *is* supported, |
||
497 | ; the "lang" and "lang_key" fields contain NULL pointers when the |
||
498 | ; "compression" field contains * PNG_TEXT_COMPRESSION_NONE or |
||
499 | ; PNG_TEXT_COMPRESSION_zTXt. Note that the "compression value" is not the |
||
500 | ; same as what appears in the PNG tEXt/zTXt/iTXt chunk's "compression flag" |
||
501 | ; which is always 0 or 1, or its "compression method" which is always 0. |
||
502 | |||
503 | |||
504 | compression dd ? ;int ;compression value: |
||
505 | ;-1: tEXt, none |
||
506 | ; 0: zTXt, deflate |
||
507 | ; 1: iTXt, none |
||
508 | ; 2: iTXt, deflate |
||
509 | key dd ? ;charp ;keyword, 1-79 character description of "text" |
||
510 | text dd ? ;charp ;comment, may be an empty string (ie "") |
||
511 | ; or a NULL pointer |
||
512 | text_length dd ? ;png_size_t ;length of the text string |
||
513 | itxt_length dd ? ;png_size_t ;length of the itxt string |
||
514 | lang dd ? ;charp ;language code, 0-79 characters |
||
515 | ; or a NULL pointer |
||
516 | lang_key dd ? ;charp ;keyword translated UTF-8 string, 0 or more |
||
517 | ; chars or a NULL pointer |
||
518 | ends |
||
519 | end if |
||
520 | |||
521 | |||
522 | ; The values of the PNG_TEXT_COMPRESSION_ defines should NOT be changed. |
||
523 | PNG_TEXT_COMPRESSION_NONE_WR equ -3 |
||
524 | PNG_TEXT_COMPRESSION_zTXt_WR equ -2 |
||
525 | PNG_TEXT_COMPRESSION_NONE equ -1 |
||
526 | PNG_TEXT_COMPRESSION_zTXt equ 0 |
||
527 | PNG_ITXT_COMPRESSION_NONE equ 1 |
||
528 | PNG_ITXT_COMPRESSION_zTXt equ 2 |
||
529 | PNG_TEXT_COMPRESSION_LAST equ 3 ;Not a valid value |
||
530 | |||
531 | |||
532 | ; Two conversions are provided, both from time_t and struct tm. There |
||
533 | ; is no portable way to convert to either of these structures, as far |
||
534 | ; as I know. If you know of a portable way, send it to me. As a side |
||
535 | ; note - PNG has always been Year 2000 compliant! |
||
536 | |||
537 | |||
538 | year dw ? ;uint_16 ;full year, as in, 1995 |
||
539 | month db ? ;byte ;month of year, 1 - 12 |
||
540 | day db ? ;byte ;day of month, 1 - 31 |
||
541 | hour db ? ;byte ;hour of day, 0 - 23 |
||
542 | minute db ? ;byte ;minute of hour, 0 - 59 |
||
543 | second db ? ;byte ;second of minute, 0 - 60 (for leap seconds) |
||
544 | ends |
||
545 | |||
546 | |||
547 | ; png_unknown_chunk is a structure to hold queued chunks for which there is |
||
548 | ; no specific support. The idea is that we can use this to queue |
||
549 | ; up private chunks for output even though the library doesn't actually |
||
550 | ; know about their semantics. |
||
551 | |||
552 | |||
553 | |||
554 | |||
555 | name rb 5 ;byte[5] ;Textual chunk name with '\0' terminator |
||
556 | podata dd ? ;byte* ;Data, should not be modified on read! |
||
557 | size dd ? ;png_size_t |
||
558 | |||
559 | |||
560 | ; Notice that on read it is set by libpng however the values stored have |
||
561 | ; more bits set than are listed below. Always treat the value as a |
||
562 | ; bitmask. On write set only one bit - setting multiple bits may cause the |
||
563 | ; chunk to be written in multiple places. |
||
564 | |||
565 | |||
566 | ends |
||
567 | end if |
||
568 | |||
569 | |||
570 | PNG_HAVE_IHDR equ 0x01 |
||
571 | PNG_HAVE_PLTE equ 0x02 |
||
572 | PNG_AFTER_IDAT equ 0x08 |
||
573 | |||
574 | |||
575 | PNG_UINT_31_MAX equ 0x7fffffff ;uint_32 |
||
576 | PNG_UINT_32_MAX equ -1 ;uint_32 |
||
577 | PNG_SIZE_MAX equ 0x60000000 ;1.5 Gb |
||
578 | |||
579 | |||
580 | ; PNG specification manner (x100000) |
||
581 | |||
582 | |||
583 | PNG_FP_HALF equ 50000 |
||
584 | PNG_FP_MAX equ ((png_fixed_point)0x7fffffffL) |
||
585 | PNG_FP_MIN equ (-PNG_FP_MAX) |
||
586 | |||
587 | |||
588 | ; color type masks |
||
589 | PNG_COLOR_MASK_PALETTE equ 1 |
||
590 | PNG_COLOR_MASK_COLOR equ 2 |
||
591 | PNG_COLOR_MASK_ALPHA equ 4 |
||
592 | |||
593 | |||
594 | PNG_COLOR_TYPE_GRAY equ 0 |
||
595 | PNG_COLOR_TYPE_PALETTE equ (PNG_COLOR_MASK_COLOR or PNG_COLOR_MASK_PALETTE) |
||
596 | PNG_COLOR_TYPE_RGB equ (PNG_COLOR_MASK_COLOR) |
||
597 | PNG_COLOR_TYPE_RGB_ALPHA equ (PNG_COLOR_MASK_COLOR or PNG_COLOR_MASK_ALPHA) |
||
598 | PNG_COLOR_TYPE_GRAY_ALPHA equ (PNG_COLOR_MASK_ALPHA) |
||
599 | ; aliases |
||
600 | PNG_COLOR_TYPE_RGBA equ PNG_COLOR_TYPE_RGB_ALPHA |
||
601 | PNG_COLOR_TYPE_GA equ PNG_COLOR_TYPE_GRAY_ALPHA |
||
602 | |||
603 | |||
604 | PNG_COMPRESSION_TYPE_BASE equ 0 ;Deflate method 8, 32K window |
||
605 | PNG_COMPRESSION_TYPE_DEFAULT equ PNG_COMPRESSION_TYPE_BASE |
||
606 | |||
607 | |||
608 | PNG_FILTER_TYPE_BASE equ 0 ;Single row per-byte filtering |
||
609 | PNG_INTRAPIXEL_DIFFERENCING equ 64 ;Used only in MNG datastreams |
||
610 | PNG_FILTER_TYPE_DEFAULT equ PNG_FILTER_TYPE_BASE |
||
611 | |||
612 | |||
613 | PNG_INTERLACE_NONE equ 0 ;Non-interlaced image |
||
614 | PNG_INTERLACE_ADAM7 equ 1 ;Adam7 interlacing |
||
615 | PNG_INTERLACE_LAST equ 2 ;Not a valid value |
||
616 | |||
617 | |||
618 | PNG_OFFSET_PIXEL equ 0 ;Offset in pixels |
||
619 | PNG_OFFSET_MICROMETER equ 1 ;Offset in micrometers (1/10^6 meter) |
||
620 | PNG_OFFSET_LAST equ 2 ;Not a valid value |
||
621 | |||
622 | |||
623 | PNG_EQUATION_LINEAR equ 0 ;Linear transformation |
||
624 | PNG_EQUATION_BASE_E equ 1 ;Exponential base e transform |
||
625 | PNG_EQUATION_ARBITRARY equ 2 ;Arbitrary base exponential transform |
||
626 | PNG_EQUATION_HYPERBOLIC equ 3 ;Hyperbolic sine transformation |
||
627 | PNG_EQUATION_LAST equ 4 ;Not a valid value |
||
628 | |||
629 | |||
630 | PNG_SCALE_UNKNOWN equ 0 ;unknown unit (image scale) |
||
631 | PNG_SCALE_METER equ 1 ;meters per pixel |
||
632 | PNG_SCALE_RADIAN equ 2 ;radians per pixel |
||
633 | PNG_SCALE_LAST equ 3 ;Not a valid value |
||
634 | |||
635 | |||
636 | PNG_RESOLUTION_UNKNOWN equ 0 ;pixels/unknown unit (aspect ratio) |
||
637 | PNG_RESOLUTION_METER equ 1 ;pixels/meter |
||
638 | PNG_RESOLUTION_LAST equ 2 ;Not a valid value |
||
639 | |||
640 | |||
641 | PNG_sRGB_INTENT_PERCEPTUAL equ 0 |
||
642 | PNG_sRGB_INTENT_RELATIVE equ 1 |
||
643 | PNG_sRGB_INTENT_SATURATION equ 2 |
||
644 | PNG_sRGB_INTENT_ABSOLUTE equ 3 |
||
645 | PNG_sRGB_INTENT_LAST equ 4 ;Not a valid value |
||
646 | |||
647 | |||
648 | PNG_KEYWORD_MAX_LENGTH equ 79 |
||
649 | |||
650 | |||
651 | PNG_MAX_PALETTE_LENGTH equ 256 |
||
652 | |||
653 | |||
654 | ; from the PNG header, or if the application has filled in the corresponding |
||
655 | ; data in the info_struct to be written into the output file. The values |
||
656 | ; of the PNG_INFO_ |
||
657 | |||
658 | |||
659 | PNG_INFO_sBIT equ 0x0002 |
||
660 | PNG_INFO_cHRM equ 0x0004 |
||
661 | PNG_INFO_PLTE equ 0x0008 |
||
662 | PNG_INFO_tRNS equ 0x0010 |
||
663 | PNG_INFO_bKGD equ 0x0020 |
||
664 | PNG_INFO_hIST equ 0x0040 |
||
665 | PNG_INFO_pHYs equ 0x0080 |
||
666 | PNG_INFO_oFFs equ 0x0100 |
||
667 | PNG_INFO_tIME equ 0x0200 |
||
668 | PNG_INFO_pCAL equ 0x0400 |
||
669 | PNG_INFO_sRGB equ 0x0800 ; GR-P, 0.96a |
||
670 | PNG_INFO_iCCP equ 0x1000 ; ESR, 1.0.6 |
||
671 | PNG_INFO_sPLT equ 0x2000 ; ESR, 1.0.6 |
||
672 | PNG_INFO_sCAL equ 0x4000 ; ESR, 1.0.6 |
||
673 | PNG_INFO_IDAT equ 0x8000 ; ESR, 1.0.6 |
||
674 | |||
675 | |||
676 | ; change these values for the row. It also should enable using |
||
677 | ; the routines for other purposes. |
||
678 | |||
679 | |||
680 | width dd ? ;uint_32 ;width of row |
||
681 | rowbytes dd ? ;png_size_t ;number of bytes in row |
||
682 | color_type db ? ;byte ;color type of row |
||
683 | bit_depth db ? ;byte ;bit depth of row |
||
684 | channels db ? ;byte ;number of channels (1, 2, 3, or 4) |
||
685 | pixel_depth db ? ;byte ;bits per pixel (depth * channels) |
||
686 | ends |
||
687 | |||
688 | |||
689 | ; This must match the function definition in |
||
690 | ; must include this before png.h to obtain the definition of jmp_buf. The |
||
691 | ; function is required to be PNG_NORETURN, but this is not checked. If the |
||
692 | ; function does return the application will crash via an abort() or similar |
||
693 | ; system level call. |
||
694 | |||
695 | |||
696 | ; changes to ensure that pnglibconf.h records the calling convention used by |
||
697 | ; your compiler. This may be very difficult - try using a different compiler |
||
698 | ; to build the library! |
||
699 | |||
700 | |||
701 | end if |
||
702 | |||
703 | |||
704 | PNG_TRANSFORM_IDENTITY equ 0x0000 ; read and write |
||
705 | PNG_TRANSFORM_STRIP_16 equ 0x0001 ; read only |
||
706 | PNG_TRANSFORM_STRIP_ALPHA equ 0x0002 ; read only |
||
707 | PNG_TRANSFORM_PACKING equ 0x0004 ; read and write |
||
708 | PNG_TRANSFORM_PACKSWAP equ 0x0008 ; read and write |
||
709 | PNG_TRANSFORM_EXPAND equ 0x0010 ; read only |
||
710 | PNG_TRANSFORM_INVERT_MONO equ 0x0020 ; read and write |
||
711 | PNG_TRANSFORM_SHIFT equ 0x0040 ; read and write |
||
712 | PNG_TRANSFORM_BGR equ 0x0080 ; read and write |
||
713 | PNG_TRANSFORM_SWAP_ALPHA equ 0x0100 ; read and write |
||
714 | PNG_TRANSFORM_SWAP_ENDIAN equ 0x0200 ; read and write |
||
715 | PNG_TRANSFORM_INVERT_ALPHA equ 0x0400 ; read and write |
||
716 | PNG_TRANSFORM_STRIP_FILLER equ 0x0800 ; write only |
||
717 | ; Added to libpng-1.2.34 |
||
718 | PNG_TRANSFORM_STRIP_FILLER_BEFORE equ PNG_TRANSFORM_STRIP_FILLER |
||
719 | PNG_TRANSFORM_STRIP_FILLER_AFTER equ 0x1000 ; write only |
||
720 | ; Added to libpng-1.4.0 |
||
721 | PNG_TRANSFORM_GRAY_TO_RGB equ 0x2000 ; read only |
||
722 | ; Added to libpng-1.5.4 |
||
723 | PNG_TRANSFORM_EXPAND_16 equ 0x4000 ;read only |
||
724 | ;if INT_MAX >= 0x8000 ;else this might break |
||
725 | PNG_TRANSFORM_SCALE_16 equ 0x8000 ;read only |
||
726 | ;end if |
||
727 | |||
728 | |||
729 | PNG_FLAG_MNG_EMPTY_PLTE equ 0x01 |
||
730 | PNG_FLAG_MNG_FILTER_64 equ 0x04 |
||
731 | PNG_ALL_MNG_FEATURES equ 0x05 |
||
732 | |||
733 | |||
734 | ; this allowed the zlib default functions to be used on Windows |
||
735 | ; platforms. In 1.5 the zlib default malloc (which just calls malloc and |
||
736 | ; ignores the first argument) should be completely compatible with the |
||
737 | ; following. |
||
738 | |||
739 | |||
740 | ; Here are the function definitions most commonly used. This is not |
||
741 | ; the place to find out how to use libpng. See libpng-manual.txt for the |
||
742 | ; full explanation, see example.c for the summary. This just provides |
||
743 | ; a simple one line description of the use of each function. |
||
744 | |||
745 | |||
746 | |||
747 | |||
748 | ; png_check_sig(sig, n) := !png_sig_cmp(sig, 0, n). |
||
749 | |||
750 | |||
751 | |||
752 | |||
753 | { |
||
754 | local .end0 |
||
755 | and eax,0xff |
||
756 | if PNG_USE_ABS eq 1 |
||
757 | add sum,128 |
||
758 | sub al,128 ;v - 128 |
||
759 | cmp al,128 |
||
760 | jl @f |
||
761 | neg al |
||
762 | inc al ;abs(v - 128) |
||
763 | @@: |
||
764 | sub sum,eax |
||
765 | else |
||
766 | cmp eax,128 |
||
767 | jl @f |
||
768 | add sum,256 |
||
769 | sub sum,eax |
||
770 | jmp .end0 |
||
771 | @@: |
||
772 | add sum,eax |
||
773 | .end0: |
||
774 | end if |
||
775 | } |
||
776 | |||
777 | |||
778 | PNG_ERROR_ACTION_NONE equ 1 |
||
779 | PNG_ERROR_ACTION_WARN equ 2 |
||
780 | PNG_ERROR_ACTION_ERROR equ 3 |
||
781 | PNG_RGB_TO_GRAY_DEFAULT equ (-1) ;for red/green coefficients |
||
782 | |||
783 | |||
784 | ; of a PNG file are returned to the calling application when an alpha channel, |
||
785 | ; or a tRNS chunk in a palette file, is present. |
||
786 | |||
787 | |||
788 | ; datastream. The color samples in a PNG datastream are never premultiplied |
||
789 | ; with the alpha samples. |
||
790 | |||
791 | |||
792 | ; channel is a linear measure of the contribution of the pixel to the |
||
793 | ; corresponding composited pixel, and the color channels are unassociated |
||
794 | ; (not premultiplied). The gamma encoded color channels must be scaled |
||
795 | ; according to the contribution and to do this it is necessary to undo |
||
796 | ; the encoding, scale the color values, perform the composition and reencode |
||
797 | ; the values. This is the 'PNG' mode. |
||
798 | |||
799 | |||
800 | ; storing color channel values that have been scaled by the alpha. |
||
801 | ; image. These are the 'STANDARD', 'ASSOCIATED' or 'PREMULTIPLIED' modes |
||
802 | ; (the latter being the two common names for associated alpha color channels). |
||
803 | |||
804 | |||
805 | ; value is equal to the maximum value. |
||
806 | |||
807 | |||
808 | ; broken because, in practice, no implementation that uses this choice |
||
809 | ; correctly undoes the encoding before handling alpha composition. Use this |
||
810 | ; choice only if other serious errors in the software or hardware you use |
||
811 | ; mandate it; the typical serious error is for dark halos to appear around |
||
812 | ; opaque areas of the composited PNG image because of arithmetic overflow. |
||
813 | |||
814 | |||
815 | ; with an enumerated 'mode' value and the gamma of the required output: |
||
816 | |||
817 | |||
818 | PNG_ALPHA_STANDARD equ 1 ;according to Porter/Duff |
||
819 | PNG_ALPHA_ASSOCIATED equ 1 ;as above; this is the normal practice |
||
820 | PNG_ALPHA_PREMULTIPLIED equ 1 ;as above |
||
821 | PNG_ALPHA_OPTIMIZED equ 2 ;'PNG' for opaque pixels, else 'STANDARD' |
||
822 | PNG_ALPHA_BROKEN equ 3 ;the alpha channel is gamma encoded |
||
823 | |||
824 | |||
825 | ; The output_gamma value is a screen gamma in libpng terminology: it expresses |
||
826 | ; how to decode the output values, not how they are encoded. |
||
827 | |||
828 | |||
829 | PNG_GAMMA_MAC_18 equ -2 ;Old Mac '1.8' gamma and color space |
||
830 | PNG_GAMMA_sRGB equ 220000 ;Television standards--matches sRGB gamma |
||
831 | PNG_GAMMA_LINEAR equ PNG_FP_1 ;Linear |
||
832 | end if |
||
833 | |||
834 | |||
835 | PNG_FILLER_BEFORE equ 0 |
||
836 | PNG_FILLER_AFTER equ 1 |
||
837 | |||
838 | |||
839 | |||
840 | |||
841 | ; libpng-1.5.4 this API must not be called before the PNG file header has been |
||
842 | ; read. Doing so will result in unexpected behavior and possible warnings or |
||
843 | ; errors if the PNG file contains a bKGD chunk. |
||
844 | |||
845 | |||
846 | PNG_BACKGROUND_GAMMA_UNKNOWN equ 0 |
||
847 | PNG_BACKGROUND_GAMMA_SCREEN equ 1 |
||
848 | PNG_BACKGROUND_GAMMA_FILE equ 2 |
||
849 | PNG_BACKGROUND_GAMMA_UNIQUE equ 3 |
||
850 | end if |
||
851 | |||
852 | |||
6779 | IgorA | 853 | |
6733 | IgorA | 854 | |
855 | ; library. The following is the floating point variant. |
||
856 | |||
857 | |||
6779 | IgorA | 858 | |
6733 | IgorA | 859 | |
860 | ; NOTE: this API simply sets the screen and file gamma values. It will |
||
861 | ; therefore override the value for gamma in a PNG file if it is called after |
||
862 | ; the file header has been read - use with care - call before reading the PNG |
||
863 | ; file for best results! |
||
864 | |||
865 | |||
866 | |||
867 | ; ancillary and critical chunks, and whether to use the data contained |
||
868 | ; therein. Note that it is impossible to "discard" data in a critical |
||
869 | ; chunk. For versions prior to 0.90, the action was always error/quit, |
||
870 | ; whereas in version 0.90 and later, the action for CRC errors in ancillary |
||
871 | ; chunks is warn/discard. These values should NOT be changed. |
||
872 | |||
873 | |||
874 | |||
875 | |||
876 | PNG_CRC_ERROR_QUIT equ 1 ;error/quit error/quit |
||
877 | PNG_CRC_WARN_DISCARD equ 2 ;(INVALID) warn/discard data |
||
878 | PNG_CRC_WARN_USE equ 3 ;warn/use data warn/use data |
||
879 | PNG_CRC_QUIET_USE equ 4 ;quiet/use data quiet/use data |
||
880 | PNG_CRC_NO_CHANGE equ 5 ;use current value use current value |
||
881 | |||
882 | |||
883 | ; are chosen so that they don't conflict with real filter types |
||
884 | ; below, in case they are supplied instead of the #defined constants. |
||
885 | ; These values should NOT be changed. |
||
886 | |||
887 | |||
888 | PNG_FILTER_NONE equ 0x08 |
||
889 | PNG_FILTER_SUB equ 0x10 |
||
890 | PNG_FILTER_UP equ 0x20 |
||
891 | PNG_FILTER_AVG equ 0x40 |
||
892 | PNG_FILTER_PAETH equ 0x80 |
||
893 | PNG_FAST_FILTERS equ (PNG_FILTER_NONE or PNG_FILTER_SUB or PNG_FILTER_UP) |
||
894 | PNG_ALL_FILTERS equ (PNG_FAST_FILTERS or PNG_FILTER_AVG or PNG_FILTER_PAETH) |
||
895 | |||
896 | |||
897 | ; These defines should NOT be changed. |
||
898 | |||
899 | |||
900 | PNG_FILTER_VALUE_SUB equ 1 |
||
901 | PNG_FILTER_VALUE_UP equ 2 |
||
902 | PNG_FILTER_VALUE_AVG equ 3 |
||
903 | PNG_FILTER_VALUE_PAETH equ 4 |
||
904 | PNG_FILTER_VALUE_LAST equ 5 |
||
905 | |||
906 | |||
907 | PNG_FILTER_HEURISTIC_DEFAULT equ 0 ;Currently "UNWEIGHTED" |
||
908 | PNG_FILTER_HEURISTIC_UNWEIGHTED equ 1 ;Used by libpng < 0.95 |
||
909 | PNG_FILTER_HEURISTIC_WEIGHTED equ 2 ;Experimental feature |
||
910 | PNG_FILTER_HEURISTIC_LAST equ 3 ;Not a valid value |
||
911 | |||
912 | |||
913 | ; may result either in memory leaks or double free of allocated data. |
||
914 | |||
915 | |||
916 | PNG_DESTROY_WILL_FREE_DATA equ 1 |
||
917 | PNG_SET_WILL_FREE_DATA equ 1 |
||
918 | PNG_USER_WILL_FREE_DATA equ 2 |
||
919 | ; Flags for png_ptr->free_me and info_ptr->free_me |
||
920 | PNG_FREE_HIST equ 0x0008 |
||
921 | PNG_FREE_ICCP equ 0x0010 |
||
922 | PNG_FREE_SPLT equ 0x0020 |
||
923 | PNG_FREE_ROWS equ 0x0040 |
||
924 | PNG_FREE_PCAL equ 0x0080 |
||
925 | PNG_FREE_SCAL equ 0x0100 |
||
926 | if PNG_STORE_UNKNOWN_CHUNKS_SUPPORTED eq 1 |
||
927 | PNG_FREE_UNKN equ 0x0200 |
||
928 | end if |
||
929 | PNG_FREE_LIST equ 0x0400 ;removed in 1.6.0 because it is ignored |
||
930 | PNG_FREE_PLTE equ 0x1000 |
||
931 | PNG_FREE_TRNS equ 0x2000 |
||
932 | PNG_FREE_TEXT equ 0x4000 |
||
933 | PNG_FREE_ALL equ 0x7fff |
||
934 | PNG_FREE_MUL equ 0x4220 ;PNG_FREE_SPLT|PNG_FREE_TEXT|PNG_FREE_UNKN |
||
935 | |||
936 | |||
937 | |||
938 | |||
939 | ;# define png_chunk_error(s1,s2) png_err(s1) |
||
940 | ;end if |
||
941 | |||
942 | |||
943 | ;# define png_warning(s1,s2) ((void)(s1)) |
||
944 | ;# define png_chunk_warning(s1,s2) ((void)(s1)) |
||
945 | |||
946 | |||
947 | |||
948 | |||
949 | ;# ifdef PNG_ALLOW_BENIGN_ERRORS |
||
950 | macro png_benign_error h,txt |
||
951 | { |
||
952 | png_warning h,txt |
||
953 | } |
||
954 | ;# define png_chunk_benign_error png_chunk_warning |
||
955 | ;# else |
||
956 | ;# define png_benign_error png_error |
||
957 | ;# define png_chunk_benign_error png_chunk_error |
||
958 | ;# endif |
||
959 | ;end if |
||
960 | |||
961 | |||
962 | |||
963 | ; specific unknown chunks. |
||
964 | |||
965 | |||
966 | ; ignored and the default was used, the per-chunk setting only had an effect on |
||
967 | ; write. If you wish to have chunk-specific handling on read in code that must |
||
968 | ; work on earlier versions you must use a user chunk callback to specify the |
||
969 | ; desired handling (keep or discard.) |
||
970 | |||
971 | |||
972 | ; parameter is interpreted as follows: |
||
973 | |||
974 | |||
975 | ; PNG_HANDLE_CHUNK_AS_DEFAULT: |
||
976 | ; Known chunks: do normal libpng processing, do not keep the chunk (but |
||
977 | ; see the comments below about PNG_HANDLE_AS_UNKNOWN_SUPPORTED) |
||
978 | ; Unknown chunks: for a specific chunk use the global default, when used |
||
979 | ; as the default discard the chunk data. |
||
980 | ; PNG_HANDLE_CHUNK_NEVER: |
||
981 | ; Discard the chunk data. |
||
982 | ; PNG_HANDLE_CHUNK_IF_SAFE: |
||
983 | ; Keep the chunk data if the chunk is not critical else raise a chunk |
||
984 | ; error. |
||
985 | ; PNG_HANDLE_CHUNK_ALWAYS: |
||
986 | ; Keep the chunk data. |
||
987 | |||
988 | |||
989 | ; below. Notice that specifying "AS_DEFAULT" as a global default is equivalent |
||
990 | ; to specifying "NEVER", however when "AS_DEFAULT" is used for specific chunks |
||
991 | ; it simply resets the behavior to the libpng default. |
||
992 | |||
993 | |||
994 | ; The per-chunk handling is always used when there is a png_user_chunk_ptr |
||
995 | ; callback and the callback returns 0; the chunk is then always stored *unless* |
||
996 | ; it is critical and the per-chunk setting is other than ALWAYS. Notice that |
||
997 | ; the global default is *not* used in this case. (In effect the per-chunk |
||
998 | ; value is incremented to at least IF_SAFE.) |
||
999 | |||
1000 | |||
1001 | ; per-chunk defaults will be honored. If you want to preserve the current |
||
1002 | ; behavior when your callback returns 0 you must set PNG_HANDLE_CHUNK_IF_SAFE |
||
1003 | ; as the default - if you don't do this libpng 1.6 will issue a warning. |
||
1004 | |||
1005 | |||
1006 | ; earlier simply return '1' (handled). |
||
1007 | |||
1008 | |||
1009 | ; If this is *not* set known chunks will always be handled by libpng and |
||
1010 | ; will never be stored in the unknown chunk list. Known chunks listed to |
||
1011 | ; png_set_keep_unknown_chunks will have no effect. If it is set then known |
||
1012 | ; chunks listed with a keep other than AS_DEFAULT will *never* be processed |
||
1013 | ; by libpng, in addition critical chunks must either be processed by the |
||
1014 | ; callback or saved. |
||
1015 | |||
1016 | |||
1017 | ; default handling for chunks that would otherwise be recognized the |
||
1018 | ; behavior of libpng transformations may well become incorrect! |
||
1019 | |||
1020 | |||
1021 | ; When writing chunks the options only apply to the chunks specified by |
||
1022 | ; png_set_unknown_chunks (below), libpng will *always* write known chunks |
||
1023 | ; required by png_set_ calls and will always write the core critical chunks |
||
1024 | ; (as required for PLTE). |
||
1025 | |||
1026 | |||
1027 | ; png_set_keep_unknown_chunks list to find the keep setting, this is then |
||
1028 | ; interpreted as follows: |
||
1029 | |||
1030 | |||
1031 | ; Write safe-to-copy chunks and write other chunks if the global |
||
1032 | ; default is set to _ALWAYS, otherwise don't write this chunk. |
||
1033 | ; PNG_HANDLE_CHUNK_NEVER: |
||
1034 | ; Do not write the chunk. |
||
1035 | ; PNG_HANDLE_CHUNK_IF_SAFE: |
||
1036 | ; Write the chunk if it is safe-to-copy, otherwise do not write it. |
||
1037 | ; PNG_HANDLE_CHUNK_ALWAYS: |
||
1038 | ; Write the chunk. |
||
1039 | |||
1040 | |||
1041 | ; in read unknown chunks are not stored by default, in write they are written |
||
1042 | ; by default. Also the behavior of PNG_HANDLE_CHUNK_IF_SAFE is very different |
||
1043 | ; - on write the safe-to-copy bit is checked, on read the critical bit is |
||
1044 | ; checked and on read if the chunk is critical an error will be raised. |
||
1045 | |||
1046 | |||
1047 | ; =========== |
||
1048 | ; If num_chunks is positive, then the "keep" parameter specifies the manner |
||
1049 | ; for handling only those chunks appearing in the chunk_list array, |
||
1050 | ; otherwise the chunk list array is ignored. |
||
1051 | |||
1052 | |||
1053 | ; unknown chunks, as described above. |
||
1054 | |||
1055 | |||
1056 | ; for handling all unknown chunks plus all chunks recognized by libpng |
||
1057 | ; except for the IHDR, PLTE, tRNS, IDAT, and IEND chunks (which continue to |
||
1058 | ; be processed by libpng. |
||
1059 | |||
1060 | |||
1061 | |||
1062 | PNG_HANDLE_CHUNK_AS_DEFAULT equ 0 |
||
1063 | PNG_HANDLE_CHUNK_NEVER equ 1 |
||
1064 | PNG_HANDLE_CHUNK_IF_SAFE equ 2 |
||
1065 | PNG_HANDLE_CHUNK_ALWAYS equ 3 |
||
1066 | PNG_HANDLE_CHUNK_LAST equ 4 |
||
1067 | |||
1068 | |||
1069 | ;PNG_REMOVED(200, bytep, png_get_io_chunk_name, (png_structrp png_ptr), |
||
1070 | ; PNG_DEPRECATED) |
||
1071 | |||
1072 | |||
1073 | PNG_IO_NONE equ 0x0000 ; no I/O at this moment |
||
1074 | PNG_IO_READING equ 0x0001 ; currently reading |
||
1075 | PNG_IO_WRITING equ 0x0002 ; currently writing |
||
1076 | PNG_IO_SIGNATURE equ 0x0010 ; currently at the file signature |
||
1077 | PNG_IO_CHUNK_HDR equ 0x0020 ; currently at the chunk header |
||
1078 | PNG_IO_CHUNK_DATA equ 0x0040 ; currently at the chunk data |
||
1079 | PNG_IO_CHUNK_CRC equ 0x0080 ; currently at the chunk crc |
||
1080 | PNG_IO_MASK_OP equ 0x000f ; current operation: reading/writing |
||
1081 | PNG_IO_MASK_LOC equ 0x00f0 ; current location: sig/hdr/data/crc |
||
1082 | ;end if /* IO_STATE */ |
||
1083 | |||
1084 | |||
1085 | ; libpng interlace handling is turned off the macros may be used to handle |
||
1086 | ; interlaced images within the application. |
||
1087 | |||
1088 | |||
6779 | IgorA | 1089 | |
6733 | IgorA | 1090 | |
1091 | ; full, image which appears in a given pass. 'pass' is in the range 0 |
||
1092 | ; to 6 and the result is in the range 0 to 7. |
||
1093 | |||
1094 | |||
1095 | { |
||
1096 | push ebx ecx |
||
1097 | mov eax,pass |
||
1098 | mov ebx,eax |
||
6779 | IgorA | 1099 | not eax |
6733 | IgorA | 1100 | and eax,1 |
1101 | shr ebx,1 |
||
1102 | mov ecx,3 |
||
1103 | sub ecx,ebx |
||
1104 | shl eax,cl |
||
1105 | and eax,7 |
||
1106 | pop ecx ebx |
||
1107 | } |
||
1108 | macro PNG_PASS_START_COL pass |
||
1109 | { |
||
1110 | push ebx ecx |
||
1111 | mov eax,pass |
||
1112 | mov ebx,eax |
||
6779 | IgorA | 1113 | and eax,1 |
6733 | IgorA | 1114 | inc ebx |
1115 | shr ebx,1 |
||
1116 | mov ecx,3 |
||
1117 | sub ecx,ebx |
||
1118 | shl eax,cl |
||
1119 | and eax,7 |
||
1120 | pop ecx ebx |
||
1121 | } |
||
1122 | |||
1123 | |||
1124 | ; pixels in the input - effectively the inverse of the 'COL_SHIFT' macro that |
||
1125 | ; follows. Note that ROW_OFFSET is the offset from one row to the next whereas |
||
1126 | ; COL_OFFSET is from one column to the next, within a row. |
||
1127 | |||
1128 | |||
1129 | ;#define PNG_PASS_COL_OFFSET(pass) (1<<((7-(pass))>>1)) |
||
1130 | |||
1131 | |||
1132 | ; pass. This is expressed as a shift - effectively log2 of the number or |
||
1133 | ; rows or columns in each 8x8 tile of the original image. |
||
1134 | |||
1135 | |||
1136 | { |
||
1137 | local .end0 |
||
1138 | mov eax,3 |
||
1139 | cmp pass,2 |
||
1140 | jle .end0 |
||
1141 | mov eax,8 |
||
1142 | sub eax,pass |
||
1143 | shr eax,1 |
||
1144 | .end0: |
||
1145 | } |
||
1146 | macro PNG_PASS_COL_SHIFT pass |
||
1147 | { |
||
1148 | local .end0 |
||
1149 | mov eax,3 |
||
1150 | cmp pass,1 |
||
1151 | jle .end0 |
||
1152 | mov eax,7 |
||
1153 | sub eax,pass |
||
1154 | shr eax,1 |
||
1155 | .end0: |
||
1156 | } |
||
1157 | |||
1158 | |||
1159 | ; pass of an image given its height or width. In fact these macros may |
||
1160 | ; return non-zero even though the sub-image is empty, because the other |
||
1161 | ; dimension may be empty for a small image. |
||
1162 | |||
1163 | |||
1164 | { |
||
1165 | push ecx |
||
1166 | push ebx |
||
1167 | PNG_PASS_START_ROW pass |
||
1168 | mov ebx,eax |
||
1169 | PNG_PASS_ROW_SHIFT pass |
||
1170 | mov ecx,eax |
||
1171 | xor eax,eax |
||
1172 | inc eax |
||
1173 | shl eax,cl |
||
1174 | dec eax |
||
1175 | sub eax,ebx |
||
1176 | pop ebx |
||
1177 | add eax,height |
||
1178 | shr eax,cl |
||
1179 | pop ecx |
||
1180 | } |
||
1181 | macro PNG_PASS_COLS width, pass |
||
1182 | { |
||
1183 | push ecx |
||
1184 | push ebx |
||
1185 | PNG_PASS_START_COL pass |
||
1186 | mov ebx,eax |
||
1187 | PNG_PASS_COL_SHIFT pass |
||
1188 | mov ecx,eax |
||
1189 | xor eax,eax |
||
1190 | inc eax |
||
1191 | shl eax,cl |
||
1192 | dec eax |
||
1193 | sub eax,ebx |
||
1194 | pop ebx |
||
1195 | add eax,width |
||
1196 | shr eax,cl |
||
1197 | pop ecx |
||
1198 | } |
||
1199 | |||
1200 | |||
1201 | ; necessary to find the row in the output image given a row in an interlaced |
||
1202 | ; image, so two more macros: |
||
1203 | |||
1204 | |||
1205 | ; (((y_in)< |
||
1206 | ;#define PNG_COL_FROM_PASS_COL(x_in, pass) \ |
||
1207 | ; (((x_in)< |
||
1208 | |||
1209 | |||
1210 | ; or column is in a particular pass. These use a common utility macro that |
||
1211 | ; returns a mask for a given pass - the offset 'off' selects the row or |
||
1212 | ; column version. The mask has the appropriate bit set for each column in |
||
1213 | ; the tile. |
||
1214 | |||
1215 | |||
1216 | ; ((0x110145AF>>(((7-(off))-(pass))<<2)) & 0xF) | \ |
||
1217 | ; ((0x01145AF0>>(((7-(off))-(pass))<<2)) & 0xF0)) |
||
1218 | |||
1219 | |||
1220 | ; ((PNG_PASS_MASK(pass,0) >> ((y)&7)) & 1) |
||
1221 | ;#define PNG_COL_IN_INTERLACE_PASS(x, pass) \ |
||
1222 | ; ((PNG_PASS_MASK(pass,1) >> ((x)&7)) & 1) |
||
1223 | |||
1224 | |||
1225 | ; With these routines we avoid an integer divide, which will be slower on |
||
1226 | ; most machines. However, it does take more operations than the corresponding |
||
1227 | ; divide method, so it may be slower on a few RISC systems. There are two |
||
1228 | ; shifts (by 8 or 16 bits) and an addition, versus a single integer divide. |
||
1229 | |||
1230 | |||
1231 | ; 32768 are correct for the NODIV code; 127 and 32767 are correct for the |
||
1232 | ; standard method. |
||
1233 | |||
1234 | |||
1235 | |||
1236 | |||
1237 | |||
1238 | |||
1239 | |||
1240 | ; { \ |
||
1241 | ; uint_16 temp = (uint_16)((uint_16)(fg) \ |
||
1242 | ; * (uint_16)(alpha) \ |
||
1243 | ; + (uint_16)(bg)*(uint_16)(255 \ |
||
1244 | ; - (uint_16)(alpha)) + 128); \ |
||
1245 | ; (composite) = (byte)(((temp + (temp >> 8)) >> 8) & 0xff); \ |
||
1246 | ; } |
||
1247 | |||
1248 | |||
1249 | ; { \ |
||
1250 | ; uint_32 temp = (uint_32)((uint_32)(fg) \ |
||
1251 | ; * (uint_32)(alpha) \ |
||
1252 | ; + (uint_32)(bg)*(65535 \ |
||
1253 | ; - (uint_32)(alpha)) + 32768); \ |
||
1254 | ; (composite) = (uint_16)(0xffff & ((temp + (temp >> 16)) >> 16)); \ |
||
1255 | ; } |
||
1256 | |||
1257 | |||
1258 | |||
1259 | |||
1260 | ; (composite) = \ |
||
1261 | ; (byte)(0xff & (((uint_16)(fg) * (uint_16)(alpha) + \ |
||
1262 | ; (uint_16)(bg) * (uint_16)(255 - (uint_16)(alpha)) + \ |
||
1263 | ; 127) / 255)) |
||
1264 | |||
1265 | |||
1266 | ; (composite) = \ |
||
1267 | ; (uint_16)(0xffff & (((uint_32)(fg) * (uint_32)(alpha) + \ |
||
1268 | ; (uint_32)(bg)*(uint_32)(65535 - (uint_32)(alpha)) + \ |
||
1269 | ; 32767) / 65535)) |
||
1270 | ;end if /* READ_COMPOSITE_NODIV */ |
||
1271 | |||
1272 | |||
6779 | IgorA | 1273 | ; Inline macros to do direct reads of bytes from the input buffer. |
6733 | IgorA | 1274 | ; The png_get_int_32() routine assumes we are using two's complement |
1275 | ; format for negative values, which is almost certainly true. |
||
1276 | |||
1277 | |||
1278 | ; (((uint_32)(*(buf)) << 24) + \ |
||
1279 | ; ((uint_32)(*((buf) + 1)) << 16) + \ |
||
1280 | ; ((uint_32)(*((buf) + 2)) << 8) + \ |
||
1281 | ; ((uint_32)(*((buf) + 3)))) |
||
1282 | |||
1283 | |||
1284 | ; function) incorrectly returned a value of type uint_32. |
||
1285 | |||
1286 | |||
1287 | ; ((uint_16) \ |
||
1288 | ; (((unsigned int)(*(buf)) << 8) + \ |
||
1289 | ; ((unsigned int)(*((buf) + 1))))) |
||
1290 | |||
1291 | |||
1292 | ; ((int_32)((*(buf) & 0x80) \ |
||
1293 | ; ? -((int_32)(((png_get_uint_32(buf)^0xffffffffU)+1U)&0x7fffffffU)) \ |
||
1294 | ; : (int_32)png_get_uint_32(buf))) |
||
1295 | end if |
||
6779 | IgorA | 1296 | |
6733 | IgorA | 1297 | |
1298 | ; Section 5: SIMPLIFIED API |
||
1299 | ; ******************************************************************************* |
||
1300 | |||
1301 | |||
1302 | ; documentation) if you don't understand what follows. |
||
1303 | |||
1304 | |||
1305 | ; itself. It allows PNG files to be read into a very limited number of |
||
1306 | ; in-memory bitmap formats or to be written from the same formats. If these |
||
1307 | ; formats do not accomodate your needs then you can, and should, use the more |
||
1308 | ; sophisticated APIs above - these support a wide variety of in-memory formats |
||
1309 | ; and a wide variety of sophisticated transformations to those formats as well |
||
1310 | ; as a wide variety of APIs to manipulate ancillary information. |
||
1311 | |||
1312 | |||
1313 | |||
1314 | |||
1315 | ; version field to PNG_IMAGE_VERSION and the 'opaque' pointer to NULL |
||
1316 | ; (this is REQUIRED, your program may crash if you don't do it.) |
||
1317 | ; 2) Call the appropriate png_image_begin_read... function. |
||
1318 | ; 3) Set the png_image 'format' member to the required sample format. |
||
1319 | ; 4) Allocate a buffer for the image and, if required, the color-map. |
||
1320 | ; 5) Call png_image_finish_read to read the image and, if required, the |
||
1321 | ; color-map into your buffers. |
||
1322 | |||
1323 | |||
1324 | ; color types, bit depths, and interlace methods are acceptable, and the |
||
1325 | ; input image is transformed as necessary to the requested in-memory format |
||
1326 | ; during the png_image_finish_read() step. The only caveat is that if you |
||
1327 | ; request a color-mapped image from a PNG that is full-color or makes |
||
1328 | ; complex use of an alpha channel the transformation is extremely lossy and the |
||
1329 | ; result may look terrible. |
||
1330 | |||
1331 | |||
1332 | |||
1333 | |||
1334 | ; 2) Initialize the members of the structure that describe the image, setting |
||
1335 | ; the 'format' member to the format of the image samples. |
||
1336 | ; 3) Call the appropriate png_image_write... function with a pointer to the |
||
1337 | ; image and, if necessary, the color-map to write the PNG data. |
||
1338 | |||
1339 | |||
1340 | ; when it is being read or defines the in-memory format of an image that you |
||
1341 | ; need to write: |
||
1342 | |||
1343 | |||
1344 | ; defined(PNG_SIMPLIFIED_WRITE_SUPPORTED) |
||
1345 | |||
1346 | |||
1347 | |||
1348 | |||
1349 | opaque dd ? ;png_controlp ;Initialize to NULL, free with png_image_free |
||
1350 | version dd ? ;uint_32 ;Set to PNG_IMAGE_VERSION |
||
1351 | width dd ? ;uint_32 ;Image width in pixels (columns) |
||
1352 | height dd ? ;uint_32 ;Image height in pixels (rows) |
||
1353 | format dd ? ;uint_32 ;Image format as defined below |
||
1354 | flags dd ? ;uint_32 ;A bit mask containing informational flags |
||
1355 | colormap_entries dd ? ;uint_32 ;Number of entries in the color-map |
||
1356 | |||
1357 | |||
1358 | ; non-zero value and the 'message' field will contain a '\0' terminated |
||
1359 | ; string with the libpng error or warning message. If both warnings and |
||
1360 | ; an error were encountered, only the error is recorded. If there |
||
1361 | ; are multiple warnings, only the first one is recorded. |
||
1362 | |||
1363 | |||
1364 | ; a value as follows: |
||
1365 | |||
1366 | |||
1367 | PNG_IMAGE_ERROR equ 2 |
||
1368 | |||
1369 | |||
1370 | ; a failure in the API just called: |
||
1371 | |||
1372 | |||
1373 | ; 1 - warning |
||
1374 | ; 2 - error |
||
1375 | ; 3 - error preceded by warning |
||
1376 | |||
1377 | |||
1378 | |||
1379 | |||
1380 | message rb 64 ;char[64] |
||
1381 | ends |
||
1382 | |||
1383 | |||
1384 | ; original values in the range 0 to 1.0: |
||
1385 | |||
1386 | |||
1387 | ; 2: A gray/luminance channel and an alpha channel (GA). |
||
1388 | ; 3: Three red, green, blue color channels (RGB). |
||
1389 | ; 4: Three color channels and an alpha channel (RGBA). |
||
1390 | |||
1391 | |||
1392 | |||
1393 | |||
1394 | ; alpha channel the original value is simply value/255. For the color or |
||
1395 | ; luminance channels the value is encoded according to the sRGB specification |
||
1396 | ; and matches the 8-bit format expected by typical display devices. |
||
1397 | |||
1398 | |||
1399 | ; channel and are suitable for passing to color management software. |
||
1400 | |||
1401 | |||
1402 | ; channels can be converted to the original value by dividing by 65535; all |
||
1403 | ; channels are linear. Color channels use the RGB encoding (RGB end-points) of |
||
1404 | ; the sRGB specification. This encoding is identified by the |
||
1405 | ; PNG_FORMAT_FLAG_LINEAR flag below. |
||
1406 | |||
1407 | |||
1408 | ; the actual sRGB transfer curve defined in the sRGB specification (see the |
||
1409 | ; article at http://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2 |
||
1410 | ; approximation used elsewhere in libpng. |
||
1411 | |||
1412 | |||
1413 | ; of the color or luminance channels and is returned as an associated alpha |
||
1414 | ; channel: the color/gray channels are scaled (pre-multiplied) by the alpha |
||
1415 | ; value. |
||
1416 | |||
1417 | |||
1418 | ; bytes per pixel according to the encoding, or are held in a color-map indexed |
||
1419 | ; by bytes in the image data. In the case of a color-map the color-map entries |
||
1420 | ; are individual samples, encoded as above, and the image data has one byte per |
||
1421 | ; pixel to select the relevant sample from the color-map. |
||
1422 | |||
1423 | |||
1424 | |||
1425 | |||
1426 | |||
1427 | ; particular layout of sample data and, if present, alpha values. There are |
||
1428 | ; separate defines for each of the two component encodings. |
||
1429 | |||
1430 | |||
1431 | ; valid. Formats can be built up from the flag values or you can use one of |
||
1432 | ; the predefined values below. When testing formats always use the FORMAT_FLAG |
||
1433 | ; macros to test for individual features - future versions of the library may |
||
1434 | ; add new flags. |
||
1435 | |||
1436 | |||
1437 | ; format of the entries in the color-map then png_image_{read,write}_colormap |
||
1438 | ; called to read or write the color-map and set the format correctly for the |
||
1439 | ; image data. Do not set the PNG_FORMAT_FLAG_COLORMAP bit directly! |
||
1440 | |||
1441 | |||
1442 | ; compiler errors because the definition of one of the following flags has been |
||
1443 | ; compiled out it is because libpng does not have the required support. It is |
||
1444 | ; possible, however, for the libpng configuration to enable the format on just |
||
1445 | ; read or just write; in that case you may see an error at run time. You can |
||
1446 | ; guard against this by checking for the definition of the appropriate |
||
1447 | ; "_SUPPORTED" macro, one of: |
||
1448 | |||
1449 | |||
1450 | |||
1451 | |||
1452 | PNG_FORMAT_FLAG_COLOR equ 0x02 ;color format: otherwise grayscale |
||
1453 | PNG_FORMAT_FLAG_LINEAR equ 0x04 ;2-byte channels else 1-byte |
||
1454 | PNG_FORMAT_FLAG_COLORMAP equ 0x08 ;image data is color-mapped |
||
1455 | |||
1456 | |||
1457 | |||
1458 | |||
1459 | |||
1460 | |||
1461 | |||
1462 | |||
1463 | |||
1464 | |||
1465 | PNG_FORMAT_GA equ PNG_FORMAT_FLAG_ALPHA |
||
1466 | PNG_FORMAT_AG equ (PNG_FORMAT_GA|PNG_FORMAT_FLAG_AFIRST) |
||
1467 | PNG_FORMAT_RGB equ PNG_FORMAT_FLAG_COLOR |
||
1468 | PNG_FORMAT_BGR equ (PNG_FORMAT_FLAG_COLOR|PNG_FORMAT_FLAG_BGR) |
||
1469 | PNG_FORMAT_RGBA equ (PNG_FORMAT_RGB|PNG_FORMAT_FLAG_ALPHA) |
||
1470 | PNG_FORMAT_ARGB equ (PNG_FORMAT_RGBA|PNG_FORMAT_FLAG_AFIRST) |
||
1471 | PNG_FORMAT_BGRA equ (PNG_FORMAT_BGR|PNG_FORMAT_FLAG_ALPHA) |
||
1472 | PNG_FORMAT_ABGR equ (PNG_FORMAT_BGRA|PNG_FORMAT_FLAG_AFIRST) |
||
1473 | |||
1474 | |||
1475 | ; indicate a luminance (gray) channel. |
||
1476 | |||
1477 | |||
1478 | PNG_FORMAT_LINEAR_Y_ALPHA equ (PNG_FORMAT_FLAG_LINEAR|PNG_FORMAT_FLAG_ALPHA) |
||
1479 | PNG_FORMAT_LINEAR_RGB equ (PNG_FORMAT_FLAG_LINEAR|PNG_FORMAT_FLAG_COLOR) |
||
1480 | PNG_FORMAT_LINEAR_RGB_ALPHA equ\ |
||
1481 | (PNG_FORMAT_FLAG_LINEAR|PNG_FORMAT_FLAG_COLOR|PNG_FORMAT_FLAG_ALPHA) |
||
1482 | |||
1483 | |||
1484 | ; is an index into the color-map which is formatted as above. To obtain a |
||
1485 | ; color-mapped format it is sufficient just to add the PNG_FOMAT_FLAG_COLORMAP |
||
1486 | ; to one of the above definitions, or you can use one of the definitions below. |
||
1487 | |||
1488 | |||
1489 | PNG_FORMAT_BGR_COLORMAP equ (PNG_FORMAT_BGR|PNG_FORMAT_FLAG_COLORMAP) |
||
1490 | PNG_FORMAT_RGBA_COLORMAP equ (PNG_FORMAT_RGBA|PNG_FORMAT_FLAG_COLORMAP) |
||
1491 | PNG_FORMAT_ARGB_COLORMAP equ (PNG_FORMAT_ARGB|PNG_FORMAT_FLAG_COLORMAP) |
||
1492 | PNG_FORMAT_BGRA_COLORMAP equ (PNG_FORMAT_BGRA|PNG_FORMAT_FLAG_COLORMAP) |
||
1493 | PNG_FORMAT_ABGR_COLORMAP equ (PNG_FORMAT_ABGR|PNG_FORMAT_FLAG_COLORMAP) |
||
1494 | |||
1495 | |||
1496 | |||
1497 | |||
1498 | ; structure. The PNG_IMAGE_SAMPLE_ macros return values appropriate to the |
||
1499 | ; actual image sample values - either the entries in the color-map or the |
||
1500 | ; pixels in the image. The PNG_IMAGE_PIXEL_ macros return corresponding values |
||
1501 | ; for the pixels and will always return 1 for color-mapped formats. The |
||
1502 | ; remaining macros return information about the rows in the image and the |
||
1503 | ; complete image. |
||
1504 | |||
1505 | |||
1506 | ; constants if the format parameter is, itself, a constant. Therefore these |
||
1507 | ; macros can be used in array declarations and case labels where required. |
||
1508 | ; Similarly the macros are also pre-processor constants (sizeof is not used) so |
||
1509 | ; they can be used in #if tests. |
||
1510 | |||
1511 | |||
1512 | |||
1513 | |||
1514 | { |
||
1515 | mov eax,fmt |
||
1516 | and eax,PNG_FORMAT_FLAG_COLOR or PNG_FORMAT_FLAG_ALPHA |
||
1517 | inc eax |
||
1518 | } |
||
1519 | ; Return the total number of channels in a given format: 1..4 |
||
1520 | |||
1521 | |||
1522 | ; ((((fmt) & PNG_FORMAT_FLAG_LINEAR) >> 2)+1) |
||
1523 | ; /* Return the size in bytes of a single component of a pixel or color-map |
||
1524 | ; entry (as appropriate) in the image: 1 or 2. |
||
1525 | |||
1526 | |||
1527 | |||
1528 | ; (PNG_IMAGE_SAMPLE_CHANNELS(fmt) * PNG_IMAGE_SAMPLE_COMPONENT_SIZE(fmt)) |
||
1529 | ; /* This is the size of the sample data for one sample. If the image is |
||
1530 | ; color-mapped it is the size of one color-map entry (and image pixels are |
||
1531 | ; one byte in size), otherwise it is the size of one image pixel. |
||
1532 | |||
1533 | |||
1534 | |||
1535 | ; (PNG_IMAGE_SAMPLE_CHANNELS(fmt) * 256) |
||
1536 | ; /* The maximum size of the color-map required by the format expressed in a |
||
1537 | ; count of components. This can be used to compile-time allocate a |
||
1538 | ; color-map: |
||
1539 | |||
1540 | |||
1541 | |||
1542 | |||
1543 | |||
1544 | |||
1545 | ; information from one of the png_image_begin_read_ APIs and dynamically |
||
1546 | ; allocate the required memory. |
||
1547 | |||
1548 | |||
1549 | |||
1550 | macro PNG_IMAGE_PIXEL_ p1,fmt |
||
1551 | { |
||
1552 | local .end0 |
||
1553 | local .end1 |
||
1554 | mov eax,fmt |
||
1555 | and eax,PNG_FORMAT_FLAG_COLORMAP |
||
1556 | cmp eax,0 |
||
1557 | je .end0 |
||
1558 | xor eax,eax |
||
1559 | inc eax |
||
1560 | jmp .end1 |
||
1561 | .end0: |
||
1562 | p1 fmt |
||
1563 | .end1: |
||
1564 | } |
||
1565 | |||
1566 | |||
1567 | { |
||
1568 | PNG_IMAGE_PIXEL_ PNG_IMAGE_SAMPLE_CHANNELS,fmt |
||
1569 | } |
||
1570 | ; The number of separate channels (components) in a pixel; 1 for a |
||
1571 | ; color-mapped image. |
||
1572 | |||
1573 | |||
1574 | |||
1575 | ; PNG_IMAGE_PIXEL_(PNG_IMAGE_SAMPLE_COMPONENT_SIZE,fmt) |
||
1576 | ; /* The size, in bytes, of each component in a pixel; 1 for a color-mapped |
||
1577 | ; image. |
||
1578 | |||
1579 | |||
1580 | |||
1581 | ; /* The size, in bytes, of a complete pixel; 1 for a color-mapped image. */ |
||
1582 | |||
1583 | |||
1584 | ;#define PNG_IMAGE_ROW_STRIDE(image)\ |
||
1585 | ; (PNG_IMAGE_PIXEL_CHANNELS((image).format) * (image).width) |
||
1586 | ; Return the total number of components in a single row of the image; this |
||
1587 | ; is the minimum 'row stride', the minimum count of components between each |
||
1588 | ; row. For a color-mapped image this is the minimum number of bytes in a |
||
1589 | ; row. |
||
1590 | |||
1591 | |||
1592 | ; and very large image widths. libpng will refuse to process an image where |
||
1593 | ; this macro would overflow. |
||
1594 | |||
1595 | |||
1596 | |||
1597 | ; (PNG_IMAGE_PIXEL_COMPONENT_SIZE((image).format)*(image).height*(row_stride)) |
||
1598 | ; Return the size, in bytes, of an image buffer given a png_image and a row |
||
1599 | ; stride - the number of components to leave space for in each row. |
||
1600 | |||
1601 | |||
1602 | ; libpng will refuse to process an image where such an overflow would occur. |
||
1603 | |||
1604 | |||
1605 | |||
1606 | ; PNG_IMAGE_BUFFER_SIZE(image, PNG_IMAGE_ROW_STRIDE(image)) |
||
1607 | ; Return the size, in bytes, of the image in memory given just a png_image; |
||
1608 | ; the row stride is the minimum stride required for the image. |
||
1609 | |||
1610 | |||
1611 | |||
1612 | ; (PNG_IMAGE_SAMPLE_SIZE((image).format) * (image).colormap_entries) |
||
1613 | ; Return the size, in bytes, of the color-map of this image. If the image |
||
1614 | ; format is not a color-map format this will return a size sufficient for |
||
1615 | ; 256 entries in the given format; check PNG_FORMAT_FLAG_COLORMAP if |
||
1616 | ; you don't want to allocate a color-map in this case. |
||
1617 | |||
1618 | |||
1619 | |||
1620 | |||
1621 | |||
1622 | ; 'flags' field of png_image. |
||
1623 | |||
1624 | |||
1625 | ; This indicates the the RGB values of the in-memory bitmap do not |
||
1626 | ; correspond to the red, green and blue end-points defined by sRGB. |
||
1627 | |||
1628 | |||
1629 | ; On write emphasise speed over compression; the resultant PNG file will be |
||
1630 | ; larger but will be produced significantly faster, particular for large |
||
1631 | ; images. Do not use this option for images which will be distributed, only |
||
1632 | ; used it when producing intermediate files that will be read back in |
||
1633 | ; repeatedly. For a typical 24-bit image the option will double the read |
||
1634 | ; speed at the cost of increasing the image size by 25%, however for many |
||
1635 | ; more compressible images the PNG file can be 10 times larger with only a |
||
1636 | ; slight speed gain. |
||
1637 | |||
1638 | |||
1639 | ; On read if the image is a 16-bit per component image and there is no gAMA |
||
1640 | ; or sRGB chunk assume that the components are sRGB encoded. Notice that |
||
1641 | ; images output by the simplified API always have gamma information; setting |
||
1642 | ; this flag only affects the interpretation of 16-bit images from an |
||
1643 | ; external source. It is recommended that the application expose this flag |
||
1644 | ; to the user; the user can normally easily recognize the difference between |
||
1645 | ; linear and sRGB encoding. This flag has no effect on write - the data |
||
1646 | ; passed to the write APIs must have the correct encoding (as defined |
||
1647 | ; above.) |
||
1648 | |||
1649 | |||
1650 | ; assumed to be linear. |
||
1651 | |||
1652 | |||
1653 | ; because that call initializes the 'flags' field. |
||
1654 | |||
1655 | |||
6779 | IgorA | 1656 | ; WRITE APIS |
1657 | ; ---------- |
||
6733 | IgorA | 1658 | ; For write you must initialize a png_image structure to describe the image to |
1659 | ; be written. To do this use memset to set the whole structure to 0 then |
||
1660 | ; initialize fields describing your image. |
||
1661 | |||
1662 | |||
1663 | ; opaque: must be initialized to NULL |
||
1664 | ; width: image width in pixels |
||
1665 | ; height: image height in rows |
||
1666 | ; format: the format of the data (image and color-map) you wish to write |
||
1667 | ; flags: set to 0 unless one of the defined flags applies; set |
||
1668 | ; PNG_IMAGE_FLAG_COLORSPACE_NOT_sRGB for color format images where the RGB |
||
1669 | ; values do not correspond to the colors in sRGB. |
||
1670 | ; colormap_entries: set to the number of entries in the color-map (0 to 256) |
||
1671 | |||
1672 | |||
1673 | ; data then setting convert_to_8_bit will cause the output to be an 8-bit PNG |
||
1674 | ; gamma encoded according to the sRGB specification, otherwise a 16-bit linear |
||
1675 | ; encoded PNG file is written. |
||
1676 | |||
1677 | |||
1678 | ; with at least image->colormap_entries encoded in the specified format. If |
||
1679 | ; the format is linear the written PNG color-map will be converted to sRGB |
||
1680 | ; regardless of the convert_to_8_bit flag. |
||
1681 | |||
1682 | |||
1683 | ; from one row to the next in component sized units (1 or 2 bytes) and if |
||
1684 | ; negative indicates a bottom-up row layout in the buffer. If row_stride is |
||
1685 | ; zero, libpng will calculate it for you from the image width and number of |
||
1686 | ; channels. |
||
1687 | |||
1688 | |||
1689 | ; most ancillary chunks. If you need to write text chunks (e.g. for copyright |
||
1690 | ; notices) you need to use one of the other APIs. |
||
1691 | |||
1692 | |||
1693 | |||
1694 | ; row_stride, colormap)\ |
||
1695 | ; png_image_write_to_memory(&(image), 0, &(size), convert_to_8_bit, buffer,\ |
||
1696 | ; row_stride, colormap) |
||
1697 | ; Return the amount of memory in 'size' required to compress this image. |
||
1698 | ; The png_image structure 'image' must be filled in as in the above |
||
1699 | ; function and must not be changed before the actual write call, the buffer |
||
1700 | ; and all other parameters must also be identical to that in the final |
||
1701 | ; write call. The 'size' variable need not be initialized. |
||
1702 | |||
1703 | |||
1704 | ; set to zero and the write failed and probably will fail if tried again. |
||
1705 | |||
1706 | |||
1707 | ; regardless of the amount of compression achieved. The buffer size will |
||
1708 | ; always be bigger than the original image and it will never be filled. The |
||
1709 | ; following macros are provided to assist in allocating the buffer. |
||
1710 | |||
1711 | |||
1712 | ; The number of uncompressed bytes in the PNG byte encoding of the image; |
||
1713 | ; uncompressing the PNG IDAT data will give this number of bytes. |
||
1714 | |||
1715 | |||
1716 | ; macro can because of the extra bytes used in the PNG byte encoding. You |
||
1717 | ; need to avoid this macro if your image size approaches 2^30 in width or |
||
1718 | ; height. The same goes for the remainder of these macros; they all produce |
||
1719 | ; bigger numbers than the actual in-memory image size. |
||
1720 | |||
1721 | |||
1722 | ;# define PNG_ZLIB_MAX_SIZE(b) ((b)+(((b)+7U)>>3)+(((b)+63U)>>6)+11U) |
||
1723 | ; An upper bound on the number of compressed bytes given 'b' uncompressed |
||
1724 | ; bytes. This is based on deflateBounds() in zlib; different |
||
1725 | ; implementations of zlib compression may conceivably produce more data so |
||
1726 | ; if your zlib implementation is not zlib itself redefine this macro |
||
1727 | ; appropriately. |
||
1728 | |||
1729 | |||
1730 | |||
1731 | |||
1732 | ; PNG_ZLIB_MAX_SIZE((png_alloc_size_t)PNG_IMAGE_DATA_SIZE(image)) |
||
1733 | ; An upper bound on the size of the data in the PNG IDAT chunks. |
||
6779 | IgorA | 1734 | |
1735 | |||
6733 | IgorA | 1736 | ; ((8U/*sig*/+25U/*IHDR*/+16U/*gAMA*/+44U/*cHRM*/+12U/*IEND*/+\ |
1737 | ; (((image).format&PNG_FORMAT_FLAG_COLORMAP)?/*colormap: PLTE, tRNS*/\ |
||
1738 | ; 12U+3U*(image).colormap_entries/*PLTE data*/+\ |
||
1739 | ; (((image).format&PNG_FORMAT_FLAG_ALPHA)?\ |
||
1740 | ; 12U/*tRNS*/+(image).colormap_entries:0U):0U)+\ |
||
1741 | ; 12U)+(12U*((image_size)/PNG_ZBUF_SIZE))/*IDAT*/+(image_size)) |
||
1742 | |||
6779 | IgorA | 1743 | |
1744 | ; following macro use this one with the result of |
||
6733 | IgorA | 1745 | ; PNG_IMAGE_COMPRESSED_SIZE_MAX(image) as the second argument (most |
1746 | ; compilers should handle this just fine.) |
||
1747 | |||
1748 | |||
1749 | ; PNG_IMAGE_PNG_SIZE_MAX_(image, PNG_IMAGE_COMPRESSED_SIZE_MAX(image)) |
||
1750 | ; An upper bound on the total length of the PNG data stream for 'image'. |
||
1751 | ; The result is of type png_alloc_size_t, on 32-bit systems this may |
||
1752 | ; overflow even though PNG_IMAGE_DATA_SIZE does not overflow; the write will |
||
1753 | ; run out of buffer space but return a corrected size which should work. |
||
1754 | |||
1755 | |||
6779 | IgorA | 1756 | ;/******************************************************************************* |
6733 | IgorA | 1757 | ; END OF SIMPLIFIED API |
1758 | ; ******************************************************************************/ |
||
1759 | ;end if /* SIMPLIFIED_{READ|WRITE} */ |
||
1760 | |||
1761 | |||
1762 | ; Section 6: IMPLEMENTATION OPTIONS |
||
1763 | ; ******************************************************************************* |
||
1764 | |||
1765 | |||
1766 | ; particular options to be turned on or off. 'Option' is the number of the |
||
1767 | ; option and 'onoff' is 0 (off) or non-0 (on). The value returned is given |
||
1768 | ; by the PNG_OPTION_ defines below. |
||
1769 | |||
1770 | |||
1771 | ; are detected at run time, however sometimes it may be impossible |
||
1772 | ; to do this in user mode, in which case it is necessary to discover |
||
1773 | ; the capabilities in an OS specific way. Such capabilities are |
||
1774 | ; listed here when libpng has support for them and must be turned |
||
1775 | ; ON by the application if present. |
||
1776 | |||
1777 | |||
1778 | ; decrease on some architectures or systems, or with some sets of |
||
1779 | ; PNG images. 'Software' options allow such optimizations to be |
||
1780 | ; selected at run time. |
||
1781 | |||
1782 | |||
1783 | if PNG_ARM_NEON_API_SUPPORTED eq 1 |
||
1784 | PNG_ARM_NEON equ 0 ;HARDWARE: ARM Neon SIMD instructions supported |
||
1785 | end if |
||
1786 | PNG_MAXIMUM_INFLATE_WINDOW equ 2 ;SOFTWARE: force maximum window |
||
1787 | PNG_SKIP_sRGB_CHECK_PROFILE equ 4 ;SOFTWARE: Check ICC profile for sRGB |
||
1788 | if PNG_MIPS_MSA_API_SUPPORTED eq 1 |
||
1789 | PNG_MIPS_MSA equ 6 ;HARDWARE: MIPS Msa SIMD instructions supported |
||
1790 | end if |
||
1791 | PNG_OPTION_NEXT equ 8 ;Next option - numbers must be even |
||
1792 | |||
1793 | |||
1794 | PNG_OPTION_UNSET equ 0 ;Unset - defaults to off |
||
1795 | PNG_OPTION_INVALID equ 1 ;Option number out of range |
||
1796 | PNG_OPTION_OFF equ 2 |
||
1797 | PNG_OPTION_ON equ 3 |
||
1798 | end if ;SET_OPTION |
||
1799 | |||
1800 | |||
1801 | ; END OF HARDWARE AND SOFTWARE OPTIONS |
||
1802 | ; ******************************************************************************/ |
||
1803 | |||
1804 | |||
1805 | ; defs, and in scripts/symbols.def. |
||
1806 | |||
1807 | |||
1808 | |||
1809 | ; one to use is one more than this.) |
||
1810 | |||
1811 | |||
1812 | ; Do not put anything past this line><>><>><>><>2))><2))>2))><2))> |
||
1813 |