This document describes the changes made to the software between the previous and current versions (see above). If you don't find something listed here, then it was not done in this timeframe, or it was not considered important enough to be mentioned. The following information is located here:
Added ZSTD compression codec. 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,
| Compressor | 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 |
Please note that COMPRESSION_ZSTD is self-assigned the id 34926 by the libtiff project and is not officially registered with Adobe since Adobe's registration function is defunct.
Added WebP compression codec. WebP is a high performance compressor intended for photos as commonly used on the Web. The WebP encoder is not designed for huge images, but serves very well for compressing strips and tiles in TIFF as long as the strips or tiles do not exceed the capability of the encoder.
As a test of compression performance metrics, GraphicsMagick was used on an extremely high quality 8-bit TIFF image from a Hasselblad H4D-200MS camera with pixel dimensions of 16352x12264. The image was re-encoded with 1024x1024 tiles and various compression algorithms, using default settings for each algorithm. Based on this test, the compression and decompression performance (in iterations per second), the resulting file size, and the calculated total PSNR are provided here. It can be seen that WebP provided excellent encode and decode performance, and the compressed file size was very small:
| Compressor | Compression | Decompression | File size | PSNR |
|---|---|---|---|---|
| None | 0.536 iter/s | 1.506 iter/s | 576.03MiB | Inf |
| LZW | 0.105 iter/s | 0.266 iter/s | 270.68MiB | Inf |
| ZStd | 0.020 iter/s | 0.518 iter/s | 238.42MiB | Inf |
| LZMA | 0.009 iter/s | 0.056 iter/s | 247.61MiB | Inf |
| ZIP | 0.009 iter/s | 0.301 iter/s | 247.88MiB | Inf |
| JPEG | 0.446 iter/s | 0.760 iter/s | 18.59MiB | 39.00 |
| WebP | 0.019 iter/s | 0.330 iter/s | 9.38MiB | 37.78 |
Please note that COMPRESSION_WEBP is self-assigned the id 34927 by the libtiff project and is not officially registered with Adobe since Adobe's registration function is defunct.
Fix for bug 2772. It is possible to craft a TIFF document where the IFD list is circular, leading to an infinite loop while traversing the chain. The libtiff directory reader has a failsafe that will break out of this loop after reading 65535 directory entries, but it will continue processing, consuming time and resources to process what is essentially a bogus TIFFdocument.
This change fixes the above behavior by breaking out of processing when a TIFF document has >= 65535 directories and terminating with an error.
Remove builtin support for GUI warning and error message boxes. Now warnings always go to the console by default unless applications define their own warning and error handlers.
GUI applications (and Windows CE) are required to define such handlers.