[gdal-dev] Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)

[Even Rouault]

> Wondering if when generating overviews we still have a problem similar to
> the one you have fixed in 2.0 or some data-updating issue.
> 
> These are my hypothesis on what is going on.
> A simple translate with no overviews makes the file ending at 0x7555 with
> offset of next IFD saying 0x0000.
> When you add overviews, it writes a new IFD at 0x7556 with TAG entries,
> then it encodes something and then it writes a new IFD.
> At the end, it goes back updating the offset of the 1st overview IFD
> (0xBBF0) making the one at 0x7556 being not referred anymore.
> Does it make sense?
> 

With JPEG compression right ? I do reproduce something similar to your findings in 2.1 
indeed. This no longer happens in trunk due to related improvements (https://
trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF), I made in the last couple of weeks (using 
the same trick of creating a in-memory TIFF file to get the JPEG tables and set them direcly 
on the overview IFD at creation time).

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161216/de8c4eb8/attachment.html>