This was in my Leveller heightfield modeler.
My bad; there was a small mistake in my call to RasterBand::RasterIO; I
had forgotten to multiply a band index (channel no.) by the pixel byte
size for the pData argument when packing the bands into an interleaved
RGB buffer.
Thanks,
Ray
On 12/24/2025 1:46 AM, Even Rouault via gdal-dev wrote:
Ray,
what tool do you use to assess if the colors are wrong ? Doing
"gdal_translate 48bpp.png 48bpp.tif", and then opening in GIMP
48bpp.png, 48bpp.tif and 24bpp.tif, the colors are all identical. I see
that the 3 files have an ICC profile. Perhaps your visualization tool
doesn't honour it for the 16-bit version ?
Even
Le 24/12/2025 à 04:58, Ray at Daylon via gdal-dev a écrit :
I came across a 16-bit RGB PNG file that appears to read incorrectly
in GDAL 3.11.3. I didn't see any changes in the readme's for later
GDAL versions in regards to this.
The file content is okay but the colors are wrong. Looking at the band
pixel data returned by GDAL, it might be similar to the endian issue
that happened with 16-bit grayscale PNGs earlier, but applying endian
corrections and RGB/BGR ordering on my end didn't help. Near as I can
tell it looks like the channels are shifted in some other way.
An example file is available at
daylongraphics.com/download/test/gdal_png_issue/48bpp.png (554K)
For reference, a correctly read 8-bit version is available at
daylongraphics.com/download/test/gdal_png_issue/24bpp.png
Ray Gardener
Daylon Graphics Ltd.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
