Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
X-Original-To: filtered@awaresystems.be
Delivered-To: filtered@awaresystems.be
Received: from mx-k.one.com (mx-k.one.com [91.198.169.58])
	by mail9.b-one.net (Postfix) with ESMTP id B4A12400220
	for <filtered@awaresystems.be>; Thu, 26 Jan 2012 20:01:34 +0100 (CET)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-k: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.210.48 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-pz0-f48.google.com (mail-pz0-f48.google.com [209.85.210.48])
	by mx-k.one.com (Postfix) with ESMTP id 282E4144ABDB
	for <filtered@awaresystems.be>; Thu, 26 Jan 2012 19:01:33 +0000 (UTC)
Received: by dakj40 with SMTP id j40so810838dak.21
        for <filtered@awaresystems.be>; Thu, 26 Jan 2012 11:01:33 -0800 (PST)
Received: by 10.68.208.196 with SMTP id mg4mr7099151pbc.108.1327604493116;
        Thu, 26 Jan 2012 11:01:33 -0800 (PST)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.142.51.2 with SMTP id y2cs69970wfy;
        Thu, 26 Jan 2012 11:01:32 -0800 (PST)
Received: by 10.68.115.195 with SMTP id jq3mr7369997pbb.34.1327604491205;
        Thu, 26 Jan 2012 11:01:31 -0800 (PST)
Received-SPF: softfail (google.com: best guess record for domain of transitioning tiff-bounces@lists.maptools.org does not designate 91.198.169.250 as permitted sender) client-ip=91.198.169.250;
Received: by 10.68.18.6 with POP3 id s6mf1526704pbd.19;
        Thu, 26 Jan 2012 11:01:30 -0800 (PST)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-s.one.com (mx-s.one.com [91.198.169.250])
	by mail9.b-one.net (Postfix) with ESMTP id 72E3D400220
	for <info@awaresystems.be>; Thu, 26 Jan 2012 19:50:15 +0100 (CET)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-s.one.com (Postfix) with ESMTP id 17A1C2EEA6AD
	for <info@awaresystems.be>; Thu, 26 Jan 2012 18:50:14 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 03F191EDABF;
	Thu, 26 Jan 2012 13:49:14 -0500 (EST)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com
	[74.125.149.69])
	by lists.maptools.org (Postfix) with ESMTPS id CA98D1EDAB5
	for <tiff@lists.maptools.org>; Thu, 26 Jan 2012 13:14:42 -0500 (EST)
Received: from hub3.qnx.com ([209.226.137.86]) (using TLSv1) by
	na3sys009aob102.postini.com ([74.125.148.12]) with SMTP
	ID DSNKTyGYDxqZk0nGDFcT7FnEQ8fV50aV2iOT@postini.com;
	Thu, 26 Jan 2012 10:15:03 PST
Received: by hub3.qnx.com (Postfix, from userid 32767)
	id 5F11C6C51B3; Thu, 26 Jan 2012 13:14:38 -0500 (EST)
Received: from EXHTS1.ott.qnx.com (exhts1 [10.222.2.110])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by hub3.qnx.com (Postfix) with ESMTPS id AFF8F6C51AE;
	Thu, 26 Jan 2012 13:14:36 -0500 (EST)
Received: from EXMBX1.ott.qnx.com ([fe80::c5ad:e9ef:74ad:52de]) by
	EXHTS1.ott.qnx.com ([fe80::f573:de57:f69d:f285%13]) with mapi id
	14.01.0355.002; Thu, 26 Jan 2012 13:13:39 -0500
From: Christopher Cameron <ccameron@qnx.com>
To: Olivier Paquet <olivier.paquet@gmail.com>
Thread-Topic: [Tiff] TIFFClientOpen() output stream/encoding behaviour
Thread-Index: AQHM3ElXXdyBWyP7JkuZj0u/UwlC/pYfQuCA//+xRIA=
Date: Thu, 26 Jan 2012 18:13:39 +0000
Message-ID: <CB470154.210C%ccameron@qnx.com>
In-Reply-To: <CAAcuQebbm+3YYXhvtHSf9rwv7b1sXybGewTEoxLvObUE=5kcRw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.222.102.221]
Content-ID: <FA868A53F360A2449A593E1B85E689F2@qnx.com>
MIME-Version: 1.0
Cc: "tiff@lists.maptools.org" <tiff@lists.maptools.org>
Subject: Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

As this can be deployed on a device with limited memory, buffering the
whole image first would be undesirable.

And I suppose the strip offsets / byte counts can't simply come before
each strip right?

Then the file would be formatted, e.g.

Header -> IFD 0 -> Strip Offset 0 Strip Byte Count 0 -> Strip 0 -> Strip
Offset 1 -> Strip Byte Count 1 -> Strip 1 -> ...

But I think I read that the strip offsets and bytecounts are contiguous
blocks...

Chris

On 12-01-26 12:56 PM, "Olivier Paquet" <olivier.paquet@gmail.com> wrote:

>On Thu, Jan 26, 2012 at 11:41 AM, Christopher Cameron <ccameron@qnx.com>
>wrote:
>> I am writing a TIFF codec for an image library. We have decided to use
>> libtiff as the basis for that codec.
>>
>> The image library provides access to an output stream which can be
>>written
>> to only forward. Once data is written, it's written and the stream
>>pointer
>> can only go forward.
>
>I don't think it's possible to write a TIFF that way, at all, if you
>use lossless compression. The header needs to point an IFD which needs
>to contain strip (or tile) offsets which you'll know only once you
>have compressed the entire image. It would in theory be possible using
>no compression or a lossy compression codec with a fixed compression
>ratio as you can predict the strip/tile sizes in the file. But libtiff
>isn't architectured for that very specific purpose.
>
>The only way out I can see is to buffer up the TIFF output data for a
>whole image before writing it to your stream.
>
>Olivier

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
