AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2019.05.09 21:12 "[Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Even Rouault
2019.05.09 23:39 "Re: [Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Kemp Watson
2019.05.10 05:52 "Re: [Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Rob Tillaart
2019.05.10 08:33 "Re: [Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Even Rouault
2019.05.10 13:31 "Re: [Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Bob Friesenhahn

2019.05.09 21:12 "[Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Even Rouault

Hi,

I've submitted a merge request https://gitlab.com/libtiff/libtiff/merge_requests/78 which will result in BigTIFF files being created with the StripByteCounts / TileByteCounts tag using the LONG type instead of a LONG8, when the strip/ tiles are of "reasonable" size. See the detailed comment in the merge request for when this is done precisely.

In summary, such change is legal according to the BigTIFF specification, and in practice backward compatible with past libtiff 4.X versions. That said, I'm interested in hearing if people would be aware of interoperability problems with other implementations. I'm attaching such a (small) BigTIFF file for testing.

Motivation for the change: such an optimization is in particular important for "cloud" oriented use of TIFF where minimizing the amount of data transferred for partial reading of a file is desirable (further optimizations to come in that area).

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com