Received: from sgi.sgi.com (192.48.153.1) by cerious.com
 with SMTP (Apple Internet Mail Server 1.1.1); Fri, 31 Jan 1997 17:35:07 -0500
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA22910; Fri, 31 Jan 1997 14:26:15 -0800
Received: (from daemon@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA26863 for tiff-list; Fri, 31 Jan 1997 16:10:08 GMT
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA26858 for <tiff-relay@relay.engr.sgi.com>; Fri, 31 Jan 1997 08:10:07 -0800
Received: from hyla.chez.sgi.com ([155.11.194.4]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA25910 for <tiff@sgi.com>; Fri, 31 Jan 1997 08:10:05 -0800
Received: from localhost by hyla.chez.sgi.com via SMTP (950413.SGI.8.6.12/940406.SGI)
	 id IAA28737; Fri, 31 Jan 1997 08:07:41 -0800
Message-Id: <199701311607.IAA28737@hyla.chez.sgi.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Rainer Wiesenfarth <wiesenfarth@zeiss.de>
cc: Kyriakos Georgiou <kg@olympiakos.com>,
        Thomas Loecherbach <thomasl@hjw.com>, tiff@sgi.com
Subject: Re: write subset 
Reply-To: Sam Leffler <sam@relay.engr.SGI.COM>
In-reply-to: Your message of "Fri, 31 Jan 1997 08:51:09 +0100."
             <32F1A46D.167E@zeiss.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 31 Jan 1997 08:07:41 -0800
From: Sam Leffler <sam@hyla.chez.sgi.com>
Sender: owner-tiff@relay.engr.SGI.COM
Precedence: bulk

    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


