AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

1999.06.03 19:48 "Large File Support", by Bruce Forsberg
1999.06.04 03:45 "Re: Large File Support", by Frank Warmerdam
1999.06.04 07:32 "Re: Large File Support", by Rob Tillaart
1999.06.07 07:05 "Re: Large File Support", by Rainer Wiesenfarth
1999.06.08 21:14 "Re: Large File Support", by Peter Smith
1999.06.08 21:58 "Re: Large File Support", by Ed Grissom
1999.06.08 22:52 "Re: Large File Support", by Peter Smith
1999.06.09 01:27 "Re: Large File Support", by Martin Bailey
1999.06.09 06:50 "Re: Large File Support", by Owen Pearn
1999.06.09 14:33 "Re: Large File Support", by Martin Bailey
1999.06.09 08:07 "Re: Large File Support", by Rob Tillaart
1999.06.04 18:35 "Re: Large File Support", by Bruce Forsberg
1999.06.07 13:03 "Re: Large File Support", by Frank Warmerdam
1999.06.09 03:05 "Re: Large File Support", by <glen@lumisys.com>
1999.06.09 13:13 "Re: Large File Support", by Ed Grissom
1999.06.09 13:33 "Re: Large File Support", by Frank Warmerdam
1999.06.09 14:08 "Re: Large File Support", by Ed Grissom
1999.06.09 18:50 "Re: Large File Support", by Chris Barker
1999.06.09 18:41 "Large File Support", by Chris Barker
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 15:10 "Re: Large File Support", by Peter Smith
1999.06.10 16:56 "Re: Large File Support", by Chris Barker
1999.06.14 11:16 "Re: Large File Support", by Martin Bailey
1999.06.14 14:58 "Re: Large File Support", by Tom Lane
1999.06.14 15:30 "Re: Large File Support", by Eric Shapiro
1999.06.14 16:27 "Re: Large File Support", by Chris Barker
1999.06.14 15:51 "Re: Large File Support", by Martin Bailey
1999.06.09 15:52 "Re: Large File Support", by Ed Grissom
1999.06.10 09:48 "Re: Large File Support", by Klaus Bartz
1999.06.10 13:05 "Re: Large File Support", by Chris Hanson
1999.06.11 01:48 "Re: Large File Support", by <glen@lumisys.com>

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