[gdal-dev] Possible RGB 16-bit PNG read error?

[Ray at Daylon]

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
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>