Changes in TIFF v4.1.0¶
v4.1.0 (tag v4.1.0)
Master Download Site
Master HTTP Site #1
Master HTTP Site #2
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. A change summary is also provided by the
ChangeLog file included in the release package and by the Git commit
Make defer strile offset/bytecount loading available at runtime 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_LOADavailable for default builds when specifying the new
TIFFOpen()flag. In that mode, the [
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.
Another addition 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
TIFFGetStrileByteCountWithErr()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.
The BigTIFF writer now optimizes file size by using 32-bit
LONGvalues (rather than 64-bit) where it is reasonable and safe to do so. Likewise, the 16-bit
SHORTtype is used when possible for
Software configuration changes¶
WIN32build now uses
tif_win32.cwhen building with CMake.
Properly set value of
LSB2MSBfor Windows CMake builds. It was not being properly set!
Changes in the libtiff library may be viewed on-line Libtiff Library Commits..
TIFFReadFromUserBuffer()which replaces the use of
TIFFReadEncodedTile()when the user can provide the buffer for the input data, for example when he wants to avoid libtiff to read the strile offset/count values from the
TIFFForceStrileArrayWriting(). Those advanced writing functions must be used in a particular sequence to make their intended effect. Their aim is to control when/where the
[Strip/Tile][Offsets/ByteCounts]arrays are written into the file.
The purpose of this is to generate 'cloud-optimized geotiff' files where the first KB of the file only contain the IFD entries without the potentially large strile arrays. Those are written afterwards.
Changes in the libtiff utilities may be viewed on-line at Libtiff Tools Commits.
Contributed software changes¶
Changes in the libtiff contrib area may be viewed on-line at Libtiff Contrib Commits.