diff -r 000000000000 -r 1918ee327afb src/3rdparty/libtiff/html/v3.6.0.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/3rdparty/libtiff/html/v3.6.0.html Mon Jan 11 14:00:40 2010 +0000 @@ -0,0 +1,434 @@ + + + +Changes in TIFF v3.6.0 + + + + + + + + +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 accessable 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.

+ +Amoung 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: 2003/10/04 11:38:17 $. + + +