TIFF CHANGE INFORMATION

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:

MAJOR CHANGES:

Custom Tag Support

The approach to extending libtiff with custom tags has changed radically. Previously, all internally supported TIFF tags had a place in the private TIFFDirectory structure within libtiff to hold the values (if read), and a "field number" (ie. FIELD_SUBFILETYPE) used to identify that tag. However, every time a new tag was added to the core, the size of the TIFFDirectory structure would changing, breaking any dynamically linked software that used the private data structures.

Also, any tag not recognised by libtiff would not be read and accessible to applications without some fairly complicated work on the applications part to pre-register the tags as exemplified by the support for "Geo"TIFF tags by libgeotiff layered on libtiff.

Among other things this approach required the extension code to access the private libtiff structures ... which made the higher level non-libtiff code be locked into a specific version of libtiff at compile time. This caused no end of bug reports!

The new approach is for libtiff to read all tags from TIFF files. Those that aren't recognised as "core tags" (those having an associated FIELD_ value, and place for storage in the TIFFDirectory structure) are now read into a dynamic list of extra tags (td_customValues in TIFFDirectory). When a new tag code is encountered for the first time in a given TIFF file, a new anonymous tag definition is created for the tag in the tag definition list. The type, and some other metadata is worked out from the instance encountered. These fields are known as "custom tags".

Custom tags can be set and fetched normally using TIFFSetField() and TIFFGetField(), and appear pretty much like normal tags to application code. However, they have no impact on internal libtiff processing (such as compression). Some utilities, such as tiffcp will now copy these custom tags to the new output files.

As well as the internal work with custom tags, new C API entry points were added so that extension libraries, such as libgeotiff, could define new tags more easily without accessing internal data structures. Because tag handling of extension tags is done via the "custom fields" mechanism as well, the definition provided externally mostly serves to provide a meaningful name for the tag. The addition of "custom tags" and the altered approach to extending libtiff with externally defined tags is the primary reason for the shift to the 3.6.x version number from 3.5.x.

CHANGES IN THE SOFTWARE CONFIGURATION:

CHANGES IN LIBTIFF:

CHANGES IN THE TOOLS:

CHANGES IN THE CONTRIB AREA: CHANGES IN THE LZW COMPRESSION KIT: TIFF home page.
Last updated $Date: 2016-09-25 20:05:45 $.