internal functions called by png_do_{read|write}_transformations static. On an
x86-64 DLL build (Gentoo Linux) this reduces the size of the text
segment of the DLL by 1208 bytes, about 0.6%. It also simplifies
maintenance by removing the declarations from pngpriv.h and allowing
easier changes to the internal interfaces.
function definitions before the place where they are called so that
they can be masde static. Move the intrapixel functions and the
grayscale palette builder out of the png?tran.c files. The latter
isn't a transform function and is no longer used internally, and the
former MNG specific functions are better placed in pngread/pngwrite.c
configurations don't build because of missing contrib/libtests test programs
and overly complex dependencies in scripts/pnglibconf.dfa. This change adds
contrib/conftest/*.dfa files that can be used in automatic build
scripts to ensure that these configurations continue to build.
the #ifdef PNG_SET_UNKNOWN_CHUNKS_SUPPORTED/#endif block.
Removed recently-added #ifdef from pngpread.c; moving the prototype
in pngpriv.h fixed the compiler warning that the #ifdef was trying
to solve.
or intrinsics to be turned on during the build by defining
PNG_ARM_NEON_IMPLEMENTATION to the correct value (2 or 1). The
default is "undefined" and the build type is selected in pngpriv.h.
off. Also fixed the pngminim makefiles to work when $(MAKEFLAGS) contains stuff
which terminates the make options (as by default in recent versions of Gentoo).
png_chunk_unknown_handling() function, and restored the unknown-chunk
handling code from libpng-1.6.6.
Send comments/corrections/commendations to png-mng-implement at lists.sf.net
(subscription required; visit
https://lists.sourceforge.net/lists/listinfo/png-mng-implement
to subscribe)
or to glennrp at users.sourceforge.net
Glenn R-P
strip option. pngfix relied on undefined behavior and even a simple change from
gcc to g++ caused it to fail. The new strip option 'unsafe' has been
implemented and is the default if --max is given. Option names have
been clarified, with --strip=transform now stripping the bKGD chunk,
which was stripped previously with --strip=unused.
Added all documented chunk types to pngpriv.h
Previous iOS/Xcode fixes for the ARM NEON optimizations moved the test
on __ARM_NEON__ from configure time to compile time. This breaks symbol
prefixing because the definition of the special png_init_filter_functions
call was hidden at configure time if the relevant compiler arguments are
passed in CFLAGS as opposed to CC. This change attempts to avoid all
the confusion that would result by declaring the init function even when
it is not used, so that it will always get prefixed.
pnglibconf.h, allowing more of the decisions to be made internally
(pngpriv.h) during the compile. Without this, symbol prefixing is broken
under certain circumstances on ARM platforms. Now only the API parts of
the optimizations ('check' vs 'api') are exposed in the public header files
except that the new setting PNG_ARM_NEON_OPT documents how libpng makes the
decision about whether or not to use the optimizations.
management system (CMS). In practice it is not possible to obtain cHRM
information reliably using just the end-point tags because they do not exist
in the vast majority of profiles. Instead it is necessary to run the endpoints
through the ICC colorimetric intent transform (as described in the v4
spec). Since this is likely to be too much code inside libpng for too
little gain (it implies a fairly complete CMS implementation) the code
has been changed to allow an external CMS to be used. This code is
temporarily disabled until a suitable set of test cases using one or more
external CMS implementations have been implemented.
fixed Cygwin+MSVC build errors. The ICC profile handling now includes more
checking. Several errors that caused rejection of the profile are now
handled with a warning in such a way that the invalid profiles will be
read by default in release (but not pre-RC) builds but will not be
written by default. The easy part of handling a cHRM chunk is written,
where the ICC profile contains the required data. The more difficult
part plus guessing a gAMA value requires code to pass selected RGB values
through the profile.
contrib/libtests/makepng: corrected 'rgb' and 'gray' cases. profile_error
messages could be truncated; made a correct buffer size calculation and
adjusted pngerror.c appropriately. png_icc_check_* checking improved;
changed the functions to receive the correct color type of the PNG on read
or write and check that it matches the color space of the profile (despite
what the comments said before, there is danger in assuming the app will
cope correctly with an RGB profile on a grayscale image and, since it
violates the PNG spec, allowing it is certain to produce inconsistent
app behavior and might even cause app crashes.) Check that profiles
contain the tags needed to process the PNG (tags all required by the ICC
spec). Removed unused PNG_STATIC from pngpriv.h.
control of the unknown handling, corrects the pre-existing bug where
the per-chunk 'keep' setting is ignored and makes it possible to skip
IDAT chunks in the sequential reader (broken in earlier 1.6 versions).
There is a new test program, test-unknown.c, which is a work in progress
(not currently part of the test suite). Comments in the header files now
explain how the unknown handling works.
on read and write. In libpng 1.6 the two cases can be distinguished and
considerable code cleanup, and extra error checking, is possible. This
makes calls on the write side that have no effect be ignored with a
png_app_error(), which can be disabled in the app using
png_set_benign_errors(), and removes the spurious use of usr_channels
on the read side.
Because of the changes to support symbol prefixing PNG_INTERNAL_FUNCTION
declares floating point APIs during libpng builds even if they are completely
disabled. This requires the png floating point types (png_double*) to be
declared even though the functions are never actually defined. This
change provides a dummy definition so that the declarations work, yet any
implementation will fail to compile because of an incomplete type.
on alignment increasing pointer casts when -Wcast-align is passed. This
fixes the cases clang warns about either (pngread.c) by eliminating the
casts from png_bytep to png_uint_16p or, for pngrutil.c where the cast
is previously verified or pngstest.c where it is OK by introducing new
png_aligncast macros to do the cast in a way that clang accepts.
functions [rw]util.c. A new shared keyword check routine was also added
and the 'zbuf' is no longer allocated on progressive read. It is now
possible to call png_inflate() incrementally.
read code now claims and releases png_ptr->zstream, like the write code.
The bug whereby the progressive reader failed to release the zstream
is now fixed, all initialization is delayed, and the code checks for
changed parameters on deflate rather than always calling
deflatedEnd/deflateInit.
problems. This is an intermediate check-in that solves the immediate problems
and introduces one performance improvement (avoiding a copy via png_ptr->zbuf.)
Further changes will be made to make ICC profile handling more secure.
all potentially valid ICC profiles and reject obviously invalid ones.
It now uses png_error() to do so rather than casually writing a PNG
without the necessary color data.
to reset the user limits to safe ones if PNG_SAFE_LIMITS is defined.
To enable, use CPPFLAGS=-DPNG_SAFE_LIMITS on the configure command
or put #define PNG_SAFE_LIMITS_SUPPORTED in pnglibconf.h.prebuilt.
(Reverted previous implementation of PNG_SECURE.)
FLOATING_POINT options were switched off, png.h ended up with lone ';'
characters. This is not valid ANSI-C outside a function. The ';'
characters have been moved inside the definition of PNG_FP_EXPORT and
PNG_FIXED_EXPORT. 2) If either option was switched off, the declaration
of the corresponding functions were completely omitted, even though some
of them are still used internally. The result is still valid, but
produces warnings from gcc with some warning options (including -Wall). The
fix is to cause png.h to declare the functions with PNG_INTERNAL_FUNCTION
when png.h is included from pngpriv.h.
Added new "png_structrp" typedef. Because of the
way libpng works both png_info and png_struct are always accessed via a
single pointer. This means adding C99 'restrict' to the pointer gives
the compiler some opportunity to optimize the code. This change allows that.
changes alter how the tricky allocation of the initial png_struct and png_info
structures are handled. png_info is now handled in pretty much the same
way as everything else, except that the allocations handle NULL return
silently. png_struct is changed in a similar way on allocation and on
deallocation a 'safety' error handler is put in place (which should never
be required). The error handler itself is changed to permit mismatches
in the application and libpng error buffer size; however, this means a
silent change to the API to return the jmp_buf if the size doesn't match
the size from the libpng compilation; libpng now allocates the memory and
this may fail. Overall these changes result in slight code size
reductions; however, this is a reduction in code that is always executed
so is particularly valuable. Overall on a 64-bit system the libpng DLL
decreases in code size by 1733 bytes. pngerror.o increases in size by
about 465 bytes because of the new functionality.
These changes alter how the tricky allocation of the initial png_struct and
png_info structures are handled. png_info is now handled in pretty much the
same way as everything else, except that the allocations handle NULL return
silently. png_struct is changed in a similar way on allocation and on
deallocation a 'safety' error handler is put in place (which should never
be required). The error handler itself is changed to permit mismatches
in the application and libpng error buffer size; however, this means a
silent change to the API to return the jmp_buf if the size doesn't match
the size from the libpng compilation; libpng now allocates the memory and
this may fail. Overall these changes result in slight code size
reductions; however, this is a reduction in code that is always executed
so is particularly valuable. Overall on a 64-bit system the libpng DLL
decreases in code size by 1733 bytes. pngerror.o increases in size by
about 465 bytes because of the new functionality.
