Subversion Repositories Kolibri OS

; (Version 0.96 Copyright (c) 1996, 1997 Andreas Dilger)

; (Version 0.88 Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.)

;   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.

; this sentence.

; files that are distributed with libpng have other copyright owners and

; are released under other open source licenses.

; 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:

;    Eric S. Raymond

;    Mans Rullgard

;    Cosmin Truta

;    Gilles Vollant

;    James Yu

;    Mandar Sahastrabuddhe

;    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.

; are released under other open source licenses.

; 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:

;    Glenn Randers-Pehrson

;    Willem van Schaik

; but are also released under this license.

; 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:

;    Kevin Bracey

;    Sam Bushell

;    Magnus Holmgren

;    Greg Roelofs

;    Tom Tanner

; but are released under this license.

; Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc.

; is defined as the following set of individuals:

;    Dave Martindale

;    Guy Eric Schalnat

;    Paul Schmidt

;    Tim Wegner

; 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.

; source code, or portions hereof, for any purpose, without fee, subject

; to the following restrictions:

;      be misrepresented as being the original source.

;      source or altered source distribution.

; 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.

; 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.

; a certification mark of the Open Source Initiative. OSI has not addressed

; the additional disclaimers inserted at version 1.0.7.

; 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).

; boxes and the like:

; files "pngbar.png" and "pngbar.jpg (88x31) and "pngnow.png" (98x31).

; with testing, bug fixes, and patience.  This wouldn't have been

; possible without all of you.

; 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]

;    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".

;    to the info_ptr or png_ptr members through png.h, and the compiled

;    application is loaded with a different version of the library.

;    in binary compatibility (e.g., when a new feature is added).

; is available as a W3C Recommendation and as an ISO Specification,

; 

; =========================

;    an official declaration.

;    upward through 1.6.25 are Y2K compliant.  It is my belief that

;    earlier versions were also Y2K compliant.

;    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.

;        "uint_16 year" in png_time_struct.

;        "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.

;        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

;    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.

;    integer to hold the year, and can hold years as large as 65535.

;    no date-related code.

;       libpng maintainer

;       PNG Development Group

; 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

; 

; skip to the end of this file and read the section entitled 'simplified API'.

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_DLLNUM equ 16

PNG_LIBPNG_VER_MAJOR  equ 1

PNG_LIBPNG_VER_MINOR  equ 6

PNG_LIBPNG_VER_RELEASE equ 25

; PNG_LIBPNG_VER_STRING, omitting any leading zero:

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

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

; 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

; the library has been built.

; VS_FF_PRIVATEBUILD File *was not* built using standard release

; procedures. If this value is given, the StringFileInfo block must

; contain a PrivateBuild string.

; 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.

;#  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

; the version above.

; 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.

; allow configuration of the library.

; See pnglibconf.h for build time configuration

; 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

; 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.

; does not use division?

;   PNG_READ_COMPOSITE_NODIV_SUPPORTED: use the 'no division'

;      algorithm.

;   PNG_NO_READ_COMPOSITE_NODIV: use the 'division' algorithm.

; false?

;   PNG_ALLOW_BENIGN_ERRORS: map calls to the benign error

;      APIs to png_warning.

; Otherwise the calls are mapped to png_error.

; constants.

; See pngconf.h for base types that vary by machine/system

; do not agree upon the version number.

; PNG file.  One of these is always required, although the simplified API

; (below) hides the creation and destruction of it.

; 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.

; 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'.

; exact size) is not important, although the size of the fields need to

; be byte or uint_16 (as defined below).

	red   db ? ;byte

	green db ? ;byte

	blue  db ? ;byte

ends

	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

	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

; of sPLT chunks.

	red   dw ? ;uint_16

	green dw ? ;uint_16

	blue  dw ? ;uint_16

	alpha dw ? ;uint_16

	frequency dw ? ;uint_16

ends

; 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.

	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

; 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.

	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

; 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

; 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!

	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

; 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.

	name rb 5 ;byte[5] ;Textual chunk name with '\0' terminator

	podata dd ? ;byte* ;Data, should not be modified on read!

	size dd ? ;png_size_t

	; 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.

ends

end if

PNG_HAVE_IHDR equ  0x01

PNG_HAVE_PLTE equ  0x02

PNG_AFTER_IDAT equ 0x08

PNG_UINT_31_MAX equ 0x7fffffff ;uint_32

PNG_UINT_32_MAX equ -1 ;uint_32

PNG_SIZE_MAX    equ 0x60000000 ;1.5 Gb

; PNG specification manner (x100000)

PNG_FP_HALF equ 50000

PNG_FP_MAX equ ((png_fixed_point)0x7fffffffL)

PNG_FP_MIN equ (-PNG_FP_MAX)

; color type masks

PNG_COLOR_MASK_PALETTE equ 1

PNG_COLOR_MASK_COLOR   equ 2

PNG_COLOR_MASK_ALPHA   equ 4

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

PNG_COMPRESSION_TYPE_BASE equ 0 ;Deflate method 8, 32K window

PNG_COMPRESSION_TYPE_DEFAULT equ PNG_COMPRESSION_TYPE_BASE

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

PNG_INTERLACE_NONE       equ 0 ;Non-interlaced image

PNG_INTERLACE_ADAM7      equ 1 ;Adam7 interlacing

PNG_INTERLACE_LAST       equ 2 ;Not a valid value

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

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

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

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

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

PNG_KEYWORD_MAX_LENGTH equ 79

PNG_MAX_PALETTE_LENGTH equ 256

; 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_ defines should NOT be changed.

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

; change these values for the row.  It also should enable using

; the routines for other purposes.

	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

; This must match the function definition in , 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.

; 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!

end if

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

PNG_FLAG_MNG_EMPTY_PLTE    equ 0x01

PNG_FLAG_MNG_FILTER_64     equ 0x04

PNG_ALL_MNG_FEATURES       equ 0x05

; 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.

; 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.

; pngconf.h and in the *.dfn files in the scripts directory.

;                   *.def files. The ordinal value is only

;                   relevant when preprocessing png.h with

;                   the *.dfn files for building symbol table

;                   entries, and are removed by pngconf.h.

;       type:       return type of the function

;       name:       function name

;       args:       function arguments, with types

; the PNG_EXPORTA() macro instead.

;       attributes: function attributes

{

align 4

nam:

local .end_t

local .m_txt

jmp .end_t

	.m_txt db `nam,13,10,0

.end_t:

	stdcall dbg_print,txt_zv,.m_txt

ret

}

; png_check_sig(sig, n) := !png_sig_cmp(sig, 0, n).

{

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

}

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

; of a PNG file are returned to the calling application when an alpha channel,

; or a tRNS chunk in a palette file, is present.

; datastream. The color samples in a PNG datastream are never premultiplied

; with the alpha samples.

; 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.

; 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).

; value is equal to the maximum value.

; 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.

; with an enumerated 'mode' value and the gamma of the required output:

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

; 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_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

PNG_FILLER_BEFORE equ 0

PNG_FILLER_AFTER equ 1

; 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.

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

; library.  The following is the floating point variant.

; 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!

; 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.

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

; 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_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)

; These defines should NOT be changed.

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

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

; handling.  They are in the file pngrio.c, pngwio.c, and pngerror.c,

; and call standard C I/O routines such as fread(), fwrite(), and

; fprintf().  These functions can be made to use other I/O routines

; at run time for those applications that need to handle I/O in a

; different manner by calling png_set_???_fn().  See libpng-manual.txt for

; more information.

PNG_EXPORT 78, void, png_set_read_fn, '(png_structrp png_ptr, voidp io_ptr, png_rw_ptr read_data_fn)'

; by libpng or by the application; this works on the png_info structure passed

; in, it does not change the state for other png_info structures.

; may result either in memory leaks or double free of allocated data.

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

; The same, but the chunk name is prepended to the error string.

;PNG_EXPORTA(103, void, png_chunk_error, (png_const_structrp png_ptr,

;    charp error_message), PNG_NORETURN);

; Fatal error in PNG image of libpng - can't continue

;PNG_EXPORTA(104, void, png_err, (png_const_structrp png_ptr), PNG_NORETURN);

;#  define png_chunk_error(s1,s2) png_err(s1)

;end if

PNG_EXPORT 106, void, png_chunk_warning, '(png_const_structrp png_ptr, charp warning_message)'

;#else

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

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

; User can choose whether to handle as a fatal error or as a warning.

PNG_EXPORT 107, void, png_benign_error, '(png_const_structrp png_ptr, charp warning_message)'

; Same, chunk name is prepended to message (only during read)

PNG_EXPORT 108, void, png_chunk_benign_error, '(png_const_structrp png_ptr, charp warning_message)'

;#  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

; specific unknown chunks.

; 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.)

; parameter is interpreted as follows:

;    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.

; 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.

; 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.)

; 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.

; earlier simply return '1' (handled).

;    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.

;    default handling for chunks that would otherwise be recognized the

;    behavior of libpng transformations may well become incorrect!

;    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).

;    png_set_keep_unknown_chunks list to find the keep setting, this is then

;    interpreted as follows:

;       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.

; 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.

; ===========

;    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.

;    unknown chunks, as described above.

;    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.

PNG_HANDLE_CHUNK_AS_DEFAULT  equ 0

PNG_HANDLE_CHUNK_NEVER       equ 1

PNG_HANDLE_CHUNK_IF_SAFE     equ 2