AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
September 2007

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2007.09.20 21:03 "libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Frank Warmerdam
2007.09.20 22:20 "Re: libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Andrey Kiselev
2007.09.21 17:46 "Re: libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Joris Van Damme
2007.10.04 15:05 "Re: libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Frank Warmerdam
2007.10.05 05:45 "Re: libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Joris Van Damme

2007.09.20 22:20 "Re: 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