Return-Path: <tiff-admin@remotesensing.org>
Received: from inav005.isp.belgacom.be (inav005.isp.belgacom.be [195.238.2.77])
        by six.skynet.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.14) with ESMTP id i2G4WsaK001924
        for <joris.at.lebbeke@skynet.be>; Tue, 16 Mar 2004 05:32:54 +0100
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from inmx012.isp.belgacom.be (inmx012.isp.belgacom.be [195.238.3.90])
        by inav005.isp.belgacom.be (8.12.9/8.12.9/Skynet-IN-AV-2.02) with ESMTP id i2G4WmRj015027
        for <joris.at.lebbeke@skynet.be>; Tue, 16 Mar 2004 05:32:49 +0100
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com ([208.24.120.42])
        by inmx012.isp.belgacom.be (8.12.9/8.12.9/Skynet-IN-2.32) with ESMTP id i2G4WaLJ031790
        for <joris.at.lebbeke@skynet.be>; Tue, 16 Mar 2004 05:32:37 +0100
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com (localhost.localdomain [127.0.0.1])
	by yoda.imagelinks.com (8.11.6/8.11.2) with ESMTP id i2G4VCl17974;
	Mon, 15 Mar 2004 23:31:12 -0500
Received: from sabre.velocet.net (postfix@sabre.velocet.net [216.138.209.205])
	by yoda.imagelinks.com (8.11.6/8.11.2) with ESMTP id i2G4Unl17943
	for <tiff@remotesensing.org>; Mon, 15 Mar 2004 23:30:50 -0500
Received: from pobox.com (H156.C195.tor.velocet.net [216.138.195.156])
	by sabre.velocet.net (Postfix) with ESMTP
	id 97182138251; Mon, 15 Mar 2004 23:30:47 -0500 (EST)
Message-ID: <405682F3.8040607@pobox.com>
From: Frank Warmerdam <warmerdam@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: d_sf@cox.net
Cc: tiff@remotesensing.org
Subject: Re: [Tiff] libtiff and streams
References: <BAY1-DAV38i4u6LbosM00026558@hotmail.com> <p0521060abc7bbefda1cb@[153.32.48.223]> <4056430A.9050509@cox.net>
In-Reply-To: <4056430A.9050509@cox.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: tiff-admin@remotesensing.org
Errors-To: tiff-admin@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Post: <mailto:tiff@remotesensing.org>
List-Subscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
List-Id: TIFF and libtiff discussion <tiff.remotesensing.org>
List-Unsubscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://remotesensing.org/pipermail/tiff/>
Date: Mon, 15 Mar 2004 23:30:43 -0500
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (inav005.isp.belgacom.be)
X-UIDL: 19f197559d6ef9a59bb410c106fb4083

Dimitar Gospodinov wrote:
> Hi,
> 
> How difficult would be to modify libtiff to support streams-like 
> operations?
> Having random access files is not always possible - for example when 
> reading from sockets, the file size is unknown.
> One of the things that should change, if streams are to be supported, is 
> get file size functions. They can not be used.
> 
> Do you think this is an easy change? For example using new switch for 
> "stream i/o"?

Dimitar,

I can only repeat and support what Joris has said and verify that it should
be possible to write TIFF files to a stream (since writing *normally* happens
sequentially) but that libtiff is not set to read from non-seekable streams.
As noted, the TIFF format makes extensive use of file offsets to connect
different structures, and places few requirements on the order of sections
of the file making general reading of libtiff files from a stream pretty
much impossible without caching the file somewhere.

However, there is a standard (EXIF? TIFF-IT?) which states a particular
order of sections in a TIFF file which guarantees it is possible to read the
file from a stream. Basically this is accomplished by ensuring that all
pointers point forward in the file.  Libtiff isn't setup to take advantage
of this or to generate this type of file.

I would note that by default libtiff will write the imagery right after the
8bit header, and then flush out the directory at the end of file on closing,
which makes it impossible to read the files in "streaming" form.

> P.S. I tried to use libtiff with streams and everything worked, except 
> get file size.

I'm not sure what file size getting is referred to.  Is this the code that
figures out where new stuff will be written based on current file size?
I believe libtiff uses seek and tell to figure out where stuff will be
written rather than keeping track of file length internally.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://remotesensing.org/mailman/listinfo/tiff
