Understood. Thank you. On Fri, Aug 30, 2024 at 2:54 PM Even Rouault <even.roua...@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.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
