Understood. Thank you.
On Fri, Aug 30, 2024 at 2:54 PM Even Rouault
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
>
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 m
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 PNG
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
Dear List,
We are in the process of creating an ARM build of our system, and we have
discovered some differences in GDAL behavior between the two.
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