Alien-FreeImage

 view release on metacpan or  search on metacpan

src/Source/LibPNG/libpng.3  view on Meta::CPAN

    if (interlace_type == PNG_INTERLACE_ADAM7)
       number_of_passes
           = png_set_interlace_handling(png_ptr);

This will return the number of passes needed.  Currently, this is seven,
but may change if another interlace type is added.  This function can be
called even if the file is not interlaced, where it will return one pass.
You then need to read the whole image 'number_of_passes' times.  Each time
will distribute the pixels from the current pass to the correct place in
the output image, so you need to supply the same rows to png_read_rows in
each pass.

If you are not going to display the image after each pass, but are
going to wait until the entire image is read in, use the sparkle
effect.  This effect is faster and the end result of either method
is exactly the same.  If you are planning on displaying the image
after each pass, the "rectangle" effect is generally considered the
better looking one.

If you only want the "sparkle" effect, just call png_read_rows() as
normal, with the third parameter NULL.  Make sure you make pass over
the image number_of_passes times, and you don't change the data in the
rows between calls.  You can change the locations of the data, just
not the data.  Each pass only writes the pixels appropriate for that
pass, and assumes the data from previous passes is still valid.

    png_read_rows(png_ptr, row_pointers, NULL,
        number_of_rows);

If you only want the first effect (the rectangles), do the same as
before except pass the row buffer in the third parameter, and leave
the second parameter NULL.

    png_read_rows(png_ptr, NULL, row_pointers,
        number_of_rows);

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
certainly need to distribute the pixels from each sub-image to the
correct place.  This is where everything gets very tricky.

If you want to retrieve the separate images you must pass the correct
number of rows to each successive call of png_read_rows().  The calculation
gets pretty complicated for small images, where some sub-images may
not even exist because either their width or height ends up zero.
libpng provides two macros to help you in 1.5 and later versions:

   png_uint_32 width = PNG_PASS_COLS(image_width, pass_number);
   png_uint_32 height = PNG_PASS_ROWS(image_height, pass_number);

Respectively these tell you the width and height of the sub-image
corresponding to the numbered pass.  'pass' is in in the range 0 to 6 -
this can be confusing because the specification refers to the same passes
as 1 to 7!  Be careful, you must check both the width and height before
calling png_read_rows() and not call it for that pass if either is zero.

You can, of course, read each sub-image row by row.  If you want to
produce optimal code to make a pixel-by-pixel transformation of an
interlaced image this is the best approach; read each row of each pass,
transform it, and write it out to a new interlaced image.

If you want to de-interlace the image yourself libpng provides further
macros to help that tell you where to place the pixels in the output image.
Because the interlacing scheme is rectangular - sub-image pixels are always
arranged on a rectangular grid - all you need to know for each pass is the
starting column and row in the output image of the first pixel plus the
spacing between each pixel.  As of libpng 1.5 there are four macros to
retrieve this information:

   png_uint_32 x = PNG_PASS_START_COL(pass);
   png_uint_32 y = PNG_PASS_START_ROW(pass);
   png_uint_32 xStep = 1U << PNG_PASS_COL_SHIFT(pass);
   png_uint_32 yStep = 1U << PNG_PASS_ROW_SHIFT(pass);

These allow you to write the obvious loop:

   png_uint_32 input_y = 0;
   png_uint_32 output_y = PNG_PASS_START_ROW(pass);

   while (output_y < output_image_height)
   {
      png_uint_32 input_x = 0;
      png_uint_32 output_x = PNG_PASS_START_COL(pass);

      while (output_x < output_image_width)
      {
         image[output_y][output_x] =
             subimage[pass][input_y][input_x++];

         output_x += xStep;
      }

      ++input_y;
      output_y += yStep;
   }

Notice that the steps between successive output rows and columns are
returned as shifts.  This is possible because the pixels in the subimages
are always a power of 2 apart - 1, 2, 4 or 8 pixels - in the original
image.  In practice you may need to directly calculate the output coordinate
given an input coordinate.  libpng provides two further macros for this
purpose:

   png_uint_32 output_x = PNG_COL_FROM_PASS_COL(input_x, pass);
   png_uint_32 output_y = PNG_ROW_FROM_PASS_ROW(input_y, pass);

Finally a pair of macros are provided to tell you if a particular image
row or column appears in a given pass:

   int col_in_pass = PNG_COL_IN_INTERLACE_PASS(output_x, pass);
   int row_in_pass = PNG_ROW_IN_INTERLACE_PASS(output_y, pass);

Bear in mind that you will probably also need to check the width and height
of the pass in addition to the above to be sure the pass even exists!

With any luck you are convinced by now that you don't want to do your own
interlace handling.  In reality normally the only good reason for doing this
is if you are processing PNG files on a pixel-by-pixel basis and don't want
to load the whole file into memory when it is interlaced.

src/Source/LibPNG/libpng.3  view on Meta::CPAN

functions, you will need to set up your own message callbacks.  These
functions are normally supplied at the time that the png_struct is created.
It is also possible to redirect errors and warnings to your own replacement
functions after png_create_*_struct() has been called by calling:

    png_set_error_fn(png_structp png_ptr,
        png_voidp error_ptr, png_error_ptr error_fn,
        png_error_ptr warning_fn);

    png_voidp error_ptr = png_get_error_ptr(png_ptr);

If NULL is supplied for either error_fn or warning_fn, then the libpng
default function will be used, calling fprintf() and/or longjmp() if a
problem is encountered.  The replacement error functions should have
parameters as follows:

    void user_error_fn(png_structp png_ptr,
        png_const_charp error_msg);

    void user_warning_fn(png_structp png_ptr,
        png_const_charp warning_msg);

The motivation behind using setjmp() and longjmp() is the C++ throw and
catch exception handling methods.  This makes the code much easier to write,
as there is no need to check every return code of every function call.
However, there are some uncertainties about the status of local variables
after a longjmp, so the user may want to be careful about doing anything
after setjmp returns non-zero besides returning itself.  Consult your
compiler documentation for more details.  For an alternative approach, you
may wish to use the "cexcept" facility (see http://cexcept.sourceforge.net),
which is illustrated in pngvalid.c and in contrib/visupng.

Beginning in libpng-1.4.0, the png_set_benign_errors() API became available.
You can use this to handle certain errors (normally handled as errors)
as warnings.

    png_set_benign_errors (png_ptr, int allowed);

    allowed: 0: treat png_benign_error() as an error.
             1: treat png_benign_error() as a warning.

As of libpng-1.6.0, the default condition is to treat benign errors as
warnings while reading and as errors while writing.

.SS Custom chunks

If you need to read or write custom chunks, you may need to get deeper
into the libpng code.  The library now has mechanisms for storing
and writing chunks of unknown type; you can even declare callbacks
for custom chunks.  However, this may not be good enough if the
library code itself needs to know about interactions between your
chunk and existing `intrinsic' chunks.

If you need to write a new intrinsic chunk, first read the PNG
specification. Acquire a first level of understanding of how it works.
Pay particular attention to the sections that describe chunk names,
and look at how other chunks were designed, so you can do things
similarly.  Second, check out the sections of libpng that read and
write chunks.  Try to find a chunk that is similar to yours and use
it as a template.  More details can be found in the comments inside
the code.  It is best to handle private or unknown chunks in a generic method,
via callback functions, instead of by modifying libpng functions. This
is illustrated in pngtest.c, which uses a callback function to handle a
private "vpAg" chunk and the new "sTER" chunk, which are both unknown to
libpng.

If you wish to write your own transformation for the data, look through
the part of the code that does the transformations, and check out some of
the simpler ones to get an idea of how they work.  Try to find a similar
transformation to the one you want to add and copy off of it.  More details
can be found in the comments inside the code itself.

.SS Configuring for gui/windowing platforms:

You will need to write new error and warning functions that use the GUI
interface, as described previously, and set them to be the error and
warning functions at the time that png_create_*_struct() is called,
in order to have them available during the structure initialization.
They can be changed later via png_set_error_fn().  On some compilers,
you may also have to change the memory allocators (png_malloc, etc.).

.SS Configuring zlib:

There are special functions to configure the compression.  Perhaps the
most useful one changes the compression level, which currently uses
input compression values in the range 0 - 9.  The library normally
uses the default compression level (Z_DEFAULT_COMPRESSION = 6).  Tests
have shown that for a large majority of images, compression values in
the range 3-6 compress nearly as well as higher levels, and do so much
faster.  For online applications it may be desirable to have maximum speed
(Z_BEST_SPEED = 1).  With versions of zlib after v0.99, you can also
specify no compression (Z_NO_COMPRESSION = 0), but this would create
files larger than just storing the raw bitmap.  You can specify the
compression level by calling:

    #include zlib.h
    png_set_compression_level(png_ptr, level);

Another useful one is to reduce the memory level used by the library.
The memory level defaults to 8, but it can be lowered if you are
short on memory (running DOS, for example, where you only have 640K).
Note that the memory level does have an effect on compression; among
other things, lower levels will result in sections of incompressible
data being emitted in smaller stored blocks, with a correspondingly
larger relative overhead of up to 15% in the worst case.

    #include zlib.h
    png_set_compression_mem_level(png_ptr, level);

The other functions are for configuring zlib.  They are not recommended
for normal use and may result in writing an invalid PNG file.  See
zlib.h for more information on what these mean.

    #include zlib.h
    png_set_compression_strategy(png_ptr,
        strategy);

    png_set_compression_window_bits(png_ptr,
        window_bits);

    png_set_compression_method(png_ptr, method);

src/Source/LibPNG/libpng.3  view on Meta::CPAN

The PNG spec requirement that only grayscale profiles may appear in images
with color type 0 or 4 and that even if the image only contains gray pixels,
only RGB profiles may appear in images with color type 2, 3, or 6, is now
enforced.  The sRGB chunk is allowed to appear in images with any color type
and is interpreted by libpng to convey a one-tracer-curve gray profile or a
three-tracer-curve RGB profile as appropriate.

Prior to libpng-1.6.0 a warning would be issued if the iTXt chunk contained
an empty language field or an empty translated keyword.  Both of these
are allowed by the PNG specification, so these warnings are no longer issued.

The library now issues an error if the application attempts to set a
transform after it calls png_read_update_info() or if it attempts to call
both png_read_update_info() and png_start_read_image() or to call either
of them more than once.

The default condition for benign_errors is now to treat benign errors as
warnings while reading and as errors while writing.

The library now issues a warning if both background processing and RGB to
gray are used when gamma correction happens. As with previous versions of
the library the results are numerically very incorrect in this case.

There are some minor arithmetic changes in some transforms such as
png_set_background(), that might be detected by certain regression tests.

Unknown chunk handling has been improved internally, without any API change.
This adds more correct option control of the unknown handling, corrects
a pre-existing bug where the per-chunk 'keep' setting is ignored, and makes
it possible to skip IDAT chunks in the sequential reader.

The machine-generated configure files are no longer included in branches
libpng16 and later of the GIT repository.  They continue to be included
in the tarball releases, however.

Libpng-1.6.0 through 1.6.2 used the CMF bytes at the beginning of the IDAT
stream to set the size of the sliding window for reading instead of using the
default 32-kbyte sliding window size.  It was discovered that there are
hundreds of PNG files in the wild that have incorrect CMF bytes that caused
zlib to issue the "invalid distance too far back" error and reject the file.
Libpng-1.6.3 and later calculate their own safe CMF from the image dimensions,
provide a way to revert to the libpng-1.5.x behavior (ignoring the CMF bytes
and using a 32-kbyte sliding window), by using

    png_set_option(png_ptr, PNG_MAXIMUM_INFLATE_WINDOW,
        PNG_OPTION_ON);

and provide a tool (contrib/tools/pngfix) for rewriting a PNG file while
optimizing the CMF bytes in its IDAT chunk correctly.

Libpng-1.6.0 and libpng-1.6.1 wrote uncompressed iTXt chunks with the wrong
length, which resulted in PNG files that cannot be read beyond the bad iTXt
chunk.  This error was fixed in libpng-1.6.3, and a tool (called
contrib/tools/png-fix-itxt) has been added to the libpng distribution.

.SH XIII.  Detecting libpng

The png_get_io_ptr() function has been present since libpng-0.88, has never
changed, and is unaffected by conditional compilation macros.  It is the
best choice for use in configure scripts for detecting the presence of any
libpng version since 0.88.  In an autoconf "configure.in" you could use

    AC_CHECK_LIB(png, png_get_io_ptr, ...

.SH XV. Source code repository

Since about February 2009, version 1.2.34, libpng has been under "git" source
control.  The git repository was built from old libpng-x.y.z.tar.gz files
going back to version 0.70.  You can access the git repository (read only)
at

    git://git.code.sf.net/p/libpng/code

or you can browse it with a web browser by selecting the "code" button at

    https://sourceforge.net/projects/libpng

Patches can be sent to glennrp at users.sourceforge.net or to
png-mng-implement at lists.sourceforge.net or you can upload them to
the libpng bug tracker at

    http://libpng.sourceforge.net

We also accept patches built from the tar or zip distributions, and
simple verbal discriptions of bug fixes, reported either to the
SourceForge bug tracker, to the png-mng-implement at lists.sf.net
mailing list, or directly to glennrp.

.SH XV. Coding style

Our coding style is similar to the "Allman" style
(See http://en.wikipedia.org/wiki/Indent_style#Allman_style), with curly
braces on separate lines:

    if (condition)
    {
       action;
    }

    else if (another condition)
    {
       another action;
    }

The braces can be omitted from simple one-line actions:

    if (condition)
       return (0);

We use 3-space indentation, except for continued statements which
are usually indented the same as the first line of the statement
plus four more spaces.

For macro definitions we use 2-space indentation, always leaving the "#"
in the first column.

    #ifndef PNG_NO_FEATURE
    #  ifndef PNG_FEATURE_SUPPORTED
    #    define PNG_FEATURE_SUPPORTED
    #  endif