LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
March 2000
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
2000.03.13 18:04 "Re: TIFF image file size", by Daniel Mccoy
From: Bruce Cameron <cameron@petris.com> >When you say 'file offset' I presume you mean strip offset, or an offset >the TIFF write process has to use to place header information at the >end of the file. It seems to me that if the header were at the start >of the file, then the size limitation is moot [except that the bytes >per strip are also limited to a [signed?unsigned?] integer. Although >I don't know if it is possible to ensure that the header data is at >the start of the file. Putting the directory at the front only pushes the problems to the strips. If you have really big strips that might give you a little bit more space, but it doesn't really fix the problem. Within the existing spec the only possible help is to treat the offsets as unsigned rather that signed as mentioned below, that doubles the possible size. (That's very short lasting help, since image sizes tend to go up by quadruples instead of doubles.) Beyond that, it would require a TIFF spec extension to allow 64-bit offsets or something. That being said, the directory can be put at the front. We do it all the time and sent the necessary patches in back when Sam was supporting it at sgi, although they may not have made it in before he handed it off, I can't remember at the moment and I've only got our internal version of the library handy. We write TIFF files from a renderer that can take hours to generate a picture. If something crashes halfway through we would like to be able to display the partial image. Even if it doesn't crash, it's handy to be able to display the image to see how far it's gotten. A libtiff written file is totally unreadable until the directory is written. In normal libtiff usage that's not the the file is closed. We added a call to tif_dirwrite.c called TIFFCheckpointDirectory. It checkpoints the directory information so that our image files are readable while our renderer still has them open and is writing to them. We usually call it before any strips are written, so that the directory is at the beginning of the file. As long as we don't add any more new tags after that point, just write strips of image data, it will keep re-writing the updated directory in place, and it will still be there at close. If you add any more new tags after the first checkpoint, the directory will get relocated to the current end of file and old directory location will end up a "hole" in the file. I'm not doing much tiff stuff myself these days but if this change is not in the current library, I could talk to the current tiff maintainer here about feeding this back into the library. Dan McCoy Pixar mccoy@pixar.com Frank Warmerdam wrote: > > Bruce, > > The most recent release version of libtiff (which this application may > be using) uses signed integers for file offset, and this implicitly > limits > seeks to be within the first 2GB. I presume the application has > successfully > written the image data beyond the 2GB limit (because no seeks are > required) > but when it tries to write the directory while closing the file a seek > is done > and this fail. I suspect BitsPerSample is just the first tag that it > tries > to write to the directory. > > The current CVS source contains patches to use unsigned offsets for file > positions, and allows writing and reading up to 4GB files successfully. > Because TIFF itself uses 32bit offsets in the format, it is not possible > to > go beyond 4GB without changing the format, or making some really funky > assumptions. > > Best regards, > > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn 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