Palette map bug

[Zmey]

I'm trying to map croco.png to palette.png's palette.

croco.png:


palette.png:


When saving to GIF, everything works as expected:
convert croco.png -map palette.png croco_mapped.gif
croco_mapped.gif:


When using PNG-8, resulting image is corrupted:
convert croco.png -map palette.png png8:croco_mapped_png8.png
croco_mapped_png8.png:

Is this a bug?

Saving to plain PNG works, but transparent color which was white in palette.png becomes black in resulting image (is this also a bug?)...
convert croco.png -map palette.png croco_mapped.png
croco_mapped.png:

^^^ you won't see difference here because Internet Explorer renders it as transparent, but you can see the difference when using ACDSee or other picture viewer if you open this picture.

Please help to solve the png8 issue.
Archive with pictures for testing:
http://bemaniclub.com/Data/af/im_palett ... te_bug.zip

Version: ImageMagick 6.4.1 05/16/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

[fmw42]

I don't know if this is a bug or not, but I can verify that your white becomes black under the transparency when doing

Saving to plain PNG works, but transparent color which was white in palette.png becomes black in resulting image (is this also a bug?)...
convert croco.png -map palette.png croco_mapped.png
croco_mapped.png:

but you can at least correct it after the fact by doing:

convert croco_mapped.png +matte -fill white -opaque black -transparent white croco_mapped_t.png

[anthony]

It goes black for a normal PNG because normal PNG does not use a palette. As such any color value associated with transparency is not defined, and the PNG uses what ever is set within the image from the mapping process (which defaults to BLACK!)

GIF and PNG8 can specify what the color 'transparent' should be using the -transparent-color setting, wehn it is writing to these formats, This should NOT effect the look of the resulting image except in very old image viewers that do not understand transparency.

You are allowed to re-use a existing opaque color for the transparent color as they are assigned two separate palette indexes.

For more details see http://imagemagick.org/Usage/formats/#gif_trans

[Zmey]

When using PNG-8, resulting image is corrupted:
convert croco.png -map palette.png png8:croco_mapped_png8.png
croco_mapped_png8.png:

Saving to png8 is still broken in ImageMagick 6.4.2 07/13/08.

[fmw42]

Don't know if that is a bug or not. Perhaps you want to use PNG32 instead of PNG8.

See comment about how IM handles PNG8 at http://www.imagemagick.org/Usage/formats/#png

PNG8: The PNG equivalent to GIF, including boolean transparency and a 256 color table.
PNG24: 8 bit RGB channels without an alpha channel (a bit like JPEG)
PNG32: Force a full RGBA image format with semi-transparency channels.
IM will use the most economical style given above, if a plain PNG is given.

"PNG8 was defined by PhotoShop, not the PNG group. And while it can handle multiple semi-transparent colors, as well as a fullly transparent color, IM assumes that it doesn't. This provides a way to force files to still be readable by Internet Explorer v6. Also "Photoshop CS" also still handles it."

Hope the IM folks reply to set this straight.

I tried your example with IM 6.4.2-3 and got the same result as you. But the comment above may indicate that IM will not handle the transparency. I am not sure how to interpret that.

P.S. I tried
convert croco.png -map palette.png -transparent-color white png8:croco_mapped_trans_png8.png

per Anthony's comment and reference, but it did not work either.

[anthony]

I wish you did not edit your original question. It makes all the later responses confusing!

But at least your problem is now clear.

And that is some type of bug in the PNG8 output. It looks to me like the coder is not reading the image data correctly. This should be passed to the PNG coder development person.

[Zmey]

I wish you did not edit your original question. It makes all the later responses confusing! But at least your problem is now clear.

And that is some type of bug in the PNG8 output. It looks to me like the coder is not reading the image data correctly. This should be passed to the PNG coder development person.

I didn't edit it, but, perhaps, asking two questions in single post was not a good idea because the other one went unnoticed. Thanks for the response. How can I contact him?