2004.05.27 01:15 "[Tiff] large TIFF - two alternatives", by Steve Carlsen

2004.06.04 14:01 "Re: [Tiff] large TIFF - two alternatives", by Frank Warmerdam

  1. add TIFFType of LONG8, an 8 byte (unsigned) int

Although I am not sure that any use would be made of it, why not have a signed version as well? Is the omission just complexity reduction?

I would concur that we should have TIFF_LONG8 (unsigned) and TIFF_SLONG8 (signed) for similarity with other integer types.

  1. StripOffsets and TileOffsets and ByteCounts can be LONG8

Can be? How do you know which they are? I think I am misunderstanding this. Either say that they _must_be_ LONG8 or define new tags StripOffsets8 and TileOffsets8 and ByteCounts8 that are always LONG8

The tag itself includes the type information, so I don't see any particular problem with allowing either type for the StripOffsets and TileOffsets field.

Alternative 2: A more modern and general approach

While I would prefer an approach like the one above that require only minimal changes to the code to support a new format definition, I am not adverse to an entirely new format as long as it remains as flexible as the original TIFF is. The only issue is implementation time, of which we all have less than we need.

I am with this too. I am interested in an upgraded TIFF that supports large files, but I am not interested in engineering a whole new format with high implementation cost.

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    | Geospatial Programmer for Rent