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.10 13:31 "Re: [Tiff] BigTIFF and Strip/TileByteCounts being of LONG type", by Bob Friesenhahn

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.

I can imagine tangible value from this. If libtiff is going to be space efficient, it might as well be maximally efficient.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt