the useful side effect of avoiding a bogus warning generated by the latest
version of the Intel C compiler (it objects to
condition ? string-literal : string-literal).
requirements of png_modifier are greater than that of png_store and as a
consequence compilation of pngvalid.c results in a warning about increased
alignment requirements because of the bare cast to (png_modifier*). The code
is safe, because the pointer is known to point to a stack allocated
png_modifier, but this change avoids the warning.
Fixed default behavior of ARM_NEON_API. If the ARM NEON API option was
compiled without the CHECK option it defaulted to on, not off.
Check user callback behavior in pngunknown.c. Previous versions compiled
if SAVE_UNKNOWN was not available but did nothing since the callback
was never implemented.
Merged pngunknown.c with 1.7 version and back ported 1.7 improvements/fixes
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).
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
only works with libpng versions that can be made to reliably fail when
the deflate data contains an out-of-window reference. This means only
1.6 and later.
Fixed gnu issues: g++ needs a static_cast, gcc 4.4.7 has a broken warning
message which it is easier to work round than ignore.
For inflate, reverted previous fixes.
Added fixitxt and pngdeflate to the built programs and removed warnings
from the source code and timepng that are revealed as a result. Fixed
fixitxt when the chunk length is more than 65535 (untested, no test case).
a flag to change default. In 1.6.0 when the simplified API was used
to produce color-mapped output from an input image with no gamma
information the gamma assumed for the input could be different from
that assumed for non-color-mapped output. In particular 16-bit depth
input files were assumed to be sRGB encoded, whereas in the 'direct'
case they were assumed to have linear data. This was an error. The
fix makes the simplified API treat all input files the same way and
adds a new flag to the png_image::flags member to allow the
application/user to specify that 16-bit files contain sRGB data
rather than the default linear.
Fixed bugs in the pngpixel and makepng test programs.
READ_GAMMA. Prior to 1.6.0 switching off READ_GAMMA did unpredictable things
to the interfaces that use it (specifically, png_do_background in 1.4 would
simply display composite for grayscale images but do composition
with the incorrect arithmetic for color ones). In 1.6 the semantic
of -DPNG_NO_READ_GAMMA is changed to simply disable any interface that
depends on it; this obliges people who set it to consider whether they
really want it off if they happen to use any of the interfaces in
question (typically most users who disable it won't).
