2000.03.13 18:04 "Re: TIFF image file size", by Daniel McCoy
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 email@example.com