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.
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.
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.
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.
