Subversion Repositories Kolibri OS

; Copyright (c) 1998-2002,2004,2006-2013 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.)

; For conditions of distribution and use, see the disclaimer

; and license in png.inc

; that the application can find out the characteristics of the image.

; If you are reading the file, this structure will tell you what is

; in the PNG file.  If you are writing the file, fill in the information

; you want to put into the PNG file, using png_set_*() functions, then

; call png_write_info().

; consult that document for information about the meaning of each field.

; the values in the png_info_struct, which meant that the contents and

; order of the values had to remain fixed.  With libpng 0.95 and later,

; however, there are now functions that abstract the contents of

; png_info_struct from the application, so this makes it easier to use

; libpng with dynamic libraries, and even makes it possible to use

; libraries that don't have all of the libpng ancillary chunk-handing

; functionality.  In libpng-1.5.0 this was moved into a separate private

; file that is not visible to applications.

; cleaned up before the structure is discarded: palette, trans, text,

; pcal_purpose, pcal_units, pcal_params, hist, iccp_name, iccp_profile,

; splt_palettes, scal_unit, row_pointers, and unknowns.   By default, these

; are automatically freed when the info structure is deallocated, if they were

; allocated internally by libpng.  This behavior can be changed by means

; of the png_data_freer() function.

; change these members go through the corresponding png_set_*

; functions.  A function to clear these members is available: see

; png_free_data().  The png_set_* functions do not depend on being

; able to point info structure members to any of the storage they are

; passed (they make their own copies), EXCEPT that the png_set_text

; functions use the same storage passed to them in the text_ptr or

; itxt_ptr structure argument, and the png_set_rows and png_set_unknowns

; functions do not make their own copies.

	; The following are necessary for every PNG file

	width  dd ? ;uint_32 ;width of image in pixels (from IHDR)

	height dd ? ;uint_32 ;height of image in pixels (from IHDR)

	valid  dd ? ;uint_32 ;valid chunk data (see PNG_INFO_ below)

	rowbytes dd ? ;png_size_t ;bytes needed to hold an untransformed row

	palette  dd ? ;png_colorp ; array of color values (valid & PNG_INFO_PLTE)

	num_palette dw ? ;uint_16 ;number of color entries in "palette" (PLTE)

	num_trans   dw ? ;uint_16 ;number of transparent palette color (tRNS)

	bit_depth   db ? ;byte ;1, 2, 4, 8, or 16 bits/channel (from IHDR)

	color_type  db ? ;byte ;see PNG_COLOR_TYPE_ below (from IHDR)

	; The following three should have been named *_method not *_type

	compression_type db ? ;byte ;must be PNG_COMPRESSION_TYPE_BASE (IHDR)

	filter_type    db ? ;byte ;must be PNG_FILTER_TYPE_BASE (from IHDR)

	interlace_type db ? ;byte ;One of PNG_INTERLACE_NONE, PNG_INTERLACE_ADAM7

	; write, but the are never actually used by the write code.

	pixel_depth db ? ;byte ;number of bits per pixel

	spare_byte  db ? ;byte ;to align the data, and for future use

	; This is never set during write

	signature db 8 ;byte[8] ;magic bytes read by libpng from start of file

end if

	; valid field to see if the information in these are valid.  If you

	; are writing, set the valid field to those chunks you want written,

	; and initialize the appropriate fields below.

	; png_colorspace only contains 'flags' if neither GAMMA or COLORSPACE are

	; defined.  When COLORSPACE is switched on all the colorspace-defining

	; chunks should be enabled, when GAMMA is switched on all the gamma-defining

	; chunks should be enabled.  If this is not done it becomes possible to read

	; inconsistent PNG files and assign a probably incorrect interpretation to

	; the information.  (In other words, by carefully choosing which chunks to

	; recognize the system configuration can select an interpretation for PNG

	; files containing ambiguous data and this will result in inconsistent

	; behavior between different libpng builds!)

end if

	; iCCP chunk data.

	iccp_name dd ? ;charp ;profile name

	iccp_profile dd ? ;bytep ;International Color Consortium profile data

	iccp_proflen dd ? ;uint_32 ;ICC profile data length

end if

	; The tEXt, and zTXt chunks contain human-readable textual data in

	; uncompressed, compressed, and optionally compressed forms, respectively.

	; The data in "text" is an array of pointers to uncompressed,

	; null-terminated C strings. Each chunk has a keyword that describes the

	; textual data contained in that chunk.  Keywords are not required to be

	; unique, and the text string may be empty.  Any number of text chunks may

	; be in an image.

	max_text dd ? ;int ;current size of text array

	text dd ? ;png_textp ;array of comments read or comments to write

end if ;TEXT

	; The tIME chunk holds the last time the displayed image data was

	; modified.  See the png_time struct for the contents of this struct.

end if

	; The sBIT chunk specifies the number of significant high-order bits

	; in the pixel data.  Values are in the range [1, bit_depth], and are

	; only specified for the channels in the pixel data.  The contents of

	; the low-order bits is not specified.  Data is valid if

	; (valid & PNG_INFO_sBIT) is non-zero.

end if

;defined(PNG_READ_BACKGROUND_SUPPORTED)

	; The tRNS chunk supplies transparency data for paletted images and

	; other image types that don't need a full alpha channel.  There are

	; "num_trans" transparency values for a paletted image, stored in the

	; same order as the palette colors, starting from index 0.  Values

	; for the data are in the range [0, 255], ranging from fully transparent

	; to fully opaque, respectively.  For non-paletted images, there is a

	; single color specified that should be treated as fully transparent.

	; Data is valid if (valid & PNG_INFO_tRNS) is non-zero.

	trans_color png_color_16 ;transparent color for non-palette image

;end if

	; The bKGD chunk gives the suggested image background color if the

	; display program does not have its own background color and the image

	; is needs to composited onto a background before display.  The colors

	; in "background" are normally in the same color space/depth as the

	; pixel data.  Data is valid if (valid & PNG_INFO_bKGD) is non-zero.

end if

	; The oFFs chunk gives the offset in "offset_unit_type" units rightwards

	; and downwards from the top-left corner of the display, page, or other

	; application-specific co-ordinate space.  See the PNG_OFFSET_ defines

	; below for the unit types.  Valid if (valid & PNG_INFO_oFFs) non-zero.

	y_offset dd ? ;int_32 ;y offset on page

	offset_unit_type db ? ;byte ;offset units type

end if

	; The pHYs chunk gives the physical pixel density of the image for

	; display or printing in "phys_unit_type" units (see PNG_RESOLUTION_

	; defines below).  Data is valid if (valid & PNG_INFO_pHYs) is non-zero.

	y_pixels_per_unit dd ? ;uint_32 ;vertical pixel density

	phys_unit_type db ? ;byte ;resolution type (see PNG_RESOLUTION_ below)

end if

	; The hIST chunk contains the relative frequency or importance of the

	; various palette entries, so that a viewer can intelligently select a

	; reduced-color palette, if required.  Data is an array of "num_palette"

	; values in the range [0,65535]. Data valid if (valid & PNG_INFO_hIST)

	; is non-zero.

end if

	; The pCAL chunk describes a transformation between the stored pixel

	; values and original physical data values used to create the image.

	; The integer range [0, 2^bit_depth - 1] maps to the floating-point

	; range given by [pcal_X0, pcal_X1], and are further transformed by a

	; (possibly non-linear) transformation function given by "pcal_type"

	; and "pcal_params" into "pcal_units".  Please see the PNG_EQUATION_

	; defines below, and the PNG-Group's PNG extensions document for a

	; complete description of the transformations and how they should be

	; implemented, and for a description of the ASCII parameter strings.

	; Data values are valid if (valid & PNG_INFO_pCAL) non-zero.

	pcal_X0 dd ? ;int_32 ;minimum value

	pcal_X1 dd ? ;int_32 ;maximum value

	pcal_units   dd ? ;charp ;Latin-1 string giving physical units

	pcal_params  dd ? ;charpp ;ASCII strings containing parameter values

	pcal_type    db ? ;byte ;equation type (see PNG_EQUATION_ below)

	pcal_nparams db ? ;byte ;number of parameters given in pcal_params

end if

	free_me dd ? ;uint_32 ;flags items libpng is responsible for freeing

	; Storage for unknown chunks that the library doesn't recognize.

	unknown_chunks dd ? ;png_unknown_chunkp

	; png_struct::user_chunk_cache_max, else overflow can occur.

end if

	; Data on sPLT chunks (there may be more than one).

	splt_palettes dd ? ;png_sPLT_tp

	splt_palettes_num dd ? ;int ;Match type returned by png_get API

end if

	; The sCAL chunk describes the actual physical dimensions of the

	; subject matter of the graphic.  The chunk contains a unit specification

	; a byte value, and two ASCII strings representing floating-point

	; values.  The values are width and height corresponsing to one pixel

	; in the image.  Data values are valid if (valid & PNG_INFO_sCAL) is

	; non-zero.

	scal_s_width dd ? ;charp ;string containing height

	scal_s_height dd ? ;charp ;string containing width

end if

	; Memory has been allocated if (valid & PNG_ALLOCATED_INFO_ROWS)

	; non-zero

	; Data valid if (valid & PNG_INFO_IDAT) non-zero

	row_pointers dd ? ;bytepp ;the image bits

end if