2007.08.24 21:08 "[Tiff] A few libtiff4 changes", by Frank Warmerdam

2007.09.21 17:46 "Re: [Tiff] libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Joris Van Damme

I discovered a problem today with GDAL's use of libtiff4. The problem occurs because libtiff decides as it is writing directories whether to write fields like TILEOFFSETs as LONG (4byte) or LONG8 (8byte). However, my code depends on the questionable assumption that I can rewrite a directory after altering (only) the tile/strip offset and size values.

This apparently used to be true, but now it may happen that the offsets switch from using LONG to LONG8.

It used to be true for tiles, in LibTiff. Please note that it wasn't true for strips. StripByteCounts and StripOffsets in ClassicTIFF can be either SHORT or LONG, and LibTiff <4.0 behaved the same way already for these (picking smallest possible datatype, that is). As a sidenote, if I remember correctly, in the ClassicTIFF spec either TileByteCounts or TileOffsets is documented to have datatype SHORT or LONG, the other is documented to have datatype LONG only. If I remember correctly, that is, as I have no time to double-check. I've always interpreted this as a small oversight, and seeing the situation with strips, I've always considered SHORT a valid datatype of TileByteCounts and TileOffsets both. But LibTiff considered only LONG for these.

How important is this dynamic behavior?

I have taken the liberty of changing tif_dirwrite.c so that for BigTIFF files the tile/strip sizes and offsets are always written as LONG8. (r1.58 of tif_dirwrite.c) in order to resolve my GDAL problems.

I have done so by altering the semantics of TIFFWriteDirectoryTagLongLong8Array(). I believe it used to write the array of values as LONG if possible, otherwise write as LONG8 (if values are too large). Now it basically just writes as LONG for classic tiff, and as LONG8 for bigtiff. It also does some checking to confirm that larger than LONG values aren't being written to classic tiff.

I would recommend against changing things on that level. I'd rather change things in the level above this, and call TIFFWriteDirectoryTagLong8Array for TileByteCounts and TileOffsets tag. That's a hack too, but at least the lower level array of tag writer functions keep their intended behaviour and we keep the option to predictably reuse them for other stuff now or in the future.

Another option would be to add some mechanism to force the LONG8 datatype being used for TileByteCounts and TileOffsets from your calling code, so that there's no real change for code that doesn't need this feature.

Best regards,

Joris Van Damme
Download your free TIFF tag viewer for windows here: