PageRenderTime 38ms CodeModel.GetById 16ms app.highlight 9ms RepoModel.GetById 1ms app.codeStats 0ms

/src/FreeImage/Source/LibPNG/libpng.txt

https://bitbucket.org/cabalistic/ogredeps/
Plain Text | 1513 lines | 1227 code | 286 blank | 0 comment | 0 complexity | ffa7eb01a237d2219f0020e029830427 MD5 | raw file

Large files files are truncated, but you can click here to view the full file

   1libpng.txt - A description on how to use and modify libpng
   2
   3 libpng version 1.2.41 - December 3, 2009
   4 Updated and distributed by Glenn Randers-Pehrson
   5 <glennrp at users.sourceforge.net>
   6 Copyright (c) 1998-2009 Glenn Randers-Pehrson
   7
   8 This document is released under the libpng license.
   9 For conditions of distribution and use, see the disclaimer
  10 and license in png.h
  11
  12 Based on:
  13
  14 libpng versions 0.97, January 1998, through 1.2.41 - December 3, 2009
  15 Updated and distributed by Glenn Randers-Pehrson
  16 Copyright (c) 1998-2009 Glenn Randers-Pehrson
  17
  18 libpng 1.0 beta 6  version 0.96 May 28, 1997
  19 Updated and distributed by Andreas Dilger
  20 Copyright (c) 1996, 1997 Andreas Dilger
  21
  22 libpng 1.0 beta 2 - version 0.88  January 26, 1996
  23 For conditions of distribution and use, see copyright
  24 notice in png.h. Copyright (c) 1995, 1996 Guy Eric
  25 Schalnat, Group 42, Inc.
  26
  27 Updated/rewritten per request in the libpng FAQ
  28 Copyright (c) 1995, 1996 Frank J. T. Wojcik
  29 December 18, 1995 & January 20, 1996
  30
  31I. Introduction
  32
  33This file describes how to use and modify the PNG reference library
  34(known as libpng) for your own use.  There are five sections to this
  35file: introduction, structures, reading, writing, and modification and
  36configuration notes for various special platforms.  In addition to this
  37file, example.c is a good starting point for using the library, as
  38it is heavily commented and should include everything most people
  39will need.  We assume that libpng is already installed; see the
  40INSTALL file for instructions on how to install libpng.
  41
  42For examples of libpng usage, see the files "example.c", "pngtest.c",
  43and the files in the "contrib" directory, all of which are included in
  44the libpng distribution.
  45
  46Libpng was written as a companion to the PNG specification, as a way
  47of reducing the amount of time and effort it takes to support the PNG
  48file format in application programs.
  49
  50The PNG specification (second edition), November 2003, is available as
  51a W3C Recommendation and as an ISO Standard (ISO/IEC 15948:2003 (E)) at
  52<http://www.w3.org/TR/2003/REC-PNG-20031110/
  53The W3C and ISO documents have identical technical content.
  54
  55The PNG-1.2 specification is available at
  56<http://www.libpng.org/pub/png/documents/>.  It is technically equivalent
  57to the PNG specification (second edition) but has some additional material.
  58
  59The PNG-1.0 specification is available
  60as RFC 2083 <http://www.libpng.org/pub/png/documents/> and as a
  61W3C Recommendation <http://www.w3.org/TR/REC.png.html>.
  62
  63Some additional chunks are described in the special-purpose public chunks
  64documents at <http://www.libpng.org/pub/png/documents/>.
  65
  66Other information
  67about PNG, and the latest version of libpng, can be found at the PNG home
  68page, <http://www.libpng.org/pub/png/>.
  69
  70Most users will not have to modify the library significantly; advanced
  71users may want to modify it more.  All attempts were made to make it as
  72complete as possible, while keeping the code easy to understand.
  73Currently, this library only supports C.  Support for other languages
  74is being considered.
  75
  76Libpng has been designed to handle multiple sessions at one time,
  77to be easily modifiable, to be portable to the vast majority of
  78machines (ANSI, K&R, 16-, 32-, and 64-bit) available, and to be easy
  79to use.  The ultimate goal of libpng is to promote the acceptance of
  80the PNG file format in whatever way possible.  While there is still
  81work to be done (see the TODO file), libpng should cover the
  82majority of the needs of its users.
  83
  84Libpng uses zlib for its compression and decompression of PNG files.
  85Further information about zlib, and the latest version of zlib, can
  86be found at the zlib home page, <http://www.info-zip.org/pub/infozip/zlib/>.
  87The zlib compression utility is a general purpose utility that is
  88useful for more than PNG files, and can be used without libpng.
  89See the documentation delivered with zlib for more details.
  90You can usually find the source files for the zlib utility wherever you
  91find the libpng source files.
  92
  93Libpng is thread safe, provided the threads are using different
  94instances of the structures.  Each thread should have its own
  95png_struct and png_info instances, and thus its own image.
  96Libpng does not protect itself against two threads using the
  97same instance of a structure.
  98
  99II. Structures
 100
 101There are two main structures that are important to libpng, png_struct
 102and png_info.  The first, png_struct, is an internal structure that
 103will not, for the most part, be used by a user except as the first
 104variable passed to every libpng function call.
 105
 106The png_info structure is designed to provide information about the
 107PNG file.  At one time, the fields of png_info were intended to be
 108directly accessible to the user.  However, this tended to cause problems
 109with applications using dynamically loaded libraries, and as a result
 110a set of interface functions for png_info (the png_get_*() and png_set_*()
 111functions) was developed.  The fields of png_info are still available for
 112older applications, but it is suggested that applications use the new
 113interfaces if at all possible.
 114
 115Applications that do make direct access to the members of png_struct (except
 116for png_ptr->jmpbuf) must be recompiled whenever the library is updated,
 117and applications that make direct access to the members of png_info must
 118be recompiled if they were compiled or loaded with libpng version 1.0.6,
 119in which the members were in a different order.  In version 1.0.7, the
 120members of the png_info structure reverted to the old order, as they were
 121in versions 0.97c through 1.0.5.  Starting with version 2.0.0, both
 122structures are going to be hidden, and the contents of the structures will
 123only be accessible through the png_get/png_set functions.
 124
 125The png.h header file is an invaluable reference for programming with libpng.
 126And while I'm on the topic, make sure you include the libpng header file:
 127
 128#include <png.h>
 129
 130III. Reading
 131
 132We'll now walk you through the possible functions to call when reading
 133in a PNG file sequentially, briefly explaining the syntax and purpose
 134of each one.  See example.c and png.h for more detail.  While
 135progressive reading is covered in the next section, you will still
 136need some of the functions discussed in this section to read a PNG
 137file.
 138
 139Setup
 140
 141You will want to do the I/O initialization(*) before you get into libpng,
 142so if it doesn't work, you don't have much to undo.  Of course, you
 143will also want to insure that you are, in fact, dealing with a PNG
 144file.  Libpng provides a simple check to see if a file is a PNG file.
 145To use it, pass in the first 1 to 8 bytes of the file to the function
 146png_sig_cmp(), and it will return 0 (false) if the bytes match the
 147corresponding bytes of the PNG signature, or nonzero (true) otherwise.
 148Of course, the more bytes you pass in, the greater the accuracy of the
 149prediction.
 150
 151If you are intending to keep the file pointer open for use in libpng,
 152you must ensure you don't read more than 8 bytes from the beginning
 153of the file, and you also have to make a call to png_set_sig_bytes_read()
 154with the number of bytes you read from the beginning.  Libpng will
 155then only check the bytes (if any) that your program didn't read.
 156
 157(*): If you are not using the standard I/O functions, you will need
 158to replace them with custom functions.  See the discussion under
 159Customizing libpng.
 160
 161
 162    FILE *fp = fopen(file_name, "rb");
 163    if (!fp)
 164    {
 165        return (ERROR);
 166    }
 167    fread(header, 1, number, fp);
 168    is_png = !png_sig_cmp(header, 0, number);
 169    if (!is_png)
 170    {
 171        return (NOT_PNG);
 172    }
 173
 174
 175Next, png_struct and png_info need to be allocated and initialized.  In
 176order to ensure that the size of these structures is correct even with a
 177dynamically linked libpng, there are functions to initialize and
 178allocate the structures.  We also pass the library version, optional
 179pointers to error handling functions, and a pointer to a data struct for
 180use by the error functions, if necessary (the pointer and functions can
 181be NULL if the default error handlers are to be used).  See the section
 182on Changes to Libpng below regarding the old initialization functions.
 183The structure allocation functions quietly return NULL if they fail to
 184create the structure, so your application should check for that.
 185
 186    png_structp png_ptr = png_create_read_struct
 187       (PNG_LIBPNG_VER_STRING, (png_voidp)user_error_ptr,
 188        user_error_fn, user_warning_fn);
 189    if (!png_ptr)
 190        return (ERROR);
 191
 192    png_infop info_ptr = png_create_info_struct(png_ptr);
 193    if (!info_ptr)
 194    {
 195        png_destroy_read_struct(&png_ptr,
 196           (png_infopp)NULL, (png_infopp)NULL);
 197        return (ERROR);
 198    }
 199
 200    png_infop end_info = png_create_info_struct(png_ptr);
 201    if (!end_info)
 202    {
 203        png_destroy_read_struct(&png_ptr, &info_ptr,
 204          (png_infopp)NULL);
 205        return (ERROR);
 206    }
 207
 208If you want to use your own memory allocation routines,
 209define PNG_USER_MEM_SUPPORTED and use
 210png_create_read_struct_2() instead of png_create_read_struct():
 211
 212    png_structp png_ptr = png_create_read_struct_2
 213       (PNG_LIBPNG_VER_STRING, (png_voidp)user_error_ptr,
 214        user_error_fn, user_warning_fn, (png_voidp)
 215        user_mem_ptr, user_malloc_fn, user_free_fn);
 216
 217The error handling routines passed to png_create_read_struct()
 218and the memory alloc/free routines passed to png_create_struct_2()
 219are only necessary if you are not using the libpng supplied error
 220handling and memory alloc/free functions.
 221
 222When libpng encounters an error, it expects to longjmp back
 223to your routine.  Therefore, you will need to call setjmp and pass
 224your png_jmpbuf(png_ptr).  If you read the file from different
 225routines, you will need to update the jmpbuf field every time you enter
 226a new routine that will call a png_*() function.
 227
 228See your documentation of setjmp/longjmp for your compiler for more
 229information on setjmp/longjmp.  See the discussion on libpng error
 230handling in the Customizing Libpng section below for more information
 231on the libpng error handling.  If an error occurs, and libpng longjmp's
 232back to your setjmp, you will want to call png_destroy_read_struct() to
 233free any memory.
 234
 235    if (setjmp(png_jmpbuf(png_ptr)))
 236    {
 237        png_destroy_read_struct(&png_ptr, &info_ptr,
 238           &end_info);
 239        fclose(fp);
 240        return (ERROR);
 241    }
 242
 243If you would rather avoid the complexity of setjmp/longjmp issues,
 244you can compile libpng with PNG_SETJMP_NOT_SUPPORTED, in which case
 245errors will result in a call to PNG_ABORT() which defaults to abort().
 246
 247Now you need to set up the input code.  The default for libpng is to
 248use the C function fread().  If you use this, you will need to pass a
 249valid FILE * in the function png_init_io().  Be sure that the file is
 250opened in binary mode.  If you wish to handle reading data in another
 251way, you need not call the png_init_io() function, but you must then
 252implement the libpng I/O methods discussed in the Customizing Libpng
 253section below.
 254
 255    png_init_io(png_ptr, fp);
 256
 257If you had previously opened the file and read any of the signature from
 258the beginning in order to see if this was a PNG file, you need to let
 259libpng know that there are some bytes missing from the start of the file.
 260
 261    png_set_sig_bytes(png_ptr, number);
 262
 263Setting up callback code
 264
 265You can set up a callback function to handle any unknown chunks in the
 266input stream. You must supply the function
 267
 268    read_chunk_callback(png_ptr ptr,
 269         png_unknown_chunkp chunk);
 270    {
 271       /* The unknown chunk structure contains your
 272          chunk data, along with similar data for any other
 273          unknown chunks: */
 274
 275           png_byte name[5];
 276           png_byte *data;
 277           png_size_t size;
 278
 279       /* Note that libpng has already taken care of
 280          the CRC handling */
 281
 282       /* put your code here.  Search for your chunk in the
 283          unknown chunk structure, process it, and return one
 284          of the following: */
 285
 286       return (-n); /* chunk had an error */
 287       return (0); /* did not recognize */
 288       return (n); /* success */
 289    }
 290
 291(You can give your function another name that you like instead of
 292"read_chunk_callback")
 293
 294To inform libpng about your function, use
 295
 296    png_set_read_user_chunk_fn(png_ptr, user_chunk_ptr,
 297        read_chunk_callback);
 298
 299This names not only the callback function, but also a user pointer that
 300you can retrieve with
 301
 302    png_get_user_chunk_ptr(png_ptr);
 303
 304If you call the png_set_read_user_chunk_fn() function, then all unknown
 305chunks will be saved when read, in case your callback function will need
 306one or more of them.  This behavior can be changed with the
 307png_set_keep_unknown_chunks() function, described below.
 308
 309At this point, you can set up a callback function that will be
 310called after each row has been read, which you can use to control
 311a progress meter or the like.  It's demonstrated in pngtest.c.
 312You must supply a function
 313
 314    void read_row_callback(png_ptr ptr, png_uint_32 row,
 315       int pass);
 316    {
 317      /* put your code here */
 318    }
 319
 320(You can give it another name that you like instead of "read_row_callback")
 321
 322To inform libpng about your function, use
 323
 324    png_set_read_status_fn(png_ptr, read_row_callback);
 325
 326Unknown-chunk handling
 327
 328Now you get to set the way the library processes unknown chunks in the
 329input PNG stream. Both known and unknown chunks will be read.  Normal
 330behavior is that known chunks will be parsed into information in
 331various info_ptr members while unknown chunks will be discarded. This
 332behavior can be wasteful if your application will never use some known
 333chunk types. To change this, you can call:
 334
 335    png_set_keep_unknown_chunks(png_ptr, keep,
 336        chunk_list, num_chunks);
 337    keep       - 0: default unknown chunk handling
 338                 1: ignore; do not keep
 339                 2: keep only if safe-to-copy
 340                 3: keep even if unsafe-to-copy
 341               You can use these definitions:
 342                 PNG_HANDLE_CHUNK_AS_DEFAULT   0
 343                 PNG_HANDLE_CHUNK_NEVER        1
 344                 PNG_HANDLE_CHUNK_IF_SAFE      2
 345                 PNG_HANDLE_CHUNK_ALWAYS       3
 346    chunk_list - list of chunks affected (a byte string,
 347                 five bytes per chunk, NULL or '\0' if
 348                 num_chunks is 0)
 349    num_chunks - number of chunks affected; if 0, all
 350                 unknown chunks are affected.  If nonzero,
 351                 only the chunks in the list are affected
 352
 353Unknown chunks declared in this way will be saved as raw data onto a
 354list of png_unknown_chunk structures.  If a chunk that is normally
 355known to libpng is named in the list, it will be handled as unknown,
 356according to the "keep" directive.  If a chunk is named in successive
 357instances of png_set_keep_unknown_chunks(), the final instance will
 358take precedence.  The IHDR and IEND chunks should not be named in
 359chunk_list; if they are, libpng will process them normally anyway.
 360
 361Here is an example of the usage of png_set_keep_unknown_chunks(),
 362where the private "vpAg" chunk will later be processed by a user chunk
 363callback function:
 364
 365    png_byte vpAg[5]={118, 112,  65, 103, (png_byte) '\0'};
 366
 367    #if defined(PNG_UNKNOWN_CHUNKS_SUPPORTED)
 368      png_byte unused_chunks[]=
 369      {
 370        104,  73,  83,  84, (png_byte) '\0',   /* hIST */
 371        105,  84,  88, 116, (png_byte) '\0',   /* iTXt */
 372        112,  67,  65,  76, (png_byte) '\0',   /* pCAL */
 373        115,  67,  65,  76, (png_byte) '\0',   /* sCAL */
 374        115,  80,  76,  84, (png_byte) '\0',   /* sPLT */
 375        116,  73,  77,  69, (png_byte) '\0',   /* tIME */
 376      };
 377    #endif
 378
 379    ...
 380
 381    #if defined(PNG_UNKNOWN_CHUNKS_SUPPORTED)
 382      /* ignore all unknown chunks: */
 383      png_set_keep_unknown_chunks(read_ptr, 1, NULL, 0);
 384      /* except for vpAg: */
 385      png_set_keep_unknown_chunks(read_ptr, 2, vpAg, 1);
 386      /* also ignore unused known chunks: */
 387      png_set_keep_unknown_chunks(read_ptr, 1, unused_chunks,
 388         (int)sizeof(unused_chunks)/5);
 389    #endif
 390
 391User limits
 392
 393The PNG specification allows the width and height of an image to be as
 394large as 2^31-1 (0x7fffffff), or about 2.147 billion rows and columns.
 395Since very few applications really need to process such large images,
 396we have imposed an arbitrary 1-million limit on rows and columns.
 397Larger images will be rejected immediately with a png_error() call. If
 398you wish to override this limit, you can use
 399
 400   png_set_user_limits(png_ptr, width_max, height_max);
 401
 402to set your own limits, or use width_max = height_max = 0x7fffffffL
 403to allow all valid dimensions (libpng may reject some very large images
 404anyway because of potential buffer overflow conditions).
 405
 406You should put this statement after you create the PNG structure and
 407before calling png_read_info(), png_read_png(), or png_process_data().
 408If you need to retrieve the limits that are being applied, use
 409
 410   width_max = png_get_user_width_max(png_ptr);
 411   height_max = png_get_user_height_max(png_ptr);
 412
 413The PNG specification sets no limit on the number of ancillary chunks
 414allowed in a PNG datastream.  You can impose a limit on the total number
 415of sPLT, tEXt, iTXt, zTXt, and unknown chunks that will be stored, with
 416
 417   png_set_chunk_cache_max(png_ptr, user_chunk_cache_max);
 418
 419where 0x7fffffffL means unlimited.  You can retrieve this limit with
 420
 421   chunk_cache_max = png_get_chunk_cache_max(png_ptr);
 422
 423This limit also applies to the number of buffers that can be allocated
 424by png_decompress_chunk() while decompressing iTXt, zTXt, and iCCP chunks.
 425
 426The high-level read interface
 427
 428At this point there are two ways to proceed; through the high-level
 429read interface, or through a sequence of low-level read operations.
 430You can use the high-level interface if (a) you are willing to read
 431the entire image into memory, and (b) the input transformations
 432you want to do are limited to the following set:
 433
 434    PNG_TRANSFORM_IDENTITY      No transformation
 435    PNG_TRANSFORM_STRIP_16      Strip 16-bit samples to
 436                                8 bits
 437    PNG_TRANSFORM_STRIP_ALPHA   Discard the alpha channel
 438    PNG_TRANSFORM_PACKING       Expand 1, 2 and 4-bit
 439                                samples to bytes
 440    PNG_TRANSFORM_PACKSWAP      Change order of packed
 441                                pixels to LSB first
 442    PNG_TRANSFORM_EXPAND        Perform set_expand()
 443    PNG_TRANSFORM_INVERT_MONO   Invert monochrome images
 444    PNG_TRANSFORM_SHIFT         Normalize pixels to the
 445                                sBIT depth
 446    PNG_TRANSFORM_BGR           Flip RGB to BGR, RGBA
 447                                to BGRA
 448    PNG_TRANSFORM_SWAP_ALPHA    Flip RGBA to ARGB or GA
 449                                to AG
 450    PNG_TRANSFORM_INVERT_ALPHA  Change alpha from opacity
 451                                to transparency
 452    PNG_TRANSFORM_SWAP_ENDIAN   Byte-swap 16-bit samples
 453    PNG_TRANSFORM_GRAY_TO_RGB   Expand grayscale samples
 454                                to RGB (or GA to RGBA)
 455
 456(This excludes setting a background color, doing gamma transformation,
 457dithering, and setting filler.)  If this is the case, simply do this:
 458
 459    png_read_png(png_ptr, info_ptr, png_transforms, NULL)
 460
 461where png_transforms is an integer containing the bitwise OR of some
 462set of transformation flags.  This call is equivalent to png_read_info(),
 463followed the set of transformations indicated by the transform mask,
 464then png_read_image(), and finally png_read_end().
 465
 466(The final parameter of this call is not yet used.  Someday it might point
 467to transformation parameters required by some future input transform.)
 468
 469You must use png_transforms and not call any png_set_transform() functions
 470when you use png_read_png().
 471
 472After you have called png_read_png(), you can retrieve the image data
 473with
 474
 475   row_pointers = png_get_rows(png_ptr, info_ptr);
 476
 477where row_pointers is an array of pointers to the pixel data for each row:
 478
 479   png_bytep row_pointers[height];
 480
 481If you know your image size and pixel size ahead of time, you can allocate
 482row_pointers prior to calling png_read_png() with
 483
 484   if (height > PNG_UINT_32_MAX/png_sizeof(png_byte))
 485      png_error (png_ptr,
 486         "Image is too tall to process in memory");
 487   if (width > PNG_UINT_32_MAX/pixel_size)
 488      png_error (png_ptr,
 489         "Image is too wide to process in memory");
 490   row_pointers = png_malloc(png_ptr,
 491      height*png_sizeof(png_bytep));
 492   for (int i=0; i<height, i++)
 493      row_pointers[i]=NULL;  /* security precaution */
 494   for (int i=0; i<height, i++)
 495      row_pointers[i]=png_malloc(png_ptr,
 496         width*pixel_size);
 497   png_set_rows(png_ptr, info_ptr, &row_pointers);
 498
 499Alternatively you could allocate your image in one big block and define
 500row_pointers[i] to point into the proper places in your block.
 501
 502If you use png_set_rows(), the application is responsible for freeing
 503row_pointers (and row_pointers[i], if they were separately allocated).
 504
 505If you don't allocate row_pointers ahead of time, png_read_png() will
 506do it, and it'll be free'ed when you call png_destroy_*().
 507
 508The low-level read interface
 509
 510If you are going the low-level route, you are now ready to read all
 511the file information up to the actual image data.  You do this with a
 512call to png_read_info().
 513
 514    png_read_info(png_ptr, info_ptr);
 515
 516This will process all chunks up to but not including the image data.
 517
 518Querying the info structure
 519
 520Functions are used to get the information from the info_ptr once it
 521has been read.  Note that these fields may not be completely filled
 522in until png_read_end() has read the chunk data following the image.
 523
 524    png_get_IHDR(png_ptr, info_ptr, &width, &height,
 525       &bit_depth, &color_type, &interlace_type,
 526       &compression_type, &filter_method);
 527
 528    width          - holds the width of the image
 529                     in pixels (up to 2^31).
 530    height         - holds the height of the image
 531                     in pixels (up to 2^31).
 532    bit_depth      - holds the bit depth of one of the
 533                     image channels.  (valid values are
 534                     1, 2, 4, 8, 16 and depend also on
 535                     the color_type.  See also
 536                     significant bits (sBIT) below).
 537    color_type     - describes which color/alpha channels
 538                         are present.
 539                     PNG_COLOR_TYPE_GRAY
 540                        (bit depths 1, 2, 4, 8, 16)
 541                     PNG_COLOR_TYPE_GRAY_ALPHA
 542                        (bit depths 8, 16)
 543                     PNG_COLOR_TYPE_PALETTE
 544                        (bit depths 1, 2, 4, 8)
 545                     PNG_COLOR_TYPE_RGB
 546                        (bit_depths 8, 16)
 547                     PNG_COLOR_TYPE_RGB_ALPHA
 548                        (bit_depths 8, 16)
 549
 550                     PNG_COLOR_MASK_PALETTE
 551                     PNG_COLOR_MASK_COLOR
 552                     PNG_COLOR_MASK_ALPHA
 553
 554    filter_method  - (must be PNG_FILTER_TYPE_BASE
 555                     for PNG 1.0, and can also be
 556                     PNG_INTRAPIXEL_DIFFERENCING if
 557                     the PNG datastream is embedded in
 558                     a MNG-1.0 datastream)
 559    compression_type - (must be PNG_COMPRESSION_TYPE_BASE
 560                     for PNG 1.0)
 561    interlace_type - (PNG_INTERLACE_NONE or
 562                     PNG_INTERLACE_ADAM7)
 563
 564    Any or all of interlace_type, compression_type, or
 565    filter_method can be NULL if you are
 566    not interested in their values.
 567
 568    Note that png_get_IHDR() returns 32-bit data into
 569    the application's width and height variables.
 570    This is an unsafe situation if these are 16-bit
 571    variables.  In such situations, the
 572    png_get_image_width() and png_get_image_height()
 573    functions described below are safer.
 574
 575    width            = png_get_image_width(png_ptr,
 576                         info_ptr);
 577    height           = png_get_image_height(png_ptr,
 578                         info_ptr);
 579    bit_depth        = png_get_bit_depth(png_ptr,
 580                         info_ptr);
 581    color_type       = png_get_color_type(png_ptr,
 582                         info_ptr);
 583    filter_method    = png_get_filter_type(png_ptr,
 584                         info_ptr);
 585    compression_type = png_get_compression_type(png_ptr,
 586                         info_ptr);
 587    interlace_type   = png_get_interlace_type(png_ptr,
 588                         info_ptr);
 589
 590    channels = png_get_channels(png_ptr, info_ptr);
 591    channels       - number of channels of info for the
 592                     color type (valid values are 1 (GRAY,
 593                     PALETTE), 2 (GRAY_ALPHA), 3 (RGB),
 594                     4 (RGB_ALPHA or RGB + filler byte))
 595    rowbytes = png_get_rowbytes(png_ptr, info_ptr);
 596    rowbytes       - number of bytes needed to hold a row
 597
 598    signature = png_get_signature(png_ptr, info_ptr);
 599    signature      - holds the signature read from the
 600                     file (if any).  The data is kept in
 601                     the same offset it would be if the
 602                     whole signature were read (i.e. if an
 603                     application had already read in 4
 604                     bytes of signature before starting
 605                     libpng, the remaining 4 bytes would
 606                     be in signature[4] through signature[7]
 607                     (see png_set_sig_bytes())).
 608
 609These are also important, but their validity depends on whether the chunk
 610has been read.  The png_get_valid(png_ptr, info_ptr, PNG_INFO_<chunk>) and
 611png_get_<chunk>(png_ptr, info_ptr, ...) functions return non-zero if the
 612data has been read, or zero if it is missing.  The parameters to the
 613png_get_<chunk> are set directly if they are simple data types, or a
 614pointer into the info_ptr is returned for any complex types.
 615
 616    png_get_PLTE(png_ptr, info_ptr, &palette,
 617                     &num_palette);
 618    palette        - the palette for the file
 619                     (array of png_color)
 620    num_palette    - number of entries in the palette
 621
 622    png_get_gAMA(png_ptr, info_ptr, &gamma);
 623    gamma          - the gamma the file is written
 624                     at (PNG_INFO_gAMA)
 625
 626    png_get_sRGB(png_ptr, info_ptr, &srgb_intent);
 627    srgb_intent    - the rendering intent (PNG_INFO_sRGB)
 628                     The presence of the sRGB chunk
 629                     means that the pixel data is in the
 630                     sRGB color space.  This chunk also
 631                     implies specific values of gAMA and
 632                     cHRM.
 633
 634    png_get_iCCP(png_ptr, info_ptr, &name,
 635       &compression_type, &profile, &proflen);
 636    name            - The profile name.
 637    compression     - The compression type; always
 638                      PNG_COMPRESSION_TYPE_BASE for PNG 1.0.
 639                      You may give NULL to this argument to
 640                      ignore it.
 641    profile         - International Color Consortium color
 642                      profile data. May contain NULs.
 643    proflen         - length of profile data in bytes.
 644
 645    png_get_sBIT(png_ptr, info_ptr, &sig_bit);
 646    sig_bit        - the number of significant bits for
 647                     (PNG_INFO_sBIT) each of the gray,
 648                     red, green, and blue channels,
 649                     whichever are appropriate for the
 650                     given color type (png_color_16)
 651
 652    png_get_tRNS(png_ptr, info_ptr, &trans, &num_trans,
 653                     &trans_values);
 654    trans          - array of transparent
 655                     entries for palette (PNG_INFO_tRNS)
 656    trans_values   - graylevel or color sample values of
 657                     the single transparent color for
 658                     non-paletted images (PNG_INFO_tRNS)
 659    num_trans      - number of transparent entries
 660                     (PNG_INFO_tRNS)
 661
 662    png_get_hIST(png_ptr, info_ptr, &hist);
 663                     (PNG_INFO_hIST)
 664    hist           - histogram of palette (array of
 665                     png_uint_16)
 666
 667    png_get_tIME(png_ptr, info_ptr, &mod_time);
 668    mod_time       - time image was last modified
 669                    (PNG_VALID_tIME)
 670
 671    png_get_bKGD(png_ptr, info_ptr, &background);
 672    background     - background color (PNG_VALID_bKGD)
 673                     valid 16-bit red, green and blue
 674                     values, regardless of color_type
 675
 676    num_comments   = png_get_text(png_ptr, info_ptr,
 677                     &text_ptr, &num_text);
 678    num_comments   - number of comments
 679    text_ptr       - array of png_text holding image
 680                     comments
 681    text_ptr[i].compression - type of compression used
 682                 on "text" PNG_TEXT_COMPRESSION_NONE
 683                           PNG_TEXT_COMPRESSION_zTXt
 684                           PNG_ITXT_COMPRESSION_NONE
 685                           PNG_ITXT_COMPRESSION_zTXt
 686    text_ptr[i].key   - keyword for comment.  Must contain
 687                         1-79 characters.
 688    text_ptr[i].text  - text comments for current
 689                         keyword.  Can be empty.
 690    text_ptr[i].text_length - length of text string,
 691                 after decompression, 0 for iTXt
 692    text_ptr[i].itxt_length - length of itxt string,
 693                 after decompression, 0 for tEXt/zTXt
 694    text_ptr[i].lang  - language of comment (empty
 695                         string for unknown).
 696    text_ptr[i].lang_key  - keyword in UTF-8
 697                         (empty string for unknown).
 698    Note that the itxt_length, lang, and lang_key
 699    members of the text_ptr structure only exist
 700    when the library is built with iTXt chunk support.
 701
 702    num_text       - number of comments (same as
 703                     num_comments; you can put NULL here
 704                     to avoid the duplication)
 705    Note while png_set_text() will accept text, language,
 706    and translated keywords that can be NULL pointers, the
 707    structure returned by png_get_text will always contain
 708    regular zero-terminated C strings.  They might be
 709    empty strings but they will never be NULL pointers.
 710
 711    num_spalettes = png_get_sPLT(png_ptr, info_ptr,
 712       &palette_ptr);
 713    palette_ptr    - array of palette structures holding
 714                     contents of one or more sPLT chunks
 715                     read.
 716    num_spalettes  - number of sPLT chunks read.
 717
 718    png_get_oFFs(png_ptr, info_ptr, &offset_x, &offset_y,
 719       &unit_type);
 720    offset_x       - positive offset from the left edge
 721                     of the screen
 722    offset_y       - positive offset from the top edge
 723                     of the screen
 724    unit_type      - PNG_OFFSET_PIXEL, PNG_OFFSET_MICROMETER
 725
 726    png_get_pHYs(png_ptr, info_ptr, &res_x, &res_y,
 727       &unit_type);
 728    res_x          - pixels/unit physical resolution in
 729                     x direction
 730    res_y          - pixels/unit physical resolution in
 731                     x direction
 732    unit_type      - PNG_RESOLUTION_UNKNOWN,
 733                     PNG_RESOLUTION_METER
 734
 735    png_get_sCAL(png_ptr, info_ptr, &unit, &width,
 736       &height)
 737    unit        - physical scale units (an integer)
 738    width       - width of a pixel in physical scale units
 739    height      - height of a pixel in physical scale units
 740                 (width and height are doubles)
 741
 742    png_get_sCAL_s(png_ptr, info_ptr, &unit, &width,
 743       &height)
 744    unit        - physical scale units (an integer)
 745    width       - width of a pixel in physical scale units
 746    height      - height of a pixel in physical scale units
 747                 (width and height are strings like "2.54")
 748
 749    num_unknown_chunks = png_get_unknown_chunks(png_ptr,
 750       info_ptr, &unknowns)
 751    unknowns          - array of png_unknown_chunk
 752                        structures holding unknown chunks
 753    unknowns[i].name  - name of unknown chunk
 754    unknowns[i].data  - data of unknown chunk
 755    unknowns[i].size  - size of unknown chunk's data
 756    unknowns[i].location - position of chunk in file
 757
 758    The value of "i" corresponds to the order in which the
 759    chunks were read from the PNG file or inserted with the
 760    png_set_unknown_chunks() function.
 761
 762The data from the pHYs chunk can be retrieved in several convenient
 763forms:
 764
 765    res_x = png_get_x_pixels_per_meter(png_ptr,
 766       info_ptr)
 767    res_y = png_get_y_pixels_per_meter(png_ptr,
 768       info_ptr)
 769    res_x_and_y = png_get_pixels_per_meter(png_ptr,
 770       info_ptr)
 771    res_x = png_get_x_pixels_per_inch(png_ptr,
 772       info_ptr)
 773    res_y = png_get_y_pixels_per_inch(png_ptr,
 774       info_ptr)
 775    res_x_and_y = png_get_pixels_per_inch(png_ptr,
 776       info_ptr)
 777    aspect_ratio = png_get_pixel_aspect_ratio(png_ptr,
 778       info_ptr)
 779
 780   (Each of these returns 0 [signifying "unknown"] if
 781       the data is not present or if res_x is 0;
 782       res_x_and_y is 0 if res_x != res_y)
 783
 784The data from the oFFs chunk can be retrieved in several convenient
 785forms:
 786
 787    x_offset = png_get_x_offset_microns(png_ptr, info_ptr);
 788    y_offset = png_get_y_offset_microns(png_ptr, info_ptr);
 789    x_offset = png_get_x_offset_inches(png_ptr, info_ptr);
 790    y_offset = png_get_y_offset_inches(png_ptr, info_ptr);
 791
 792   (Each of these returns 0 [signifying "unknown" if both
 793       x and y are 0] if the data is not present or if the
 794       chunk is present but the unit is the pixel)
 795
 796For more information, see the png_info definition in png.h and the
 797PNG specification for chunk contents.  Be careful with trusting
 798rowbytes, as some of the transformations could increase the space
 799needed to hold a row (expand, filler, gray_to_rgb, etc.).
 800See png_read_update_info(), below.
 801
 802A quick word about text_ptr and num_text.  PNG stores comments in
 803keyword/text pairs, one pair per chunk, with no limit on the number
 804of text chunks, and a 2^31 byte limit on their size.  While there are
 805suggested keywords, there is no requirement to restrict the use to these
 806strings.  It is strongly suggested that keywords and text be sensible
 807to humans (that's the point), so don't use abbreviations.  Non-printing
 808symbols are not allowed.  See the PNG specification for more details.
 809There is also no requirement to have text after the keyword.
 810
 811Keywords should be limited to 79 Latin-1 characters without leading or
 812trailing spaces, but non-consecutive spaces are allowed within the
 813keyword.  It is possible to have the same keyword any number of times.
 814The text_ptr is an array of png_text structures, each holding a
 815pointer to a language string, a pointer to a keyword and a pointer to
 816a text string.  The text string, language code, and translated
 817keyword may be empty or NULL pointers.  The keyword/text
 818pairs are put into the array in the order that they are received.
 819However, some or all of the text chunks may be after the image, so, to
 820make sure you have read all the text chunks, don't mess with these
 821until after you read the stuff after the image.  This will be
 822mentioned again below in the discussion that goes with png_read_end().
 823
 824Input transformations
 825
 826After you've read the header information, you can set up the library
 827to handle any special transformations of the image data.  The various
 828ways to transform the data will be described in the order that they
 829should occur.  This is important, as some of these change the color
 830type and/or bit depth of the data, and some others only work on
 831certain color types and bit depths.  Even though each transformation
 832checks to see if it has data that it can do something with, you should
 833make sure to only enable a transformation if it will be valid for the
 834data.  For example, don't swap red and blue on grayscale data.
 835
 836The colors used for the background and transparency values should be
 837supplied in the same format/depth as the current image data.  They
 838are stored in the same format/depth as the image data in a bKGD or tRNS
 839chunk, so this is what libpng expects for this data.  The colors are
 840transformed to keep in sync with the image data when an application
 841calls the png_read_update_info() routine (see below).
 842
 843Data will be decoded into the supplied row buffers packed into bytes
 844unless the library has been told to transform it into another format.
 845For example, 4 bit/pixel paletted or grayscale data will be returned
 8462 pixels/byte with the leftmost pixel in the high-order bits of the
 847byte, unless png_set_packing() is called.  8-bit RGB data will be stored
 848in RGB RGB RGB format unless png_set_filler() or png_set_add_alpha()
 849is called to insert filler bytes, either before or after each RGB triplet.
 85016-bit RGB data will be returned RRGGBB RRGGBB, with the most significant
 851byte of the color value first, unless png_set_strip_16() is called to
 852transform it to regular RGB RGB triplets, or png_set_filler() or
 853png_set_add alpha() is called to insert filler bytes, either before or
 854after each RRGGBB triplet.  Similarly, 8-bit or 16-bit grayscale data can
 855be modified with
 856png_set_filler(), png_set_add_alpha(), or png_set_strip_16().
 857
 858The following code transforms grayscale images of less than 8 to 8 bits,
 859changes paletted images to RGB, and adds a full alpha channel if there is
 860transparency information in a tRNS chunk.  This is most useful on
 861grayscale images with bit depths of 2 or 4 or if there is a multiple-image
 862viewing application that wishes to treat all images in the same way.
 863
 864    if (color_type == PNG_COLOR_TYPE_PALETTE)
 865        png_set_palette_to_rgb(png_ptr);
 866
 867    if (color_type == PNG_COLOR_TYPE_GRAY &&
 868        bit_depth < 8) png_set_expand_gray_1_2_4_to_8(png_ptr);
 869
 870    if (png_get_valid(png_ptr, info_ptr,
 871        PNG_INFO_tRNS)) png_set_tRNS_to_alpha(png_ptr);
 872
 873These three functions are actually aliases for png_set_expand(), added
 874in libpng version 1.0.4, with the function names expanded to improve code
 875readability.  In some future version they may actually do different
 876things.
 877
 878As of libpng version 1.2.9, png_set_expand_gray_1_2_4_to_8() was
 879added.  It expands the sample depth without changing tRNS to alpha.
 880
 881As of libpng version 1.2.41, not all possible expansions are supported.
 882
 883In the following table, the 01 means grayscale with depth<8, 31 means
 884indexed with depth<8, other numerals represent the color type, "T" means
 885the tRNS chunk is present, A means an alpha channel is present, and O
 886means tRNS or alpha is present but all pixels in the image are opaque.
 887
 888  FROM  01  31   0  0T  0O   2  2T  2O   3  3T  3O  4A  4O  6A  6O 
 889   TO
 890   01    -                   
 891   31        -
 892    0    1       -           
 893   0T                -
 894   0O                    -
 895    2           GX           -
 896   2T                            -
 897   2O                                -
 898    3        1                           -
 899   3T                                        -
 900   3O                                            -
 901   4A                T                               -
 902   4O                                                    -
 903   6A               GX         TX           TX               -
 904   6O                   GX                      TX               -
 905
 906Within the matrix,
 907     "-" means the transformation is not supported.
 908     "X" means the transformation is obtained by png_set_expand().
 909     "1" means the transformation is obtained by
 910         png_set_expand_gray_1_2_4_to_8
 911     "G" means the transformation is obtained by
 912         png_set_gray_to_rgb().
 913     "P" means the transformation is obtained by
 914         png_set_expand_palette_to_rgb().
 915     "T" means the transformation is obtained by
 916         png_set_tRNS_to_alpha().
 917
 918PNG can have files with 16 bits per channel.  If you only can handle
 9198 bits per channel, this will strip the pixels down to 8 bit.
 920
 921    if (bit_depth == 16)
 922        png_set_strip_16(png_ptr);
 923
 924If, for some reason, you don't need the alpha channel on an image,
 925and you want to remove it rather than combining it with the background
 926(but the image author certainly had in mind that you *would* combine
 927it with the background, so that's what you should probably do):
 928
 929    if (color_type & PNG_COLOR_MASK_ALPHA)
 930        png_set_strip_alpha(png_ptr);
 931
 932In PNG files, the alpha channel in an image
 933is the level of opacity.  If you need the alpha channel in an image to
 934be the level of transparency instead of opacity, you can invert the
 935alpha channel (or the tRNS chunk data) after it's read, so that 0 is
 936fully opaque and 255 (in 8-bit or paletted images) or 65535 (in 16-bit
 937images) is fully transparent, with
 938
 939    png_set_invert_alpha(png_ptr);
 940
 941The PNG format only supports pixels with postmultiplied alpha.
 942If you want to replace the pixels, after reading them, with pixels
 943that have premultiplied color samples, you can do this with
 944
 945    png_set_premultiply_alpha(png_ptr);
 946
 947If you do this, any input with a tRNS chunk will be expanded to
 948have an alpha channel.
 949
 950PNG files pack pixels of bit depths 1, 2, and 4 into bytes as small as
 951they can, resulting in, for example, 8 pixels per byte for 1 bit
 952files.  This code expands to 1 pixel per byte without changing the
 953values of the pixels:
 954
 955    if (bit_depth < 8)
 956        png_set_packing(png_ptr);
 957
 958PNG files have possible bit depths of 1, 2, 4, 8, and 16.  All pixels
 959stored in a PNG image have been "scaled" or "shifted" up to the next
 960higher possible bit depth (e.g. from 5 bits/sample in the range [0,31]
 961to 8 bits/sample in the range [0, 255]).  However, it is also possible
 962to convert the PNG pixel data back to the original bit depth of the
 963image.  This call reduces the pixels back down to the original bit depth:
 964
 965    png_color_8p sig_bit;
 966
 967    if (png_get_sBIT(png_ptr, info_ptr, &sig_bit))
 968        png_set_shift(png_ptr, sig_bit);
 969
 970PNG files store 3-color pixels in red, green, blue order.  This code
 971changes the storage of the pixels to blue, green, red:
 972
 973    if (color_type == PNG_COLOR_TYPE_RGB ||
 974        color_type == PNG_COLOR_TYPE_RGB_ALPHA)
 975        png_set_bgr(png_ptr);
 976
 977PNG files store RGB pixels packed into 3 or 6 bytes. This code expands them
 978into 4 or 8 bytes for windowing systems that need them in this format:
 979
 980    if (color_type == PNG_COLOR_TYPE_RGB)
 981        png_set_filler(png_ptr, filler, PNG_FILLER_BEFORE);
 982
 983where "filler" is the 8 or 16-bit number to fill with, and the location is
 984either PNG_FILLER_BEFORE or PNG_FILLER_AFTER, depending upon whether
 985you want the filler before the RGB or after.  This transformation
 986does not affect images that already have full alpha channels.  To add an
 987opaque alpha channel, use filler=0xff or 0xffff and PNG_FILLER_AFTER which
 988will generate RGBA pixels.
 989
 990Note that png_set_filler() does not change the color type.  If you want
 991to do that, you can add a true alpha channel with
 992
 993    if (color_type == PNG_COLOR_TYPE_RGB ||
 994           color_type == PNG_COLOR_TYPE_GRAY)
 995    png_set_add_alpha(png_ptr, filler, PNG_FILLER_AFTER);
 996
 997where "filler" contains the alpha value to assign to each pixel.
 998This function was added in libpng-1.2.7.
 999
1000If you are reading an image with an alpha channel, and you need the
1001data as ARGB instead of the normal PNG format RGBA:
1002
1003    if (color_type == PNG_COLOR_TYPE_RGB_ALPHA)
1004        png_set_swap_alpha(png_ptr);
1005
1006For some uses, you may want a grayscale image to be represented as
1007RGB.  This code will do that conversion:
1008
1009    if (color_type == PNG_COLOR_TYPE_GRAY ||
1010        color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
1011          png_set_gray_to_rgb(png_ptr);
1012
1013Conversely, you can convert an RGB or RGBA image to grayscale or grayscale
1014with alpha.
1015
1016    if (color_type == PNG_COLOR_TYPE_RGB ||
1017        color_type == PNG_COLOR_TYPE_RGB_ALPHA)
1018          png_set_rgb_to_gray_fixed(png_ptr, error_action,
1019             int red_weight, int green_weight);
1020
1021    error_action = 1: silently do the conversion
1022    error_action = 2: issue a warning if the original
1023                      image has any pixel where
1024                      red != green or red != blue
1025    error_action = 3: issue an error and abort the
1026                      conversion if the original
1027                      image has any pixel where
1028                      red != green or red != blue
1029
1030    red_weight:       weight of red component times 100000
1031    green_weight:     weight of green component times 100000
1032                      If either weight is negative, default
1033                      weights (21268, 71514) are used.
1034
1035If you have set error_action = 1 or 2, you can
1036later check whether the image really was gray, after processing
1037the image rows, with the png_get_rgb_to_gray_status(png_ptr) function.
1038It will return a png_byte that is zero if the image was gray or
10391 if there were any non-gray pixels.  bKGD and sBIT data
1040will be silently converted to grayscale, using the green channel
1041data, regardless of the error_action setting.
1042
1043With red_weight+green_weight<=100000,
1044the normalized graylevel is computed:
1045
1046    int rw = red_weight * 65536;
1047    int gw = green_weight * 65536;
1048    int bw = 65536 - (rw + gw);
1049    gray = (rw*red + gw*green + bw*blue)/65536;
1050
1051The default values approximate those recommended in the Charles
1052Poynton's Color FAQ, <http://www.inforamp.net/~poynton/>
1053Copyright (c) 1998-01-04 Charles Poynton <poynton at inforamp.net>
1054
1055    Y = 0.212671 * R + 0.715160 * G + 0.072169 * B
1056
1057Libpng approximates this with
1058
1059    Y = 0.21268 * R    + 0.7151 * G    + 0.07217 * B
1060
1061which can be expressed with integers as
1062
1063    Y = (6969 * R + 23434 * G + 2365 * B)/32768
1064
1065The calculation is done in a linear colorspace, if the image gamma
1066is known.
1067
1068If you have a grayscale and you are using png_set_expand_depth(),
1069png_set_expand(), or png_set_gray_to_rgb to change to truecolor or to
1070a higher bit-depth, you must either supply the background color as a gray
1071value at the original file bit-depth (need_expand = 1) or else supply the
1072background color as an RGB triplet at the final, expanded bit depth
1073(need_expand = 0).  Similarly, if you are reading a paletted image, you
1074must either supply the background color as a palette index (need_expand = 1)
1075or as an RGB triplet that may or may not be in the palette (need_expand = 0).
1076
1077    png_color_16 my_background;
1078    png_color_16p image_background;
1079
1080    if (png_get_bKGD(png_ptr, info_ptr, &image_background))
1081        png_set_background(png_ptr, image_background,
1082          PNG_BACKGROUND_GAMMA_FILE, 1, 1.0);
1083    else
1084        png_set_background(png_ptr, &my_background,
1085          PNG_BACKGROUND_GAMMA_SCREEN, 0, 1.0);
1086
1087The png_set_background() function tells libpng to composite images
1088with alpha or simple transparency against the supplied background
1089color.  If the PNG file contains a bKGD chunk (PNG_INFO_bKGD valid),
1090you may use this color, or supply another color more suitable for
1091the current display (e.g., the background color from a web page).  You
1092need to tell libpng whether the color is in the gamma space of the
1093display (PNG_BACKGROUND_GAMMA_SCREEN for colors you supply), the file
1094(PNG_BACKGROUND_GAMMA_FILE for colors from the bKGD chunk), or one
1095that is neither of these gammas (PNG_BACKGROUND_GAMMA_UNIQUE - I don't
1096know why anyone would use this, but it's here).
1097
1098To properly display PNG images on any kind of system, the application needs
1099to know what the display gamma is.  Ideally, the user will know this, and
1100the application will allow them to set it.  One method of allowing the user
1101to set the display gamma separately for each system is to check for a
1102SCREEN_GAMMA or DISPLAY_GAMMA environment variable, which will hopefully be
1103correctly set.
1104
1105Note that display_gamma is the overall gamma correction required to produce
1106pleasing results, which depends on the lighting conditions in the surrounding
1107environment.  In a dim or brightly lit room, no compensation other than
1108the physical gamma exponent of the monitor is needed, while in a dark room
1109a slightly smaller exponent is better.
1110
1111   double gamma, screen_gamma;
1112
1113   if (/* We have a user-defined screen
1114       gamma value */)
1115   {
1116      screen_gamma = user_defined_screen_gamma;
1117   }
1118   /* One way that applications can share the same
1119      screen gamma value */
1120   else if ((gamma_str = getenv("SCREEN_GAMMA"))
1121      != NULL)
1122   {
1123      screen_gamma = (double)atof(gamma_str);
1124   }
1125   /* If we don't have another value */
1126   else
1127   {
1128      screen_gamma = 2.2; /* A good guess for a
1129           PC monitor in a bright office or a dim room */
1130      screen_gamma = 2.0; /* A good guess for a
1131           PC monitor in a dark room */
1132      screen_gamma = 1.7 or 1.0;  /* A good
1133           guess for Mac systems */
1134   }
1135
1136The png_set_gamma() function handles gamma transformations of the data.
1137Pass both the file gamma and the current screen_gamma.  If the file does
1138not have a gamma value, you can pass one anyway if you have an idea what
1139it is (usually 0.45455 is a good guess for GIF images on PCs).  Note
1140that file gammas are inverted from screen gammas.  See the discussions
1141on gamma in the PNG specification for an excellent description of what
1142gamma is, and why all applications should support it.  It is strongly
1143recommended that PNG viewers support gamma correction.
1144
1145   if (png_get_gAMA(png_ptr, info_ptr, &gamma))
1146      png_set_gamma(png_ptr, screen_gamma, gamma);
1147   else
1148      png_set_gamma(png_ptr, screen_gamma, 0.45455);
1149
1150If you need to reduce an RGB file to a pal…

Large files files are truncated, but you can click here to view the full file