16703aca2SAndrey Kiselev<HTML> 26703aca2SAndrey Kiselev<HEAD> 36703aca2SAndrey Kiselev<TITLE> 46703aca2SAndrey Kiselev Changes in TIFF v4.0.0 56703aca2SAndrey Kiselev</TITLE> 66703aca2SAndrey Kiselev</HEAD> 76703aca2SAndrey Kiselev 86703aca2SAndrey Kiselev<BODY BGCOLOR=white> 96703aca2SAndrey Kiselev<FONT FACE="Helvetica, Arial, Sans"> 106703aca2SAndrey Kiselev<FONT FACE="Helvetica, Arial, Sans"> 116703aca2SAndrey Kiselev 126703aca2SAndrey Kiselev<BASEFONT SIZE=4> 136703aca2SAndrey Kiselev<B><FONT SIZE=+3>T</FONT>IFF <FONT SIZE=+2>C</FONT>HANGE <FONT SIZE=+2>I</FONT>NFORMATION</B> 146703aca2SAndrey Kiselev<BASEFONT SIZE=3> 156703aca2SAndrey Kiselev 166703aca2SAndrey Kiselev<UL> 176703aca2SAndrey Kiselev<HR SIZE=4 WIDTH=65% ALIGN=left> 186703aca2SAndrey Kiselev<B>Current Version</B>: v4.0.0<BR> 19feab28eaSBob Friesenhahn<B>Previous Version</B>: <A HREF=v3.9.5.html>v3.9.5</a><BR> 20*d4dd6cccSBob Friesenhahn<B>Master FTP Site</B>: <A HREF="ftp://download.osgeo.org/libtiff"> 21*d4dd6cccSBob Friesenhahndownload.osgeo.org</a>, directory pub/libtiff</A><BR> 22*d4dd6cccSBob Friesenhahn<B>Master HTTP Site</B>: <A HREF="ftp://download.osgeo.org/libtiff"> 23*d4dd6cccSBob Friesenhahnftp://download.osgeo.org/libtiff</a> 246703aca2SAndrey Kiselev<HR SIZE=4 WIDTH=65% ALIGN=left> 256703aca2SAndrey Kiselev</UL> 266703aca2SAndrey Kiselev 276703aca2SAndrey Kiselev<P> 286703aca2SAndrey KiselevThis document describes the changes made to the software between the 29feab28eaSBob Friesenhahn<I>previous</I> and <I>current</I> versions (see above). If you don't 30feab28eaSBob Friesenhahnfind something listed here, then it was not done in this timeframe, or 31feab28eaSBob Friesenhahnit was not considered important enough to be mentioned. Please consult 32feab28eaSBob Friesenhahnthe ChangeLog file in the source package for full change details. The 33feab28eaSBob Friesenhahnfollowing information is located here: 346703aca2SAndrey Kiselev<UL> 356703aca2SAndrey Kiselev<LI><A HREF="#hightlights">Major Changes</A> 366703aca2SAndrey Kiselev<LI><A HREF="#configure">Changes in the software configuration</A> 376703aca2SAndrey Kiselev<LI><A HREF="#libtiff">Changes in libtiff</A> 386703aca2SAndrey Kiselev<LI><A HREF="#tools">Changes in the tools</A> 396703aca2SAndrey Kiselev<LI><A HREF="#contrib">Changes in the contrib area</A> 406703aca2SAndrey Kiselev</UL> 416703aca2SAndrey Kiselev<p> 426703aca2SAndrey Kiselev<P><HR WIDTH=65% ALIGN=left> 436703aca2SAndrey Kiselev 446703aca2SAndrey Kiselev<!---------------------------------------------------------------------------> 456703aca2SAndrey Kiselev 4628b4b360SJoris Van Damme<P><A NAME="highlights"><B><FONT SIZE=+3>M</FONT>AJOR CHANGES:</B></A></P> 476703aca2SAndrey Kiselev 4828b4b360SJoris Van DammeBigTIFF support changes: 4928b4b360SJoris Van Damme 5028b4b360SJoris Van Damme<UL> 5128b4b360SJoris Van Damme 5280d98dc2SAndrey Kiselev <LI>The options parameter in the TIFFOpen and TIFFClientOpen funcs has 5380d98dc2SAndrey Kiselev been extended. When creating new files, you can add option '4' to 5480d98dc2SAndrey Kiselev specify you want to create a ClassicTIFF file, though that is the 5580d98dc2SAndrey Kiselev default and the option is not strictly necessary. (As such, old 5680d98dc2SAndrey Kiselev calling code will continue to function and create ClassicTIFF files.) 5780d98dc2SAndrey Kiselev Or you can add option '8' to specify you want to create a BigTIFF file 5880d98dc2SAndrey Kiselev instead. This new option is also reflected in some of the tools we 5980d98dc2SAndrey Kiselev already upgraded. For instance, you can use the -8 option on tiffcp to 6080d98dc2SAndrey Kiselev have tiffcp produce BigTIFF files instead of the default ClassicTIFF. 6180d98dc2SAndrey Kiselev (Whilst on additional option is provided for version selection when 6280d98dc2SAndrey Kiselev creating new files, no such option is necessary when reading TIFF 6380d98dc2SAndrey Kiselev files. LibTiff reads ClassicTIFF and BigTIFF both, and the application 6480d98dc2SAndrey Kiselev does not need to be aware which TIFF version an opened file is.) 6528b4b360SJoris Van Damme 6680d98dc2SAndrey Kiselev <LI>Although the tag count in BigTIFF is 64bit, we restricted the 6780d98dc2SAndrey Kiselev count in the implementation to a much more reasonable size. This is 6880d98dc2SAndrey Kiselev necessary in current implementation, because all tag data gets read 6980d98dc2SAndrey Kiselev automatically in the IFD reading stage, so if there's half a dozen 7080d98dc2SAndrey Kiselev private tags with multiple gigabytes of data that causes considerable 7180d98dc2SAndrey Kiselev overhead even if the application level is never interested in these 7280d98dc2SAndrey Kiselev tags. Our choice to ignore tags with data longer then a certain sanity 7380d98dc2SAndrey Kiselev value is much needed as things stand. We also recommend to step away 7480d98dc2SAndrey Kiselev from writing tiles that are 8 kilobyte in their uncompressed form, or 7580d98dc2SAndrey Kiselev writing single-line strips, in really big files, resulting in mega's 7680d98dc2SAndrey Kiselev of tiles or strips. It's much more efficient to choose bigger tile or 7780d98dc2SAndrey Kiselev strip sizes, up to several megabyte if needed, and have a few kilo of 7880d98dc2SAndrey Kiselev tiles or strips instead. 7928b4b360SJoris Van Damme 8080d98dc2SAndrey Kiselev <LI>Although it's rare, some application code does directly access 8180d98dc2SAndrey Kiselev file offsets. Some of these are automatically upgraded because they 8280d98dc2SAndrey Kiselev used the toff_t type, others need to be aware that the datatype 8380d98dc2SAndrey Kiselev changed and need to start using toff_t or uint64. This impacts access 8480d98dc2SAndrey Kiselev to tags like the EXIF IFD tag, for example, or the SubIfds tag, or to 8580d98dc2SAndrey Kiselev StripOffsets or TileOffsets, the return type of functions like 8680d98dc2SAndrey Kiselev TIFFCurrentDirOffset, and a parameter type to functions like 8780d98dc2SAndrey Kiselev TIFFSetSubDirectory. 8828b4b360SJoris Van Damme 8980d98dc2SAndrey Kiselev <LI>Although it's rare, some application code does use structures 9080d98dc2SAndrey Kiselev like TIFFHeader or TIFFDirEntry that used to be an exact binary 9180d98dc2SAndrey Kiselev representation of TIFF structures. These need to change. The old 9280d98dc2SAndrey Kiselev TIFFHeader structure is replaced by the new TIFFHeaderClassic, 9380d98dc2SAndrey Kiselev TIFFHeaderBig, and TIFFHeaderCommon structures that are an exact 9480d98dc2SAndrey Kiselev binary representation of the ClassicTIFF and BigTIFF header, and of 9580d98dc2SAndrey Kiselev the part that is common to both. There is no new equivalent for the 9680d98dc2SAndrey Kiselev old TIFFDirEntry structure (or more precisely, there is still a 9780d98dc2SAndrey Kiselev TIFFDirEntry structure, but it is changed, moved to library-private 9828b4b360SJoris Van Damme definition, and no longer an exact binary representation of the tag 9928b4b360SJoris Van Damme structure of either TIFF version). 10028b4b360SJoris Van Damme 10180d98dc2SAndrey Kiselev <LI>Sizer functions, like TIFFTileSize or TIFFScanlineSize and the 10280d98dc2SAndrey Kiselev like, return a tmsize_t value (tmsize_t is defined as int32 on 32bit 10380d98dc2SAndrey Kiselev machines, and int64 on 64bit machines, and as such it is meant to 10480d98dc2SAndrey Kiselev represent signed memory sizes). This is because we figure 98% of the 10580d98dc2SAndrey Kiselev calling code uses the return value as sizes in allocations and the 10680d98dc2SAndrey Kiselev like. So, any overflow that is theoretically possible with BigTIFF 10780d98dc2SAndrey Kiselev when LibTiff is running on a 32bit system, is best detected inside the 10880d98dc2SAndrey Kiselev sizer functions and it is best to return a type that makes sense as a 10980d98dc2SAndrey Kiselev memory size. If your calling code is the exception and is interested 11080d98dc2SAndrey Kiselev in actual file size, you best use the newer TIFFTileSize64 or 11180d98dc2SAndrey Kiselev TIFFScanlineSize64 function that returns an uint64 type. 11228b4b360SJoris Van Damme 113f7ec1e9dSBob Friesenhahn <LI>These TIFF tags require a 64-bit type as an argument in 114f7ec1e9dSBob Friesenhahn libtiff 4.0.0: 115f7ec1e9dSBob Friesenhahn <UL> 116f7ec1e9dSBob Friesenhahn <LI> TIFFTAG_FREEBYTECOUNTS 117f7ec1e9dSBob Friesenhahn <LI> TIFFTAG_FREEOFFSETS 118f7ec1e9dSBob Friesenhahn <LI> TIFFTAG_STRIPBYTECOUNTS 119f7ec1e9dSBob Friesenhahn <LI> TIFFTAG_STRIPOFFSETS 120f7ec1e9dSBob Friesenhahn <LI> TIFFTAG_TILEBYTECOUNTS 121f7ec1e9dSBob Friesenhahn <LI> TIFFTAG_TILEOFFSETS 122f7ec1e9dSBob Friesenhahn </UL> 123f7ec1e9dSBob Friesenhahn 12428b4b360SJoris Van Damme</UL> 12528b4b360SJoris Van Damme 12628b4b360SJoris Van DammeOther important backward incompatible changes in the public API: 1276703aca2SAndrey Kiselev 1286703aca2SAndrey Kiselev<UL> 1294441831fSAndrey Kiselev <LI> TIFFRewriteField() renamed into _TIFFRewriteField() and moved out 1304441831fSAndrey Kiselev from the public interface (from tiffio.h to tiffiop.h). Type of its 1314441831fSAndrey Kiselev 'count' parameter changed from uint32 to tmsize_t. 1324441831fSAndrey Kiselev 133875d6d38SAndrey Kiselev <LI> TIFFMergeFieldInfo() returns non-void result now. It returns 0 134875d6d38SAndrey Kiselev if successful and -1 if failed. Though this is now obsoleted function 135875d6d38SAndrey Kiselev and should not be used in new programs. Use the new tag extension 136875d6d38SAndrey Kiselev scheme instead. 137875d6d38SAndrey Kiselev 13880d98dc2SAndrey Kiselev <LI> TIFFFieldWithTag() and TIFFFieldWithName() functions now return 13980d98dc2SAndrey Kiselev pointer to TIFFField constant object instead of TIFFFieldInfo. 14080d98dc2SAndrey Kiselev 1416703aca2SAndrey Kiselev <LI> TIFFReassignTagToIgnore() function and TIFFIgnoreSense enumeration 1426703aca2SAndrey Kiselev have been removed. They was unused and never been used properly. 1436703aca2SAndrey Kiselev Should be unneeded for high-level applications. 1446703aca2SAndrey Kiselev 1456703aca2SAndrey Kiselev <LI> TIFFTagValue structure removed from the public tiffio.h 1466703aca2SAndrey Kiselev to private tif_dir.h and not accessible anymore. It should be unneeded 1476703aca2SAndrey Kiselev for high-level applications. 148f7ec1e9dSBob Friesenhahn 1496703aca2SAndrey Kiselev</UL> 1506703aca2SAndrey Kiselev 1516703aca2SAndrey Kiselev<P><HR WIDTH=65% ALIGN=left> 1526703aca2SAndrey Kiselev<!---------------------------------------------------------------------------> 1536703aca2SAndrey Kiselev 15428b4b360SJoris Van Damme<P><A NAME="configure"><B><FONT SIZE=+3>C</FONT>HANGES IN THE SOFTWARE CONFIGURATION:</B></A></P> 1556703aca2SAndrey Kiselev 1566703aca2SAndrey Kiselev<UL> 1576703aca2SAndrey Kiselev 158feab28eaSBob Friesenhahn <LI>Updated autotools: Autoconf 2.68, Automake 1.11.1, libtool 159feab28eaSBob Friesenhahn 2.4. 160aeb4c8beSBob Friesenhahn 161aeb4c8beSBob Friesenhahn <LI>Enabled support for Automake silent build rules 162aeb4c8beSBob Friesenhahn (--enable-silent-rules or 'make V=0') 163aeb4c8beSBob Friesenhahn 164aeb4c8beSBob Friesenhahn <LI>Enabled support for Automake colorized and parallel tests. 165aeb4c8beSBob Friesenhahn 166aeb4c8beSBob Friesenhahn <LI>Added detection of 64-bit integer types since libtiff 4.0 167aeb4c8beSBob Friesenhahn requires use of 64-bit signed and unsigned integer types. 168aeb4c8beSBob Friesenhahn 169aeb4c8beSBob Friesenhahn <LI>Libtiff now provides a more comprehensive test suite with 170aeb4c8beSBob Friesenhahn over 72 tests, which may be executed on Unix-like systems, or 171aeb4c8beSBob Friesenhahn under Microsoft Windows using MinGW/MSYS or Cygwin. 172aeb4c8beSBob Friesenhahn 173feab28eaSBob Friesenhahn <LI>--disable-lzma configure option to disable use of liblzma. 174feab28eaSBob Friesenhahn 175feab28eaSBob Friesenhahn <LI>--enable-defer-strile-load configure option to enable 176feab28eaSBob Friesenhahn experimental deferred strip/tile offset/size loading. May 177feab28eaSBob Friesenhahn cause some extremely sophisticated uses of libtiff to fail. 178feab28eaSBob Friesenhahn 179feab28eaSBob Friesenhahn <LI>--enable-chunky-strip-read configure option to enable 180feab28eaSBob Friesenhahn experimental enable reading large strips in chunks in 181feab28eaSBob Friesenhahn TIFFReadScanline(). 182feab28eaSBob Friesenhahn 183feab28eaSBob Friesenhahn <LI>Now always uses WIN32 native I/O functions for Microsoft 184feab28eaSBob Friesenhahn Windows except for under Cygwin. 185feab28eaSBob Friesenhahn 186feab28eaSBob Friesenhahn <LI>Now provides a pkg-config support file (libtiff-4.pc). 187feab28eaSBob Friesenhahn 1886703aca2SAndrey Kiselev</UL> 1896703aca2SAndrey Kiselev 1906703aca2SAndrey Kiselev<P><HR WIDTH=65% ALIGN=left> 1916703aca2SAndrey Kiselev 1926703aca2SAndrey Kiselev<!---------------------------------------------------------------------------> 1936703aca2SAndrey Kiselev 19428b4b360SJoris Van Damme<P><A NAME="libtiff"><B><FONT SIZE=+3>C</FONT>HANGES IN LIBTIFF:</B></A></P> 1956703aca2SAndrey Kiselev 1966703aca2SAndrey Kiselev<UL> 1976703aca2SAndrey Kiselev 198feab28eaSBob Friesenhahn <LI>Patches/fixes made to stable libtiff (v3.9.X) are also 199aeb4c8beSBob Friesenhahn applied to 4.0.0. There are too many to list here. See the 200aeb4c8beSBob Friesenhahn distribution ChangeLog for a detailed change list. 20128b4b360SJoris Van Damme 202aeb4c8beSBob Friesenhahn <LI>There is considerable change in some files like 203aeb4c8beSBob Friesenhahn tif_dirread and tif_dirwrite. These changes don't impact 204aeb4c8beSBob Friesenhahn backwards compatibility, they are mostly a clean rewrite that 205aeb4c8beSBob Friesenhahn does allow BigTIFF support as well as somewhat more robust 206aeb4c8beSBob Friesenhahn reading of the unexpected already and will also serve future 207aeb4c8beSBob Friesenhahn API extension but does not impact current API or functionality 208aeb4c8beSBob Friesenhahn in a negative way that you need to know about. 20928b4b360SJoris Van Damme 210aeb4c8beSBob Friesenhahn <LI>Although there is still a functional definition for types 211aeb4c8beSBob Friesenhahn like toff_t (file offset), tstrip_t (strip index number), etc, 212aeb4c8beSBob Friesenhahn we recommend against using these in newer code. We have 213aeb4c8beSBob Friesenhahn learned that it is next to impossible to use these 214aeb4c8beSBob Friesenhahn consistently and make real abstraction of the binary format of 215aeb4c8beSBob Friesenhahn these types. Instead, at a certain level we always end up 216aeb4c8beSBob Friesenhahn doing casts anyway, and taking the exact binary format into 217aeb4c8beSBob Friesenhahn account, so these types are nothing but dangerously misleading 218aeb4c8beSBob Friesenhahn and obfuscating. You do not need to update calling code that 219aeb4c8beSBob Friesenhahn uses them, as 99.9% of such code will continue to work. But we 220aeb4c8beSBob Friesenhahn recommend against using them in newer calling code, and we 221aeb4c8beSBob Friesenhahn started replacing them with binary clear types like uint16, 222aeb4c8beSBob Friesenhahn uint32 and such in the library. 223aeb4c8beSBob Friesenhahn 224aeb4c8beSBob Friesenhahn <LI>We do use and will continue to use one functional type 225aeb4c8beSBob Friesenhahn that is an exception to the above rule, being tmsize_t. This 226aeb4c8beSBob Friesenhahn is a signed memory size type, i.e. it is int32 on 32bit 227aeb4c8beSBob Friesenhahn machines, or int64 on 64bit machines. 22828b4b360SJoris Van Damme 229feab28eaSBob Friesenhahn <LI>Optionally support LZMA compression via TIFF tag 34925. 230feab28eaSBob Friesenhahn Tiffcp supports compression levels similar to "-c lzma:p1" or 231feab28eaSBob Friesenhahn "-c zip:p9 for setting the LZMA compression parameters. 232feab28eaSBob Friesenhahn 233feab28eaSBob Friesenhahn <LI>Optionally defer the load of strip/tile offset and size 234feab28eaSBob Friesenhahn tags for optimized scanning of directories. Enabled with the 235feab28eaSBob Friesenhahn --enable-defer-strile-load configure option (DEFER_STRILE_LOAD 236feab28eaSBob Friesenhahn #define in tif_config.h). 237feab28eaSBob Friesenhahn 238feab28eaSBob Friesenhahn <LI>Optionally enable experimental support for reading big 239feab28eaSBob Friesenhahn strips in chunks. Enabled with the --enable-chunky-strip-read 240feab28eaSBob Friesenhahn configure option. 241feab28eaSBob Friesenhahn 2426703aca2SAndrey Kiselev</UL> 2436703aca2SAndrey Kiselev 2446703aca2SAndrey Kiselev<P><HR WIDTH=65% ALIGN=left> 2456703aca2SAndrey Kiselev 2466703aca2SAndrey Kiselev<!--------------------------------------------------------------------------> 2476703aca2SAndrey Kiselev 24828b4b360SJoris Van Damme<P><A NAME="tools"><B><FONT SIZE=+3>C</FONT>HANGES IN THE TOOLS:</B></A></P> 2496703aca2SAndrey Kiselev 2506703aca2SAndrey Kiselev<UL> 2516703aca2SAndrey Kiselev 252feab28eaSBob Friesenhahn <LI>tiffset: add -d and -sd switches to allow operation on 253feab28eaSBob Friesenhahn a particular directory, not just the first. 254feab28eaSBob Friesenhahn 2556703aca2SAndrey Kiselev</UL> 2566703aca2SAndrey Kiselev 2576703aca2SAndrey Kiselev<P><HR WIDTH=65% ALIGN=left> 2586703aca2SAndrey Kiselev 2596703aca2SAndrey Kiselev<!---------------------------------------------------------------------------> 2606703aca2SAndrey Kiselev 26128b4b360SJoris Van Damme<P><A NAME="contrib"><B><FONT SIZE=+3>C</FONT>HANGES IN THE CONTRIB AREA:</B></A></P> 2626703aca2SAndrey Kiselev 2636703aca2SAndrey Kiselev<UL> 2646703aca2SAndrey Kiselev</UL> 2656703aca2SAndrey Kiselev 266*d4dd6cccSBob FriesenhahnLast updated $Date: 2016-09-25 20:05:47 $. 2676703aca2SAndrey Kiselev 2686703aca2SAndrey Kiselev</BODY> 2696703aca2SAndrey Kiselev</HTML> 270