[gdal-dev] x86/ARM Differences

[Even Rouault]

I can't think of other formats with similar behavior right now, but you 
shouldn't trust my memory. That said, reported block sizes might very 
well change with versions. Like in JPEG2000 drivers where heuristics to 
determine which block size to expose may be tuned, although this hasn't 
changed much recently.

Le 30/08/2024 à 23:43, Simon Eves a écrit :
> 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.
>
-- 
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/fb02e9b3/attachment-0001.htm>