Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: <filtered@awaresystems.be>
Received: from mx8.public.one.com ([10.246.18.28])
	by mail6.local.one.com (Dovecot) with LMTP id jnjfOA1/e1c98AAAsyOMew
	for <filtered@awaresystems.be>; Tue, 05 Jul 2016 09:43:48 +0000
X-HalOne-ID: f8776916-4294-11e6-a152-549f350a57e2
Received: from mail-qk0-f179.google.com (unknown [209.85.220.179])
	by mx8.public.one.com (Halon Mail Gateway) with ESMTPS
	for <filtered@awaresystems.be>; Tue,  5 Jul 2016 09:43:46 +0000 (UTC)
Received: by mail-qk0-f179.google.com with SMTP id u68so7169851qkc.3
        for <filtered@awaresystems.be>; Tue, 05 Jul 2016 02:43:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-original-authentication-results:x-gm-message-state:delivered-to
         :mime-version:from:date:message-id:to:subject:precedence:list-id
         :list-unsubscribe:list-archive:list-post:list-help:list-subscribe
         :mime-version:sender:errors-to;
        bh=Qvt10v/DAYNBDyPsZlwBvQ3YbMpgLaNMLg8j3npFwbU=;
        b=NM3VeBrebx98+ALQYHXgmPFvJl/y5H0xqpn74Y3D+65Ov1sJFSGa1me7r089gRc/ON
         imMFAeIt7vYbcSZ90CGXI3LYpGrQPKVmT7f6nj7/mVoOM/LbBA16zSJ4tBv+4nh086++
         5umbWLRleURRW7JLY68NmTVGwzcKw95AQdj3EWtwqh/HIgJjXoOtTXjBMeRADYq4OS1h
         pKDrITINK43bB7DSm1lS/Ee8+M9ixY5BaPyR4ORDV9Ekx2gx5j/gELl/hOika9MQsR1n
         s7OnvwG0QvQgfRqdiQuIC1DxFI9gvZXsfaXhL8zYdYrNHYPN6A8RBPPiUCIfnLHpKiUC
         BUqw==
X-Original-Authentication-Results: mx.google.com;       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org;       dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
X-Gm-Message-State: ALyK8tJkU6ooTjEeZRI+R4sx8b/BbOlBOQMFJWYXnZfVpwkNvx/GmhrTQVjIpYPTseuIBpIG6xdWQh3q9yxv3JXn8a9Mo6g=
X-Received: by 10.55.21.97 with SMTP id f94mr21450416qkh.8.1467711825640;
        Tue, 05 Jul 2016 02:43:45 -0700 (PDT)
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.55.147.70 with SMTP id v67csp178440qkd;
        Tue, 5 Jul 2016 02:43:44 -0700 (PDT)
X-Received: by 10.28.10.196 with SMTP id 187mr15782539wmk.48.1467711824628;
        Tue, 05 Jul 2016 02:43:44 -0700 (PDT)
Return-Path: <tiff-bounces@lists.maptools.org>
Received: from lists.maptools.org (ks365428.kimsufi.com. [94.23.4.142])
        by mx.google.com with ESMTP id hq9si2393282wjb.0.2016.07.05.02.43.43;
        Tue, 05 Jul 2016 02:43:44 -0700 (PDT)
Received-SPF: neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=94.23.4.142;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org;
       dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 4784435C03C;
	Tue,  5 Jul 2016 04:42:31 -0500 (EST)
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
	by lists.maptools.org (Postfix) with ESMTPS id D6B5635C026
	for <tiff@lists.maptools.org>; Tue,  5 Jul 2016 04:42:12 -0500 (EST)
Received: by mail-wm0-f53.google.com with SMTP id r190so25808015wmr.0
	for <tiff@lists.maptools.org>; Tue, 05 Jul 2016 02:42:12 -0700 (PDT)
X-Received: by 10.194.177.230 with SMTP id ct6mr14217507wjc.170.1467711731647; 
	Tue, 05 Jul 2016 02:42:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.21.201 with HTTP; Tue, 5 Jul 2016 02:41:52 -0700 (PDT)
From: Yakov Galka <ybungalobill@gmail.com>
Date: Tue, 5 Jul 2016 12:41:52 +0300
Message-ID: <CAO=tXLDUwfzM1Tt+S17MKC-=mhZSLQYB0A6dV8NXbP1Dw5m67A@mail.gmail.com>
To: tiff@lists.maptools.org
Subject: [Tiff] Proposed API improvements
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: multipart/mixed; boundary="===============0435512076=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============0435512076==
Content-Type: multipart/alternative; boundary=089e013d1d9c65ce740536e0449e

--089e013d1d9c65ce740536e0449e
Content-Type: text/plain; charset=UTF-8

Hello everyone,


I know that libtiff is very old, doesn't change much, and thus I'm not sure
how reluctant you are to any significant modifications, even if backward
compatible. Yet, I inherited a codebase that uses libtiff a lot and thus I
wish to provide some input based on my experience of real-world uses of
libtiff, lessons learned, and suggest what can be done to improve libtiff
in year 2016.


Uniformization: Read strips as tiles
=============

Despite the difference between them per the specification, they are
essentially different ways to segment the image. Code that reads a TIFF
does the same thing: gets the dimensions of the tiles/strips, computes the
indices of the tiles/strips within the region-of-interest, and fetches the
data from these tiles/strips. In the codebase I maintain there was a lot of
code that supported both tiled and stripped tiffs by means of conditioning
and calling one interface or the other. I refactored it to use some
TIFFBlockXXX functions which dispatch to TIFFTileXXX or TIFFStripXXX as
needed, thus hiding the differences. Although a trivial change, I believe
that others will benefit if this makes it into libtiff. Since libtiff can
extend the behavior of its APIs, we can change the TIFFTileXXX interface to
support reading strips rather than introducing new API like I did. The only
function that has to be added is TIFFTileDims(TIFF *t, uint32 *tw, uint32
*th, uint32 *td) which will return the dimensions by looking at the tags
appropriate for the tiff at hand.

Having something like this for writing TIFFs would be useful too, though I
haven't looked into it yet.

Note that libtiff already provides a somewhat similar feature wrt. reading
scanlines through the strip interface (aka 'strip chopping'), though there
we have a significant difference between the two: strips provide fast
random-access which scanlines do not.

Side note on strip chopping: it had been nice if the reported tag values
would always be what's written in the TIFF (or what's implied), and the
actual tile sizes reported by TIFFTileDims. Though I acknowledge that this
would break the compatibility and thus isn't relevant much for the current
discussion.


Error handling
=========

Already raised in, at least, 2000 and 2007:
http://www.asmail.be/msg0054963626.html
http://www.asmail.be/msg0054639755.html

Current error handling routines are overridden globally, thus causing
trouble in multi-threaded environments or in library code that uses libtiff
internally but cannot interfere with other users of libtiff (i.e. from
application code or sibling libraries using libtiff).

It was suggested to use TIFFErrorHandlerExt as a potential solution. But
TIFFErrorHandlerExt CANNOT BE RELIABLY USED, because the caller of
TIFFErrorHandlerExt is not in control of what the clientdata he is
receiving will be.

In one of the above threads, it was proposed to duplicate each of the
TIFFOpen, TIFFOpenW, TIFFFdOpen, TIFFClientOpen functions to accept the
error handling procedure. I want to note that this is nonsensical either,
because if the clientdata isn't specified by the author of the error
handler (like in the TIFFOpen, TIFFOpenW and TIFFFdOpen) then there is
nothing she can do with it in the callback. Therefore it's only the
TIFFClientOpen which has to be extended.


Surely these features require a lot of laborious work (mostly the second
one). I may participate in some of the effort. Therefore, considering the
scope of the changes, I wish a consensus is reached of whether such changes
would be welcome at all.


Sincerely,
Yakov

--089e013d1d9c65ce740536e0449e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hello everyone,</p><p><br></p><p></p>
<p dir=3D"ltr">I know that libtiff is very old, doesn&#39;t change much, an=
d thus I&#39;m not sure how  reluctant you are to any significant modificat=
ions, even if backward compatible. Yet, I inherited a codebase that uses li=
btiff a lot and thus I wish to provide some input based on my experience of=
 real-world uses of libtiff, lessons learned, and suggest what can be done =
to improve libtiff in year 2016.</p>
<p dir=3D"ltr"><br></p>
<p dir=3D"ltr">Uniformization: Read strips as tiles<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</p>
<p dir=3D"ltr">Despite the difference between them per the specification, t=
hey are essentially different ways to segment the image. Code that reads a =
TIFF does the same thing: gets the dimensions of the tiles/strips, computes=
 the indices of the tiles/strips within the region-of-interest, and fetches=
 the data from these tiles/strips. In the codebase I maintain there was a l=
ot of code that supported both tiled and stripped tiffs by means of conditi=
oning and calling one interface or the other. I refactored it to use some T=
IFFBlockXXX functions which dispatch to TIFFTileXXX or TIFFStripXXX as need=
ed, thus hiding the differences. Although a trivial change, I believe that =
others will benefit if this makes it into libtiff. Since libtiff can extend=
 the behavior of its APIs, we can change the TIFFTileXXX interface to suppo=
rt reading strips rather than introducing new API like I did. The only func=
tion that has to be added is TIFFTileDims(TIFF *t, uint32 *tw, uint32 *th, =
uint32 *td) which will return the dimensions by looking at the tags appropr=
iate for the tiff at hand.</p><p dir=3D"ltr">Having something like this for=
 writing TIFFs would be useful too, though I haven&#39;t looked into it yet=
.</p>

<p dir=3D"ltr">Note that libtiff already provides a somewhat similar featur=
e wrt. reading scanlines through the strip interface (aka &#39;strip choppi=
ng&#39;), though there we have a significant difference between the two: st=
rips provide fast random-access which scanlines do not.</p><p dir=3D"ltr">S=
ide note on strip chopping: it had been nice if the reported tag values wou=
ld always be what&#39;s written in the TIFF (or what&#39;s implied), and th=
e actual tile sizes reported by TIFFTileDims. Though I acknowledge that thi=
s would break the compatibility and thus isn&#39;t relevant much for the cu=
rrent discussion.<br></p><p dir=3D"ltr"><br></p>
<p dir=3D"ltr">Error handling<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D</p>
<p dir=3D"ltr">Already raised in, at least, 2000 and 2007:<br>
<a href=3D"http://www.asmail.be/msg0054963626.html" target=3D"_blank">http:=
//www.asmail.be/msg0054963626.html</a><br>
<a href=3D"http://www.asmail.be/msg0054639755.html" target=3D"_blank">http:=
//www.asmail.be/msg0054639755.html</a></p>
<p dir=3D"ltr">Current error handling routines are overridden globally, thu=
s causing trouble in multi-threaded environments or in library code that us=
es libtiff internally but cannot interfere with other users of libtiff (i.e=
. from application code or sibling libraries using libtiff).</p>
<p dir=3D"ltr">It was suggested to use TIFFErrorHandlerExt as a potential s=
olution. But TIFFErrorHandlerExt CANNOT BE RELIABLY USED, because the calle=
r of TIFFErrorHandlerExt is not in control of what the clientdata he is rec=
eiving will be.</p>
<p dir=3D"ltr">In one of the above threads, it was proposed to duplicate ea=
ch of the TIFFOpen, TIFFOpenW, TIFFFdOpen, TIFFClientOpen functions to acce=
pt the error handling procedure. I want to note that this is nonsensical ei=
ther, because if the clientdata isn&#39;t specified by the author of the er=
ror handler (like in the TIFFOpen, TIFFOpenW and TIFFFdOpen) then there is =
nothing she can do with it in the callback. Therefore it&#39;s only the TIF=
FClientOpen which has to be extended.</p><p dir=3D"ltr"><br></p>
<p dir=3D"ltr">Surely these features require a lot of laborious work (mostl=
y the second one). I may participate in some of the effort. Therefore, cons=
idering the scope of the changes, I wish a consensus is reached of whether =
such changes would be welcome at all.</p><p dir=3D"ltr"><br></p><p dir=3D"l=
tr"></p>
<p dir=3D"ltr">Sincerely,<br>
Yakov<br>
</p>
</div>

--089e013d1d9c65ce740536e0449e--

--===============0435512076==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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