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