<div dir="ltr">Thank you, Even.<div><br></div><div>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... :)</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2024 at 1:24 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <p>Simon,<br>
    </p>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>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 <font face="monospace">gdalinfo</font> on x86
            reports that for the block size of the three bands also.
            However, on ARM it reports the block sizes as 320x1.</div>
        </div>
      </div>
    </blockquote>
    <p>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<br>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <p>Yes likely a floating-point precision difference in
      OGRLineString::isClockwise() computations</p>
    <p>Even<br>
    </p>
    <span style="white-space:pre-wrap">
</span>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</blockquote></div>