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

Even Rouault even.rouault at spatialys.com
Tue Jan 31 09:34:24 PST 2017


On mardi 31 janvier 2017 18:29:48 CET Daniele Romagnoli wrote:
> Hi Even,
> I'm back to this topic and I have a couple of questions.
> - Is it there any libtiff specific version involvement on that?
> - Are all these improvements self contained in GDAL code itself or do them
> require some specific libtiff version?

Should probably work with any libtiff 4.0.X version

> 
> Cheers,
> Daniele
> 
> On Fri, Dec 16, 2016 at 2:56 PM, Daniele Romagnoli <
> 
> daniele.romagnoli at geo-solutions.it> wrote:
> > On Fri, Dec 16, 2016 at 2:48 PM, Even Rouault <even.rouault at spatialys.com>
> > 
> > wrote:
> >> > 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.
> > 
> > It makes sense, indeed.
> > 
> >> 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.
> > 
> > Understood. thanks for the feedback.
> > Cheers,
> > Daniele
> > 
> >> Even
> >> 
> >> 
> >> 
> >> --
> >> 
> >> Spatialys - Geospatial professional services
> >> 
> >> http://www.spatialys.com
> > 
> > --
> > ==
> > GeoServer Professional Services from the experts! Visit
> > http://goo.gl/it488V for more information.
> > ==
> > 
> > Ing. Daniele Romagnoli
> > Senior Software Engineer
> > 
> > GeoSolutions S.A.S.
> > Via di Montramito 3/A
> > 55054  Massarosa (LU)
> > Italy
> > phone: +39 0584 962313 <+39%200584%20962313>
> > fax:      +39 0584 1660272 <+39%200584%20166%200272>
> > 
> > http://www.geo-solutions.it
> > http://twitter.com/geosolutions_it
> > 
> > -------------------------------------------------------
> > 
> > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
> > 
> > Le informazioni contenute in questo messaggio di posta elettronica e/o
> > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170131/5bc752e3/attachment-0001.html>


More information about the gdal-dev mailing list