LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
May 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
Thread
2004.05.27 16:37 "Re: large TIFF - two alternatives", by Frank Warmerdam
Steve Carlsen wrote: > Greetings all, > > I haven't been involved in TIFF for a very long time, but I've been > talking to Chris Cox about the subject of "Large TIFF", and would like > to run a couple of alternatives by this group. > > The first alternative is, I think, the smallest number of changes > possible such that the result cleanly supports 8-byte addresses. > > The second alternative is the way I would design TIFF if I were doing it > over again today, taking advantage of the fact that no old TIFF readers > will be able to read "Large TIFF" files anyway, even with the minimal > approach. > > The second alternative is more general, more flexible, easier to debug, > supports layers, and simplifies a number of things. > > I don't _really_ expect to convince everyone that Alternative 2 is worth > the new code that it would require (not that any of it is difficult); > but I thought I should bring it up because if we're ever going to move > to a a more powerful version of the 'old TIFF', there will never be a > better opportunity than now. > > - SteveC > > > > Alternative 1: Minimal changes for TIFF to support 8-byte addresses > ----------------------------------------------------------------------------------------------------- > a. ID = 43 (or maybe 0x4242?) > b. 8-byte offset to 0th IFD > c. Value/Offset fields are 8 bytes > d. 8-byte offset to the next IFD (does anyone use this?) > e. add TIFFType of LONG8, an 8 byte (unsigned) int > f. StripOffsets and TileOffsets and ByteCounts can be LONG8 Steve, I think this approach is sensible and easy to implement. Any implementor of existing TIFF readers or writers could adapt to support this fairly easily. I am not fond of Alternative 2 as an upgrade to TIFF since it substantially alters the TIFF data model which I think would be disruptive. Of course, it might make sense to pursue as a next-generation imaging format but I wouldn't really want to call it TIFF. I also doubt that it would have enough advantages to gain wide adoption but I could be wrong. So, back to option 1, what would it take to get this ball rolling? Would Adobe consider producing an updated specification that addresses this? Would it be helpful for the libtiff team to go ahead with prototype implementation of the new format for "test driving"? I am personally very in favor of specification documents developed concurrently with a couple of interoperable implementations of the specification. PS. Folks, sorry for not participating in the discussion much to date. I was off for a week when the discussion peaked and I never found much I felt I needed to add from skimming it all. Steve's Alternative 1 pretty much captures what I wanted to accomplish albeit at the cost that older readers can't possible get anything from the new files till updated. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent