[gdal-dev] x86/ARM Differences

[Simon Eves]

Thank you, Even.

Does that whole-image optimization only apply to PNG? I mean, obviously
that particular build option is PNG-specific, but are there other formats
which might exhibit similar differences in presented block size? If it's
just PNG, I'm not worried, as there aren't many geospatial PNGs... :)



On Fri, Aug 30, 2024 at 1:24 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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/41da0462/attachment.htm>