[gdal-dev] gdaladdo bus errors for large, LZW-compressed GTiff
Even Rouault
even.rouault at mines-paris.org
Fri Oct 5 13:47:27 PDT 2012
Le vendredi 05 octobre 2012 22:21:27, David Shean a écrit :
> While the topic of gdaladdo resampling methods is active...
>
> I get bus errors when I use gdaladdo's gauss resampling method for large,
> float32, LZW-compressed GTiff. This is repeatable.
Repeatable on various large float32 LZW-compressed GTiff, or that particular one
?
> Using a different
> gdaladdo resampling method (e.g., average) on the same LZW-compressed
> GTiff works. When I decompress first, gdaladdo with gauss works.
> For smaller, LZW-compressed GTiff input, gdaladdo with gauss works.
>
> I'm using gdal 1.9.1 with internal libtiff, libgeotiff, libz on OS X 10.7.
>
> Hopefully this will involve a simple fix. Thanks.
This is something very likely related to update-in-place TIFF support, so
generally not in the "simple fix" category. You might want to re-check with
GDAL trunk whose internal libtiff has received per
http://trac.osgeo.org/gdal/ticket/4771 a fix in that area (no promise that it
fixes your particular issue).
Otherwise, if you can provide a link to the dataset, I can try to see if I
reproduce.
That kind of bug really depends on how the imagery compress. I have created a
fake dataset with similar characteristics to yours with :
$ python
from osgeo import gdal
ds = gdal.GetDriverByName('GTiff').Create('buglzw.tif', 17719, 14955, \
1, gdal.GDT_Float32, options = ['TILED=YES', 'COMPRESS=LZW'])
ds.GetRasterBand(1).SetNoDataValue(0)
ds = None
And :
$ gdaladdo -r gauss buglzw.tif 2 4 8 16 32
0...10...20...30...40...50...60...70...80...90...100 - done.
More information about the gdal-dev
mailing list