AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2007.08.24 21:08 "[Tiff] A few libtiff4 changes", by Frank Warmerdam
2007.09.20 21:03 "[Tiff] libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Frank Warmerdam
2007.09.20 22:20 "Re: [Tiff] libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Andrey Kiselev
2007.09.21 17:46 "Re: [Tiff] libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Joris
2007.10.04 15:05 "Re: [Tiff] libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Frank Warmerdam
[...]

2007.09.20 22:20 "Re: [Tiff] libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Andrey Kiselev

On Thu, Sep 20, 2007 at 05:03:57PM -0400, Frank Warmerdam wrote:

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.

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.

Hmm... I think it is not important for the current state of libtiff4, but it should be important for automatic switching between Classic TIFF and Big TIFF writing.

Best regards,

Andrey

--
Andrey V. Kiselev
ICQ# 26871517