Return-Path: <tiff-admin@remotesensing.org>
Received: from inav008.isp.belgacom.be (inav008.isp.belgacom.be [195.238.2.78])
        by six.skynet.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.14) with ESMTP id i2G1jexk025009
        for <joris.at.lebbeke@skynet.be>; Tue, 16 Mar 2004 02:45:40 +0100
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from inmx012.isp.belgacom.be (inmx012.isp.belgacom.be [195.238.3.90])
        by inav008.isp.belgacom.be (8.12.9/8.12.9/Skynet-IN-AV-2.02) with ESMTP id i2G1jdmi009397
        for <joris.at.lebbeke@skynet.be>; Tue, 16 Mar 2004 02:45:39 +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 i2G1jVnS007416
        for <joris.at.lebbeke@skynet.be>; Tue, 16 Mar 2004 02:45:32 +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 i2G1eBl16911;
	Mon, 15 Mar 2004 20:40:11 -0500
Received: from lakemtao02.cox.net (lakemtao02.cox.net [68.1.17.243])
	by yoda.imagelinks.com (8.11.6/8.11.2) with ESMTP id i2G1d2l16892
	for <tiff@remotesensing.org>; Mon, 15 Mar 2004 20:39:02 -0500
Received: from cox.net ([68.100.86.50]) by lakemtao02.cox.net
          (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP
          id <20040316013854.HVST13694.lakemtao02.cox.net@cox.net>;
          Mon, 15 Mar 2004 20:38:54 -0500
Message-ID: <40565AB0.8000200@cox.net>
From: Dimitar Gospodinov <d_sf@cox.net>
Reply-To: d_sf@cox.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joris <joris.at.lebbeke@skynet.be>
CC: Tiff mailing list <tiff@remotesensing.org>
Subject: Re: [Tiff] libtiff and streams
References: <BAY1-DAV38i4u6LbosM00026558@hotmail.com> <p0521060abc7bbefda1cb@[153.32.48.223]> <4056430A.9050509@cox.net> <001601c40aef$b46891f0$568388d9@dfgrrxsknr4e>
In-Reply-To: <001601c40aef$b46891f0$568388d9@dfgrrxsknr4e>
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 20:38:56 -0500
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (inav008.isp.belgacom.be)
X-UIDL: 231af453700466579683df3c77a11a60

I am not that familiar with the TIFF specification, and hoped that the 
specification itself would allow serial read/write.
But if it does not probably there is not much hope.

I am trying to read/write very simple TIFFs - no compression, single 
strip, 256 indexed colors.

Dimitar



Joris wrote:

>Dimitar Gospodinov wrote:
>  
>
>>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.
>>    
>>
>
>I think/thought such a thing is completely incompatible with the TIFF
>specification. It's quite possible and compliant with the specification that the
>header points to the first IFD being at the end of the file, which points to
>data spread throughout the file, and may point to a second IFD that follows the
>header immediatelly. Plus, applications could be interested in page 10 to begin
>with, and develop an interest in page 1 afterwards. (OK, finding IFD for page 10
>implies passing through IFD for page 1, but I mean, the actual raster decoding
>activity of page 1 should not be necessary at this stage, and yet still possible
>at any later stage.) So how can this scheme possible be combined with sequential
>access of the TIFF?
>
>I must be missing something basic and hope that someone will be so kind as to
>correct me.
>
>If I'm not mistaking, there's a kind of sub-specification somewhere, that does
>impose extra rules as to the actual order of the data blocks inside the TIFF
>file, mainly to work around this incompatibility of TIFF specification and
>stream-line sequential decoding. I seem to remember there's an RFC about this.
>But I could very well be mistaking.
>
>  
>
>>P.S. I tried to use libtiff with streams and everything worked, except
>>get file size.
>>    
>>
>
>Perhaps in this particular attempt both TIFF file and application requests where
>in some specific order?
>
>I've never understood LibTiff's need for file size. That is *not* a logical
>consequence of the TIFF specification, I think. But again, I gladly stand
>corrected.
>
>
>
>Joris Van Damme
>info@awaresystems.be
>http://www.awaresystems.be
>Download your free TIFF tag viewer for windows here:
>http://www.awaresystems.be/free_downloads/astifftools.html
>
>_______________________________________________
>Tiff mailing list
>Tiff@remotesensing.org
>http://remotesensing.org/mailman/listinfo/tiff
>
>  
>


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