2019.05.10 08:33 "Re: [Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Even Rouault

On vendredi 10 mai 2019 07:52:17 CEST Rob Tillaart wrote:

Afaik i see no negative implications although i miss information about percentage gained.

Depends on the number of tiles/strips. Here I'm thinking to images of size in the order of 1 million x 1 million pixels, with tiles of 512 x 512, so 3.8 million tiles, hnce the size of TileOffsets in LONG8 is ~ 30.5 MB and the size of TileByteCounts in LONG4 is ~ 15.2 MB.

That said

Would it make sense to allow SHORT (2 byte) too?

True, this is allowed in the spec too. Not directly in my use case, but given the security margin I took regarding compression schemes, SHORT could be only used in practice for uncompressed tiles up to 128 x 128 pixels of type Byte with up to 3 channels in PlanarConfig=Contig, or of size 128 x 128 of type Byte/Short/UShort with one channel.

I can give it a crack though.

Small tiles and strips could result in multiple identical ones. That could optimize transmission time by referencing earlier sent tiles that are identical.

In theory yes, but the TIFF6 specification warns about that: "No Duplicate Pointers. No data should be referenced from more than one place.TIFF readers and editors are under no obligation to detect this condition and handle it properly. This would not be a problem if TIFF files were read-only entities, but they are not. This warning covers both TIFF field value offsets and fieldsthat are defined as offsets, such as StripOffsets."

Even

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