Return-Path: <rob.tillaart@gmail.com>
Delivered-To: even.rouault@spatialys.com
Received: from spool.mail.gandi.net (spool5.mail.gandi.net [217.70.178.214])
	by nmboxes134.sd4.0x35.net (Postfix) with ESMTP id 1F77260280
	for <even.rouault@spatialys.com>; Fri, 10 May 2019 05:52:30 +0000 (UTC)
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52])
	by spool.mail.gandi.net (Postfix) with ESMTPS id CD578D804A2
	for <even.rouault@spatialys.com>; Fri, 10 May 2019 05:52:29 +0000 (UTC)
Received: by mail-vs1-f52.google.com with SMTP id o10so2903413vsp.12
        for <even.rouault@spatialys.com>; Thu, 09 May 2019 22:52:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=jcdUgvqHH5NYsFXCKYr7uGbkLyA5DELkl2+bLr+IOt8=;
        b=nNzsiaB4VXtgSmx69mvbuDb3KNPqqTn+Z3S/2gmyirhXwWAnjEk1FZ6CVCGl8aDFc1
         1Gf/kDPXJyHU/JJ7zk7mVNjB/SQRVQ23a8r2LC1Db2guXgCp77saDJS5TWMdcmzCUdqs
         n+WDMUIcBErCjFwr+tNVRZaBK+Wmmb9+loMh6GC2i4GGn+QjRo76+ZUbyoa4nAQrok60
         jR08MgvfOBmldQ/+dHe7TfbWiOtyD1fBAD7G4ltt4/HnOipNWMHpVhk87468ZptkJhGX
         50Hx/3XPK6IBBturK1Ad7YH1KPzLwjh/Jv/8fjkPjcRUAhTih9aZucoSyGbGyfE42ZLM
         q3ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=jcdUgvqHH5NYsFXCKYr7uGbkLyA5DELkl2+bLr+IOt8=;
        b=JldUHHk2Pdb/q6mRFAoDzK6Pwm2arpFFKPAJ0Ax7C8Ukv67K4nA/FikaSh+A85LVS0
         6HRjh6KO/eCkt7XGGcVTigX2VpyqcJSRoxhZnNZZJfAnVi/4eHIWJw4An9W3vJ5Eo+OA
         x0Kj4S5gfVk2+dWtooQN5Hoodqy+QwJ152W7v26qJfvXxPhFTzrvRtiIn9H4jG3kZNpU
         2/NL8SCiA4lDfMt1Jcb9SG3Z9f6bwHtBn7I8l8VWdUEOTCPUkbaT7vSSE67rZMMcC4D+
         x0v7jlMWVf9+BeaCWqFec8YdGBkQ4X5X1EhbUQdoSdQBiVasymufxWfWC3IVY7G55n6Q
         gsCw==
X-Gm-Message-State: APjAAAUjY04DB3N7sKXpdNWCWAc7Vc11AVmJgq4RWdbzqxEfi/PPBFj7
	XxrBQsI43vuaGfNGkkTyP930Ji7aurzkGrTEZB6Q/83a
X-Google-Smtp-Source: APXvYqzNW6ygKvp4oDxjGJZ4Zyn4Gk7PFaAmKd/RJDSrmhnKj3JW7ODa6ZRq5nwhnOcHgps3WVt+XQeyYeiL0JXenq4=
X-Received: by 2002:a67:e886:: with SMTP id x6mr4623554vsn.173.1557467548259;
 Thu, 09 May 2019 22:52:28 -0700 (PDT)
MIME-Version: 1.0
References: <5769666.kBCjlYZPBc@even-i700>
In-Reply-To: <5769666.kBCjlYZPBc@even-i700>
From: Rob Tillaart <rob.tillaart@gmail.com>
Date: Fri, 10 May 2019 07:52:17 +0200
Message-ID: <CANoujwH5jeu5JAcLa6X0pZz+eE1xwD5cvzaXG3raj-gbi_Vaug@mail.gmail.com>
Subject: Re: [Tiff] BigTIFF and Strip/TileByteCounts being of LONG type
To: Even Rouault <even.rouault@spatialys.com>
Content-Type: multipart/alternative; boundary="000000000000f697500588822bbf"
X-GND-Status: LEGIT

--000000000000f697500588822bbf
Content-Type: text/plain; charset="UTF-8"

Hi
Afaik i see no negative implications although i miss information about
percentage gained.

That said
Would it make sense to allow SHORT (2 byte) too?
Small tiles and strips could result in multiple identical ones. That could
optimize transmission time by referencing earlier sent tiles that are
identical.
Such a compression scheme should know the logical structure of BIGTIFF.

Just thinking out loud
Rob

On Fri, 10 May 2019, 00:08 Even Rouault, <even.rouault@spatialys.com> wrote:

> Hi,
>
> I've submitted a merge request
> https://gitlab.com/libtiff/libtiff/merge_requests/78
> which will result in BigTIFF files being created with the StripByteCounts
> /
> TileByteCounts tag using the LONG type instead of a LONG8, when the strip/
> tiles are of "reasonable" size. See the detailed comment in the merge
> request
> for when this is done precisely.
>
> In summary, such change is legal according to the BigTIFF specification,
> and
> in practice backward compatible with past libtiff 4.X versions. That said,
> I'm
> interested in hearing if people would be aware of interoperability
> problems
> with other implementations. I'm attaching such a (small) BigTIFF file for
> testing.
>
> Motivation for the change: such an optimization is in particular important
> for
> "cloud" oriented use of TIFF where minimizing the amount of data
> transferred
> for partial reading of a file is desirable (further optimizations to come
> in
> that area).
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com_______________________________________________
> Tiff mailing list
> Tiff@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/tiff
>

--000000000000f697500588822bbf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Hi</div><div dir=3D"auto">Afaik i see n=
o negative implications although i miss information about percentage gained=
.=C2=A0<br><div dir=3D"auto"><br></div><div dir=3D"auto">That said</div><di=
v dir=3D"auto">Would it make sense to allow SHORT (2 byte) too?=C2=A0</div>=
<div dir=3D"auto">Small tiles and strips could result in multiple identical=
 ones. That could optimize transmission time by referencing earlier sent ti=
les that are identical.=C2=A0</div><div dir=3D"auto">Such a compression sch=
eme should know the logical structure of BIGTIFF.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Just thinking out loud</div><div dir=3D"auto">Rob=
</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Fri, 10 May 2019, 00:08 Even Rouault, &lt;<a href=3D"mailto:=
even.rouault@spatialys.com">even.rouault@spatialys.com</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I&#39;ve submitted a merge request<br>
<a href=3D"https://gitlab.com/libtiff/libtiff/merge_requests/78" rel=3D"nor=
eferrer noreferrer" target=3D"_blank">https://gitlab.com/libtiff/libtiff/me=
rge_requests/78</a><br>
which will result in BigTIFF files being created with the StripByteCounts /=
 <br>
TileByteCounts tag using the LONG type instead of a LONG8, when the strip/<=
br>
tiles are of &quot;reasonable&quot; size. See the detailed comment in the m=
erge request <br>
for when this is done precisely.<br>
<br>
In summary, such change is legal according to the BigTIFF specification, an=
d <br>
in practice backward compatible with past libtiff 4.X versions. That said, =
I&#39;m <br>
interested in hearing if people would be aware of interoperability problems=
 <br>
with other implementations. I&#39;m attaching such a (small) BigTIFF file f=
or <br>
testing.<br>
<br>
Motivation for the change: such an optimization is in particular important =
for <br>
&quot;cloud&quot; oriented use of TIFF where minimizing the amount of data =
transferred <br>
for partial reading of a file is desirable (further optimizations to come i=
n <br>
that area).<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href=3D"http://www.spatialys.com" rel=3D"noreferrer noreferrer" target=
=3D"_blank">http://www.spatialys.com</a>___________________________________=
____________<br>
Tiff mailing list<br>
<a href=3D"mailto:Tiff@lists.osgeo.org" target=3D"_blank" rel=3D"noreferrer=
">Tiff@lists.osgeo.org</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/tiff" rel=3D"noreferrer=
 noreferrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/tif=
f</a><br>
</blockquote></div>

--000000000000f697500588822bbf--

