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.21 17:46 "Re: 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
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html