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 21:03 "libtiff4, and the size of STRIPOFFSETs and TILEOFFSETs", by Frank Warmerdam

Joris, and others,

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.

If the dynamic sizing of these tags is considered important then I
can consider other approaches.  Perhaps some sort of flag I can set
at runtime to get the "biggest size" behavior I need.  But if this is
just intended to be a small space savings in file sizes I think it would
be simplier and safer to just write strip/tile offset/size values in "big"
form for bigtiff.

PS. I see the following when building now.  At least one of these used
to be used, but I altered things.  But a bunch have never been used. I'd
also like to remove the unused code.  It would cut down on warnings as well
as code bloat.

tif_dirwrite.c:902: warning: 'TIFFWriteDirectoryTagByte' defined but not used
tif_dirwrite.c:950: warning: 'TIFFWriteDirectoryTagSbyte' defined but not used
tif_dirwrite.c:1046: warning: 'TIFFWriteDirectoryTagSshort' defined but not used
tif_dirwrite.c:1142: warning: 'TIFFWriteDirectoryTagSlong' defined but not used
tif_dirwrite.c:1190: warning: 'TIFFWriteDirectoryTagLong8' defined but not used
tif_dirwrite.c:1212: warning: 'TIFFWriteDirectoryTagSlong8' defined but not used
tif_dirwrite.c:1266: warning: 'TIFFWriteDirectoryTagFloat' defined but not used
tif_dirwrite.c:1311: warning: 'TIFFWriteDirectoryTagDouble' defined but not used
tif_dirwrite.c:1451: warning: 'TIFFWriteDirectoryTagShortLongLong8Array' 
defined but not used

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org