Re: PNG image files with alpha channel

[Miles Bader <miles@gnu.org>]

Jason Rumney <jasonr@gnu.org> writes:
>>   png_set_IHDR (libpng_struct, libpng_info, width, height,
>>                 8, PNG_COLOR_TYPE_RGB_ALPHA, PNG_INTERLACE_NONE,
>> 		PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT);
>>   png_set_gAMA (libpng_struct, libpng_info, gamma_correction);
>
> Is there any program that can dump a PNG header in some readable format,
> so we can compare yours with the image that Gimp saves?
>
> Or maybe someone needs to step through the PNG display code in Emacs,
> and see where it (or libpng) makes the wrong decision.

Actually I realized that while my software wrote the original image,
those "*-256.png", etc, images are decimated versions that I created
using imagemagick, with "convert -resize ...".

Upon looking closer, I see on very odd attribute:  while the original
image I wrote was RGBA, 8-bits per channel, the decimated versions
written by imagemagick are RGBA, 16-bits per channel...  The Emacs
PNG-reading code asks libpng to convert 16-bit-per-channel images to
8-bits per channel, but as such images are fairly rare, it may be that
libpng doesn't do it correctly.

If I open the original RGBA 8-bits per channel image with Emacs, indeed,
it handles the alpha-channel correctly.

I did step through the code, BTW, and as far as I can tell, Emacs is
doing the correct things.

So the problem may in fact be something with the libpng 16-to-8-bit
conversion code...

[I have no idea why imagemagick creates 16-bit-per-channel output images
from 8-bit-per-channel input images; offhand it seems like a bad idea as
16-bit support is probably less widespread...]

-Miles

-- 
Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling.