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

[Even Rouault]

> Right,
> Indeed, before sending my previous email I have also tried with:
> *gdaladdo -r average --config COMPRESS_OVERVIEW DEFLATE --config
> PHOTOMETRIC_OVERVIEW RGB*
> to understand if it was related to JPEG only but, even with these options,
> the output overviews were jpeg compressed (I assume there is some kind of
> coherency check in gdaladdo).

With internal overviews, the _OVERVIEW configuration options are ignored. Their value is 
deduced from the settings of the main IFD. I don't think there's a strong technical reason for 
that. Mostly a side effect of the fact that there are slightly different code paths to handle 
creation of internal and external overviews, and the reading of _OVERVIEW config options is 
done only in the external overview code path.

> 
> > 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).
> 
> Do you think this will be available in other series or does it introduce
> new API/major changes which makes it available on 2.2.x only?

No API change, but this is in the improvement category rather than bugfixing, and my first 
changeset resulted in some corrupted images in some situations, which was unnoticed for a 
few weeks, so that's a sign that it is a somewhat risky change (the GeoTIFF driver is a complex 
beast), not worth the trouble of breaking stable branches.

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/16d5a69d/attachment-0001.html>