Legacy ImageMagick Discussions Archive

I'm attempting to convert a .png to a .gif on an appliance I'm working on. Unfortunately, it's doing some strange stuff when --colors=256 is used.

The source image is:

HERE

convert test.png test.gif Generates: this

convert -colors 256 test.png testcolors.png generates: this

convert -depth 8 test.png testdepth.png generates: this

If I try it on my host system, it's fine. So... where could the problem be? Some library? Some way it's being compiled? Any ideas on where to begin?

EDIT: Keeping the post size down by linking to images...

wokka wrote:I'm attempting to convert a .png to a .gif on an appliance I'm working on. Unfortunately, it's doing some strange stuff when --colors=256 is used.

The source image is:

HERE

convert test.png test.gif Generates: this

convert -colors 256 test.png testcolors.png generates: this

convert -depth 8 test.png testdepth.png generates: this

If I try it on my host system, it's fine. So... where could the problem be? Some library? Some way it's being compiled? Any ideas on where to begin?

EDIT: Keeping the post size down by linking to images...

You are using outdated syntax. See http://www.imagemagick.org/Usage/basics/#why

try

convert <input> arguments <output>

fmw42 wrote: try

convert <input> arguments <output>

I tried your suggestion. I receive the same result.

wokka wrote:

fmw42 wrote: try

convert <input> arguments <output>

I tried your suggestion. I receive the same result.

I get the same result. But that may just be the way it works. When you go from 24-bit color to limited colors such as with -colors 256 or just GIF, then you are going to get color quantization.

Perhaps Anthony can give you more details or tell if there is really some error here.

No, something else is going on here. You won't get those kind of results across areas that were formerly entirely homogeneous. When I load that very same image into gimp and convert to indexed and save as gif, I get the following result: IMAGE

wokka wrote:No, something else is going on here. You won't get those kind of results across areas that were formerly entirely homogeneous. When I load that very same image into gimp and convert to indexed and save as gif, I get the following result: IMAGE

The images look visually homogeneous, but they are not. I opened the image in Debabelizer and moved my cursor over the colors to get RGB color readout and they are NOT homogeneous.

IM -colors and the conversion to GIF may behave differently to whatever GIMP is using. I am no expert on this and will certainly defer to Anthony or Magick on whether there is odd behavior in IM.

On the other hand, I believe that you need to turn off dithering when using -colors. So this seems to work fine:

convert test.png +dither -colors 256 test_256_nodither.gif

Oh hoh! That did it indeed! Thank you

Let me clarify. By "homogeneous", I was not referring to exact sameness between the pixel values, but sameness to the extent that it's imperceptible to the eye and should probably get mapped to the same color in an indexed image.

Even though that worked, it still might bear looking into, however, as the GIMP does not mottle the colors like that even when dithering is enabled. Looks like there might be a slight error in the algorithm to pick the nearest color, and it's rolling over to the darker color(s) in areas where it shouldn't.

This is highlighting a problem I have been reporting repeatedaly about the current color quantization and dithering methods in IM.

I can get an improved result by switching to a -dither FloydSteinberg but the dither is still very highly visible.

Stranglely looking at the resulting color table does seem to show that a good gradient of colors exists, so I am wondering just why the dither is producing such a bad result.

Using a +dither shows pre-dithered color quantization had even more colors that was present after dithering, whcih highlights that for some reason dither is not making good use of the whole color range IM generated.

This has been a major problem in IM for some time now (repeated reports).

I also have a test case where I create an image with 255 colors and one transparent color, which should be able to be saved perfectly to GIF without quantization or dithering, BUT which saves with color reductions.

For example this 256 gradient saves perfectly... but replacing one color with transparency (still has 256 colors) ends up being color reduced to only 65 colors! Adding a -treedepth 8 which often improves color quantization, does not work in this case producing no change.

Basically color quantization, and dithering is not working well, and does not seem to be picking the 'closest' color during dither.

In both the above cases color quantization and dither should produce NO-OP results, and that is not what is happening!

The problem you reported is fixed in ImageMagick 6.4.5-4 available sometime tomorrow. Thanks.

Thank you!!!!!! I'll test it shortly.

magick wrote:The problem you reported is fixed in ImageMagick 6.4.5-4 available sometime tomorrow. Thanks.

Well. Guess that answers that.

Would you be willing to talk about what the specific nature of the problem was? I'd be interested in some of the more technical details.

wokka wrote:Would you be willing to talk about what the specific nature of the problem was? I'd be interested in some of the more technical details.

As would I

The two above tests both now generate PERFECT gif images just as they should. But I have spotted other errors and problems, which I have reported. hopefully these will be fixed before IM is released.

As an update the bug was fixed. But then a much more serious problem developed, so was backed out.

The problem does seem to stem from the the 'nearest color' selection algorithm used by the dithers, as an image with less that 256 colors, which should save perfectly in the GIF format, also gets dithered to a reduced color set, even though all the pixels exactly match the final color selection.

It is however being worked on.