PNG8 broken after -transparent

[Drarakel]

is there a further IM command to introduce these chunks into the image?

I think that directly writing the file as palette PNG [...] is not possible with the current IM versions

You could test some older ImageMagick versions though.
In IM v6.5.8-5, for example, simple commands like these are successful and write a palette PNG with tRNS chunk:
convert img.png -transparent "#FB00FF" -type PaletteMatte img2.png
convert img.png -transparent "#FB00FF" -colors 256 img2.png
(I would prefer the first command as the color reduction parameter can be a bit more risky.)

Result:

[UICodes]

I think that directly writing the file as palette PNG (even when it has only binary transparency) is not possible with the current IM versions - there are some problems with it.

The image works great, thank you. Do you recommend that I file this issue as a bug?

[Drarakel]

Well, you can add your case if you want. That's up to you.
But I think it's already known now that there are issues with palette PNGs.
Your case can be compared to my test case #6 in this report. With one difference: I used images with less than 257 pixels - with this, ImageMagick tries to write a palette with smaller bit depth and one seems to get errors like 'tRNS chunk has out-of-range samples for bit_depth' more often and in the process the alpha layer is lost completely.
When one tries to write a image like yours with the option '-type PaletteMatte', there's no error message and IM reverts to full RGBA at least - but then the alpha layer is fully opaque.

By the way: Is anyone else getting a crash with this command:
convert img.png -transparent "#FB00FF" -define png:color-type=2 test.png
I mean, color-type 2 (RGB) is not a wise choice here, but I didn't expect a crash with this..

[snibgo]

By the way: Is anyone else getting a crash with this command:
convert img.png -transparent "#FB00FF" -define png:color-type=2 test.png

On Windows 7, IM 6.6.2-4: yes.

The final lines of "-debug all" are:

Writing PNG header chunks
2010-06-23T23:38:15+01:00 0:05.258 0.421u 6.6.2 Coder convert[4660]: png.c/LogPN
GChunk/1057/Coder
Writing vpAg chunk, length: 9
2010-06-23T23:38:15+01:00 0:05.258 0.421u 6.6.2 Coder convert[4660]: png.c/Write
OnePNGImage/7649/Coder
Writing PNG image data
2010-06-23T23:38:15+01:00 0:05.273 0.437u 6.6.2 Coder convert[4660]: png.c/Write
OnePNGImage/7651/Coder
Allocating 1218 bytes of memory for pixels
2010-06-23T23:38:15+01:00 0:05.305 0.437u 6.6.2 Coder convert[4660]: png.c/Write
OnePNGImage/7826/Coder
Writing row of pixels (3)

[fmw42]

Mac OSX Tiger IM 6.6.2-7 Q16

convert logo.png -transparent "#FB00FF" -define png:color-type=2 test.png
convert(407) malloc: *** error for object 0x2013a00: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
convert(407) malloc: *** set a breakpoint in szone_error to debug

then it hangs

Also


convert logo.png -transparent white -define png:color-type=2 test.png
Segmentation fault

but


convert logo: -transparent white -define png:color-type=2 test_logot.png

runs fine but the image does look odd.

[Drarakel]

Thanks, guys!

I'm also getting a lot of random results now if I vary my 'RGBA saved with color-type 2' commands..
With IM v6.5.8-5, the "convert img.png -transparent "#FB00FF" -define png:color-type=2 test.png" command also tries to produce a distorted version of the former sun/clouds image - but at least it finishes without crash/error:


Don't know if it's worth a separate report. I think I'll add a note to my PNG bugs thread.