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.04 07:32 "Re: Large File Support", by Rob Tillaart

<lines deleted>

64 bit offsets for large images discussion

  >       As I see it, the fix for this is 64 bit offsets and this will
  >be a major compatibility break.
  >
  >Is there even an Adobe (or defacto) approved approach to this? 
  >
  >In my opinion:
  >
  > o Agreement should be reached on a way of handling 64bit offsets in TIFF
  >   files.
  >
  > o libtiff should be modified to support reading of 64bit files. 
  >
  > o libtiff should be modified to be able to generate 64bit files.  Of course
  >   it should not do that by default.
  >
  >Even with this approach it will be ages between 64bit files are widely
  >supported, but at least if we can get a 64bit toolkit out there the process
  >would begin. 
  >
  >Bruce, I presume you are with the photogrammetry group at Marconi?  Within t
  >*he
  >remote sensing, and photogrammetry community the 4GB limit is becoming
  >significant already.  I might be able to get funding from a government
  >agency, or software vendor to extend libtiff if there was general agreement
  >on an approach. 
  >
  >I can think of a few approachs.  One is to add a TIFF_LONGLONG type
  >to the list of data types, and this would be a 64bit integer.  The 
  >TIFFTAG_STRIPOFFSETS and TIFFTAG_TILEOFFSETS could optionally be of this typ
  >*e.
  >
  >A full 64 bit solution would also allow any other file offset or data block
  >size to be 64bit, but I think that is overkill.  On the other hand, it would
  >avoid problems with treating some offset specially, and if we are taking the
  >64bit plunge maybe it should be done comprehensively. 
  >
  >A third approach would be to add new TIFFTAG_TILEOFFSET32 and 
  >TIFFTAG_STRIPOFFSET32.  If found, the additional 32bit number would be a 
  >4GB page on which the chunk starts.  Put together with the normal offset
  >it gives a 64bit address.  Files smaller than 4GB, but generated with 
  >64bit offset handling would still be compatible with older applications
  >since they would just ignore the extra tags.
  >
  >Any opinion on the approaches?  Is this a solved problem, but just not 
  >incorporated into libtiff?

My 2 cents :)

What could be done is to define a new TIFF-header. In stead of the magic 
number 42 the number 64 could be used. Further everywhere where 32bit
numbers are used they are replaced with 64bit numbers. The rest of the 
specs does not need to change. Call the format TIFF64. 

Disadvantage is that there will be 2 libtiff's to support. Maybe TIFF64
sources could be generated from the libtiff32 sources.

Regards,
Rob van den Tillaart
Oce Technologies BV