<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 27, 2016 at 10:42 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><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">Le jeudi 27 octobre 2016 18:33:01, Peter Schmitt a écrit :<br>
> On Wed, Oct 26, 2016 at 1:39 PM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
><br>
> wrote:<br>
> > I've written recently a best practice for generating cloud optimized<br>
> > geotiffs:<br>
> > <a href="https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/<wbr>wiki/CloudOptimizedGeoTIFF</a><br>
> > (it mentions deflate compression, but jpeg-compressed can work of course)<br>
><br>
> Thanks again, Even! I did some experimentation with a 19584x19584 file with<br>
><br>
> 6 overview levels.  When the image is deflate-compressed:<br>
> > gdal_translate in.tif deflate.tif -co TILED=YES -co COMPRESS=DEFLATE -co<br>
><br>
> COPY_SRC_OVERVIEWS=YES<br>
><br>
> then this gdalinfo command does two range requests:<br>
> > env AWS_ACCESS_KEY_ID=foo<br>
><br>
> AWS_SECRET_ACCESS_KEY=bar CPL_VSIL_CURL_ALLOWED_<wbr>EXTENSIONS=.tif<br>
> CPL_CURL_VERBOSE=YES<br>
> VSI_CACHE=TRUE gdalinfo /vsis3/pschmitt-test/deflate.<wbr>tif 2>&1 | grep<br>
> "Content-Range:"<br>
><br>
> >  < Content-Range: bytes 0-49151/1038305419<br>
> >  < Content-Range: bytes 49152-147455/1038305419<br>
><br>
> When I jpeg-compress<br>
><br>
> > gdal_translate deflate.tif jpeg.tif -co TILED=YES -co COMPRESS=JPEG -co<br>
><br>
> PHOTOMETRIC=YCBCR -co COPY_SRC_OVERVIEWS=YES<br>
><br>
> then gdalinfo on the jpeg-compressed image does 13 range requests:<br>
> > env AWS_ACCESS_KEY_ID=foo<br>
><br>
> AWS_SECRET_ACCESS_KEY=bar CPL_VSIL_CURL_ALLOWED_<wbr>EXTENSIONS=.tif<br>
> CPL_CURL_VERBOSE=YES<br>
> VSI_CACHE=TRUE gdalinfo /vsis3/pschmitt-test/jpeg.tif 2>&1 | grep<br>
> "Content-Range:"<br>
><br>
> > < Content-Range: bytes 0-49151/83731710<br>
> > < Content-Range: bytes 83656704-83705855/83731710<br>
> > < Content-Range: bytes 83722240-83731709/83731710<br>
> > < Content-Range: bytes 83705856-83722239/83731710<br>
> > < Content-Range: bytes 25231360-25280511/83731710<br>
> > < Content-Range: bytes 25165824-25214975/83731710<br>
> > < Content-Range: bytes 25214976-25231359/83731710<br>
> > < Content-Range: bytes 7602176-7651327/83731710<br>
> > < Content-Range: bytes 2228224-2310143/83731710<br>
> > < Content-Range: bytes 655360-704511/83731710<br>
> > < Content-Range: bytes 229376-278527/83731710<br>
> > < Content-Range: bytes 131072-180223/83731710<br>
> > < Content-Range: bytes 98304-131071/83731710<br>
<br>
</div></div>Could you post the outpout of "tiffdump jpeg.tif" ? There are some hacks in<br>
libtiff regarding JPEG compression and in particular JPEG tables that might<br>
perhaps cause spurious IFD rewriting.<br><br></blockquote><div><br></div><div>Here's the ouput of "tiffdump jpeg.tif": <a href="http://pastebin.com/raw/pX6XMYVT">http://pastebin.com/raw/pX6XMYVT</a> </div></div>
</div></div>