[gdal-dev] x86/ARM Differences

[Simon Eves]

Understood. Thank you.

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

> 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/582949af/attachment.htm>