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.roua...@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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
