[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