LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 1997
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
1997.01.31 16:07 "Re: write subset", by Sam Leffler
To: Kyriakos Georgiou <kg@olympiakos.com>
Subject: Re: write subset
Cc: Thomas Loecherbach <thomasl@hjw.com>, tiff@sgi.com
Date: Fri, 31 Jan 1997 08:51:09 +0100
From: Rainer Wiesenfarth <wiesenfarth@zeiss.de>
Kyriakos Georgiou wrote:
>
> Thomas Loecherbach <thomasl@hjw.com> writes:
>
> > [...]
>
> [...]
>
> >
> > 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).
<...stuff deleted...>
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