Alpha information lost in some cases about lodepng HOT 4 CLOSED

Hello,

What was the exact image? I could use it as a test case to ensure there is no bug.

The intended behaviour is that if there are less than 257 colors, LodePNG writes the alpha channels in the tRNS chunk (see point 4.2.1.1. here: http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html).

So there are multiple ways that a PNG image file can be semi-translucent: either it uses the RGBA or Grey+Alpha color format, or, it uses a palette, with a tRNS chunk containing the alpha value for each palette index. Of course the latter method has smaller filesize, so is chosen for less than 257 colors.

Normally, most software reads that tRNS chunk, but in theory is allowed to ignore it. What program do you view the PNG image with?

Thanks!

from lodepng.

Hey, you're right! It was Paint Shop Pro 7 (very very old, but it does what I need and I'm used to it). Other software deals with the output just fine.

Thanks and sorry!

from lodepng.

No problem, interesting to know. I'll consider adding a setting (no promises tho :)) for this, after all the PNG spec specifically mentions software is allowed to ignore it...

from lodepng.

Just FYI, I ran into this same problem while using the C function lodepng_encode32_file. Viewing the PNG in Gimp and it looks like there's only two states for the alpha channel. In Gimp for the output PNG, some pixels look to be completely translucent when they go below a certain threshold while others aren't, but it's either all or none.

Using Imagemagick to convert to a BMP and then viewing through Gimp renders just fine so the alpha channel is definitely there and isn't being lost.

I don't know what the answer is but you might want to consider defaulting to 8-bit RGBA instead of trying to be clever and using a colormap.

from lodepng.