Legacy ImageMagick Discussions Archive

Hi,
I'm having troubles using ImageMagick for editing Image files with an indexed palette.

The problem is the reduction and reordering of the indexed palette ImageMagick automaticaly performs.
I havent found an option to disable this feature - I would need EXACTLY the same palette after a "convert" operation that was assingned to the input image.
I would like to request this feature if it isn't there allready, because this totaly prevents me from using this otherwise very useful tool for mass image manipulation!

See this image illustrating my point. GIMP shows in the right top corner the indexed palette the image had and the reduced paltte it has after "convert". Ignore the alpha channel missing, i found an option for fixing that allready.

http://imgur.com/a/Iilrh

Thanks.

What image format are you saving to? What was the original image format? Can you post a link to your original image and provide the command line used in Imagemagick? What is your IM version and platform? Please always provide that with questions since syntax may vary.

Version: ImageMagick 7.0.4-5 Q16 x64 2017-01-21 on Windows10
.png -> .png
magick convert in.png -gravity center -background none -extent 40x40 out.png
wich resizes all "in.png"s into a uniform size of 40 by 40 pixels with the original content centered in the middle. Background none is used to make the background tansparent. The problem is convert.
convert in.png out.png would lead to the same problem. A reduced palette. I don't want that, I want the original indexed palette.
Link to the image http://imgur.com/a/NX7TX

I researched a lot in this forum and found other people having the same problem. i.e. Magick messing with the indexed palette. That's why i request this feature to be added. In theory, this tool would be perfect for my case, but...

You use -extent to crop the center of the image (or -crop), you are possibly using fewer colors in the image. So IM sees that and changes the palette accordingly.

Is your input png 8-bit color (palette). I assume so. So when writing your output make it PNG8:out.png

Also using magick convert is using the legacy IM 6 convert. You should just use magick.

You could set up a colortable image of just the colors you want and use -remap to force the image to only have those colors. But I am not sure that will help. But it might be worth a try. See http://www.imagemagick.org/Usage/quantize/#remap (use -dither none).

Unfortunately, IM currently has no good way to modify/reorganize colortables as far as I know.

Have you tried "-define png:preserve-colormap=true"? See http://www.imagemagick.org/script/comma ... php#define

Good find, snibgo. I did not know/recall that.

@fmw42: i think remap had the problem that it reorders the colors in the palette following some algorithm, so the colors dont have the same idexes as before. That makes the changed palette useless as well.

All of these commands have the exact same result, as if define would do nothing:
magick in.png out.png
magick convert in.png -define png:preserve-colormap=true out.png
magick convert in.png -define png:preserve-colormap=true -define png:format=png8 out.png
magick in.png -define png:preserve-colormap=true PNG8:out.png

>> sometimes deletes the indexed palette completely, but mostly has no effect (same result as before: reduced and reordered palette)

Any more ideas?

It really doesnt seem to care wich argument is passed to define. Just tested this:

magick in.png -define png:perserve-colormap=WHATEVER PNG8:out.png

No error message,no change in behaviour, no nothing.. O.o it seems Magick just doesnt pass these arguments or use them.

How are you checking the colormap? identify -verbose in.png does not list a colormap, though it says 51 colors.

I'm not sure what you are expecting. The "PNG8:" prefix means, "please generate a reduced palette" while
png:preserve-colormap means "please do not generate a new palette".

But I have verified that the PNG palette does indeed get lost when -define png:preserve-colormap is used.

This shows no difference in the image visually or using compare (using IM 7.0.5.5 beta)

0 (0)

But identify -verbose on either image does not list the colortable.

Glenn, why is there no colortable listed?

fmw42 wrote:But identify -verbose on either image does not list the colortable.

Probably because there isn't one, and result.png is an RGB file (rather than an indexed file).

Gimp is a useful tool for examining the palette (menu: colors, map). SXnEUAe.png has 255 entries in the palette, but IM tells us only 51 colours are used. After playing with this, I haven't successfully prevented IM from removing the unused palette entries.

Perhaps Glenn has the magick spell.

Sorry I don't have the magick spell, although I'm looking for it. With the sample image
provided, "-define png:preserve-colormap" causes the image to be written as RGBA
rather than indexed, which is obviously a bug.

I read through this
https://github.com/ImageMagick/ImageMag ... 38a2562a74
and noticed

Code: Select all

+#if 0 /* To do: Option to use the original colormap */
+  if (ping_preserve_colormap != MagickFalse)
+    {
+    }
+#endif

Seems like this has never been implemented
Thanks for your replies btw. I have high hopes this issue will accumulate some momentum now.

Did this get sorted out? It's been a pain point for me when working with 1992-era images:
http://exult.sourceforge.net/forum/read ... &t=1764018

The Ultima 7 graphics are done in a pretty efficient way for 256 color VGA. They are done in the "midday light" color, and then for clouds the engine swaps the indexed palette for another darker one. A washed-out one happens briefly for lightning strikes, and a red-washed one for when the player character is wounded. It was a great technical solution in the days of the size constraints of floppy disks.

However they made an unfortunately choice to use the same color in different places in the same palette, with some cycling for a magical glimmer. For that reason keeping the exact colormap is important. A "white" in the top row is the same "white" in the bottom row of the palette, but the engine treats them differently.

Most humanoid shapes are somewhere between 24-32 frames, so hand-editing is not ideal. Exult Studio can export these as PNGs with the proper "midday light" colormap. Some work done via ImageMagick is here:
http://exult.sourceforge.net/forum/read ... &t=1732655

The command to keep the color map does not seem to work. So while all the color changes work, the palette is always reduced. I have to use GIMP to change the color map back. But for any with "magic" colors, that are handled based on their position in the original palette, there is no easy way to handle things. Can this be preserve-colormap option be implemented or fixed, please?