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
October 2004

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

2004.10.01 07:22 "BigTIFF extension issue", by Joris Van Damme
2004.10.01 16:41 "Re: BigTIFF extension issue", by Ian Ameline
2004.10.01 16:53 "Re: BigTIFF extension issue", by Frank Warmerdam
2004.10.01 17:01 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.01 17:19 "Re: BigTIFF extension issue", by Steve Carlsen
2004.10.01 17:27 "Re: BigTIFF extension issue", by Chris Losinger
2004.10.01 17:48 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.01 17:48 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.01 17:50 "Re: BigTIFF extension issue", by Frank Warmerdam
2004.10.01 18:03 "Re: BigTIFF extension issue", by Chris Losinger
2004.10.01 22:22 "Re: BigTIFF extension issue", by Chris Cox
2004.10.02 01:21 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.02 01:45 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.02 03:19 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.02 10:20 "Re: BigTIFF extension issue", by Andy Cave
2004.10.03 15:59 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.04 08:53 "Re: BigTIFF extension issue", by Andy Cave
2004.10.04 11:56 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.02 03:43 "Re: BigTIFF extension issue", by Chris Cox
2004.10.02 04:10 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.02 04:41 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.02 04:53 "Re: BigTIFF extension issue", by Chris Cox
2004.10.02 10:28 "Re: BigTIFF extension issue", by Andy Cave
2004.10.03 00:39 "Re: BigTIFF extension issue", by Chris Cox
2004.10.04 08:34 "Re: BigTIFF extension issue", by Andy Cave
2004.10.04 14:02 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.04 14:21 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.04 14:57 "Re: BigTIFF extension issue", by Andy Cave
2004.10.04 23:11 "Re: BigTIFF extension issue", by Chris Cox
2004.10.05 08:43 "Re: BigTIFF extension issue", by Andy Cave
2004.10.05 13:27 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.04 11:29 "Re: BigTIFF extension issue", by Rob Tillaart
2004.10.04 14:54 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.04 15:04 "Re: BigTIFF extension issue", by Andy Cave
2004.10.04 15:23 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.04 15:43 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.04 15:54 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.04 16:50 "Re: BigTIFF extension issue", by Steve Carlsen
2004.10.04 18:20 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.04 18:30 "Re: BigTIFF extension issue", by Bill Bither
2004.10.04 18:36 "Re: BigTIFF extension issue", by Bob Friesenhahn
2004.10.04 18:46 "Re: BigTIFF extension issue", by Joris Van Damme
2004.10.04 18:59 "Re: BigTIFF extension issue", by Andy Cave
2004.10.05 14:41 "Re: BigTIFF extension issue", by Fernando Loygorri
2004.10.04 18:49 "Re: BigTIFF extension issue", by Andy Cave
2004.10.04 19:00 "Re: BigTIFF extension issue", by Bob Friesenhahn

2004.10.04 18:59 "Re: BigTIFF extension issue", by Andy Cave

Hi All.

Here's my crunch argument for calling it .tiff.

As a good programmer, I should write a good library. My library should write 
a dummy header that could be either little tiff or big tiff. It should then 
write the possibly unknown sized compressed data. If the file size ends up 
being too big, then it should patch it up as a big tiff file. If the file 
size ends up being small enough, it should patch it up as a small tiff file. 
In the case of patching it up as small tiff, there would be a small amount 
of space wasted - so what.

The big tiff file format should also introduce a new header / dict tag which 
is EXPLICITLY designed to allow for space that can be used later on. If I 
open a small tiff file, and append some data which then makes it a big tiff 
file, IF the file is only small tiff and the library is small tiff lib 
(2.5.7,...), it will fail. If the library is big tiff compatible, and the 
image file has this extra header / dict tag, then this extra header / dict 
tag can be used to 'expand/convert' the existing date from small tiff to big 
tiff.

Now think what this means. All files produced that are less than 2/4G called 
.tif can be processed by existing applications. They can be expanded and 
remain as small tiff. They can be expanded and converted to big tiff. Nice 
and backwards compatible. Any files produced that are (end up being) more 
than 2/4G probably could not be processed by existing applications anyway, 
as these apps probably have in them inherently the 2/4G limit that TIFF 
files have anyway.

So, as part of the big tiff spec, we REQUIRE that this extra header info and 
extra dict tags be there that allows a big tiff conforming file to expand.

Customers keep their existing extension. Bigtif files that are written that 
are small NEVER have a problem with existing libraries, including 2.5.7, 
3.0... of tiff. A bigtif library that reads a small tiff file, that does NOT 
contain these additions, is NOT allowed to append to that file and make it a 
bigtif file.

Everything works.

QED. End of discussion.

_andy.