Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx3.pub.mailpod2-cph3.one.com ([10.27.25.13])
	by mailstorage18.cst.mailpod2-cph3.one.com (Dovecot) with LMTP id I7jVHcNHXlo/ZwEAQS8vrQ
	for <filtered@awaresystems.be>; Tue, 16 Jan 2018 18:45:55 +0000
X-HalOne-ID: 7ad6e289-faed-11e7-9b3c-e0d84895d241
Received: from mail-oi0-f50.google.com (unknown [209.85.218.50])
	by mx3.pub.mailpod2-cph3.one.com (Halon) with ESMTPS
	id 7ad6e289-faed-11e7-9b3c-e0d84895d241;
	Tue, 16 Jan 2018 18:45:54 +0000 (UTC)
Received: by mail-oi0-f50.google.com with SMTP id u83so11309975oie.7
        for <filtered@awaresystems.be>; Tue, 16 Jan 2018 10:45:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-original-authentication-results:x-gm-message-state:delivered-to
         :in-reply-to:references:to:mime-version:from:message-id:date:cc
         :subject:precedence:list-id:list-unsubscribe:list-archive:list-post
         :list-help:list-subscribe:mime-version:sender:errors-to;
        bh=b1/qhXSkOHlIvCEildEMGZxaDo7I905dHVq03wmO8Jg=;
        b=PZglEFSoEP6leJTYZKP9QjvDCtOokVRYGHAyNnbKmbGc5WVAWM8Be5mOefDKegUrNz
         X14U59Micuhpf1RR7PRTxSSiwA7DwMDXiMqf7TIw8rQhJ3zqeFt/gztKQOJHZ9TA54pm
         /YoVZK6lln/OWbGxWEmEA3fkAhxEIcJvfXQma1FHf3OySFt8/G74V9ww2zilzZovP5ZS
         rvbuRajrroaMz370F/WI9owM5uGBVeJl3fSGjcEiZLULnBBZ/hUCx7ankshYXOdCrHI+
         9K7njYAdN7imBpFwA0wyaz+A7AtBYccLoG6cHKTwyzplx42D8ODZJ2Iw/uOTgakyGRO5
         Z8Xw==
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
X-Gm-Message-State: AKwxytfnBMebK4Dxu4JhtFWXM2ZH57bqzmNI2m9QnQ3308IgKvf1QWRE
	yR2aig+FcZ85Ewrt3t6Xy7nbb5YGoMMshzAe588AA2vpsnB7RrM=
X-Received: by 10.202.170.80 with SMTP id t77mr17143545oie.342.1516128352724;
        Tue, 16 Jan 2018 10:45:52 -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.202.235.11 with SMTP id j11csp4520157oih;
        Tue, 16 Jan 2018 10:45:51 -0800 (PST)
X-Google-Smtp-Source: ACJfBotjW9Im80ByHxw692DxGTo0Blp5+2pM9Ww4f9w6/4rBI+vD30CTJv2fz7gT+JWCgxuvvKH+
X-Received: by 10.28.145.67 with SMTP id t64mr48422wmd.83.1516128351429;
        Tue, 16 Jan 2018 10:45:51 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1516128351; cv=none;
        d=google.com; s=arc-20160816;
        b=gTaz6PSLIEzFJglWg9QWbqU0WY9cL/EaEyO+4O2BaIQRlFq+ytYa87w9NoxfTgpxPk
         RoEvuvuxpjCAx0Mkwo2jcYUEcc/KBdUxrdy/tHSGXdVBmNLlSBlxgLUpEcbuQHikU3KF
         MUSmnlpFaEmmnFHDz2Ewa+yWgwGebCs2BHJUo1fSZrmXNPuVFtZ+zGJLBkEogm2L9WFe
         P5EhtYT6nYWl6VhWgBT1DqFHoKrcVmKbTOoCC0QihXXYNU7V0wSiOGnddAIw1S8PW/6H
         ddmJzGniG+4clfIJlYFHpNElipdykF+jDutMJn8qx09HM4FTigb/0At+I3q7djaPnvxD
         01xg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=errors-to:sender:mime-version:list-subscribe:list-help:list-post
         :list-archive:list-unsubscribe:list-id:precedence:subject:cc:date
         :message-id:from:mime-version:to:references:in-reply-to
         :arc-authentication-results;
        bh=b1/qhXSkOHlIvCEildEMGZxaDo7I905dHVq03wmO8Jg=;
        b=JWs76A5xDtlaWZj8CC/LKltJ+w0lRow5R8KWXvZlQ9lGVUnlgdpyIe3mgtoKDe1jD3
         IiLzyeCm/nhZRlUueca1jlA4pOa8J3HsoKZYW2KEuDTT42LsBqPCdGb5S5bfZfyU0cJd
         3s9VpZMu2ZpNeCjb+yZdpMPneDUqkjJ7Qe2IOqoMfQQOgU3NMGEh+flnCXd0kW5jNmMJ
         EzQItShGdzSRZibcXfcHmk3V7AixR1EBJWxepNlFjL4mCyhfhdogFYWzoDXHwIKQjR4Q
         1v5cTyhK1CO4oRM7Zx5Ou+WgdeeV4di1heYz5lcey/VUjb0I//z8JcwYIxaygMjimjaj
         agyw==
ARC-Authentication-Results: i=1; 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
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 l22si2271756wrc.75.2018.01.16.10.45.50;
        Tue, 16 Jan 2018 10:45:51 -0800 (PST)
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
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 835CD35C042;
	Tue, 16 Jan 2018 13:44:49 -0500 (EST)
Received: from mx0a-00145802.pphosted.com (mx0a-00145802.pphosted.com
	[67.231.148.190])
	by lists.maptools.org (Postfix) with ESMTPS id AFCB235C03D;
	Tue, 16 Jan 2018 13:36:44 -0500 (EST)
Received: from pps.filterd (m0046141.ppops.net [127.0.0.1])
	by mx0a-00145802.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
	w0GIWkcR005413; Tue, 16 Jan 2018 13:36:40 -0500
Received: from mgamac05.us.ricoh.ds (mcnhost1.ikon.com [205.145.16.4])
	by mx0a-00145802.pphosted.com with ESMTP id 2ffeay1437-1;
	Tue, 16 Jan 2018 13:36:40 -0500
In-Reply-To: <f279e2e7-a91a-0cd8-a513-026479f571ff@cubewerx.com>
References: <39EE49FE-23A5-43DE-8998-51526287D182@larrygritz.com>	<alpine.GSO.2.20.1801151400550.18206@scrappy.simplesystems.org>
	<4252FC16-C07D-4FA1-8B7B-25D626633236@larrygritz.com>	<F78FB533EE93A044B560CD25E17A4DAF18388904@mbx031-e1-va-4.exch031.domain.local>
	<alpine.GSO.2.20.1801151728170.18206@scrappy.simplesystems.org>
	<f279e2e7-a91a-0cd8-a513-026479f571ff@cubewerx.com>
To: Craig Bruce <csbruce@cubewerx.com>
MIME-Version: 1.0
X-KeepSent: 239FD1E6:9CEBEE62-87258217:0064336B;
 type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
From: Joe.Maniaci@ricoh-usa.com
Message-ID: <OF239FD1E6.9CEBEE62-ON87258217.0064336B-87258217.00663BB4@ricoh-usa.com>
Date: Tue, 16 Jan 2018 11:36:39 -0700
X-MIMETrack: Serialize by Router on MGAMAC05/Servers/RCUS(Release
	9.0.1FP7|August 17, 2016) at 01/16/2018 13:36:39,
	Serialize complete at 01/16/2018 13:36:39
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
	definitions=2018-01-16_09:, , signatures=0
Cc: tiff-bounces@lists.maptools.org, tiff@lists.maptools.org
Subject: Re: [Tiff] Strategies for multi-core speedups
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="===============0597526292=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

This is a multipart message in MIME format.
--===============0597526292==
Content-Type: multipart/alternative; boundary="=_alternative 00663B6E87258217_="

This is a multipart message in MIME format.
--=_alternative 00663B6E87258217_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I am a complete newbie to digital imagery and TIFFs in general, so please=20
forgive any ignorance.

I'm an automated test tool developer and I am actually going to start=20
working on a viewer for the TIFFs that my company generates, to=20
potentially include relying on the bigtiff format and this is the thing=20
I've spent most of my time thinking about. I've come to the conclusion=20
that for the images we generate, up to 10GB uncompressed(soon to be 40GB), =

that I will need to preprocess a single TIFF into multiple TIFFs=20
containing intelligently placed tiles just to get around the I/O issue. By =

intelligently placed, I mean that if a user were to scroll their view=20
window to the right, and five tiles(vertically aligned) had to be loaded=20
into memory, I could theoretically have those files intelligently located=20
in different TIFF files(subTIFFs?) that would allow multiple threads to=20
operate on. So each thread only had to find one tile. So for my tool it=20
would be a staggering amount of pre-processing, but real time manipulation =

is extremely fluid for the user which is basically my number one=20
requirement.

So for a case like mine, thread overhead is nothing to worry about. That=20
and the more I read about the C++11 thread library, the less I worry. I=20
can just leave it to the library to determine how many threads should=20
operate in my 4-core environments, or my 16-core environments. At least=20
that's the impression I've garnered.

Joseph Maniaci
Staff Software Engineer
RPPS



From:   Craig Bruce <csbruce@cubewerx.com>
To:     tiff@lists.maptools.org
Date:   01/15/2018 06:15 PM
Subject:        Re: [Tiff] Strategies for multi-core speedups [EXTERNAL]
Sent by:        tiff-bounces@lists.maptools.org



On 01/15/2018 08:15 PM, Bob Friesenhahn wrote:
On Mon, 15 Jan 2018, Mike Stanton wrote:

To begin with I am an Operating Systems guy.  When you are looking=20
at going to multi-threading, what have you determined as your=20
setup/teardown cost for the individual threads? How large a chunk=20
will each thread be processing?  Will the individual Scan-lines=20
and/or Tiles be sufficiently large to absorb the cost of that setup=20
and teardown by the inherent performance you are projecting?

It is normal to use a pool of threads where threads are created in=20
advance (or added to the pool on demand) and obtained from, and=20
returned to, the pool.  This significantly reduces overheads caused by=20
starting/stopping threads.
Creating and destroying threads ought to take on the scale of a few=20
microseconds (on Linux anyway).  Larry Gritz was saying it takes 16.2=20
seconds to read what could be 1024 tiles of size 256=D7256, which is 15.8 m=
s=20
per tile, which is nearly four orders of magnitude longer than thread=20
creation for reading.  Writing with Deflate compression is about an order=20
of magnitude slower than reading.

However, you don't need to launch a new thread for every tile if you just=20
break up the job into N=3Dnumber=5Fof=5Fcpus pieces and launch N threads wh=
ere=20
each is pre-assigned to read or write a particular group of tiles of the=20
overall image.  The thread-creation overhead would be around six or seven=20
orders of magnitude smaller than the reading or writing.

--=20
Dr. Craig S. Bruce=20
Senior Software Developer=20
CubeWerx Inc.=20
http://www.cubewerx.com=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F
Tiff mailing list: Tiff@lists.maptools.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A=5F=5Flists.maptools.or=
g=5Fmailman=5Flistinfo=5Ftiff&d=3DDwICAg&c=3D5hYF0Zu0Yz-C6S-kaHDItw&r=3DHnV=
w9YJBS4ST0tOBucT3NvWUJRRGhDxXu4zHnS5AkgY&m=3DmaPcpWIIyHM0McvhMluxRFvFc3ku8e=
N0opVcbXErRdw&s=3DgO3D=5FJk1nPaHZIGWP4FoVE2ZjlePymETKPEx3kVi0g4&e=3D

https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A=5F=5Fwww.remotesensing=
.org=5Flibtiff=5F&d=3DDwICAg&c=3D5hYF0Zu0Yz-C6S-kaHDItw&r=3DHnVw9YJBS4ST0tO=
BucT3NvWUJRRGhDxXu4zHnS5AkgY&m=3DmaPcpWIIyHM0McvhMluxRFvFc3ku8eN0opVcbXErRd=
w&s=3DKMgAOGLTaf48zkJ9S4jYu9pWlvzrZ87u0jtXhoAD66c&e=3D

--=_alternative 00663B6E87258217_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<font size=3D2 face=3D"sans-serif">I am a complete newbie to digital imagery
and TIFFs in general, so please forgive any ignorance.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">I'm an automated test tool developer
and I am actually going to start working on a viewer for the TIFFs that
my company generates, to potentially include relying on the bigtiff format
and this is the thing I've spent most of my time thinking about. I've come
to the conclusion that for the images we generate, up to 10GB uncompressed(=
soon
to be 40GB), that I will need to preprocess a single TIFF into multiple
TIFFs containing intelligently placed tiles just to get around the I/O
issue. By intelligently placed, I mean that if a user were to scroll their
view window to the right, and five tiles(vertically aligned) had to be
loaded into memory, I could theoretically have those files intelligently
located in different TIFF files(subTIFFs?) that would allow multiple threads
to operate on. So each thread only had to find one tile. So for my tool
it would be a staggering amount of pre-processing, but real time manipulati=
on
is extremely fluid for the user which is basically my number one requiremen=
t.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">So for a case like mine, thread over=
head
is nothing to worry about. That and the more I read about the C++11 thread
library, the less I worry. I can just leave it to the library to determine
how many threads should operate in my 4-core environments, or my 16-core
environments. At least that's the impression I've garnered.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Joseph Maniaci</font>
<br><font size=3D2 face=3D"sans-serif">Staff Software Engineer</font>
<br><font size=3D2 face=3D"sans-serif">RPPS</font>
<br>
<br>
<br>
<br><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">From: &nbsp; &nbsp; =
&nbsp;
&nbsp;</font><font size=3D1 face=3D"sans-serif">Craig Bruce &lt;csbruce@cub=
ewerx.com&gt;</font>
<br><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">To: &nbsp; &nbsp; &n=
bsp;
&nbsp;</font><font size=3D1 face=3D"sans-serif">tiff@lists.maptools.org</fo=
nt>
<br><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">Date: &nbsp; &nbsp; =
&nbsp;
&nbsp;</font><font size=3D1 face=3D"sans-serif">01/15/2018 06:15 PM</font>
<br><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">Subject: &nbsp; &nbs=
p;
&nbsp; &nbsp;</font><font size=3D1 face=3D"sans-serif">Re: [Tiff] Strategies
for multi-core speedups [EXTERNAL]</font>
<br><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">Sent by: &nbsp; &nbs=
p;
&nbsp; &nbsp;</font><font size=3D1 face=3D"sans-serif">tiff-bounces@lists.m=
aptools.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3D3>On 01/15/2018 08:15 PM, Bob Friesenhahn wrote:</font>
<br><tt><font size=3D3>On Mon, 15 Jan 2018, Mike Stanton wrote:<br>
</font></tt>
<br><tt><font size=3D3>To begin with I am an Operating Systems guy. &nbsp;W=
hen
you are looking <br>
at going to multi-threading, what have you determined as your <br>
setup/teardown cost for the individual threads? How large a chunk <br>
will each thread be processing? &nbsp;Will the individual Scan-lines <br>
and/or Tiles be sufficiently large to absorb the cost of that setup <br>
and teardown by the inherent performance you are projecting?<br>
</font></tt>
<br><tt><font size=3D3>It is normal to use a pool of threads where threads
are created in <br>
advance (or added to the pool on demand) and obtained from, and <br>
returned to, the pool. &nbsp;This significantly reduces overheads caused
by <br>
starting/stopping threads.</font></tt>
<br><font size=3D3>Creating and destroying threads ought to take on the sca=
le
of a few microseconds (on Linux anyway).&nbsp; Larry Gritz was saying it
takes 16.2 seconds to read what could be 1024 tiles of size 256=D7256, which
is 15.8 ms per tile, which is nearly four orders of magnitude longer than
thread creation for reading.&nbsp; Writing with Deflate compression is
about an order of magnitude slower than reading.<br>
<br>
However, you don't need to launch a new thread for every tile if you just
break up the job into N=3Dnumber=5Fof=5Fcpus pieces and launch N threads wh=
ere
each is pre-assigned to read or write a particular group of tiles of the
overall image.&nbsp; The thread-creation overhead would be around six or
seven orders of magnitude smaller than the reading or writing.<br>
</font>
<br><font size=3D3>-- <br>
Dr. Craig S. Bruce <br>
Senior Software Developer <br>
CubeWerx<i> </i>Inc. </font><font size=3D3 color=3Dblue><u><br>
</u></font><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A=
=5F=5Fwww.cubewerx.com=5F&amp;d=3DDwMDaQ&amp;c=3D5hYF0Zu0Yz-C6S-kaHDItw&amp=
;r=3DHnVw9YJBS4ST0tOBucT3NvWUJRRGhDxXu4zHnS5AkgY&amp;m=3DmaPcpWIIyHM0McvhMl=
uxRFvFc3ku8eN0opVcbXErRdw&amp;s=3D-TSTD6g4v02=5FBC45E6RRb534KRI996uryYX=5Fp=
Cs5p2Q&amp;e=3D"><font size=3D3 color=3Dblue><u>http://www.cubewerx.com</u>=
</font></a><tt><font size=3D2>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F<br>
Tiff mailing list: Tiff@lists.maptools.org<br>
</font></tt><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A=
=5F=5Flists.maptools.org=5Fmailman=5Flistinfo=5Ftiff&amp;d=3DDwICAg&amp;c=
=3D5hYF0Zu0Yz-C6S-kaHDItw&amp;r=3DHnVw9YJBS4ST0tOBucT3NvWUJRRGhDxXu4zHnS5Ak=
gY&amp;m=3DmaPcpWIIyHM0McvhMluxRFvFc3ku8eN0opVcbXErRdw&amp;s=3DgO3D=5FJk1nP=
aHZIGWP4FoVE2ZjlePymETKPEx3kVi0g4&amp;e=3D"><tt><font size=3D2>https://urld=
efense.proofpoint.com/v2/url?u=3Dhttp-3A=5F=5Flists.maptools.org=5Fmailman=
=5Flistinfo=5Ftiff&amp;d=3DDwICAg&amp;c=3D5hYF0Zu0Yz-C6S-kaHDItw&amp;r=3DHn=
Vw9YJBS4ST0tOBucT3NvWUJRRGhDxXu4zHnS5AkgY&amp;m=3DmaPcpWIIyHM0McvhMluxRFvFc=
3ku8eN0opVcbXErRdw&amp;s=3DgO3D=5FJk1nPaHZIGWP4FoVE2ZjlePymETKPEx3kVi0g4&am=
p;e=3D</font></tt></a><tt><font size=3D2><br>
</font></tt><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A=
=5F=5Fwww.remotesensing.org=5Flibtiff=5F&amp;d=3DDwICAg&amp;c=3D5hYF0Zu0Yz-=
C6S-kaHDItw&amp;r=3DHnVw9YJBS4ST0tOBucT3NvWUJRRGhDxXu4zHnS5AkgY&amp;m=3DmaP=
cpWIIyHM0McvhMluxRFvFc3ku8eN0opVcbXErRdw&amp;s=3DKMgAOGLTaf48zkJ9S4jYu9pWlv=
zrZ87u0jtXhoAD66c&amp;e=3D"><tt><font size=3D2>https://urldefense.proofpoin=
t.com/v2/url?u=3Dhttp-3A=5F=5Fwww.remotesensing.org=5Flibtiff=5F&amp;d=3DDw=
ICAg&amp;c=3D5hYF0Zu0Yz-C6S-kaHDItw&amp;r=3DHnVw9YJBS4ST0tOBucT3NvWUJRRGhDx=
Xu4zHnS5AkgY&amp;m=3DmaPcpWIIyHM0McvhMluxRFvFc3ku8eN0opVcbXErRdw&amp;s=3DKM=
gAOGLTaf48zkJ9S4jYu9pWlvzrZ87u0jtXhoAD66c&amp;e=3D</font></tt></a>
<br>
--=_alternative 00663B6E87258217_=--

--===============0597526292==
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/
--===============0597526292==--
