That did the trick; thanks.
Ray
On 12/28/2024 9:15 AM, Even Rouault wrote:
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
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,
Just noticed a small typo in the test data repo, ... autotest/gdrivers/data:
"STDS_1107834_truncated" should be "SDTS_1107834_truncated".
For parity with other folders, it might also be good to just name it "sdts".
Ray
___
gdal-dev mailing list
gda
This may already be known, but the use of std::string in CPLString
can also cause problems e.g. building a program with a version of
a C++ stdlib that differs from the one that a prebuilt GDAL DLL
used. Visual Studio e.g. has afaik a 48-byte std::string in MSVC 2010
vs. 40 bytes in MSVC 2022. It's
Evan,
On 1/30/2024 3:26 AM, Even Rouault wrote:
Ray,
Le 30/01/2024 à 05:43, Ray at Daylon via gdal-dev a écrit :
I was tracing through the TIGER/Line OGR driver and noticed that
it calls OGRTigerDataSource::Open with the bTestOpen parameter
set to TRUE, causing that function to skip calling
I was tracing through the TIGER/Line OGR driver and noticed that
it calls OGRTigerDataSource::Open with the bTestOpen parameter
set to TRUE, causing that function to skip calling CPLError
and only return FALSE if an error happens.
This causes an interesting situation: an app can have the TIGER dr
Was reviewing the TGA (Targa) raster format driver and it seems it's
read-only.
Is write support planned?
Ray
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
