<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 27, 2016 at 11:10 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
> > > When the image is deflate-compressed,  gdalinfo command does two range requests.<br>
> > > When the image is jpeg-compressed, gdalinfo does 13 range requests.<br>> ><br>
> > Could you post the outpout of "tiffdump jpeg.tif" ? There are some hacks<br>
> > in libtiff regarding JPEG compression and in particular JPEG tables that<br>
> > might perhaps cause spurious IFD rewriting.<br>
><br>
> Here's the ouput of "tiffdump jpeg.tif": <a href="http://pastebin.com/raw/pX6XMYVT" rel="noreferrer" target="_blank">http://pastebin.com/raw/<wbr>pX6XMYVT</a><br>
<br>
</div></div>That's what I suspected. The IFD are not placed at the beginning of the file,<br>
but rather rewritten after each "data section".<br>
Which libtiff version is used in your GDAL build: internal libtiff or system<br>
libtiff (if so, which version)? But I wouldn't surprise that the issue exists<br>
with any libtiff version because of what I mentionned with jpeg compression.<br>
That might probably be fixable (likely with some headaches)<br><br></blockquote><div><br></div><div>I built GDAL-2.1.1 with these flags: <a href="https://github.com/pedros007/mapserver-docker/blob/master/gdal-build.sh">https://github.com/pedros007/mapserver-docker/blob/master/gdal-build.sh</a></div><div><br></div><div><div>    --with-rename-internal-libtiff-symbols=yes \</div><div>    --with-rename-internal-libgeotiff-symbols=yes \</div><div>    --with-libtiff=internal \</div><div>    --with-geotiff=internal \</div></div><div><br></div><div><br></div></div>
</div></div>