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.
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
required tags. Found on test case of MSVR 35100.
* tools/tiffcrop.c: fix read of undefined buffer in
readContigStripsIntoBuffer() due to uint16 overflow. Probably not a
security issue but I can be wrong. Reported as MSVR 35100 by Axel
Souchet from the MSRC Vulnerabilities & Mitigations team.
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.
Based on patch by Tomasz Buchert (http://bugzilla.maptools.org/show_bug.cgi?id=2480)
Description: fix for Debian bug #741451
tiffcp crashes when converting JPEG-encoded TIFF to a different
encoding (like none or lzw). For example this will probably fail:
tiffcp -c none jpeg_encoded_file.tif output.tif
The reason is that when the input file contains JPEG data,
the tiffcp code forces conversion to RGB space. However,
the output normally inherits YCbCr subsampling parameters
from the input, which leads to a smaller working buffer
than necessary. The buffer is subsequently overrun inside
cpStripToTile() (called from writeBufferToContigTiles).
Note that the resulting TIFF file would be scrambled even
if tiffcp wouldn't crash, since the output file would contain
RGB data intepreted as subsampled YCbCr values.
This patch fixes the problem by forcing RGB space on the output
TIF if the input is JPEG-encoded and output is *not* JPEG-encoded.
Author: Tomasz Buchert <tomasz.buchert@inria.fr>
CVE-2010-1411 was not complete.
* libtiff/tiffiop.h (TIFFSafeMultiply): New macro to safely
multiply two integers. Returns zero if there is an integer
overflow.
* tools/tiffcp.c (main): tiffcp should not leak memory if an error
is reported when reading the input file.
for TIFFError(), TIFFErrorExt(), TIFFWarning(), and
TIFFWarningExt() in order to reveal bugs.
* Many fixes throughout to work better as a 64-bit build.
