This is needed to work around a build failure when this test fails, as
it spuriously does when cross-compiling for MinGW using v10 API package,
see https://sourceforge.net/p/mingw-w64/bugs/935/ for more details.
Of course, the fact that the build fails if snprintf() is unavailable is
actually a bug, but in practice this function is available everywhere by
now, so simply stop testing for it.
This mostly cherry picks ceff22ee (Use C99 snprintf, 2021-01-31), but
keeps the test for MSVC versions without vsnprintf() for compatibility.
So we can have 2 kind of builds with the Zip/Deflate codec:
- zlib only
- zlib + libdeflate
Speed improvements in the 35%-50% range can be expected when libdeflate is used.
Compression level up to 12 is now supported (capped to 9 when zlib is used).
Still requires zlib for situations where libdeflate cannot be used (that
is for scanline access, since libdeflate has no streaming mode)
Pseudo-tag TIFFTAG_DEFLATE_SUBCODEC=DEFLATE_SUBCODEC_ZLIB/DEFLATE_SUBCODEC_LIBDEFLATE
is added to control which subcodec (zlib or libdeflate) should be used (it defaults
of course to libdeflate, when it is available).
This is mostly aimed at being used on the writing side, to be able to reproduce
output of previous libtiff versions at a binary level, in situations where this would
be really needed. Or as a safety belt in case there would be unforeseen issues
with using libdeflate.
It can be used to know when libdeflate is available at runtime (DEFLATE_SUBCODEC_LIBDEFLATE
will be the default value in that situation).
Of course, deflate codestreams produced by libdeflate can be read by zlib, and vice-versa.
... and add per-strile offset/bytecount loading capabilities.
Part of this commit makes the behaviour that was previously met when
libtiff was compiled with -DDEFER_STRILE_LOAD available for default builds
when specifying the new 'D' (Deferred) TIFFOpen() flag. In that mode, the [Tile/Strip][ByteCounts/Offsets]
arrays are only loaded when first accessed. This can speed-up the opening
of files stored on the network when just metadata retrieval is needed.
This mode has been used for years by the GDAL library when compiled with
its embeded libtiff copy.
To avoid potential out-of-tree code (typically codecs) that would use
the td_stripbytecount and td_stripoffset array inconditionnaly assuming they
have been loaded, those have been suffixed with _p (for protected). The
use of the new functions mentionned below is then recommended.
Another addition of this commit is the capability of loading only the
values of the offset/bytecount of the strile of interest instead of the
whole array. This is enabled with the new 'O' (Ondemand) flag of TIFFOpen()
(which implies 'D'). That behaviour has also been used by GDAL, which hacked
into the td_stripoffset/td_stripbytecount arrays directly. The new code
added in the _TIFFFetchStrileValue() and _TIFFPartialReadStripArray() internal
functions is mostly a port of what was in GDAL GTiff driver previously.
Related to that, the public TIFFGetStrileOffset[WithErr]() and TIFFGetStrileByteCount[WithErr]()
functions have been added to API. They are of particular interest when
using sparse files (with offset == bytecount == 0) and you want to detect
if a strile is present or not without decompressing the data, or updating
an existing sparse file.
They will also be used to enable a future enhancement where client code can entirely
skip bytecount loading in some situtations
A new test/defer_strile_loading.c test has been added to test the above
capabilities.
From https://github.com/facebook/zstd
"Zstandard, or zstd as short version, is a fast lossless compression
algorithm, targeting real-time compression scenarios at zlib-level
and better compression ratios. It's backed by a very fast entropy stage,
provided by Huff0 and FSE library."
We require libzstd >= 1.0.0 so as to be able to use streaming compression
and decompression methods.
The default compression level we have selected is 9 (range goes from 1 to 22),
which experimentally offers equivalent or better compression ratio than
the default deflate/ZIP level of 6, and much faster compression.
For example on a 6600x4400 16bit image, tiffcp -c zip runs in 10.7 seconds,
while tiffcp -c zstd runs in 5.3 seconds. Decompression time for zip is
840 ms, and for zstd 650 ms. File size is 42735936 for zip, and
42586822 for zstd. Similar findings on other images.
On a 25894x16701 16bit image,
Compression time Decompression time File size
ZSTD 35 s 3.2 s 399 700 498
ZIP/Deflate 1m 20 s 4.9 s 419 622 336
Roger Leigh (via tiff mailing list on 2015-09-01) to fix issue
with BSD make and to make use of cmake in 'distcheck' target
conditional on if cmake is available.
Roger Leigh (via tiff mailing list on 2015-09-01).
CMake build is now included in 'distcheck' target.
Builds with CMake 2.8.9 and newer.
Tar is now resquested to use POSIX PAX format.
libtiff mailing list on Mon, 22 Jun 2015 21:21:01 +0100. Several
corrections to ensure that the autotools build still works were
added by me. I have not yet tested the build using 'cmake' or
MSVC with 'nmake'.
add-on library.
* test/Makefile.am (JPEG_DEPENDENT_CHECK_PROG): raw_decode
requires JPEG support to compile. Use Automake conditional to
only include it when JPEG support is available.
definitions that configure produces, including for WIN64. Still
needs to be tested.
'lld' is not assured by the run-time DLLs and so GCC warns.
Add TIFF_SIZE_T and TIFF_SIZE_FORMAT to provide a type definition
and printf format specifier to deal with printing values of
'size_t' type. In particular, this was necessary for WIN64.
Added a configure test for if the system headers provide 'optarg'
(normal case) and block out the many explicit 'extern' statements
in the utilities. This was found to be necessary under Windows
when getopt is in a DLL and the symbols are already imported with
dllimport via standard header files.
Attached is a patch that adds a configure option to select the file I/O style
on Windows hosts.
It defaults to --enable-win32-io on all windows targets other than Cygwin and
to --disable-win32-io on Cygwin, and thus should be backwards-compatible.
This allows programs using the Unix file I/O style (such as Netpbm's tifftopnm)
to link against libtiff if configured for e.g. MinGW.
value as argument".
(checksignature): Fix Coverity 1024894 "Ignoring number of bytes
read".
(readextension): Fix Coverity 1024893 "Ignoring number of bytes
read".
(readgifimage): Fix Coverity 1024890 "Ignoring number of bytes
read".
(readraster): Fix Coverity 1024891 "Ignoring number of bytes
read".
(readgifimage): Fix Coverity 1024892 "Ignoring number of bytes
read".
some TIFF/FX support in libtiff. Add the tag definitions to
tiff.h. Add the related TIFF field definitions to tif_dirinfo.c,
and also fixes an error in a comment. Adds the photometric values
to tif_print.c, and fixes a bug. These changes are by Steve
Underwood.
* libtiff/tif_write.c: Fix bug rewriting image tiles in a
ELF systems with the GNU linker. Support is enabled via
--enable-ld-version-script. Disabled by default for now until
there is a decision for how to deploy a libtiff with versioned
symbols after libtiff 4.0.0 was already released.
the run-time target whereas target is used to specify the final
output target if the package is a build tool (like a compiler),
which libtiff is not. Resolves libtiff bug 2307 "Use
AC_CANONICAL_HOST macro".
TIFF_UINT64_FORMAT appropriately for MinGW32.
* tools/tiffdump.c (ReadDirectory): MinGW32 needs to use WIN32
printf conventions for 64-bit types because it uses the WIN32 CRT.
* libtiff/{tif_dumpmode.c,tif_luv.c,tif_lzw.c,tif_print.c,
tif_read.c,tif_strip.c,tif_thunder.c}: MinGW32 needs to use WIN32
printf conventions for 64-bit types because it uses the WIN32 CRT.
* tools/tiff2pdf.c (t2p_write_pdf_string): Fix printf syntax not
understood by WIN32 CRT.
