Return-Path: <tiff-admin@remotesensing.org>
Received: from inmx011.isp.belgacom.be (inmx011.isp.belgacom.be [195.238.3.50])
        by six.skynet.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.14) with ESMTP id i1O0VNCB031227
        for <joris.at.lebbeke@skynet.be>; Tue, 24 Feb 2004 01:31:23 +0100
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com ([208.24.120.42])
        by inmx011.isp.belgacom.be (8.12.9/8.12.9/Skynet-IN-2.32) with ESMTP id i1O0VFfr024420
        for <joris.at.lebbeke@skynet.be>; Tue, 24 Feb 2004 01:31:16 +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 i1O0UKl13793;
	Mon, 23 Feb 2004 19:30:21 -0500
Received: from DarkOne.ural.ru (relay.ural.ru [195.64.192.49])
	by yoda.imagelinks.com (8.11.6/8.11.2) with ESMTP id i1O0TTl13770
	for <tiff@remotesensing.org>; Mon, 23 Feb 2004 19:29:29 -0500
Received: from ubik.convex.ru (ubik.convex.ru [195.64.222.2])
	by DarkOne.ural.ru (8.12.10/Ural) with ESMTP id i1O0TQvm084319
	for <tiff@remotesensing.org>; Tue, 24 Feb 2004 05:29:26 +0500 (YEKT)
Received: from naumen.ru (vol.convex.ru [82.193.148.152])
	by ubik.convex.ru (8.12.11/8.12.11) with ESMTP id i1O0TNU7019356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <tiff@remotesensing.org>; Tue, 24 Feb 2004 05:29:28 +0500 (YEKT)
Message-ID: <403A9AC3.7080204@naumen.ru>
From: Vladimir Pastukhov <vpastukhov@naumen.ru>
Organization: NAUMEN
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: ru, en
MIME-Version: 1.0
To: tiff@remotesensing.org
Subject: Re: [Tiff] Request for new functions
References: <4039F826.8020603@naumen.ru> <403A1329.3080900@pobox.com>
In-Reply-To: <403A1329.3080900@pobox.com>
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: Tue, 24 Feb 2004 05:28:51 +0500
X-UIDL: 2ecc6f10bffeecf62e4037c7b4223aae

Hello,

Frank Warmerdam wrote:
> 
>  1) Why not just implement all image access (on a block by block basis)
>     for PIL with libtiff?   It seems to me there has been a longstanding
>     desire for a libtiff based PIL TIFF driver in addition to the existing
>     custom one.

This will require much more resources than I can afford
at this time.  On the other hand, current codecs-based patch
is rather simple and is being used by a considerable amount
of people for seven months already.  The only problem with
it seen so far is its dependence on the libtiff internals.

Another cause is that inside PIL file/IO manipulation and
codecs are separated, so writing full plugin would require
direct access to libtiff codecs alike.  Doing it in another
way can accidentally turn into a tricky task.

>  2) If not building a fully libtiff based plugin, why not just adapt
>     the codec code you need from libtiff into the pil plugin instead of
>     using a full libtiff just for the codecs.

This will need additional work to adapt new codecs and
features in the future.

Also I prefer library linking over copy&paste solutions.
I have seen several application containing (almost) the same
tif_fax3 files and this suggested me that allowing people
to link codecs from the library is good in general.

> I guess my general concern is that libtiff wasn't really intended to be
> a "codec engine" for applications that want to use the codecs in

A separate codec engine would be a big plus, but is does
not exist yet.  Then, why not to isolate libtiff codecs into
such a library one day?

> Perhaps it is this chunking I don't understand.  Lots of applications
> want to read TIFF files in chunks, but libtiff generally requires them
> to read a whole strip or block at a time, with a special case for line
> by line reading I think.

I'll look into this, and it seems like PNG plugin already
does something like that.  Though, AFAIR, I've seen some
(large) TIFF files consisting of a single "strip", which
is not memory-friendly (still, acceptable in most cases).

Best regards,
-- 
Vladimir Pastukhov
vpastukhov@naumen.ru

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