TIFF and LibTiff Mail List Archive


1999.06.03 19:48 "Large File Support", by Bruce Forsberg
1999.06.10 13:21 "Re: Large File Support", by Chris Hanson
1999.06.10 13:52 "Re: Large File Support", by Frank Warmerdam
1999.06.10 14:37 "Re: Large File Support", by John Aldridge
1999.06.10 16:56 "Re: Large File Support", by Chris Barker

1999.06.10 13:52 "Re: Large File Support", by Frank Warmerdam

We need a real honest-to-goodness *standard* (without options) so we can write good (and freely available) software. While standardizing the format it would also be an excellent idea to standardize the programming interface to read/write/verify/info-extract libraries.

I disagree. I think it's extremely important that I be able to implement my code and API completely differently from yours and be able to call both of our libraries standards-conforming so long as we both pass a test suite. I don't want to be prevented from claiming to be a compliant TI64 producer or consumer simply because I used C++ when the standard API was specified in C...


I agree that the data format definition must stand on it's own without the requirement to use a particular library implementation or even API. On the other hand, I think it can be a big help folks who want to follow the standard properly to provide a reference library implementation of the standard and that by all means we should do this.

However, I am still concerned that a TIFF64 standard, or something similar, would never gain wide enough adoption of be of much use. I might achieve some success at getting a new TIFF format adopted in the GIS/RS community but to get desktop photo editing packages to adopt it would be alot harder.

I think a large part of the utility of TIFF format in the GIS/RS field is that it provides data sharing with non GIS/RS packages such as photoshop. If we don't achieve that breadth of adoption in a new standard then it is pretty well pointless.

We might be better off defining an extention whereby a TIFF file can refer to a series of other tiff files which together form a larger image. Then each file could be less than 4GB, but the total image could be more. Packages which don't understand the ``assembly of TIFF files'' tags could still operate on each sub-TIFF file independently. libtiff could be modified to automatically assemble the set of files into one virtual image through the standard APIs.

Would such an approach be of any interest?

Best regards,

I set the clouds in motion - turned up | Frank Warmerdam,
light and sound - activate the windows |
and watch the world go round - Rush    | Geospatial Programmer for Rent