[ELGIS] Fwd: Re: [gdal-dev] Issue GDAL with JPEG-compressed TIFFS
Peter Hopfgartner
peter.hopfgartner at r3-gis.com
Fri Feb 3 09:05:15 EST 2012
I'm forwarding this message from the gdal mailing list.
IIRC, we already agreed to upgrade libtiff to libtiff4, see
http://lists.osgeo.org/pipermail/el/2011-December/000839.html.
I hope I will find some spare time in the next days to dedicate to this.
Thanks you, Even
Peter
-------- Original Message --------
Subject: Re: [gdal-dev] Issue GDAL with JPEG-compressed TIFFS
Date: Fri, 03 Feb 2012 14:52:19 +0100
From: Even Rouault <even.rouault at mines-paris.org>
To: Peter Hopfgartner <peter.hopfgartner at r3-gis.com>
CC: Even Rouault <even.rouault at mines-paris.org>,
gdal-dev at lists.osgeo.org, Enterprise Linux OSGeo <el at lists.osgeo.org>
Selon Peter Hopfgartner<peter.hopfgartner at r3-gis.com>:
I'm not sure of your exact plans, but if you want to switch to internal libtiff
4 with GDAL 1.8.1, you might get into problems with applications that link both
with GDAL and external libtiff 3.9, because of symbol conflicts. If you switch
your external libtiff to libtiff 4, no problem of course.
If you still want to both keep external libtiff to libtiff 3.9 and use internal
libtiff 4 within GDAL, I'd strongly recommand upgrading to GDAL 1.9.0 and using
the new --with-rename-internal-libtiff-symbols and
--with-rename-internal-libgeotiff-symbols configure flags, of course combined
with --with-libtiff=internal and --with-geotiff=internal. This will avoid
symbols conflicts. FYI, the UbuntuGIS team is also planning to do so soon.
> Hi Evan
>
> Indeed, the external libtiff is used and is version
> libtiff-3.9.4-1.el6_0.3.x86_64.
> In the mean time I did a quick compile of gdal-1.9.0 with internal
> libtiff and the square disappeared.
> Probably it would be a wise decision to switch to libtiff4 quickly, as
> far as ELGIS is concerned.
>
> Thanks,
>
> Peter
>
> On 02/03/2012 01:41 PM, Even Rouault wrote:
> > Peter,
> >
> > Does ELGIS GDAL uses internal libtiff (4.0beta) or external libtiff (3.8 or
> 3.9)
> > ? I guess it is external libtiff, and then it could explain the issues you
> have
> > with overviews and JPEG compression. There have been fixes in libtiff 4 to
> > better support that situation (multiple IFDs with compression).
> Altertantively,
> > you could probably workaround that by generating external overviews (add
> -ro to
> > the gdaladdo command line), but no guarantees. By the way, the --config
> > COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config
> > JPEG_QUALITY_OVERVIEW 90 options only apply to external overviews, not
> internal
> > ones.
> >
> >> I'm doing quite some experiments with GDAL and image compression these
> days
> >>
> >> I do have an issue with geotiff 1.3/gdal 1.8.1 on CentOS 6 with packages
> >> from ELGIS. The story goes like this:
> >>
> >> I create tiffs with
> >>
> >> gdal_translate -of GTiff -co COMPRESS=JPEG -co JPEG_QUALITY=90
> >> -co "TILED=YES" -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512"<infile>
> >> <outfile>
> >>
> >> and then add overviews with (I do have to add the overlays in distinct
> >> steps, otherwise gdaladdo aborts with an error message).
> >>
> >> gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW
> >> PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average<outfile> 3
> >> gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW
> >> PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average<outfile> 9
> >> gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW
> >> PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average<outfile> 27
> >> gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW
> >> PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average<outfile> 81
> >>
> >> (Trying with power-of-2-steps gives the same result. If I drop all
> >> options from gdaladdo: same result).
> >>
> >> I'll create a WMS service with MapServer 5.6.7 and do get a big red
> >> square in the image. The square is "fixed" to the geografical position,
> >> e.g. if I move the extend the square moves too. The square is situated
> >> in the corner of the tiff file.
> >> It appears only at some scales. If I change it very slightly, the square
> >> remqins, if I change for more then approx 1%, it disappears.
> >>
> >> I've put the two images at
> >>
> >>
> http://www.r3-gis.com/gdal_issues/tiff_with_jpegcompression_and_overviews.jpeg
> >> and
> >>
> http://www.r3-gis.com/gdal_issues/tiff_with_nocompression_and_overviews.jpeg
> >> .
> >>
> >> The problem disappears if I do not run gdaladdo on the images or when I
> >> do not use Jpeg compression:
> >>
> >> gdal_translate -of GTiff -co "TILED=YES" -co "BLOCKXSIZE=512" -co
> >> "BLOCKYSIZE=512"<origfile> <targetfile>
> >>
> >> There are some hits for
> >>
> >
>
http://www.google.com/search?client=ubuntu&channel=fs&q=mapserver+artefacts+in+raster+gdal&ie=utf-8&oe=utf-8,
> >> but mostly related to older versions of GDAL and without resolution.
> >>
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> --
> >>
> >> Peter Hopfgartner
> >> R3 GIS Srl - GmbH
> >> www.r3-gis.com
> >>
> >>
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>
> >
>
>
> --
> Peter Hopfgartner
> R3 GIS Srl - GmbH
> web : www.r3-gis.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/el/attachments/20120203/cf2cd774/attachment-0001.html
More information about the el
mailing list