[gdal-dev] x86/ARM Differences

Even Rouault even.rouault at spatialys.com
Fri Aug 30 13:24:26 PDT 2024


Simon,


> One is the declared block size of a simple RGB PNG image, which we use 
> for some raster import tests. The image is 320x225 and gdalinfo on x86 
> reports that for the block size of the three bands also. However, on 
> ARM it reports the block sizes as 320x1.

Yes, this is expected, as on x86_64, on byte images <= 512x512 pixels, 
there's a SSE2 optimization when decoding the whole image, which causes 
the size of the image to be set as the block size. You may disable this 
optimization by setting the GDAL_PNG_WHOLE_IMAGE_OPTIM=OFF config 
option, and you'll get a block height of 1, but I would recommend 
against it, unless this is for the purpose of having reproducible tests

> The second difference is the point order of the (single, outer) ring 
> of a MULTIPOLYGON when exported and re-imported as GeoJSONL. In either 
> the export or the import (haven't looked that deeply yet) the ring is 
> getting reversed. Note that the ring data is actually very bogus (lots 
> of repeated points and no avoidance of self-intersection). We 
> simplified it to topologically valid data and then there are no 
> differences between platforms. So it's possible that the CW/CCW 
> auto-detection/reversal is getting confused by some floating-point 
> precision differences (which we have also encountered in other 
> places). We are not worried about this one, having simplified the test 
> so that it now passes, but the difference is still slightly concerning.

Yes likely a floating-point precision difference in 
OGRLineString::isClockwise() computations

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240830/f80b3eb3/attachment.htm>


More information about the gdal-dev mailing list