1997.01.31 16:07 "Re: write subset", by Sam Leffler

A similar problem: can I open a file for read/write (I don't want to append a new tiff directory) and read/write scanlines?

Open it for read, read the whole thing, close it, modify whatever scanlines you want, reopen it for write, write it, close it. (by the way, reading/writing strips TIFFReadEncodedStrip etc. is faster.)

Why do the members of this list always assume that an image would fit completely in main memory? What if you use images with a minimum size of 70MB (grayscale) or 210MB (RGB) (like we do)? The limit of TIFF images is given by the 32-Bit offsets used. This allows images of at least 2GB in size. It is a bad approach to copy the whole file when applying changes. If you want to update this kind of images, you have to 'program around' libtiff. In case you use uncompressed images, you can modify images by getting the TIFF fields StripOffsets or TileOffsets and do the reading/writing by hand.

This approach is not very handy, but - as far as I know - the only solution when you want to use libtiff. BTW, I would be very happy if Sam would introduce random access to libtiff. But I also know that this is not that easy (simply think of compressed images).

libtiff is intended to provide a low-level interface to TIFF images. You can build higher-level interfaces that do things like buffer image data, provide a uniform abstraction to different types of images, and permit random access to image data even when the underlying TIFF data structures do not support it--SGI ships such a product. There are numerous problems involved in supporting read+write access to a TIFF image and I have been unwilling to include facilities that provide only partial support because it adds significant complexity and inevitably leads to confusion ("What do you mean I can do this but not that!?"). If someone would like to take a stab at the problem I'd be happy to integrate the work in a future distribution.

        Sam