FreeImage updated to 3.15.4

removed not used formats

git-svn-id: http://svn.miranda-ng.org/main/trunk@2926 1316c22d-e87f-b044-9b9b-93d7a3e3ba9c

1 files changed, 120 insertions, 76 deletions

diff --git a/plugins/AdvaImg/src/LibPNG/libpng.3 b/plugins/AdvaImg/src/LibPNG/libpng.3
index 1d72ab4cae..e0e0aec725 100644
--- a/plugins/AdvaImg/src/LibPNG/libpng.3
+++ b/plugins/AdvaImg/src/LibPNG/libpng.3
@@ -1,6 +1,6 @@
-.TH LIBPNG 3 "February 18, 2012"

+.TH LIBPNG 3 "September 27, 2012"

 .SH NAME

-libpng \- Portable Network Graphics (PNG) Reference Library 1.5.9

+libpng \- Portable Network Graphics (PNG) Reference Library 1.5.13

 .SH SYNOPSIS

 \fI\fB

 

@@ -552,6 +552,10 @@ libpng \- Portable Network Graphics (PNG) Reference Library 1.5.9
 

 \fI\fB

 

+\fBvoid png_set_check_for_invalid_index(png_structrp \fP\fIpng_ptr\fP\fB, int \fIallowed\fP\fB);\fP

+

+\fI\fB

+

 \fBvoid png_set_cHRM (png_structp \fP\fIpng_ptr\fP\fB, png_infop \fP\fIinfo_ptr\fP\fB, double \fP\fIwhite_x\fP\fB, double \fP\fIwhite_y\fP\fB, double \fP\fIred_x\fP\fB, double \fP\fIred_y\fP\fB, double \fP\fIgreen_x\fP\fB, double \fP\fIgreen_y\fP\fB, double \fP\fIblue_x\fP\fB, double \fIblue_y\fP\fB);\fP

 

 \fI\fB

@@ -958,14 +962,6 @@ libpng \- Portable Network Graphics (PNG) Reference Library 1.5.9
 

 \fI\fB

 

-\fBvoidpf png_zalloc (voidpf \fP\fIpng_ptr\fP\fB, uInt \fP\fIitems\fP\fB, uInt \fIsize\fP\fB);\fP

-

-\fI\fB

-

-\fBvoid png_zfree (voidpf \fP\fIpng_ptr\fP\fB, voidpf \fIptr\fP\fB);\fP

-

-\fI\fB

-

 .SH DESCRIPTION

 The

 .I libpng

@@ -975,12 +971,12 @@ the Portable Network Graphics (PNG) format image files.  It uses the
 compression library.

 Following is a copy of the libpng-manual.txt file that accompanies libpng.

 .SH LIBPNG.TXT

-libpng-manual.txt - A description on how to use and modify libpng

+Libpng-manual.txt - A description on how to use and modify libpng

 

- libpng version 1.5.9 - February 18, 2012

+ libpng version 1.5.13 - September 27, 2012

  Updated and distributed by Glenn Randers-Pehrson

  <glennrp at users.sourceforge.net>

- Copyright (c) 1998-2011 Glenn Randers-Pehrson

+ Copyright (c) 1998-2012 Glenn Randers-Pehrson

 

  This document is released under the libpng license.

  For conditions of distribution and use, see the disclaimer

@@ -988,9 +984,9 @@ libpng-manual.txt - A description on how to use and modify libpng
 

  Based on:

 

- libpng versions 0.97, January 1998, through 1.5.9 - February 18, 2012

+ libpng versions 0.97, January 1998, through 1.5.13 - September 27, 2012

  Updated and distributed by Glenn Randers-Pehrson

- Copyright (c) 1998-2011 Glenn Randers-Pehrson

+ Copyright (c) 1998-2012 Glenn Randers-Pehrson

 

  libpng 1.0 beta 6  version 0.96 May 28, 1997

  Updated and distributed by Andreas Dilger

@@ -1118,8 +1114,8 @@ APIs.  Most of these are fairly obvious; for example types corresponding
 to integers of particular sizes and types for passing color values.

 

 One exception is how non-integral numbers are handled.  For application

-convenience most APIs that take such numbers have C (double) arguments,

-however internally PNG, and libpng, use 32 bit signed integers and encode

+convenience most APIs that take such numbers have C (double) arguments;

+however, internally PNG, and libpng, use 32 bit signed integers and encode

 the value by multiplying by 100,000.  As of libpng 1.5.0 a convenience

 macro PNG_FP_1 is defined in png.h along with a type (png_fixed_point)

 which is simply (png_int_32).

@@ -1700,11 +1696,11 @@ Libpng only supports composing onto a single color (using png_set_background;
 see below).  Otherwise you must do the composition yourself and, in this case,

 you may need to call png_set_alpha_mode:

 

-#if PNG_LIBPNG_VER >= 10504

-   png_set_alpha_mode(png_ptr, mode, screen_gamma);

-#else

-   png_set_gamma(png_ptr, screen_gamma, 1.0/screen_gamma);

-#endif

+    #if PNG_LIBPNG_VER >= 10504

+       png_set_alpha_mode(png_ptr, mode, screen_gamma);

+    #else

+       png_set_gamma(png_ptr, screen_gamma, 1.0/screen_gamma);

+    #endif

 

 The screen_gamma value is the same as the argument to png_set_gamma; however,

 how it affects the output depends on the mode.  png_set_alpha_mode() sets the

@@ -1776,7 +1772,7 @@ the screen_gamma value.  Pixels with alpha less than 1.0
 will still have linear components.

 

 Use this format if you have control over your

-compositing software and do don't do other arithmetic

+compositing software and so don't do other arithmetic

 (such as scaling) on the data you get from libpng.  Your

 compositing software can simply copy opaque pixels to

 the output but still has linear values for the

@@ -2107,6 +2103,11 @@ data has been read, or zero if it is missing.  The parameters to the
 png_get_<chunk> are set directly if they are simple data types, or a

 pointer into the info_ptr is returned for any complex types.

 

+The colorspace data from gAMA, cHRM, sRGB, iCCP, and sBIT chunks

+is simply returned to give the application information about how the

+image was encoded.  Libpng itself only does transformations using the file

+gamma when combining semitransparent pixels with the background color.

+

     png_get_PLTE(png_ptr, info_ptr, &palette,

                      &num_palette);

 

@@ -2118,14 +2119,14 @@ pointer into the info_ptr is returned for any complex types.
     png_get_gAMA(png_ptr, info_ptr, &file_gamma);

     png_get_gAMA_fixed(png_ptr, info_ptr, &int_file_gamma);

 

-    file_gamma     - the gamma at which the file is

+    file_gamma     - the gamma at which the file was

                      written (PNG_INFO_gAMA)

 

     int_file_gamma - 100,000 times the gamma at which the

                      file is written

 

-    png_get_cHRM(png_ptr, info_ptr,  &white_x, &white_y, &red_x, &red_y,

-                     &green_x, &green_y, &blue_x, &blue_y)

+    png_get_cHRM(png_ptr, info_ptr,  &white_x, &white_y, &red_x,

+                     &red_y, &green_x, &green_y, &blue_x, &blue_y)

     png_get_cHRM_XYZ(png_ptr, info_ptr, &red_X, &red_Y, &red_Z, &green_X,

                      &green_Y, &green_Z, &blue_X, &blue_Y, &blue_Z)

     png_get_cHRM_fixed(png_ptr, info_ptr, &int_white_x, &int_white_y,

@@ -2136,8 +2137,9 @@ pointer into the info_ptr is returned for any complex types.
                      &int_blue_X, &int_blue_Y, &int_blue_Z)

 

     {white,red,green,blue}_{x,y}

-                     A color space encoding specified using the chromaticities

-                     of the end points and the white point. (PNG_INFO_cHRM)

+                     A color space encoding specified using the

+                     chromaticities of the end points and the

+                     white point. (PNG_INFO_cHRM)

 

     {red,green,blue}_{X,Y,Z}

                      A color space encoding specified using the encoding end

@@ -2548,17 +2550,19 @@ Within the matrix,
      "A" means the transformation is obtained by png_set_add_alpha().

      "X" means the transformation is obtained by png_set_expand().

      "1" means the transformation is obtained by

-         png_set_expand_gray_1_2_4_to_8() (and by png_set_expand() if there

-         is no transparency in the original or the final format).

+         png_set_expand_gray_1_2_4_to_8() (and by png_set_expand()

+         if there is no transparency in the original or the final

+         format).

      "C" means the transformation is obtained by png_set_gray_to_rgb().

      "G" means the transformation is obtained by png_set_rgb_to_gray().

      "P" means the transformation is obtained by

          png_set_expand_palette_to_rgb().

      "p" means the transformation is obtained by png_set_packing().

      "Q" means the transformation is obtained by png_set_quantize().

-     "T" means the transformation is obtained by png_set_tRNS_to_alpha().

-     "B" means the transformation is obtained by png_set_background(), or

-         png_strip_alpha().

+     "T" means the transformation is obtained by

+         png_set_tRNS_to_alpha().

+     "B" means the transformation is obtained by

+         png_set_background(), or png_strip_alpha().

 

 When an entry has multiple transforms listed all are required to cause the

 right overall transformation.  When two transforms are separated by a comma

@@ -2643,8 +2647,8 @@ with alpha.
 

     if (color_type == PNG_COLOR_TYPE_RGB ||

         color_type == PNG_COLOR_TYPE_RGB_ALPHA)

-       png_set_rgb_to_gray(png_ptr, error_action, double red_weight,

-          double green_weight);

+       png_set_rgb_to_gray(png_ptr, error_action,

+          double red_weight, double green_weight);

 

     error_action = 1: silently do the conversion

 

@@ -2666,7 +2670,8 @@ with alpha.
 In the corresponding fixed point API the red_weight and green_weight values are

 simply scaled by 100,000:

 

-    png_set_rgb_to_gray(png_ptr, error_action, png_fixed_point red_weight,

+    png_set_rgb_to_gray(png_ptr, error_action,

+       png_fixed_point red_weight,

        png_fixed_point green_weight);

 

 If you have set error_action = 1 or 2, you can

@@ -2710,7 +2715,7 @@ the current display (e.g., the background color from a web page).  You
 need to tell libpng how the color is represented, both the format of the

 component values in the color (the number of bits) and the gamma encoding of the

 color.  The function takes two arguments, background_gamma_mode and need_expand

-to convey this information, however only two combinations are likely to be

+to convey this information; however, only two combinations are likely to be

 useful:

 

     png_color_16 my_background;

@@ -3004,7 +3009,7 @@ the second parameter NULL.
 

 If you don't want libpng to handle the interlacing details, just call

 png_read_rows() PNG_INTERLACE_ADAM7_PASSES times to read in all the images.

-Each of the images is a valid image by itself, however you will almost

+Each of the images is a valid image by itself; however, you will almost

 certainly need to distribute the pixels from each sub-image to the

 correct place.  This is where everything gets very tricky.

 

@@ -3161,7 +3166,7 @@ sPLT, only the n'th item in the structure is freed, where n is "seq".
 The default behavior is only to free data that was allocated internally

 by libpng.  This can be changed, so that libpng will not free the data,

 or so that it will free data that was allocated by the user with png_malloc()

-or png_zalloc() and passed in via a png_set_*() function, with

+or png_calloc() and passed in via a png_set_*() function, with

 

     png_data_freer(png_ptr, info_ptr, freer, mask)

 

@@ -3182,7 +3187,7 @@ or png_destroy_*() is supposed to free the data.  When the user assumes
 responsibility for libpng-allocated data, the application must use

 png_free() to free it, and when the user transfers responsibility to libpng

 for data that the user has allocated, the user must have used png_malloc()

-or png_zalloc() to allocate it.

+or png_calloc() to allocate it.

 

 If you allocated your row_pointers in a single block, as suggested above in

 the description of the high level read interface, you must not transfer

@@ -4000,8 +4005,8 @@ tEXt chunk use RFC 1123 format dates (e.g. "22 May 1997 18:07:10 GMT"),
 although this isn't a requirement.  Unlike the tIME chunk, the

 "Creation Time" tEXt chunk is not expected to be automatically changed

 by the software.  To facilitate the use of RFC 1123 dates, a function

-png_convert_to_rfc1123(png_timep) is provided to convert from PNG

-time to an RFC 1123 format string.

+png_convert_to_rfc1123(png_ptr, png_timep) is provided to convert

+from PNG time to an RFC 1123 format string.

 

 .SS Writing unknown chunks

 

@@ -4363,7 +4368,7 @@ png_destroy_write_struct().
 The default behavior is only to free data that was allocated internally

 by libpng.  This can be changed, so that libpng will not free the data,

 or so that it will free data that was allocated by the user with png_malloc()

-or png_zalloc() and passed in via a png_set_*() function, with

+or png_calloc() and passed in via a png_set_*() function, with

 

     png_data_freer(png_ptr, info_ptr, freer, mask)

 

@@ -4399,7 +4404,7 @@ When the user assumes responsibility for libpng-allocated data, the
 application must use

 png_free() to free it, and when the user transfers responsibility to libpng

 for data that the user has allocated, the user must have used png_malloc()

-or png_zalloc() to allocate it.

+or png_calloc() to allocate it.

 

 If you allocated text_ptr.text, text_ptr.lang, and text_ptr.translated_keyword

 separately, do not transfer responsibility for freeing text_ptr to libpng,

@@ -4427,12 +4432,13 @@ in pngmem.c, pngrio.c, pngwio.c, and pngerror.c, respectively.  To change
 these functions, call the appropriate png_set_*_fn() function.

 

 Memory allocation is done through the functions png_malloc(), png_calloc(),

-and png_free().  These currently just call the standard C functions.

-png_calloc() calls png_malloc() and then clears the newly

-allocated memory to zero.  There is limited support for certain systems

-with segmented memory architectures and the types of pointers declared by

-png.h match this; you will have to use appropriate pointers in your

-application.  Since it is

+and png_free().  The png_malloc() and png_free() functions currently just

+call the standard C functions and png_calloc() calls png_malloc() and then

+clears the newly allocated memory to zero; note that png_calloc(png_ptr, size)

+is not the same as the calloc(number, size) function provided by stdlib.h.

+There is limited support for certain systems with segmented memory

+architectures and the types of pointers declared by png.h match this; you

+will have to use appropriate pointers in your application.  Since it is

 unlikely that the method of handling memory allocation on a platform

 will change between applications, these functions must be modified in

 the library at compile time.  If you prefer to use a different method

@@ -4663,7 +4669,7 @@ available to set these separately for non-IDAT
 compressed chunks such as zTXt, iTXt, and iCCP:

 

     #include zlib.h

-    #if PNG_LIBPNG_VER <= 10504

+    #if PNG_LIBPNG_VER >= 10504

     png_set_text_compression_level(png_ptr, level);

 

     png_set_text_compression_mem_level(png_ptr, level);

@@ -5062,8 +5068,8 @@ png_get_mmx_bitdepth_threshold(), png_get_mmx_rowbytes_threshold(),
 png_set_asm_flags(), and png_mmx_supported()

 

 We removed the obsolete png_check_sig(), png_memcpy_check(), and

-png_memset_check() functions.  Instead use !png_sig_cmp(), memcpy(),

-and memset(), respectively.

+png_memset_check() functions.  Instead use !png_sig_cmp(), png_memcpy(),

+and png_memset(), respectively.

 

 The function png_set_gray_1_2_4_to_8() was removed. It has been

 deprecated since libpng-1.0.18 and 1.2.9, when it was replaced with

@@ -5100,7 +5106,9 @@ png_set_strip_error_numbers() was removed from the library by default.
 

 The png_zalloc() and png_zfree() functions are no longer exported.

 The png_zalloc() function no longer zeroes out the memory that it

-allocates.

+allocates.  Applications that called png_zalloc(png_ptr, number, size)

+can call png_calloc(png_ptr, number*size) instead, and can call

+png_free() instead of png_zfree().

 

 Support for dithering was disabled by default in libpng-1.4.0, because

 it has not been well tested and doesn't actually "dither".

@@ -5120,12 +5128,22 @@ We removed the trailing '.' from the warning and error messages.
 From libpng-1.4.0 until 1.4.4, the png_get_uint_16 macro (but not the

 function) incorrectly returned a value of type png_uint_32.

 

+Checking for invalid palette index on read or write was added at libpng

+1.5.10.  When an invalid index is found, libpng issues a benign error.

+This is enabled by default but can be disabled in each png_ptr with

+

+   png_set_check_for_invalid_index(png_ptr, allowed);

+

+      allowed  - one of

+                 0: disable

+                 1: enable

+

 A. Changes that affect users of libpng

 

 There are no substantial API changes between the non-deprecated parts of

-the 1.4.5 API and the 1.5.0 API, however the ability to directly access

-the main libpng control structures, png_struct and png_info, deprecated

-in earlier versions of libpng, has been completely removed from

+the 1.4.5 API and the 1.5.0 API; however, the ability to directly access

+members of the main libpng control structures, png_struct and png_info,

+deprecated in earlier versions of libpng, has been completely removed from

 libpng 1.5.

 

 We no longer include zlib.h in png.h.  Applications that need access

@@ -5133,9 +5151,12 @@ to information in zlib.h will need to add the '#include "zlib.h"'
 directive.  It does not matter whether it is placed prior to or after

 the '"#include png.h"' directive.

 

-We moved the png_strcpy(), png_strncpy(), png_strlen(), png_memcpy(),

-png_memcmp(), png_sprintf, and png_memcpy() macros into a private

-header file (pngpriv.h) that is not accessible to applications.

+The png_sprintf(), png_strcpy(), and png_strncpy() macros are no longer used

+and were removed.

+

+We moved the png_strlen(), png_memcpy(), png_memset(), and png_memcmp()

+macros into a private header file (pngpriv.h) that is not accessible to

+applications.

 

 In png_get_iCCP, the type of "profile" was changed from png_charpp

 to png_bytepp, and in png_set_iCCP, from png_charp to png_const_bytep.

@@ -5238,16 +5259,30 @@ PNG_USER_WIDTH_MAX and PNG_USER_HEIGHT_MAX, although this document said
 that it could be used to override them.  Now this function will reduce or

 increase the limits.

 

+Starting in libpng-1.5.10, the user limits can be set en masse with the

+configuration option PNG_SAFE_LIMITS_SUPPORTED.  If this option is enabled,

+a set of "safe" limits is applied in pngpriv.h.  These can be overridden by

+application calls to png_set_user_limits(), png_set_user_chunk_cache_max(),

+and/or png_set_user_malloc_max() that increase or decrease the limits.  Also,

+in libpng-1.5.10 the default width and height limits were increased

+from 1,000,000 to 0x7ffffff (i.e., made unlimited).  Therefore, the

+limits are now

+                               default      safe

+   png_user_width_max        0x7fffffff    1,000,000

+   png_user_height_max       0x7fffffff    1,000,000

+   png_user_chunk_cache_max  0 (unlimited)   128

+   png_user_chunk_malloc_max 0 (unlimited) 8,000,000

+

 B. Changes to the build and configuration of libpng

 

 Details of internal changes to the library code can be found in the CHANGES

 file and in the GIT repository logs.  These will be of no concern to the vast

-majority of library users or builders, however the few who configure libpng

+majority of library users or builders; however, the few who configure libpng

 to a non-default feature set may need to change how this is done.

 

 There should be no need for library builders to alter build scripts if

 these use the distributed build support - configure or the makefiles -

-however users of the makefiles may care to update their build scripts

+however, users of the makefiles may care to update their build scripts

 to build pnglibconf.h where the corresponding makefile does not do so.

 

 Building libpng with a non-default configuration has changed completely.

@@ -5353,7 +5388,7 @@ merely stops the function from being exported.
 PNG_FLOATING_ARITHMETIC_SUPPORTED chooses between the internal floating

 point implementation or the fixed point one.  Typically the fixed point

 implementation is larger and slower than the floating point implementation

-on a system that supports floating point, however it may be faster on a

+on a system that supports floating point; however, it may be faster on a

 system which lacks floating point hardware and therefore uses a software

 emulation.

 

@@ -5382,7 +5417,7 @@ pngconf.h no longer includes pngusr.h, therefore pngusr.h is ignored after the
 build of pnglibconf.h and it is never included in an application build.

 

 The rarely used alternative of adding a list of feature macros to the

-CFLAGS setting in the build also still works, however the macros will be

+CFLAGS setting in the build also still works; however, the macros will be

 copied to pnglibconf.h and this may produce macro redefinition warnings

 when the individual C files are compiled.

 

@@ -5523,8 +5558,8 @@ above the comment that says
   /* Maintainer: Put new private prototypes here ^ and in libpngpf.3 */

 

 To avoid polluting the global namespace, the names of all exported

-functions and variables begin with  "png_", and all publicly visible C

-preprocessor macros begin with "PNG_".  We request that applications that

+functions and variables begin with "png_", and all publicly visible C

+preprocessor macros begin with "PNG".  We request that applications that

 use libpng *not* begin any of their own symbols with either of these strings.

 

 We put a space after each comma and after each semicolon

@@ -5551,25 +5586,25 @@ Other rules can be inferred by inspecting the libpng source.
 

 .SH XIV. Y2K Compliance in libpng

 

-February 18, 2012

+September 27, 2012

 

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

 an official declaration.

 

 This is your unofficial assurance that libpng from version 0.71 and

-upward through 1.5.9 are Y2K compliant.  It is my belief that earlier

+upward through 1.5.13 are Y2K compliant.  It is my belief that earlier

 versions were also Y2K compliant.

 

-Libpng only has three year fields.  One is a 2-byte unsigned integer that

-will hold years up to 65535.  The other two hold the date in text

+Libpng only has two year fields.  One is a 2-byte unsigned integer that

+will hold years up to 65535.  The other holds the date in text

 format, and will hold years up to 9999.

 

 The integer is

     "png_uint_16 year" in png_time_struct.

 

-The strings are

-    "png_charp time_buffer" in png_struct and

-    "near_time_buffer", which is a local character string in png.c.

+The string is

+    "char time_buffer[29]" in png_struct.  This will no

+longer be used in libpng-1.6.x and will be removed from libpng-1.7.0.

 

 There are seven time-related functions:

 

@@ -5768,6 +5803,15 @@ the first widely used release:
  1.5.9beta01-02      15    10509  15.so.15.9[.0]

  1.5.9rc01           15    10509  15.so.15.9[.0]

  1.5.9               15    10509  15.so.15.9[.0]

+ 1.5.10beta01-05     15    10510  15.so.15.10[.0]

+ 1.5.10              15    10510  15.so.15.10[.0]

+ 1.5.11beta01        15    10511  15.so.15.11[.0]

+ 1.5.11rc01-05       15    10511  15.so.15.11[.0]

+ 1.5.11              15    10511  15.so.15.11[.0]

+ 1.5.12              15    10512  15.so.15.12[.0]

+ 1.5.13beta01-02     15    10513  15.so.15.13[.0]

+ 1.5.13rc01          15    10513  15.so.15.13[.0]

+ 1.5.13              15    10513  15.so.15.13[.0]

 

 Henceforth the source version will match the shared-library minor

 and patch numbers; the shared-library major version number will be

@@ -5824,7 +5868,7 @@ possible without all of you.
 

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

 

-Libpng version 1.5.9 - February 18, 2012:

+Libpng version 1.5.13 - September 27, 2012:

 Initially created in 1995 by Guy Eric Schalnat, then of Group 42, Inc.

 Currently maintained by Glenn Randers-Pehrson (glennrp at users.sourceforge.net).

 

@@ -5847,7 +5891,7 @@ this sentence.
 

 This code is released under the libpng license.

 

-libpng versions 1.2.6, August 15, 2004, through 1.5.9, February 18, 2012, are

+libpng versions 1.2.6, August 15, 2004, through 1.5.13, September 27, 2012, are

 Copyright (c) 2004,2006-2007 Glenn Randers-Pehrson, and are

 distributed according to the same disclaimer and license as libpng-1.2.5

 with the following individual added to the list of Contributing Authors

@@ -5946,7 +5990,7 @@ certification mark of the Open Source Initiative.
 

 Glenn Randers-Pehrson

 glennrp at users.sourceforge.net

-February 18, 2012

+September 27, 2012

 

 .\" end of man page