Return-Path: <kemp@objectivepathology.com>
Delivered-To: even.rouault@spatialys.com
Received: from spool.mail.gandi.net (spool4.mail.gandi.net [217.70.178.213])
	by nmboxes134.sd4.0x35.net (Postfix) with ESMTP id 0DE8160282
	for <even.rouault@spatialys.com>; Thu,  9 May 2019 23:39:47 +0000 (UTC)
Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54])
	by spool.mail.gandi.net (Postfix) with ESMTPS id E036C780452
	for <even.rouault@spatialys.com>; Thu,  9 May 2019 23:39:46 +0000 (UTC)
Received: by mail-ed1-f54.google.com with SMTP id w11so3527195edl.5
        for <even.rouault@spatialys.com>; Thu, 09 May 2019 16:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=objectivepathology.com; s=google;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=BJCz1/baWN9XqDwyJOtlMLn67/CddQ5I+DCdetQN/9s=;
        b=RvAurC8tDDESynUN7x+ltxNzj6saZGR9PLdpTxwD/VfFJTsF3ciTyKMM/PeanE5ZBa
         O0+WQStIF22odu9gcnIR1QxIPS93hsu8qT6JwUIAj2TKTylH6BAChymTic0UzW0uXSde
         Lbdit6HqAV52VgAWVP3CUYrV42ovUQyD6Z5STyShuOOoWJkuOsaqh7rxtMAHBgxWXOEK
         xnAgQkcZJptDz7WakAj/89z0ykxRHAa6mVoKcvTU6iZ6mxuatfostHOpOvyRU0Oi5PW8
         nVRUMsJzbMP+4iwLO+bIBfU93c3NHeyvmbZrME2fj56g+HkjGZWs8PIuWyNnQa5K7s7x
         8axA==
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=BJCz1/baWN9XqDwyJOtlMLn67/CddQ5I+DCdetQN/9s=;
        b=QYL49LQBWJF2+tzpPFGjbwtIpjHY2u3BbjsWS3JLopIwij51Mi8S2xIkHNzkw40RrP
         tC5bOMANi56QTujxFKf7CmypdV74uJjV0K7J89Z4kAx7gQXXvHU3jC2FdxsNgdmkTOSl
         3zy47JKJm/m4XcZzpglafuAHMI37G3sJbtQtBns6TbifGH5FoM4DXlR7gbIsRoAFoVlN
         QtoVUR0aagTXffHvz+wPi+kwtnupBbdah9yRTVx4GrJrps71W96HLw/xMxgmNGOXORER
         SKJhZkyqNdqCv9u2k77dAXk6gGf0MPl1Fqrd70V0op4HtS2b360hAEhzUlbCaJtdENia
         7d6g==
X-Gm-Message-State: APjAAAXtU77zNvpDjs1T0xhYrLB65JGGC8PIaKobiV3MjsAB7WnVcv+o
	Nz1cqALFlbbIhAKr84uD0zld1YQBXyRb6ZXS41/gkYrO
X-Google-Smtp-Source: APXvYqzXbak4/X6F0UBFtIN1cgE3X4ho1hB/N/pB4y1+w3PH2Ywc6XXzdHgjfrJcDySGe2zAGlOZ7iGG+UhJYKj+13E=
X-Received: by 2002:a17:906:76c1:: with SMTP id q1mr5710040ejn.25.1557445186128;
 Thu, 09 May 2019 16:39:46 -0700 (PDT)
MIME-Version: 1.0
References: <5769666.kBCjlYZPBc@even-i700>
In-Reply-To: <5769666.kBCjlYZPBc@even-i700>
From: Kemp Watson <kemp@objectivepathology.com>
Date: Thu, 9 May 2019 19:39:26 -0400
Message-ID: <CACp925TOzs-1EtbeTH+v7x=TXQvr7UFbBCO3s_6pS+Sm-X+iig@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="00000000000013aa6a05887cf7d2"
X-GND-Status: LEGIT

--00000000000013aa6a05887cf7d2
Content-Type: text/plain; charset="UTF-8"

There should not be any troubles with this, in fact I'm surprised to hear
that libtiff forces a LONG8 into those tags; the BigTIFF specification,
such as it is, does indeed specifically allow for LONG and other sizes, so
compliant applications should have no issues.

Kemp Watson

On Thu, May 9, 2019 at 6:08 PM 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
>

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

<div dir=3D"ltr"><div>There should not be any troubles with this, in fact I=
&#39;m surprised to hear that libtiff forces a LONG8 into those tags; the B=
igTIFF specification, such as it is, does indeed specifically allow for LON=
G and other sizes, so compliant applications should have no issues.<br></di=
v><div><br></div><div>Kemp Watson<br></div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 9, 2019 at 6:08 PM E=
ven Rouault &lt;<a href=3D"mailto:even.rouault@spatialys.com">even.rouault@=
spatialys.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-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" target=3D"_blank">https://gitlab.com/libtiff/libtiff/merge_request=
s/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" target=3D"_blank">h=
ttp://www.spatialys.com</a>_______________________________________________<=
br>
Tiff mailing list<br>
<a href=3D"mailto:Tiff@lists.osgeo.org" target=3D"_blank">Tiff@lists.osgeo.=
org</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/tiff" rel=3D"noreferrer=
" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/tiff</a><br>
</blockquote></div>

--00000000000013aa6a05887cf7d2--

