LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 1999
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
1999.06.10 13:52 "Re: Large File Support", by Frank Warmerdam
Chris Hanson wrote: > > barker@ilt.com wrote: > > 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... Chris, 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, warmerda@home.com light and sound - activate the windows | http://members.home.com/warmerda and watch the world go round - Rush | Geospatial Programmer for Rent