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
May 1997

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

1997.05.02 07:04 "BIG TIFF file problems", by Hans Christiansen
1997.05.02 09:17 "Re: BIG TIFF file problems", by Bjorn Brox
1997.05.02 14:32 "Re: BIG TIFF file problems", by Ed Grissom
1997.05.02 19:45 "Re: BIG TIFF file problems", by Niles Ritter
1997.05.02 21:24 "Re: BIG TIFF file problems", by Ed Grissom
1997.05.02 09:47 "Re: BIG TIFF file problems", by Caspar Evans
1997.05.02 16:41 "Re: BIG TIFF file problems", by Brian Mcdougle
1997.05.05 10:04 "Re: BIG TIFF file problems", by Gerben Vos

1997.05.02 19:45 "Re: BIG TIFF file problems", by Niles Ritter

Ed Grissom writes (regarding <4GB TIFF limitation),

>  Even though this is more of a TIFF problem than a libtiff problem, I
>  would like to make others aware of the limitations of TIFF - and stdio -
>  that we are running into. 

Yes, this is an intrinsic problem of all 32-bit architectures. You
can have HUGE disks, and you can stream through huge files, but
you can't easily have random-access seek's to huge files with
just 32 bit offsets.

>  If anyone knows about plans for getting around either of these problems
>  in TIFF 7.0, I'd sure like to hear about them.

I doubt it will make the TIFF 7.0 spec, which is under review
somewhere (are you still out there, Brian?).  TIFF 8.0 maybe. 

This would a fundamental
change in the structure of TIFF, as such, which has 32-bit offsets
everwhere. I would venture to say that to change this part of
TIFF would require changing the version number from 42 to 56.
(a gin-and-tonic to the first person to get this obscure half-joke).

IMHO, 64-bit TIFF could be done in a way that at least gives some
hope of backward compatibility.  The very first thing that needs
to be defined is a "LONG64" field type, which is an unsigned
64-bit integer value.

The file could start with a valid first TIFF IFD, which is, say, 
a 32-bit "thumbnail" of the BIG image. Needless to say, this 
entire thumbnail must reside in the first 2GB of the image.
The thumbnail image directory contains a tag of type LONG64,
which is the 64-bit offset to the start of the first 64-bit
TIFF image directory. It's structure would probably be some
64-bit flavored version of the 32-bit one, which is TBD.

TIFF 6.0 compliant readers will just issure a warning about
the strange field-type and tag, and go on its merry way with
the thumbnail.

Incidentally, I think you can just about address every atom
on the planet earth with 128 bits, so we don't have too
much further to go with this stuff. Let's see, Avogadro's
number is 6.02 x 10**23 (p/mol)...

 --Niles.