<div dir="ltr">Understood. Thank you.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2024 at 2:54 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>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.<br>
    </p>
    <div>Le 30/08/2024 à 23:43, Simon Eves a
      écrit :<br>
    </div>
    <blockquote type="cite">
      
      <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" target="_blank">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">
          <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>
    </blockquote>
    <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>