kolibrios/programs/develop/libraries/libs-dev/libimg/png/libpng/png.inc

; png.inc - header file for PNG reference library

; libpng version 1.6.25, September 1, 2016

; Copyright (c) 1998-2002,2004,2006-2016 Glenn Randers-Pehrson
; (Version 0.96 Copyright (c) 1996, 1997 Andreas Dilger)
; (Version 0.88 Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.)

; This code is released under the libpng license (See LICENSE, below)

; Authors and maintainers:
;   libpng versions 0.71, May 1995, through 0.88, January 1996: Guy Schalnat
;   libpng versions 0.89, June 1996, through 0.96, May 1997: Andreas Dilger
;   libpng versions 0.97, January 1998, through 1.6.25, September 1, 2016:
;     Glenn Randers-Pehrson.
;   See also "Contributing Authors", below.



; COPYRIGHT NOTICE, DISCLAIMER, and LICENSE:

; If you modify libpng you may insert additional notices immediately following
; this sentence.

; This code is released under the libpng license.

; Some files in the "contrib" directory and some configure-generated
; files that are distributed with libpng have other copyright owners and
; are released under other open source licenses.

; libpng versions 1.0.7, July 1, 2000 through 1.6.25, September 1, 2016 are
; Copyright (c) 2000-2002, 2004, 2006-2016 Glenn Randers-Pehrson, are
; derived from libpng-1.0.6, and are distributed according to the same
; disclaimer and license as libpng-1.0.6 with the following individuals
; added to the list of Contributing Authors:

;    Simon-Pierre Cadieux
;    Eric S. Raymond
;    Mans Rullgard
;    Cosmin Truta
;    Gilles Vollant
;    James Yu
;    Mandar Sahastrabuddhe

; and with the following additions to the disclaimer:

;    There is no warranty against interference with your enjoyment of the
;    library or against infringement.  There is no warranty that our
;    efforts or the library will fulfill any of your particular purposes
;    or needs.  This library is provided with all faults, and the entire
;    risk of satisfactory quality, performance, accuracy, and effort is with
;    the user.

; Some files in the "contrib" directory have other copyright owners and
; are released under other open source licenses.


; libpng versions 0.97, January 1998, through 1.0.6, March 20, 2000, are
; Copyright (c) 1998-2000 Glenn Randers-Pehrson, are derived from
; libpng-0.96, and are distributed according to the same disclaimer and
; license as libpng-0.96, with the following individuals added to the list
; of Contributing Authors:

;    Tom Lane
;    Glenn Randers-Pehrson
;    Willem van Schaik

; Some files in the "scripts" directory have different copyright owners
; but are also released under this license.

; libpng versions 0.89, June 1996, through 0.96, May 1997, are
; Copyright (c) 1996-1997 Andreas Dilger, are derived from libpng-0.88,
; and are distributed according to the same disclaimer and license as
; libpng-0.88, with the following individuals added to the list of
; Contributing Authors:

;    John Bowler
;    Kevin Bracey
;    Sam Bushell
;    Magnus Holmgren
;    Greg Roelofs
;    Tom Tanner

; Some files in the "scripts" directory have other copyright owners
; but are released under this license.

; libpng versions 0.5, May 1995, through 0.88, January 1996, are
; Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc.

; For the purposes of this copyright and license, "Contributing Authors"
; is defined as the following set of individuals:

;    Andreas Dilger
;    Dave Martindale
;    Guy Eric Schalnat
;    Paul Schmidt
;    Tim Wegner

; The PNG Reference Library is supplied "AS IS".  The Contributing Authors
; and Group 42, Inc. disclaim all warranties, expressed or implied,
; including, without limitation, the warranties of merchantability and of
; fitness for any purpose.  The Contributing Authors and Group 42, Inc.
; assume no liability for direct, indirect, incidental, special, exemplary,
; or consequential damages, which may result from the use of the PNG
; Reference Library, even if advised of the possibility of such damage.

; Permission is hereby granted to use, copy, modify, and distribute this
; source code, or portions hereof, for any purpose, without fee, subject
; to the following restrictions:

;   1. The origin of this source code must not be misrepresented.

;   2. Altered versions must be plainly marked as such and must not
;      be misrepresented as being the original source.

;   3. This Copyright notice may not be removed or altered from any
;      source or altered source distribution.

; The Contributing Authors and Group 42, Inc. specifically permit, without
; fee, and encourage the use of this source code as a component to
; supporting the PNG file format in commercial products.  If you use this
; source code in a product, acknowledgment is not required but would be
; appreciated.

; END OF COPYRIGHT NOTICE, DISCLAIMER, and LICENSE.

; TRADEMARK:

; The name "libpng" has not been registered by the Copyright owner
; as a trademark in any jurisdiction.  However, because libpng has
; been distributed and maintained world-wide, continually since 1995,
; the Copyright owner claims "common-law trademark protection" in any
; jurisdiction where common-law trademark is recognized.

; OSI CERTIFICATION:

; Libpng is OSI Certified Open Source Software.  OSI Certified Open Source is
; a certification mark of the Open Source Initiative. OSI has not addressed
; the additional disclaimers inserted at version 1.0.7.

; EXPORT CONTROL:

; The Copyright owner believes that the Export Control Classification
; Number (ECCN) for libpng is EAR99, which means not subject to export
; controls or International Traffic in Arms Regulations (ITAR) because
; it is open source, publicly available software, that does not contain
; any encryption software.  See the EAR, paragraphs 734.3(b)(3) and
; 734.7(b).



; A "png_get_copyright" function is available, for convenient use in "about"
; boxes and the like:

;    printf("%s", png_get_copyright(NULL));

; Also, the PNG logo (in PNG format, of course) is supplied in the
; files "pngbar.png" and "pngbar.jpg (88x31) and "pngnow.png" (98x31).



; The contributing authors would like to thank all those who helped
; with testing, bug fixes, and patience.  This wouldn't have been
; possible without all of you.

; Thanks to Frank J. T. Wojcik for helping with the documentation.

;
; Note about libpng version numbers:
;
;    Due to various miscommunications, unforeseen code incompatibilities
;    and occasional factors outside the authors' control, version numbering
;    on the library has not always been consistent and straightforward.
;    The following table summarizes matters since version 0.89c, which was
;    the first widely used release:
;
;    source                 png.h  png.h  shared-lib
;    version                string   int  version
;    -------                ------ -----  ----------
;    ...
;    1.2.56                  13    10256  12.so.0.56[.0]
;    ...
;    1.5.27                  15    10527  15.so.15.27[.0]
;    ...
;    1.6.25                  16    10625  16.so.16.25[.0]

;    Henceforth the source version will match the shared-library major
;    and minor numbers; the shared-library major version number will be
;    used for changes in backward compatibility, as it is intended.  The
;    PNG_LIBPNG_VER macro, which is not used within libpng but is available
;    for applications, is an unsigned integer of the form xyyzz corresponding
;    to the source version x.y.z (leading zeros in y and z).  Beta versions
;    were given the previous public release number plus a letter, until
;    version 1.0.6j; from then on they were given the upcoming public
;    release number plus "betaNN" or "rcNN".

;    Binary incompatibility exists only when applications make direct access
;    to the info_ptr or png_ptr members through png.h, and the compiled
;    application is loaded with a different version of the library.

;    DLLNUM will change each time there are forward or backward changes
;    in binary compatibility (e.g., when a new feature is added).

; See libpng.txt or libpng.3 for more information.  The PNG specification
; is available as a W3C Recommendation and as an ISO Specification,
; <http://www.w3.org/TR/2003/REC-PNG-20031110/



; Y2K compliance in libpng:
; =========================

;    September 1, 2016

;    Since the PNG Development group is an ad-hoc body, we can't make
;    an official declaration.

;    This is your unofficial assurance that libpng from version 0.71 and
;    upward through 1.6.25 are Y2K compliant.  It is my belief that
;    earlier versions were also Y2K compliant.

;    Libpng only has two year fields.  One is a 2-byte unsigned integer
;    that will hold years up to 65535.  The other, which is deprecated,
;    holds the date in text format, and will hold years up to 9999.

;    The integer is
;        "uint_16 year" in png_time_struct.

;    The string is
;        "char time_buffer[29]" in png_struct.  This is no longer used
;    in libpng-1.6.x and will be removed from libpng-1.7.0.

;    There are seven time-related functions:
;        png.asm: png_convert_to_rfc_1123_buffer() in png.asm
;          (formerly png_convert_to_rfc_1123() prior to libpng-1.5.x and
;          png_convert_to_rfc_1152() in error prior to libpng-0.98)
;        png_convert_from_struct_tm() in pngwrite.asm, called in pngwrite.asm
;        png_convert_from_time_t() in pngwrite.asm
;        png_get_tIME() in pngget.asm
;        png_handle_tIME() in pngrutil.asm, called in pngread.asm
;        png_set_tIME() in pngset.asm
;        png_write_tIME() in pngwutil.asm, called in pngwrite.asm

;    All handle dates properly in a Y2K environment.  The
;    png_convert_from_time_t() function calls gmtime() to convert from system
;    clock time, which returns (year - 1900), which we properly convert to
;    the full 4-digit year.  There is a possibility that libpng applications
;    are not passing 4-digit years into the png_convert_to_rfc_1123_buffer()
;    function, or that they are incorrectly passing only a 2-digit year
;    instead of "year - 1900" into the png_convert_from_struct_tm() function,
;    but this is not under our control.  The libpng documentation has always
;    stated that it works with 4-digit years, and the APIs have been
;    documented as such.

;    The tIME chunk itself is also Y2K compliant.  It uses a 2-byte unsigned
;    integer to hold the year, and can hold years as large as 65535.

;    zlib, upon which libpng depends, is also Y2K compliant.  It contains
;    no date-related code.

;       Glenn Randers-Pehrson
;       libpng maintainer
;       PNG Development Group


; This is not the place to learn how to use libpng. The file libpng-manual.txt
; describes how to use libpng, and the file example.c summarizes it
; with some code on which to build.  This file is useful for looking
; at the actual function definitions and structure components.  If that
; file has been stripped from your copy of libpng, you can find it at
; <http://www.libpng.org/pub/png/libpng-manual.txt>

; If you just need to read a PNG file and don't want to read the documentation
; skip to the end of this file and read the section entitled 'simplified API'.


; Version information for png.h - this should match the version in png.asm
PNG_LIBPNG_VER_STRING db '1.6.25',0
PNG_HEADER_VERSION_STRING db ' libpng version 1.6.25 - September 1, 2016',13,10,0

PNG_LIBPNG_VER_SONUM  equ 16
PNG_LIBPNG_VER_DLLNUM equ 16

; These should match the first 3 components of PNG_LIBPNG_VER_STRING:
PNG_LIBPNG_VER_MAJOR  equ 1
PNG_LIBPNG_VER_MINOR  equ 6
PNG_LIBPNG_VER_RELEASE equ 25

; This should match the numeric part of the final component of
; PNG_LIBPNG_VER_STRING, omitting any leading zero:


PNG_LIBPNG_VER_BUILD equ 0

; Release Status
PNG_LIBPNG_BUILD_ALPHA   equ 1
PNG_LIBPNG_BUILD_BETA    equ 2
PNG_LIBPNG_BUILD_RC      equ 3
PNG_LIBPNG_BUILD_STABLE  equ 4
PNG_LIBPNG_BUILD_RELEASE_STATUS_MASK equ 7

; Release-Specific Flags
PNG_LIBPNG_BUILD_PATCH   equ  8 ;Can be OR'ed with PNG_LIBPNG_BUILD_STABLE only
PNG_LIBPNG_BUILD_PRIVATE equ 16 ;Cannot be OR'ed with PNG_LIBPNG_BUILD_SPECIAL
PNG_LIBPNG_BUILD_SPECIAL equ 32 ;Cannot be OR'ed with PNG_LIBPNG_BUILD_PRIVATE

PNG_LIBPNG_BUILD_BASE_TYPE equ PNG_LIBPNG_BUILD_STABLE

; Careful here.  At one time, Guy wanted to use 082, but that would be octal.
; We must not include leading zeros.
; Versions 0.7 through 1.0.0 were in the range 0 to 100 here (only
; version 1.0.0 was mis-numbered 100 instead of 10000).  From
; version 1.0.1 it's    xxyyzz, where x=major, y=minor, z=release

PNG_LIBPNG_VER equ 10625 ;1.6.25

; Library configuration: these options cannot be changed after
; the library has been built.


; Added at libpng-1.2.8

; Ref MSDN: Private as priority over Special
; VS_FF_PRIVATEBUILD File *was not* built using standard release
; procedures. If this value is given, the StringFileInfo block must
; contain a PrivateBuild string.

; VS_FF_SPECIALBUILD File *was* built by the original company using
; standard release procedures but is a variation of the standard
; file of the same version number. If this value is given, the
; StringFileInfo block must contain a SpecialBuild string.

;if PNG_USER_PRIVATEBUILD /* From pnglibconf.h */
;#  define PNG_LIBPNG_BUILD_TYPE \
;       (PNG_LIBPNG_BUILD_BASE_TYPE | PNG_LIBPNG_BUILD_PRIVATE)
;#else
;#  ifdef PNG_LIBPNG_SPECIALBUILD
;#    define PNG_LIBPNG_BUILD_TYPE \
;         (PNG_LIBPNG_BUILD_BASE_TYPE | PNG_LIBPNG_BUILD_SPECIAL)
;#  else
;#    define PNG_LIBPNG_BUILD_TYPE (PNG_LIBPNG_BUILD_BASE_TYPE)
;#  endif
;end if

;#ifndef PNG_VERSION_INFO_ONLY

; Version information for C files, stored in png.asm.  This had better match
; the version above.

;#define png_libpng_ver png_get_header_ver(NULL)

; This file is arranged in several sections:

; 1. [omitted]
; 2. Any configuration options that can be specified by for the application
;    code when it is built.  (Build time configuration is in pnglibconf.h)
; 3. Type definitions (base types are defined in pngconf.h), structure
;    definitions.
; 4. Exported library functions.
; 5. Simplified API.
; 6. Implementation options.

; The library source code has additional files (principally pngpriv.h) that
; allow configuration of the library.


; Section 1: [omitted]

; Section 2: run time configuration
; See pnglibconf.h for build time configuration

; Run time configuration allows the application to choose between
; implementations of certain arithmetic APIs.  The default is set
; at build time and recorded in pnglibconf.h, but it is safe to
; override these (and only these) settings.  Note that this won't
; change what the library does, only application code, and the
; settings can (and probably should) be made on a per-file basis
; by setting the #defines before including png.h

; Use macros to read integers from PNG data or use the exported
; functions?
;   PNG_USE_READ_MACROS: use the macros (see below)  Note that
;     the macros evaluate their argument multiple times.
;   PNG_NO_USE_READ_MACROS: call the relevant library function.

; Use the alternative algorithm for compositing alpha samples that
; does not use division?
;   PNG_READ_COMPOSITE_NODIV_SUPPORTED: use the 'no division'
;      algorithm.
;   PNG_NO_READ_COMPOSITE_NODIV: use the 'division' algorithm.

; How to handle benign errors if PNG_ALLOW_BENIGN_ERRORS is
; false?
;   PNG_ALLOW_BENIGN_ERRORS: map calls to the benign error
;      APIs to png_warning.
; Otherwise the calls are mapped to png_error.


; Section 3: type definitions, including structures and compile time
; constants.
; See pngconf.h for base types that vary by machine/system


; This triggers a compiler error in png.c, if png.c and png.h
; do not agree upon the version number.

;typedef char* png_libpng_version_1_6_25;

; Basic control structions.  Read libpng-manual.txt or libpng.3 for more info.

; png_struct is the cache of information used while reading or writing a single
; PNG file.  One of these is always required, although the simplified API
; (below) hides the creation and destruction of it.

; png_info contains information read from or to be written to a PNG file.  One
; or more of these must exist while reading or creating a PNG file.  The
; information is not used by libpng during read but is used to control what
; gets written when a PNG file is created.  "png_get_" function calls read
; information during read and "png_set_" functions calls write information
; when creating a PNG.
; been moved into a separate header file that is not accessible to
; applications.  Read libpng-manual.txt or libpng.3 for more info.

; Types with names ending 'p' are pointer types.  The corresponding types with
; names ending 'rp' are identical pointer types except that the pointer is
; marked 'restrict', which means that it is the only pointer to the object
; passed to the function.  Applications should not use the 'restrict' types;
; it is always valid to pass 'p' to a pointer with a function argument of the
; corresponding 'rp' type.  Different compilers have different rules with
; regard to type matching in the presence of 'restrict'.  For backward
; compatibility libpng callbacks never have 'restrict' in their parameters and,
; consequentially, writing portable application code is extremely difficult if
; an attempt is made to use 'restrict'.

; Three color definitions.  The order of the red, green, and blue, (and the
; exact size) is not important, although the size of the fields need to
; be byte or uint_16 (as defined below).

struct png_color
	red   db ? ;byte
	green db ? ;byte
	blue  db ? ;byte
ends

struct png_color_16
	index db ? ;byte ;used for palette files
	red   dw ? ;uint_16 ;for use in red green blue files
	green dw ? ;uint_16
	blue  dw ? ;uint_16
	gray  dw ? ;uint_16 ;for use in grayscale files
ends

struct png_color_8
	red   db ? ;byte ;for use in red green blue files
	green db ? ;byte
	blue  db ? ;byte
	gray  db ? ;byte ;for use in grayscale files
	alpha db ? ;byte ;for alpha channel files
ends


; The following two structures are used for the in-core representation
; of sPLT chunks.

struct png_sPLT_entry
	red   dw ? ;uint_16
	green dw ? ;uint_16
	blue  dw ? ;uint_16
	alpha dw ? ;uint_16
	frequency dw ? ;uint_16
ends

; When the depth of the sPLT palette is 8 bits, the color and alpha samples
; occupy the LSB of their respective members, and the MSB of each member
; is zero-filled.  The frequency member always occupies the full 16 bits.


struct png_sPLT_t
	name    dd ? ;charp ;palette name
	depth   db ? ;byte ;depth of palette samples
	entries dd ? ;png_sPLT_entryp ;palette entries
	nentries dd ? ;int_32 ;number of palette entries
ends

if PNG_TEXT_SUPPORTED eq 1
; png_text holds the contents of a text/ztxt/itxt chunk in a PNG file,
; and whether that contents is compressed or not.  The "key" field
; points to a regular zero-terminated C string.  The "text" fields can be a
; regular C string, an empty string, or a NULL pointer.
; However, the structure returned by png_get_text() will always contain
; the "text" field as a regular zero-terminated C string (possibly
; empty), never a NULL pointer, so it can be safely used in printf() and
; other string-handling functions.  Note that the "itxt_length", "lang", and
; "lang_key" members of the structure only exist when the library is built
; with iTXt chunk support.  Prior to libpng-1.4.0 the library was built by
; default without iTXt support. Also note that when iTXt *is* supported,
; the "lang" and "lang_key" fields contain NULL pointers when the
; "compression" field contains * PNG_TEXT_COMPRESSION_NONE or
; PNG_TEXT_COMPRESSION_zTXt. Note that the "compression value" is not the
; same as what appears in the PNG tEXt/zTXt/iTXt chunk's "compression flag"
; which is always 0 or 1, or its "compression method" which is always 0.

struct png_text
	compression dd ? ;int ;compression value:
			;-1: tEXt, none
			; 0: zTXt, deflate
			; 1: iTXt, none
			; 2: iTXt, deflate
	key  dd ? ;charp ;keyword, 1-79 character description of "text"
	text dd ? ;charp ;comment, may be an empty string (ie "")
			; or a NULL pointer
	text_length dd ? ;png_size_t ;length of the text string
	itxt_length dd ? ;png_size_t ;length of the itxt string
	lang dd ? ;charp ;language code, 0-79 characters
			; or a NULL pointer
	lang_key dd ? ;charp ;keyword translated UTF-8 string, 0 or more
			; chars or a NULL pointer
ends
end if

; Supported compression types for text in PNG files (tEXt, and zTXt).
; The values of the PNG_TEXT_COMPRESSION_ defines should NOT be changed.
PNG_TEXT_COMPRESSION_NONE_WR equ -3
PNG_TEXT_COMPRESSION_zTXt_WR equ -2
PNG_TEXT_COMPRESSION_NONE    equ -1
PNG_TEXT_COMPRESSION_zTXt    equ 0
PNG_ITXT_COMPRESSION_NONE    equ 1
PNG_ITXT_COMPRESSION_zTXt    equ 2
PNG_TEXT_COMPRESSION_LAST    equ 3 ;Not a valid value

; png_time is a way to hold the time in an machine independent way.
; Two conversions are provided, both from time_t and struct tm.  There
; is no portable way to convert to either of these structures, as far
; as I know.  If you know of a portable way, send it to me.  As a side
; note - PNG has always been Year 2000 compliant!

struct png_time
	year  dw ? ;uint_16 ;full year, as in, 1995
	month db ? ;byte ;month of year, 1 - 12
	day   db ? ;byte ;day of month, 1 - 31
	hour  db ? ;byte ;hour of day, 0 - 23
	minute db ? ;byte ;minute of hour, 0 - 59
	second db ? ;byte ;second of minute, 0 - 60 (for leap seconds)
ends

if (PNG_STORE_UNKNOWN_CHUNKS_SUPPORTED eq 1) | (PNG_USER_CHUNKS_SUPPORTED eq 1)
; png_unknown_chunk is a structure to hold queued chunks for which there is
; no specific support.  The idea is that we can use this to queue
; up private chunks for output even though the library doesn't actually
; know about their semantics.

; The data in the structure is set by libpng on read and used on write.

struct png_unknown_chunk
	name rb 5 ;byte[5] ;Textual chunk name with '\0' terminator
	rb 3 ;align
	podata dd ? ;byte* ;Data, should not be modified on read!
	size dd ? ;png_size_t

	; On write 'location' must be set using the flag values listed below.
	; Notice that on read it is set by libpng however the values stored have
	; more bits set than are listed below.  Always treat the value as a
	; bitmask.  On write set only one bit - setting multiple bits may cause the
	; chunk to be written in multiple places.

	location db ? ;byte ;mode of operation at read time
ends
end if

; Flag values for the unknown chunk location byte.
PNG_HAVE_IHDR equ  0x01
PNG_HAVE_PLTE equ  0x02
PNG_AFTER_IDAT equ 0x08

; Maximum positive integer used in PNG is (2^31)-1
PNG_UINT_31_MAX equ 0x7fffffff ;uint_32
PNG_UINT_32_MAX equ -1 ;uint_32
PNG_SIZE_MAX    equ 0x60000000 ;1.5 Gb

; These are constants for fixed point values encoded in the
; PNG specification manner (x100000)

PNG_FP_1   equ 100000
PNG_FP_HALF equ 50000
PNG_FP_MAX equ ((png_fixed_point)0x7fffffffL)
PNG_FP_MIN equ (-PNG_FP_MAX)

; These describe the color_type field in png_info.
; color type masks
PNG_COLOR_MASK_PALETTE equ 1
PNG_COLOR_MASK_COLOR   equ 2
PNG_COLOR_MASK_ALPHA   equ 4

; color types.  Note that not all combinations are legal
PNG_COLOR_TYPE_GRAY equ 0
PNG_COLOR_TYPE_PALETTE equ (PNG_COLOR_MASK_COLOR or PNG_COLOR_MASK_PALETTE)
PNG_COLOR_TYPE_RGB      equ (PNG_COLOR_MASK_COLOR)
PNG_COLOR_TYPE_RGB_ALPHA equ (PNG_COLOR_MASK_COLOR or PNG_COLOR_MASK_ALPHA)
PNG_COLOR_TYPE_GRAY_ALPHA equ (PNG_COLOR_MASK_ALPHA)
; aliases
PNG_COLOR_TYPE_RGBA equ PNG_COLOR_TYPE_RGB_ALPHA
PNG_COLOR_TYPE_GA equ PNG_COLOR_TYPE_GRAY_ALPHA

; This is for compression type. PNG 1.0-1.2 only define the single type.
PNG_COMPRESSION_TYPE_BASE equ 0 ;Deflate method 8, 32K window
PNG_COMPRESSION_TYPE_DEFAULT equ PNG_COMPRESSION_TYPE_BASE

; This is for filter type. PNG 1.0-1.2 only define the single type.
PNG_FILTER_TYPE_BASE     equ 0 ;Single row per-byte filtering
PNG_INTRAPIXEL_DIFFERENCING equ 64 ;Used only in MNG datastreams
PNG_FILTER_TYPE_DEFAULT  equ PNG_FILTER_TYPE_BASE

; These are for the interlacing type.  These values should NOT be changed.
PNG_INTERLACE_NONE       equ 0 ;Non-interlaced image
PNG_INTERLACE_ADAM7      equ 1 ;Adam7 interlacing
PNG_INTERLACE_LAST       equ 2 ;Not a valid value

; These are for the oFFs chunk.  These values should NOT be changed.
PNG_OFFSET_PIXEL         equ 0 ;Offset in pixels
PNG_OFFSET_MICROMETER    equ 1 ;Offset in micrometers (1/10^6 meter)
PNG_OFFSET_LAST          equ 2 ;Not a valid value

; These are for the pCAL chunk.  These values should NOT be changed.
PNG_EQUATION_LINEAR      equ 0 ;Linear transformation
PNG_EQUATION_BASE_E      equ 1 ;Exponential base e transform
PNG_EQUATION_ARBITRARY   equ 2 ;Arbitrary base exponential transform
PNG_EQUATION_HYPERBOLIC  equ 3 ;Hyperbolic sine transformation
PNG_EQUATION_LAST        equ 4 ;Not a valid value

; These are for the sCAL chunk.  These values should NOT be changed.
PNG_SCALE_UNKNOWN        equ 0 ;unknown unit (image scale)
PNG_SCALE_METER          equ 1 ;meters per pixel
PNG_SCALE_RADIAN         equ 2 ;radians per pixel
PNG_SCALE_LAST           equ 3 ;Not a valid value

; These are for the pHYs chunk.  These values should NOT be changed.
PNG_RESOLUTION_UNKNOWN   equ 0 ;pixels/unknown unit (aspect ratio)
PNG_RESOLUTION_METER     equ 1 ;pixels/meter
PNG_RESOLUTION_LAST      equ 2 ;Not a valid value

; These are for the sRGB chunk.  These values should NOT be changed.
PNG_sRGB_INTENT_PERCEPTUAL equ 0
PNG_sRGB_INTENT_RELATIVE   equ 1
PNG_sRGB_INTENT_SATURATION equ 2
PNG_sRGB_INTENT_ABSOLUTE   equ 3
PNG_sRGB_INTENT_LAST       equ 4 ;Not a valid value

; This is for text chunks
PNG_KEYWORD_MAX_LENGTH equ 79

; Maximum number of entries in PLTE/sPLT/tRNS arrays
PNG_MAX_PALETTE_LENGTH equ 256

; These determine if an ancillary chunk's data has been successfully read
; from the PNG header, or if the application has filled in the corresponding
; data in the info_struct to be written into the output file.  The values
; of the PNG_INFO_<chunk> defines should NOT be changed.

PNG_INFO_gAMA equ 0x0001
PNG_INFO_sBIT equ 0x0002
PNG_INFO_cHRM equ 0x0004
PNG_INFO_PLTE equ 0x0008
PNG_INFO_tRNS equ 0x0010
PNG_INFO_bKGD equ 0x0020
PNG_INFO_hIST equ 0x0040
PNG_INFO_pHYs equ 0x0080
PNG_INFO_oFFs equ 0x0100
PNG_INFO_tIME equ 0x0200
PNG_INFO_pCAL equ 0x0400
PNG_INFO_sRGB equ 0x0800 ; GR-P, 0.96a
PNG_INFO_iCCP equ 0x1000 ; ESR, 1.0.6
PNG_INFO_sPLT equ 0x2000 ; ESR, 1.0.6
PNG_INFO_sCAL equ 0x4000 ; ESR, 1.0.6
PNG_INFO_IDAT equ 0x8000 ; ESR, 1.0.6

; This is used for the transformation routines, as some of them
; change these values for the row.  It also should enable using
; the routines for other purposes.

struct png_row_info ;png_row_info_struct
	width      dd ? ;uint_32 ;width of row
	rowbytes   dd ? ;png_size_t ;number of bytes in row
	color_type db ? ;byte ;color type of row
	bit_depth  db ? ;byte ;bit depth of row
	channels   db ? ;byte ;number of channels (1, 2, 3, or 4)
	pixel_depth db ? ;byte ;bits per pixel (depth * channels)
ends

if PNG_SETJMP_SUPPORTED eq 1
; This must match the function definition in <setjmp.h>, and the application
; must include this before png.h to obtain the definition of jmp_buf.  The
; function is required to be PNG_NORETURN, but this is not checked.  If the
; function does return the application will crash via an abort() or similar
; system level call.

; If you get a warning here while building the library you may need to make
; changes to ensure that pnglibconf.h records the calling convention used by
; your compiler.  This may be very difficult - try using a different compiler
; to build the library!

;PNG_FUNCTION(void, (PNGCAPI *png_longjmp_ptr), PNGARG((jmp_buf, int)), typedef);
end if

; Transform masks for the high-level interface
PNG_TRANSFORM_IDENTITY      equ 0x0000 ; read and write
PNG_TRANSFORM_STRIP_16      equ 0x0001 ; read only
PNG_TRANSFORM_STRIP_ALPHA   equ 0x0002 ; read only
PNG_TRANSFORM_PACKING       equ 0x0004 ; read and write
PNG_TRANSFORM_PACKSWAP      equ 0x0008 ; read and write
PNG_TRANSFORM_EXPAND        equ 0x0010 ; read only
PNG_TRANSFORM_INVERT_MONO   equ 0x0020 ; read and write
PNG_TRANSFORM_SHIFT         equ 0x0040 ; read and write
PNG_TRANSFORM_BGR           equ 0x0080 ; read and write
PNG_TRANSFORM_SWAP_ALPHA    equ 0x0100 ; read and write
PNG_TRANSFORM_SWAP_ENDIAN   equ 0x0200 ; read and write
PNG_TRANSFORM_INVERT_ALPHA  equ 0x0400 ; read and write
PNG_TRANSFORM_STRIP_FILLER  equ 0x0800 ; write only
; Added to libpng-1.2.34
PNG_TRANSFORM_STRIP_FILLER_BEFORE equ PNG_TRANSFORM_STRIP_FILLER
PNG_TRANSFORM_STRIP_FILLER_AFTER equ 0x1000 ; write only
; Added to libpng-1.4.0
PNG_TRANSFORM_GRAY_TO_RGB  equ 0x2000 ; read only
; Added to libpng-1.5.4
PNG_TRANSFORM_EXPAND_16    equ 0x4000 ;read only
;if INT_MAX >= 0x8000 ;else this might break
PNG_TRANSFORM_SCALE_16     equ 0x8000 ;read only
;end if

; Flags for MNG supported features
PNG_FLAG_MNG_EMPTY_PLTE    equ 0x01
PNG_FLAG_MNG_FILTER_64     equ 0x04
PNG_ALL_MNG_FEATURES       equ 0x05

; NOTE: prior to 1.5 these functions had no 'API' style declaration,
; this allowed the zlib default functions to be used on Windows
; platforms.  In 1.5 the zlib default malloc (which just calls malloc and
; ignores the first argument) should be completely compatible with the
; following.

; Section 4: exported functions
; Here are the function definitions most commonly used.  This is not
; the place to find out how to use libpng.  See libpng-manual.txt for the
; full explanation, see example.c for the summary.  This just provides
; a simple one line description of the use of each function.



; Simple signature checking function.  This is the same as calling
; png_check_sig(sig, n) := !png_sig_cmp(sig, 0, n).

;#define png_check_sig(sig, n) !png_sig_cmp((sig), 0, (n))

macro png_setup_abs sum
{
local .end0
	and eax,0xff
if PNG_USE_ABS eq 1
	add sum,128
	sub al,128 ;v - 128
	cmp al,128
	jl @f
		neg al
		inc al ;abs(v - 128)
	@@:
	sub sum,eax
else
	cmp eax,128
	jl @f
		add sum,256
		sub sum,eax
		jmp .end0
	@@:
		add sum,eax
	.end0:
end if
}

; Reduce RGB to grayscale.
PNG_ERROR_ACTION_NONE equ 1
PNG_ERROR_ACTION_WARN equ 2
PNG_ERROR_ACTION_ERROR equ 3
PNG_RGB_TO_GRAY_DEFAULT equ (-1) ;for red/green coefficients

; How the alpha channel is interpreted - this affects how the color channels
; of a PNG file are returned to the calling application when an alpha channel,
; or a tRNS chunk in a palette file, is present.

; This has no effect on the way pixels are written into a PNG output
; datastream. The color samples in a PNG datastream are never premultiplied
; with the alpha samples.

; The default is to return data according to the PNG specification: the alpha
; channel is a linear measure of the contribution of the pixel to the
; corresponding composited pixel, and the color channels are unassociated
; (not premultiplied).  The gamma encoded color channels must be scaled
; according to the contribution and to do this it is necessary to undo
; the encoding, scale the color values, perform the composition and reencode
; the values.  This is the 'PNG' mode.

; The alternative is to 'associate' the alpha with the color information by
; storing color channel values that have been scaled by the alpha.
; image.  These are the 'STANDARD', 'ASSOCIATED' or 'PREMULTIPLIED' modes
; (the latter being the two common names for associated alpha color channels).

; For the 'OPTIMIZED' mode, a pixel is treated as opaque only if the alpha
; value is equal to the maximum value.

; The final choice is to gamma encode the alpha channel as well.  This is
; broken because, in practice, no implementation that uses this choice
; correctly undoes the encoding before handling alpha composition.  Use this
; choice only if other serious errors in the software or hardware you use
; mandate it; the typical serious error is for dark halos to appear around
; opaque areas of the composited PNG image because of arithmetic overflow.

; The API function png_set_alpha_mode specifies which of these choices to use
; with an enumerated 'mode' value and the gamma of the required output:

PNG_ALPHA_PNG          equ 0 ;according to the PNG standard
PNG_ALPHA_STANDARD     equ 1 ;according to Porter/Duff
PNG_ALPHA_ASSOCIATED   equ 1 ;as above; this is the normal practice
PNG_ALPHA_PREMULTIPLIED equ 1 ;as above
PNG_ALPHA_OPTIMIZED    equ 2 ;'PNG' for opaque pixels, else 'STANDARD'
PNG_ALPHA_BROKEN       equ 3 ;the alpha channel is gamma encoded

if (PNG_GAMMA_SUPPORTED eq 1) | (PNG_READ_ALPHA_MODE_SUPPORTED eq 1)
; The output_gamma value is a screen gamma in libpng terminology: it expresses
; how to decode the output values, not how they are encoded.

PNG_DEFAULT_sRGB equ -1       ;sRGB gamma and color space
PNG_GAMMA_MAC_18 equ -2       ;Old Mac '1.8' gamma and color space
PNG_GAMMA_sRGB   equ 220000   ;Television standards--matches sRGB gamma
PNG_GAMMA_LINEAR equ PNG_FP_1 ;Linear
end if

; The values of the PNG_FILLER_ defines should NOT be changed
PNG_FILLER_BEFORE equ 0
PNG_FILLER_AFTER equ 1

;#if defined(PNG_READ_INVERT_SUPPORTED) || defined(PNG_WRITE_INVERT_SUPPORTED)

; Handle alpha and tRNS by replacing with a background color.  Prior to
; libpng-1.5.4 this API must not be called before the PNG file header has been
; read.  Doing so will result in unexpected behavior and possible warnings or
; errors if the PNG file contains a bKGD chunk.

if PNG_READ_BACKGROUND_SUPPORTED eq 1
PNG_BACKGROUND_GAMMA_UNKNOWN equ 0
PNG_BACKGROUND_GAMMA_SCREEN equ 1
PNG_BACKGROUND_GAMMA_FILE   equ 2
PNG_BACKGROUND_GAMMA_UNIQUE equ 3
end if

;PNG_READ_16_TO_8_SUPPORTED equ 1 ;Name prior to 1.5.4

; The threshold on gamma processing is configurable but hard-wired into the
; library.  The following is the floating point variant.

PNG_GAMMA_THRESHOLD equ (PNG_GAMMA_THRESHOLD_FIXED*.00001)

; Handle gamma correction. Screen_gamma=(display_exponent).
; NOTE: this API simply sets the screen and file gamma values. It will
; therefore override the value for gamma in a PNG file if it is called after
; the file header has been read - use with care  - call before reading the PNG
; file for best results!


; Values for png_set_crc_action() say how to handle CRC errors in
; ancillary and critical chunks, and whether to use the data contained
; therein.  Note that it is impossible to "discard" data in a critical
; chunk.  For versions prior to 0.90, the action was always error/quit,
; whereas in version 0.90 and later, the action for CRC errors in ancillary
; chunks is warn/discard.  These values should NOT be changed.

;      value                       action:critical     action:ancillary

PNG_CRC_DEFAULT      equ 0 ;error/quit          warn/discard data
PNG_CRC_ERROR_QUIT   equ 1 ;error/quit          error/quit
PNG_CRC_WARN_DISCARD equ 2 ;(INVALID)           warn/discard data
PNG_CRC_WARN_USE     equ 3 ;warn/use data       warn/use data
PNG_CRC_QUIET_USE    equ 4 ;quiet/use data      quiet/use data
PNG_CRC_NO_CHANGE    equ 5 ;use current value   use current value

; Flags for png_set_filter() to say which filters to use.  The flags
; are chosen so that they don't conflict with real filter types
; below, in case they are supplied instead of the #defined constants.
; These values should NOT be changed.

PNG_NO_FILTERS   equ 0x00
PNG_FILTER_NONE  equ 0x08
PNG_FILTER_SUB   equ 0x10
PNG_FILTER_UP    equ 0x20
PNG_FILTER_AVG   equ 0x40
PNG_FILTER_PAETH equ 0x80
PNG_FAST_FILTERS equ (PNG_FILTER_NONE or PNG_FILTER_SUB or PNG_FILTER_UP)
PNG_ALL_FILTERS  equ (PNG_FAST_FILTERS or PNG_FILTER_AVG or PNG_FILTER_PAETH)

; Filter values (not flags) - used in pngwrite.c, pngwutil.c for now.
; These defines should NOT be changed.

PNG_FILTER_VALUE_NONE equ 0
PNG_FILTER_VALUE_SUB  equ 1
PNG_FILTER_VALUE_UP   equ 2
PNG_FILTER_VALUE_AVG  equ 3
PNG_FILTER_VALUE_PAETH equ 4
PNG_FILTER_VALUE_LAST equ 5

; The following are no longer used and will be removed from libpng-1.7:
PNG_FILTER_HEURISTIC_DEFAULT   equ 0 ;Currently "UNWEIGHTED"
PNG_FILTER_HEURISTIC_UNWEIGHTED equ 1 ;Used by libpng < 0.95
PNG_FILTER_HEURISTIC_WEIGHTED  equ 2 ;Experimental feature
PNG_FILTER_HEURISTIC_LAST      equ 3 ;Not a valid value

; It is unlikely that this function works correctly as of 1.6.0 and using it
; may result either in memory leaks or double free of allocated data.

; Assignments for png_data_freer
PNG_DESTROY_WILL_FREE_DATA equ 1
PNG_SET_WILL_FREE_DATA equ 1
PNG_USER_WILL_FREE_DATA equ 2
; Flags for png_ptr->free_me and info_ptr->free_me
PNG_FREE_HIST equ 0x0008
PNG_FREE_ICCP equ 0x0010
PNG_FREE_SPLT equ 0x0020
PNG_FREE_ROWS equ 0x0040
PNG_FREE_PCAL equ 0x0080
PNG_FREE_SCAL equ 0x0100
if PNG_STORE_UNKNOWN_CHUNKS_SUPPORTED eq 1
	PNG_FREE_UNKN equ 0x0200
end if
PNG_FREE_LIST equ 0x0400 ;removed in 1.6.0 because it is ignored
PNG_FREE_PLTE equ 0x1000
PNG_FREE_TRNS equ 0x2000
PNG_FREE_TEXT equ 0x4000
PNG_FREE_ALL  equ 0x7fff
PNG_FREE_MUL  equ 0x4220 ;PNG_FREE_SPLT|PNG_FREE_TEXT|PNG_FREE_UNKN

;if PNG_ERROR_TEXT_SUPPORTED

;#else
;#  define png_chunk_error(s1,s2) png_err(s1)
;end if

;#else
;#  define png_warning(s1,s2) ((void)(s1))
;#  define png_chunk_warning(s1,s2) ((void)(s1))

;if PNG_READ_SUPPORTED

;#else
;#  ifdef PNG_ALLOW_BENIGN_ERRORS
macro png_benign_error h,txt
{
	png_warning h,txt
}
;#    define png_chunk_benign_error png_chunk_warning
;#  else
;#    define png_benign_error png_error
;#    define png_chunk_benign_error png_chunk_error
;#  endif
;end if


; Provide the default handling for all unknown chunks or, optionally, for
; specific unknown chunks.

; NOTE: prior to 1.6.0 the handling specified for particular chunks on read was
; ignored and the default was used, the per-chunk setting only had an effect on
; write.  If you wish to have chunk-specific handling on read in code that must
; work on earlier versions you must use a user chunk callback to specify the
; desired handling (keep or discard.)

; The 'keep' parameter is a PNG_HANDLE_CHUNK_ value as listed below.  The
; parameter is interpreted as follows:

; READ:
;    PNG_HANDLE_CHUNK_AS_DEFAULT:
;       Known chunks: do normal libpng processing, do not keep the chunk (but
;          see the comments below about PNG_HANDLE_AS_UNKNOWN_SUPPORTED)
;       Unknown chunks: for a specific chunk use the global default, when used
;          as the default discard the chunk data.
;    PNG_HANDLE_CHUNK_NEVER:
;       Discard the chunk data.
;    PNG_HANDLE_CHUNK_IF_SAFE:
;       Keep the chunk data if the chunk is not critical else raise a chunk
;       error.
;    PNG_HANDLE_CHUNK_ALWAYS:
;       Keep the chunk data.

; If the chunk data is saved it can be retrieved using png_get_unknown_chunks,
; below.  Notice that specifying "AS_DEFAULT" as a global default is equivalent
; to specifying "NEVER", however when "AS_DEFAULT" is used for specific chunks
; it simply resets the behavior to the libpng default.

; INTERACTION WTIH USER CHUNK CALLBACKS:
; The per-chunk handling is always used when there is a png_user_chunk_ptr
; callback and the callback returns 0; the chunk is then always stored *unless*
; it is critical and the per-chunk setting is other than ALWAYS.  Notice that
; the global default is *not* used in this case.  (In effect the per-chunk
; value is incremented to at least IF_SAFE.)

; IMPORTANT NOTE: this behavior will change in libpng 1.7 - the global and
; per-chunk defaults will be honored.  If you want to preserve the current
; behavior when your callback returns 0 you must set PNG_HANDLE_CHUNK_IF_SAFE
; as the default - if you don't do this libpng 1.6 will issue a warning.

; If you want unhandled unknown chunks to be discarded in libpng 1.6 and
; earlier simply return '1' (handled).

; PNG_HANDLE_AS_UNKNOWN_SUPPORTED:
;    If this is *not* set known chunks will always be handled by libpng and
;    will never be stored in the unknown chunk list.  Known chunks listed to
;    png_set_keep_unknown_chunks will have no effect.  If it is set then known
;    chunks listed with a keep other than AS_DEFAULT will *never* be processed
;    by libpng, in addition critical chunks must either be processed by the
;    callback or saved.

;    The IHDR and IEND chunks must not be listed.  Because this turns off the
;    default handling for chunks that would otherwise be recognized the
;    behavior of libpng transformations may well become incorrect!

; WRITE:
;    When writing chunks the options only apply to the chunks specified by
;    png_set_unknown_chunks (below), libpng will *always* write known chunks
;    required by png_set_ calls and will always write the core critical chunks
;    (as required for PLTE).

;    Each chunk in the png_set_unknown_chunks list is looked up in the
;    png_set_keep_unknown_chunks list to find the keep setting, this is then
;    interpreted as follows:

;    PNG_HANDLE_CHUNK_AS_DEFAULT:
;       Write safe-to-copy chunks and write other chunks if the global
;       default is set to _ALWAYS, otherwise don't write this chunk.
;    PNG_HANDLE_CHUNK_NEVER:
;       Do not write the chunk.
;    PNG_HANDLE_CHUNK_IF_SAFE:
;       Write the chunk if it is safe-to-copy, otherwise do not write it.
;    PNG_HANDLE_CHUNK_ALWAYS:
;       Write the chunk.

; Note that the default behavior is effectively the opposite of the read case -
; in read unknown chunks are not stored by default, in write they are written
; by default.  Also the behavior of PNG_HANDLE_CHUNK_IF_SAFE is very different
; - on write the safe-to-copy bit is checked, on read the critical bit is
; checked and on read if the chunk is critical an error will be raised.

; num_chunks:
; ===========
;    If num_chunks is positive, then the "keep" parameter specifies the manner
;    for handling only those chunks appearing in the chunk_list array,
;    otherwise the chunk list array is ignored.

;    If num_chunks is 0 the "keep" parameter specifies the default behavior for
;    unknown chunks, as described above.

;    If num_chunks is negative, then the "keep" parameter specifies the manner
;    for handling all unknown chunks plus all chunks recognized by libpng
;    except for the IHDR, PLTE, tRNS, IDAT, and IEND chunks (which continue to
;    be processed by libpng.


; For use in png_set_keep_unknown, added to version 1.2.6
PNG_HANDLE_CHUNK_AS_DEFAULT  equ 0
PNG_HANDLE_CHUNK_NEVER       equ 1
PNG_HANDLE_CHUNK_IF_SAFE     equ 2
PNG_HANDLE_CHUNK_ALWAYS      equ 3
PNG_HANDLE_CHUNK_LAST        equ 4

; Removed from libpng 1.6; use png_get_io_chunk_type.
;PNG_REMOVED(200, bytep, png_get_io_chunk_name, (png_structrp png_ptr),
;    PNG_DEPRECATED)

; The flags returned by png_get_io_state() are the following:
PNG_IO_NONE        equ 0x0000 ; no I/O at this moment
PNG_IO_READING     equ 0x0001 ; currently reading
PNG_IO_WRITING     equ 0x0002 ; currently writing
PNG_IO_SIGNATURE   equ 0x0010 ; currently at the file signature
PNG_IO_CHUNK_HDR   equ 0x0020 ; currently at the chunk header
PNG_IO_CHUNK_DATA  equ 0x0040 ; currently at the chunk data
PNG_IO_CHUNK_CRC   equ 0x0080 ; currently at the chunk crc
PNG_IO_MASK_OP     equ 0x000f ; current operation: reading/writing
PNG_IO_MASK_LOC    equ 0x00f0 ; current location: sig/hdr/data/crc
;end if /* IO_STATE */

; Interlace support.  The following macros are always defined so that if
; libpng interlace handling is turned off the macros may be used to handle
; interlaced images within the application.

PNG_INTERLACE_ADAM7_PASSES equ 7

; Two macros to return the first row and first column of the original,
; full, image which appears in a given pass.  'pass' is in the range 0
; to 6 and the result is in the range 0 to 7.

macro PNG_PASS_START_ROW pass
{
	push ebx ecx
	mov eax,pass
	mov ebx,eax
	not eax
	and eax,1
	shr ebx,1
	mov ecx,3
	sub ecx,ebx
	shl eax,cl
	and eax,7
	pop ecx ebx
}
macro PNG_PASS_START_COL pass
{
	push ebx ecx
	mov eax,pass
	mov ebx,eax
	and eax,1
	inc ebx
	shr ebx,1
	mov ecx,3
	sub ecx,ebx
	shl eax,cl
	and eax,7
	pop ecx ebx
}

; A macro to return the offset between pixels in the output row for a pair of
; pixels in the input - effectively the inverse of the 'COL_SHIFT' macro that
; follows.  Note that ROW_OFFSET is the offset from one row to the next whereas
; COL_OFFSET is from one column to the next, within a row.

;#define PNG_PASS_ROW_OFFSET(pass) ((pass)>2?(8>>(((pass)-1)>>1)):8)
;#define PNG_PASS_COL_OFFSET(pass) (1<<((7-(pass))>>1))

; Two macros to help evaluate the number of rows or columns in each
; pass.  This is expressed as a shift - effectively log2 of the number or
; rows or columns in each 8x8 tile of the original image.

macro PNG_PASS_ROW_SHIFT pass
{
local .end0
	mov eax,3
	cmp pass,2
	jle .end0
		mov eax,8
		sub eax,pass
		shr eax,1
	.end0:
}
macro PNG_PASS_COL_SHIFT pass
{
local .end0
	mov eax,3
	cmp pass,1
	jle .end0
		mov eax,7
		sub eax,pass
		shr eax,1
	.end0:
}

; Hence two macros to determine the number of rows or columns in a given
; pass of an image given its height or width.  In fact these macros may
; return non-zero even though the sub-image is empty, because the other
; dimension may be empty for a small image.

macro PNG_PASS_ROWS height, pass
{
push ecx
push ebx
	PNG_PASS_START_ROW pass 
	mov ebx,eax
	PNG_PASS_ROW_SHIFT pass
	mov ecx,eax
	xor eax,eax
	inc eax
	shl eax,cl
	dec eax
	sub eax,ebx
pop ebx
	add eax,height
	shr eax,cl
pop ecx
}
macro PNG_PASS_COLS width, pass
{
push ecx
push ebx
	PNG_PASS_START_COL pass 
	mov ebx,eax
	PNG_PASS_COL_SHIFT pass
	mov ecx,eax
	xor eax,eax
	inc eax
	shl eax,cl
	dec eax
	sub eax,ebx
pop ebx
	add eax,width
	shr eax,cl
pop ecx
}

; For the reader row callbacks (both progressive and sequential) it is
; necessary to find the row in the output image given a row in an interlaced
; image, so two more macros:

;#define PNG_ROW_FROM_PASS_ROW(y_in, pass) \
;   (((y_in)<<PNG_PASS_ROW_SHIFT(pass))+PNG_PASS_START_ROW(pass))
;#define PNG_COL_FROM_PASS_COL(x_in, pass) \
;   (((x_in)<<PNG_PASS_COL_SHIFT(pass))+PNG_PASS_START_COL(pass))

; Two macros which return a boolean (0 or 1) saying whether the given row
; or column is in a particular pass.  These use a common utility macro that
; returns a mask for a given pass - the offset 'off' selects the row or
; column version.  The mask has the appropriate bit set for each column in
; the tile.

;#define PNG_PASS_MASK(pass,off) ( \
;   ((0x110145AF>>(((7-(off))-(pass))<<2)) & 0xF) | \
;   ((0x01145AF0>>(((7-(off))-(pass))<<2)) & 0xF0))

;#define PNG_ROW_IN_INTERLACE_PASS(y, pass) \
;   ((PNG_PASS_MASK(pass,0) >> ((y)&7)) & 1)
;#define PNG_COL_IN_INTERLACE_PASS(x, pass) \
;   ((PNG_PASS_MASK(pass,1) >> ((x)&7)) & 1)

;if PNG_READ_COMPOSITE_NODIV_SUPPORTED
; With these routines we avoid an integer divide, which will be slower on
; most machines.  However, it does take more operations than the corresponding
; divide method, so it may be slower on a few RISC systems.  There are two
; shifts (by 8 or 16 bits) and an addition, versus a single integer divide.

; Note that the rounding factors are NOT supposed to be the same!  128 and
; 32768 are correct for the NODIV code; 127 and 32767 are correct for the
; standard method.

; [Optimized code by Greg Roelofs and Mark Adler...blame us for bugs. :-) ]


; fg and bg should be in `gamma 1.0' space; alpha is the opacity

;#  define png_composite(composite, fg, alpha, bg)        \
;   {                                                     \
;      uint_16 temp = (uint_16)((uint_16)(fg) \
;          * (uint_16)(alpha)                         \
;          + (uint_16)(bg)*(uint_16)(255          \
;          - (uint_16)(alpha)) + 128);                \
;      (composite) = (byte)(((temp + (temp >> 8)) >> 8) & 0xff); \
;   }

;#  define png_composite_16(composite, fg, alpha, bg)     \
;   {                                                     \
;      uint_32 temp = (uint_32)((uint_32)(fg) \
;          * (uint_32)(alpha)                         \
;          + (uint_32)(bg)*(65535                     \
;          - (uint_32)(alpha)) + 32768);              \
;      (composite) = (uint_16)(0xffff & ((temp + (temp >> 16)) >> 16)); \
;   }

;#else  /* Standard method using integer division */

;#  define png_composite(composite, fg, alpha, bg)                      \
;   (composite) =                                                       \
;       (byte)(0xff & (((uint_16)(fg) * (uint_16)(alpha) +  \
;       (uint_16)(bg) * (uint_16)(255 - (uint_16)(alpha)) + \
;       127) / 255))

;#  define png_composite_16(composite, fg, alpha, bg)                       \
;   (composite) =                                                           \
;       (uint_16)(0xffff & (((uint_32)(fg) * (uint_32)(alpha) + \
;       (uint_32)(bg)*(uint_32)(65535 - (uint_32)(alpha)) +     \
;       32767) / 65535))
;end if /* READ_COMPOSITE_NODIV */

if PNG_USE_READ_MACROS eq 1
; Inline macros to do direct reads of bytes from the input buffer.
; The png_get_int_32() routine assumes we are using two's complement
; format for negative values, which is almost certainly true.

;#  define PNG_get_uint_32(buf) \
;   (((uint_32)(*(buf)) << 24) + \
;    ((uint_32)(*((buf) + 1)) << 16) + \
;    ((uint_32)(*((buf) + 2)) << 8) + \
;    ((uint_32)(*((buf) + 3))))

	; From libpng-1.4.0 until 1.4.4, the png_get_uint_16 macro (but not the
	; function) incorrectly returned a value of type uint_32.

;#  define PNG_get_uint_16(buf) \
;   ((uint_16) \
;    (((unsigned int)(*(buf)) << 8) + \
;    ((unsigned int)(*((buf) + 1)))))

;#  define PNG_get_int_32(buf) \
;   ((int_32)((*(buf) & 0x80) \
;    ? -((int_32)(((png_get_uint_32(buf)^0xffffffffU)+1U)&0x7fffffffU)) \
;    : (int_32)png_get_uint_32(buf)))
end if

;/*******************************************************************************
; Section 5: SIMPLIFIED API
; *******************************************************************************

; Please read the documentation in libpng-manual.txt (TODO: write said
; documentation) if you don't understand what follows.

; The simplified API hides the details of both libpng and the PNG file format
; itself.  It allows PNG files to be read into a very limited number of
; in-memory bitmap formats or to be written from the same formats.  If these
; formats do not accomodate your needs then you can, and should, use the more
; sophisticated APIs above - these support a wide variety of in-memory formats
; and a wide variety of sophisticated transformations to those formats as well
; as a wide variety of APIs to manipulate ancillary information.

; To read a PNG file using the simplified API:

; 1) Declare a 'png_image' structure (see below) on the stack, set the
;    version field to PNG_IMAGE_VERSION and the 'opaque' pointer to NULL
;    (this is REQUIRED, your program may crash if you don't do it.)
; 2) Call the appropriate png_image_begin_read... function.
; 3) Set the png_image 'format' member to the required sample format.
; 4) Allocate a buffer for the image and, if required, the color-map.
; 5) Call png_image_finish_read to read the image and, if required, the
;    color-map into your buffers.

; There are no restrictions on the format of the PNG input itself; all valid
; color types, bit depths, and interlace methods are acceptable, and the
; input image is transformed as necessary to the requested in-memory format
; during the png_image_finish_read() step.  The only caveat is that if you
; request a color-mapped image from a PNG that is full-color or makes
; complex use of an alpha channel the transformation is extremely lossy and the
; result may look terrible.

; To write a PNG file using the simplified API:

; 1) Declare a 'png_image' structure on the stack and memset() it to all zero.
; 2) Initialize the members of the structure that describe the image, setting
;    the 'format' member to the format of the image samples.
; 3) Call the appropriate png_image_write... function with a pointer to the
;    image and, if necessary, the color-map to write the PNG data.

; png_image is a structure that describes the in-memory format of an image
; when it is being read or defines the in-memory format of an image that you
; need to write:

;#if defined(PNG_SIMPLIFIED_READ_SUPPORTED) || \
;    defined(PNG_SIMPLIFIED_WRITE_SUPPORTED)

PNG_IMAGE_VERSION equ 1

struct png_image
	opaque  dd ? ;png_controlp ;Initialize to NULL, free with png_image_free
	version dd ? ;uint_32  ;Set to PNG_IMAGE_VERSION
	width   dd ? ;uint_32  ;Image width in pixels (columns)
	height  dd ? ;uint_32  ;Image height in pixels (rows)
	format  dd ? ;uint_32  ;Image format as defined below
	flags   dd ? ;uint_32  ;A bit mask containing informational flags
	colormap_entries dd ? ;uint_32 ;Number of entries in the color-map

	; In the event of an error or warning the following field will be set to a
	; non-zero value and the 'message' field will contain a '\0' terminated
	; string with the libpng error or warning message.  If both warnings and
	; an error were encountered, only the error is recorded.  If there
	; are multiple warnings, only the first one is recorded.

	; The upper 30 bits of this value are reserved, the low two bits contain
	; a value as follows:

PNG_IMAGE_WARNING equ 1
PNG_IMAGE_ERROR equ 2

; The result is a two-bit code such that a value more than 1 indicates
; a failure in the API just called:

;    0 - no warning or error
;    1 - warning
;    2 - error
;    3 - error preceded by warning

;#  define PNG_IMAGE_FAILED(png_cntrl) ((((png_cntrl).warning_or_error)&0x03)>1)

	warning_or_error dd ? ;uint_32
	message rb 64 ;char[64]
ends

; The samples of the image have one to four channels whose components have
; original values in the range 0 to 1.0:

; 1: A single gray or luminance channel (G).
; 2: A gray/luminance channel and an alpha channel (GA).
; 3: Three red, green, blue color channels (RGB).
; 4: Three color channels and an alpha channel (RGBA).

; The components are encoded in one of two ways:

; a) As a small integer, value 0..255, contained in a single byte.  For the
; alpha channel the original value is simply value/255.  For the color or
; luminance channels the value is encoded according to the sRGB specification
; and matches the 8-bit format expected by typical display devices.

; The color/gray channels are not scaled (pre-multiplied) by the alpha
; channel and are suitable for passing to color management software.

; b) As a value in the range 0..65535, contained in a 2-byte integer.  All
; channels can be converted to the original value by dividing by 65535; all
; channels are linear.  Color channels use the RGB encoding (RGB end-points) of
; the sRGB specification.  This encoding is identified by the
; PNG_FORMAT_FLAG_LINEAR flag below.

; When the simplified API needs to convert between sRGB and linear colorspaces,
; the actual sRGB transfer curve defined in the sRGB specification (see the
; article at http://en.wikipedia.org/wiki/SRGB) is used, not the gamma=1/2.2
; approximation used elsewhere in libpng.

; When an alpha channel is present it is expected to denote pixel coverage
; of the color or luminance channels and is returned as an associated alpha
; channel: the color/gray channels are scaled (pre-multiplied) by the alpha
; value.

; The samples are either contained directly in the image data, between 1 and 8
; bytes per pixel according to the encoding, or are held in a color-map indexed
; by bytes in the image data.  In the case of a color-map the color-map entries
; are individual samples, encoded as above, and the image data has one byte per
; pixel to select the relevant sample from the color-map.


; PNG_FORMAT_*

; #defines to be used in png_image::format.  Each #define identifies a
; particular layout of sample data and, if present, alpha values.  There are
; separate defines for each of the two component encodings.

; A format is built up using single bit flag values.  All combinations are
; valid.  Formats can be built up from the flag values or you can use one of
; the predefined values below.  When testing formats always use the FORMAT_FLAG
; macros to test for individual features - future versions of the library may
; add new flags.

; When reading or writing color-mapped images the format should be set to the
; format of the entries in the color-map then png_image_{read,write}_colormap
; called to read or write the color-map and set the format correctly for the
; image data.  Do not set the PNG_FORMAT_FLAG_COLORMAP bit directly!

; NOTE: libpng can be built with particular features disabled. If you see
; compiler errors because the definition of one of the following flags has been
; compiled out it is because libpng does not have the required support.  It is
; possible, however, for the libpng configuration to enable the format on just
; read or just write; in that case you may see an error at run time.  You can
; guard against this by checking for the definition of the appropriate
; "_SUPPORTED" macro, one of:

;    PNG_SIMPLIFIED_{READ,WRITE}_{BGR,AFIRST}_SUPPORTED

PNG_FORMAT_FLAG_ALPHA    equ 0x01 ;format with an alpha channel
PNG_FORMAT_FLAG_COLOR    equ 0x02 ;color format: otherwise grayscale
PNG_FORMAT_FLAG_LINEAR   equ 0x04 ;2-byte channels else 1-byte
PNG_FORMAT_FLAG_COLORMAP equ 0x08 ;image data is color-mapped

PNG_FORMAT_FLAG_BGR   equ 0x10 ;BGR colors, else order is RGB

PNG_FORMAT_FLAG_AFIRST equ 0x20 ;alpha channel comes first

; Commonly used formats have predefined macros.

; First the single byte (sRGB) formats:

PNG_FORMAT_GRAY equ 0
PNG_FORMAT_GA  equ PNG_FORMAT_FLAG_ALPHA
PNG_FORMAT_AG  equ (PNG_FORMAT_GA|PNG_FORMAT_FLAG_AFIRST)
PNG_FORMAT_RGB equ PNG_FORMAT_FLAG_COLOR
PNG_FORMAT_BGR equ (PNG_FORMAT_FLAG_COLOR|PNG_FORMAT_FLAG_BGR)
PNG_FORMAT_RGBA equ (PNG_FORMAT_RGB|PNG_FORMAT_FLAG_ALPHA)
PNG_FORMAT_ARGB equ (PNG_FORMAT_RGBA|PNG_FORMAT_FLAG_AFIRST)
PNG_FORMAT_BGRA equ (PNG_FORMAT_BGR|PNG_FORMAT_FLAG_ALPHA)
PNG_FORMAT_ABGR equ (PNG_FORMAT_BGRA|PNG_FORMAT_FLAG_AFIRST)

; Then the linear 2-byte formats.  When naming these "Y" is used to
; indicate a luminance (gray) channel.

PNG_FORMAT_LINEAR_Y equ PNG_FORMAT_FLAG_LINEAR
PNG_FORMAT_LINEAR_Y_ALPHA equ (PNG_FORMAT_FLAG_LINEAR|PNG_FORMAT_FLAG_ALPHA)
PNG_FORMAT_LINEAR_RGB equ (PNG_FORMAT_FLAG_LINEAR|PNG_FORMAT_FLAG_COLOR)
PNG_FORMAT_LINEAR_RGB_ALPHA equ\
	(PNG_FORMAT_FLAG_LINEAR|PNG_FORMAT_FLAG_COLOR|PNG_FORMAT_FLAG_ALPHA)

; With color-mapped formats the image data is one byte for each pixel, the byte
; is an index into the color-map which is formatted as above.  To obtain a
; color-mapped format it is sufficient just to add the PNG_FOMAT_FLAG_COLORMAP
; to one of the above definitions, or you can use one of the definitions below.

PNG_FORMAT_RGB_COLORMAP equ (PNG_FORMAT_RGB|PNG_FORMAT_FLAG_COLORMAP)
PNG_FORMAT_BGR_COLORMAP equ (PNG_FORMAT_BGR|PNG_FORMAT_FLAG_COLORMAP)
PNG_FORMAT_RGBA_COLORMAP equ (PNG_FORMAT_RGBA|PNG_FORMAT_FLAG_COLORMAP)
PNG_FORMAT_ARGB_COLORMAP equ (PNG_FORMAT_ARGB|PNG_FORMAT_FLAG_COLORMAP)
PNG_FORMAT_BGRA_COLORMAP equ (PNG_FORMAT_BGRA|PNG_FORMAT_FLAG_COLORMAP)
PNG_FORMAT_ABGR_COLORMAP equ (PNG_FORMAT_ABGR|PNG_FORMAT_FLAG_COLORMAP)

; PNG_IMAGE macros

; These are convenience macros to derive information from a png_image
; structure.  The PNG_IMAGE_SAMPLE_ macros return values appropriate to the
; actual image sample values - either the entries in the color-map or the
; pixels in the image.  The PNG_IMAGE_PIXEL_ macros return corresponding values
; for the pixels and will always return 1 for color-mapped formats.  The
; remaining macros return information about the rows in the image and the
; complete image.

; NOTE: All the macros that take a png_image::format parameter are compile time
; constants if the format parameter is, itself, a constant.  Therefore these
; macros can be used in array declarations and case labels where required.
; Similarly the macros are also pre-processor constants (sizeof is not used) so
; they can be used in #if tests.

; First the information about the samples.

macro PNG_IMAGE_SAMPLE_CHANNELS fmt
{
	mov eax,fmt
	and eax,PNG_FORMAT_FLAG_COLOR or PNG_FORMAT_FLAG_ALPHA
	inc eax
}
; Return the total number of channels in a given format: 1..4

;#define PNG_IMAGE_SAMPLE_COMPONENT_SIZE(fmt)\
;   ((((fmt) & PNG_FORMAT_FLAG_LINEAR) >> 2)+1)
;   /* Return the size in bytes of a single component of a pixel or color-map
; entry (as appropriate) in the image: 1 or 2.


;#define PNG_IMAGE_SAMPLE_SIZE(fmt)\
;   (PNG_IMAGE_SAMPLE_CHANNELS(fmt) * PNG_IMAGE_SAMPLE_COMPONENT_SIZE(fmt))
;   /* This is the size of the sample data for one sample.  If the image is
; color-mapped it is the size of one color-map entry (and image pixels are
; one byte in size), otherwise it is the size of one image pixel.


;#define PNG_IMAGE_MAXIMUM_COLORMAP_COMPONENTS(fmt)\
;   (PNG_IMAGE_SAMPLE_CHANNELS(fmt) * 256)
;   /* The maximum size of the color-map required by the format expressed in a
; count of components.  This can be used to compile-time allocate a
; color-map:

; uint_16 colormap[PNG_IMAGE_MAXIMUM_COLORMAP_COMPONENTS(linear_fmt)];

; byte colormap[PNG_IMAGE_MAXIMUM_COLORMAP_COMPONENTS(sRGB_fmt)];

; Alternatively use the PNG_IMAGE_COLORMAP_SIZE macro below to use the
; information from one of the png_image_begin_read_ APIs and dynamically
; allocate the required memory.


; Corresponding information about the pixels
macro PNG_IMAGE_PIXEL_ p1,fmt
{
local .end0
local .end1
	mov eax,fmt
	and eax,PNG_FORMAT_FLAG_COLORMAP
	cmp eax,0
	je .end0
		xor eax,eax
		inc eax
		jmp .end1
	.end0:
		p1 fmt
	.end1:
}

macro PNG_IMAGE_PIXEL_CHANNELS fmt
{
	PNG_IMAGE_PIXEL_ PNG_IMAGE_SAMPLE_CHANNELS,fmt 
}
; The number of separate channels (components) in a pixel; 1 for a
; color-mapped image.


;#define PNG_IMAGE_PIXEL_COMPONENT_SIZE(fmt)\
;   PNG_IMAGE_PIXEL_(PNG_IMAGE_SAMPLE_COMPONENT_SIZE,fmt)
;   /* The size, in bytes, of each component in a pixel; 1 for a color-mapped
; image.


;#define PNG_IMAGE_PIXEL_SIZE(fmt) PNG_IMAGE_PIXEL_(PNG_IMAGE_SAMPLE_SIZE,fmt)
;   /* The size, in bytes, of a complete pixel; 1 for a color-mapped image. */

; Information about the whole row, or whole image
;#define PNG_IMAGE_ROW_STRIDE(image)\
;   (PNG_IMAGE_PIXEL_CHANNELS((image).format) * (image).width)
; Return the total number of components in a single row of the image; this
; is the minimum 'row stride', the minimum count of components between each
; row.  For a color-mapped image this is the minimum number of bytes in a
; row.

; WARNING: this macro overflows for some images with more than one component
; and very large image widths.  libpng will refuse to process an image where
; this macro would overflow.


;#define PNG_IMAGE_BUFFER_SIZE(image, row_stride)\
;   (PNG_IMAGE_PIXEL_COMPONENT_SIZE((image).format)*(image).height*(row_stride))
; Return the size, in bytes, of an image buffer given a png_image and a row
; stride - the number of components to leave space for in each row.

; WARNING: this macro overflows a 32-bit integer for some large PNG images,
; libpng will refuse to process an image where such an overflow would occur.


;#define PNG_IMAGE_SIZE(image)\
;   PNG_IMAGE_BUFFER_SIZE(image, PNG_IMAGE_ROW_STRIDE(image))
; Return the size, in bytes, of the image in memory given just a png_image;
; the row stride is the minimum stride required for the image.


;#define PNG_IMAGE_COLORMAP_SIZE(image)\
;   (PNG_IMAGE_SAMPLE_SIZE((image).format) * (image).colormap_entries)
; Return the size, in bytes, of the color-map of this image.  If the image
; format is not a color-map format this will return a size sufficient for
; 256 entries in the given format; check PNG_FORMAT_FLAG_COLORMAP if
; you don't want to allocate a color-map in this case.


; PNG_IMAGE_FLAG_*

; Flags containing additional information about the image are held in the
; 'flags' field of png_image.

PNG_IMAGE_FLAG_COLORSPACE_NOT_sRGB equ 0x01
; This indicates the the RGB values of the in-memory bitmap do not
; correspond to the red, green and blue end-points defined by sRGB.

PNG_IMAGE_FLAG_FAST equ 0x02
; On write emphasise speed over compression; the resultant PNG file will be
; larger but will be produced significantly faster, particular for large
; images.  Do not use this option for images which will be distributed, only
; used it when producing intermediate files that will be read back in
; repeatedly.  For a typical 24-bit image the option will double the read
; speed at the cost of increasing the image size by 25%, however for many
; more compressible images the PNG file can be 10 times larger with only a
; slight speed gain.

PNG_IMAGE_FLAG_16BIT_sRGB equ 0x04
; On read if the image is a 16-bit per component image and there is no gAMA
; or sRGB chunk assume that the components are sRGB encoded.  Notice that
; images output by the simplified API always have gamma information; setting
; this flag only affects the interpretation of 16-bit images from an
; external source.  It is recommended that the application expose this flag
; to the user; the user can normally easily recognize the difference between
; linear and sRGB encoding.  This flag has no effect on write - the data
; passed to the write APIs must have the correct encoding (as defined
; above.)

; If the flag is not set (the default) input 16-bit per component data is
; assumed to be linear.

; NOTE: the flag can only be set after the png_image_begin_read_ call,
; because that call initializes the 'flags' field.

if PNG_SIMPLIFIED_WRITE_SUPPORTED eq 1
; WRITE APIS
; ----------
; For write you must initialize a png_image structure to describe the image to
; be written.  To do this use memset to set the whole structure to 0 then
; initialize fields describing your image.

; version: must be set to PNG_IMAGE_VERSION
; opaque: must be initialized to NULL
; width: image width in pixels
; height: image height in rows
; format: the format of the data (image and color-map) you wish to write
; flags: set to 0 unless one of the defined flags applies; set
;    PNG_IMAGE_FLAG_COLORSPACE_NOT_sRGB for color format images where the RGB
;    values do not correspond to the colors in sRGB.
; colormap_entries: set to the number of entries in the color-map (0 to 256)

; With all write APIs if image is in one of the linear formats with 16-bit
; data then setting convert_to_8_bit will cause the output to be an 8-bit PNG
; gamma encoded according to the sRGB specification, otherwise a 16-bit linear
; encoded PNG file is written.

; With color-mapped data formats the colormap parameter point to a color-map
; with at least image->colormap_entries encoded in the specified format.  If
; the format is linear the written PNG color-map will be converted to sRGB
; regardless of the convert_to_8_bit flag.

; With all APIs row_stride is handled as in the read APIs - it is the spacing
; from one row to the next in component sized units (1 or 2 bytes) and if
; negative indicates a bottom-up row layout in the buffer.  If row_stride is
; zero, libpng will calculate it for you from the image width and number of
; channels.

; Note that the write API does not support interlacing, sub-8-bit pixels or
; most ancillary chunks.  If you need to write text chunks (e.g. for copyright
; notices) you need to use one of the other APIs.


;#define png_image_write_get_memory_size(image, size, convert_to_8_bit, buffer,\
;   row_stride, colormap)\
;   png_image_write_to_memory(&(image), 0, &(size), convert_to_8_bit, buffer,\
;         row_stride, colormap)
; Return the amount of memory in 'size' required to compress this image.
; The png_image structure 'image' must be filled in as in the above
; function and must not be changed before the actual write call, the buffer
; and all other parameters must also be identical to that in the final
; write call.  The 'size' variable need not be initialized.

; NOTE: the macro returns true/false, if false is returned 'size' will be
; set to zero and the write failed and probably will fail if tried again.

; You can pre-allocate the buffer by making sure it is of sufficient size
; regardless of the amount of compression achieved.  The buffer size will
; always be bigger than the original image and it will never be filled.  The
; following macros are provided to assist in allocating the buffer.

;#define PNG_IMAGE_DATA_SIZE(image) (PNG_IMAGE_SIZE(image)+(image).height)
; The number of uncompressed bytes in the PNG byte encoding of the image;
; uncompressing the PNG IDAT data will give this number of bytes.

; NOTE: while PNG_IMAGE_SIZE cannot overflow for an image in memory this
; macro can because of the extra bytes used in the PNG byte encoding.  You
; need to avoid this macro if your image size approaches 2^30 in width or
; height.  The same goes for the remainder of these macros; they all produce
; bigger numbers than the actual in-memory image size.

;#ifndef PNG_ZLIB_MAX_SIZE
;#  define PNG_ZLIB_MAX_SIZE(b) ((b)+(((b)+7U)>>3)+(((b)+63U)>>6)+11U)
; An upper bound on the number of compressed bytes given 'b' uncompressed
; bytes.  This is based on deflateBounds() in zlib; different
; implementations of zlib compression may conceivably produce more data so
; if your zlib implementation is not zlib itself redefine this macro
; appropriately.

;end if

;#define PNG_IMAGE_COMPRESSED_SIZE_MAX(image)\
;   PNG_ZLIB_MAX_SIZE((png_alloc_size_t)PNG_IMAGE_DATA_SIZE(image))
	; An upper bound on the size of the data in the PNG IDAT chunks.

;#define PNG_IMAGE_PNG_SIZE_MAX_(image, image_size)\
;   ((8U/*sig*/+25U/*IHDR*/+16U/*gAMA*/+44U/*cHRM*/+12U/*IEND*/+\
;    (((image).format&PNG_FORMAT_FLAG_COLORMAP)?/*colormap: PLTE, tRNS*/\
;    12U+3U*(image).colormap_entries/*PLTE data*/+\
;    (((image).format&PNG_FORMAT_FLAG_ALPHA)?\
;    12U/*tRNS*/+(image).colormap_entries:0U):0U)+\
;    12U)+(12U*((image_size)/PNG_ZBUF_SIZE))/*IDAT*/+(image_size))

; A helper for the following macro; if your compiler cannot handle the
; following macro use this one with the result of
; PNG_IMAGE_COMPRESSED_SIZE_MAX(image) as the second argument (most
; compilers should handle this just fine.)

;#define PNG_IMAGE_PNG_SIZE_MAX(image)\
;   PNG_IMAGE_PNG_SIZE_MAX_(image, PNG_IMAGE_COMPRESSED_SIZE_MAX(image))
; An upper bound on the total length of the PNG data stream for 'image'.
; The result is of type png_alloc_size_t, on 32-bit systems this may
; overflow even though PNG_IMAGE_DATA_SIZE does not overflow; the write will
; run out of buffer space but return a corrected size which should work.

end if ;SIMPLIFIED_WRITE
;/*******************************************************************************
;  END OF SIMPLIFIED API
; ******************************************************************************/
;end if /* SIMPLIFIED_{READ|WRITE} */

;/*******************************************************************************
; Section 6: IMPLEMENTATION OPTIONS
; *******************************************************************************

; Support for arbitrary implementation-specific optimizations.  The API allows
; particular options to be turned on or off.  'Option' is the number of the
; option and 'onoff' is 0 (off) or non-0 (on).  The value returned is given
; by the PNG_OPTION_ defines below.

; HARDWARE: normally hardware capabilites, such as the Intel SSE instructions,
;           are detected at run time, however sometimes it may be impossible
;           to do this in user mode, in which case it is necessary to discover
;           the capabilities in an OS specific way.  Such capabilities are
;           listed here when libpng has support for them and must be turned
;           ON by the application if present.

; SOFTWARE: sometimes software optimizations actually result in performance
;           decrease on some architectures or systems, or with some sets of
;           PNG images.  'Software' options allow such optimizations to be
;           selected at run time.

if PNG_SET_OPTION_SUPPORTED eq 1
if PNG_ARM_NEON_API_SUPPORTED eq 1
	PNG_ARM_NEON  equ 0 ;HARDWARE: ARM Neon SIMD instructions supported
end if
PNG_MAXIMUM_INFLATE_WINDOW equ 2 ;SOFTWARE: force maximum window
PNG_SKIP_sRGB_CHECK_PROFILE equ 4 ;SOFTWARE: Check ICC profile for sRGB
if PNG_MIPS_MSA_API_SUPPORTED eq 1
	PNG_MIPS_MSA  equ 6 ;HARDWARE: MIPS Msa SIMD instructions supported
end if
PNG_OPTION_NEXT equ 8 ;Next option - numbers must be even

; Return values: NOTE: there are four values and 'off' is *not* zero
PNG_OPTION_UNSET  equ 0 ;Unset - defaults to off
PNG_OPTION_INVALID equ 1 ;Option number out of range
PNG_OPTION_OFF    equ 2
PNG_OPTION_ON     equ 3
end if ;SET_OPTION

;/*******************************************************************************
;  END OF HARDWARE AND SOFTWARE OPTIONS
; ******************************************************************************/

; Maintainer: Put new public prototypes here ^, in libpng.3, in project
; defs, and in scripts/symbols.def.


; The last ordinal number (this is the *last* one already used; the next
; one to use is one more than this.)

;end if /* PNG_VERSION_INFO_ONLY */
; Do not put anything past this line