bug with convert -remap

[fabrice_martin]

Hello,

I've experimented with convert -remap to reduce the number of colors in
images, using a predefined palette. However, I don't think the result is
always the right one. The documentation states: "the closest color (in
RGB colorspace) is selected to replace that pixel in the image." However
look at the example below, it isn't the closest color that is selected.
You can download a small example here:
http://dl.free.fr/o6b1n21Nc

The command line is:
convert +dither -remap map.gif bug.tif bug_indexed.tif

The input image is bug.tif, the result is bug_indexed.tif, and the map color is map.gif .

As you can see, the result is odd, especially in the "purple" area. From
the palette used, the right (in the sense "closest color in RGB mode")
choice should have been (152; 124; 118).

Do you confirm this is a bug ?

Best regards.

[fmw42]

Have you tried

convert bug.tif +dither -remap map.gif bug_indexed.tif

see http://www.imagemagick.org/Usage/basics/#cmdline

[fabrice_martin]

Have you tried

convert bug.tif +dither -remap map.gif bug_indexed.tif

Unfortunately, the result is the same.

[anthony]

This is I believe a known problem, and one that is proving difficult to resolve.

It also causes GIF images to be saved with a lot less colors than they should be saved at.

[fabrice_martin]

This is I believe a known problem, and one that is proving difficult to resolve.

It also causes GIF images to be saved with a lot less colors than they should be saved at.

Thank you for the information and sorry for highlighting an already known problem.
Is there a trac somewhere to read or to open tickets related to IM ?

By the way, the problem is also present when using IM 6.2.8 Q8 . Seems this bug was introduced some times ago.

[keithmgould]

Hi,

I am experiencing this problem (bug?) and am using the newest ImageMagick 6.6.9-5 on my MacBook Pro.

The goal is to take the starting image and reduce to the best 24 colors given a palette. However purple seems to be creeping in.

starting image: http://keithgould.s3.amazonaws.com/cute_cat.png
palette: http://keithgould.s3.amazonaws.com/palette_96.png
resulting image: http://keithgould.s3.amazonaws.com/out.png

command: convert cute_cat.png +dither -colors 24 -remap palette_96.png out.png

color after reduction (from doing just convert cute_cat.png +dither -colors 24) (rgb): 129,123,136
proper closest color (in my opinion via euclidian distance in 3D)(rgb): 125, 127,126
purple selected by remap(rgb): 140,94,174

Is this a bug or am I missing something? Any help would be greatly appreciated, thank you.

Keith Gould

[keithmgould]

Some insights:

Digging a bit deeper into it, it seems the -quantize operator comes into play here.

For anyone else experience this problem:

Check out: http://www.imagemagick.org/Usage/quantize/#colors and look at Color Quantization and Color Space/

So far I've landed on -quantize YIQ. Not sure where I'll end up but for now this seems like the proper solution. Would still love to hear thoughts from the pros.

Best,

Keith

[anthony]

Additional, Since the previous discussion I learnt that the reason IM is not given the closest colour is because it was making the GIF color reduction prohibitively slow, especially when typically people wanted speed instead of exact results, and complain more about speed.

I do not agree with this choice, and think selecting the exact nearest color is better. It is on my To Do list, and even found a great site explaining the coding of different color dithering methods (including oerder dither with any color for animations), but I doubt I will get to it any time soon.

However the fix was to increase 'color tree depth' setting. A weird option I myself do not really understand.

So try adding -treedepth 8 which should produce a perfect nearest color match. (I have not tried it myself)

You can monitor this using -verbose during the color reduction.

And please let us know how it goes.

[keithmgould]

Hey Anthony,

Thank you for the response!

For me treedepth did not seem to work. The color problems stayed. Just to make sure I did it correctly, here was the command:

convert cute_cat.png +dither -treedepth 8 -colors 24 -remap palette_96.png out.png

Actually some of the time with treedepth 8 the command never finished, it just hung.

Hope this helps, and thank you again.

Keith

[anthony]

color after reduction (from doing just convert cute_cat.png +dither -colors 24) (rgb): 129,123,136
proper closest color (in my opinion via euclidian distance in 3D)(rgb): 125, 127,126
purple selected by remap(rgb): 140,94,174

Hmmm I did say the -treedepth was bad (speed wise).

However going back to the original request... distance from 129,123,136
to 125, 127,126 is 11.4891252930761
to 140,94,174 is 11.2243817258757

In this case the IM selected was closer than the one you suggested!

[keithmgould]

Anthony,

I think either I was unclear or one of us made a math mistake -- I'm showing a distance of around 49 for the color I said was wrong. You and I got the same distance (around 11) for the color that should have been chosen.

Here is an online calculator to confirm: http://www.calculatorsoup.com/calculato ... points.php

Let me know, and thank you,

Keith

[anthony]

Sorry yes you are right. That last distance was not a distance it was an angle (standard geometry vector program).

However I do not have a soltuion for your problme at this time. The -treedepth option is the only thing I have, as I am not directly involved in the quantization code. I have sent a message about this discussion to "Magick" the program coordinator, and hopefully he will respond soon.