[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