Hi,
This should be fixed per https://github.com/OSGeo/gdal/pull/11553 . This
is indeed a 25-year old issue. An indication of how 16-bit interlaced
PNGs are popular :-)
Even
Le 28/12/2024 à 10:42, Ray at Daylon via gdal-dev a écrit :
In GDAL 1.8.0 on little-endian platforms like x64, the PNG driver will
not byteswap pixels from network order (big endian) to little-endian
if the PNG is interlaced (or at least if it's 16-bit grayscale
interlaced).
Does anyone know if this was corrected in a future version?
In pngdataset.cpp, PNGDataset::LoadScanline() has this code:
if( bInterlaced )
return LoadInterlacedChunk( nLine );
The early return causes this downstream byteswapping section:
if( nBitDepth == 16 )
GDALSwapWords( row, 2, GetRasterXSize() * GetRasterCount(), 2 );
to be skipped.
LoadInterlacedChunk() as far as I can tell even in 3.9.2. doesn't
do any byteswapping.
Ray Gardener
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is
just about bytes.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
