[gdal-dev] Question on 0th IFD offset when producing a JPEG-Compressed GeoTIFF (GDAL 1.11 vs 2.x)
even.rouault at spatialys.com
Fri Dec 16 05:48:25 PST 2016
> 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.
Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev