On jeudi 11 mai 2017 23:29:15 CEST Gregory, Matthew wrote: > Hi all, > > I think this is a bug, but wanted to make sure I wasn't doing something > stupid before I posted it as such. > > At r32878 (git 1eb605a), Even added new logic for dealing with raw 32-bit > AIG blocks. I've got an AIG raster that has a few blocks where valid data > is getting set to the min Int32 value (-2147483648) when doing a > gdal_translate to GeoTiff. > > gdal_translate -of GTiff ai_bug ai_bug.tif > > Note the "old" way of getting these values was providing the correct values > in this case: > > panData[i] = pabyCur[0] * 256 * 256 * 256 > + pabyCur[1] * 256 * 256 > + pabyCur[2] * 256 > + pabyCur[3] + nMin; > > Note that this is only affecting selected blocks within the raster. Other > blocks seem to be just fine. > > Test raster posted here: > > ftp://ftp.fsl.orst.edu/pub/gregorym/gdal/ai_bug.7z (1MB) > > From my testing, <= 2.0 is OK, >= 2.1 is affected. Tested on Windows 10 > 64-bit.
Matt Thanks for the report. I've fixed the issue per https://trac.osgeo.org/gdal/ticket/6886 AIG relies on rollover on addition of big negative values, which is undefined behaviour in C. Interesting... Can the test dataset be integrated in the GDAL test suite ? (probably in http:// download.osgeo.org/gdal/data/aig/ ) Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
