Legacy ImageMagick Discussions Archive

Yes, "-alpha on" cures the problem in IM v7.0.3-5. I suggest this is still a bug. If V7 "-layers optimize" required "-alpha on", it should set it itself (and restore the original value when it is finished).

magick wrote: ↑2017-01-09T13:57:21-07:00 Try this command:

Code: Select all

magick -delay 50 img_*.png -alpha on -layers optimize output.gif

Ok, that works on my green squares test case.

No change on my checkerboard test case, though - still the same artifacts as before. I now believe that the artifacts from the two test cases have different causes: the green squares test case has a transparency issue, and the checkerboard test case has a color space issue. I'm confident of the latter because when I run on my checkerboard test case, I get the same artifacts as when I was trying to make a gif.

Your second problem is due to the fact that both images have 259 colors. When you use -colors 256, you probably end up with slightly different colors, such that two images do not have the same colormap. Thus the two images have more than 256 unique colors and that causes the problem with the animation, since it tries to force a unique set.

Converting to grayscale, fixes your issue (as I mentioned earlier in this topic)
Alternately, you can try to force the two image to have the same 256 colors colormap using -remap.

fmw42 wrote: ↑2017-01-10T11:02:23-07:00 you probably end up with slightly different colors, such that two images do not have the same colormap.

But the problem still occurs if I'm using only one image. Sorry if that wasn't clear from my previous message.

(But even if I wasn't, isn't the 256 color limitation per-frame anyway? Wikipedia says the file format "allows a separate palette of up to 256 colors for each frame.")

Your one image probably has more than 256 colors to start. When you specify -colors 256 it forces some colors to change. That is what you are likely seeing.

See http://www.imagemagick.org/Usage/anim_opt/#colortables regarding optimizing to one colortable.

The first checkerboard image has 259 colors. When I use "-colors 256" on it, I get 34 colors. (This is with v6.9.5-3. Other IM versions may give a different number.) Converting to a GIF gives the same number.

Does that explain your problem?

"-colors N" doesn't guarantee the result will contain N colors. For your purposes, a different colour-reduction method may give better results, eg find the 256 most common colours and remap to those.

fmw42 wrote: ↑2017-01-10T16:11:33-07:00 Your one image probably has more than 256 colors to start.

Correct. It has 259 colors.

When you specify -colors 256 it forces some colors to change. That is what you are likely seeing.

I certainly expect some colors to change, but I expect all instances of that color to change to another color. But this isn't what's happening. My image has a 200x32 block of solid blue at the top. After applying -colors 256, the block is still there, and it's still blue, but a few select pixels have been changed while the majority are unchanged. This occurs even with dithering disabled.

input.png:


output.png:



Zoomed detail of input.png:



Zoomed detail of output.png:



Highlight of speckles in zoomed detail of output.png:



Note additionally that the majority of the sky hasn't even changed to a new color: it is (128, 128, 160) in both input.png and output.png. So these speckles are probably not even a side-effect of `-colors 256` changing the color of the sky, because the color of the sky isn't actually changing (mostly).

Kevin wrote:-colors 256 +dither

Commands are executed in the order given. If you want "+dither" to affect the processing of "-colors 256", put it before, not after.

snibgo wrote: ↑2017-01-11T07:38:59-07:00

Kevin wrote:-colors 256 +dither

If you want "+dither" to affect the processing of "-colors 256", put it before, not after.

Thanks for the tip. If I do `+dither -colors 256`, the speckles go away...

... But I still think this is a bug if I just do `magick convert input.png -colors 256 output.png` and permit dithering. You might say "it's normal for solid blocks of color to no longer be solid blocks of color when dithering is enabled, because that's what dithering is", but I reject this reasoning for three reasons:

1. If the sky were being dithered, I'd expect the entire sky to be dithered. I'd expect a significant portion of the rectangle to have changed colors, distributed semi-regularly throughout. Instead, only three out of a possible 6400 pixels are changed.
2. If dithering the sky was necessary to reduce the total number of colors in the image, I'd expect the original color of the sky to no longer be present in the output image -- I'd expect it to be replaced by two or more colors already present elsewhere in the image. But the original color, (128, 128, 160), is still there in large quantities.
3. Even if I accept that changing four pixels in the sky is a valid output for the dithering algorithm, I'd expect those changes to be limited to the sky itself. Instead, some blue is bleeding downwards onto the gray horizon.

Update: A peer of mine directed me to this page: E-Dither Pixel Speckling. It describes how dithering "can produce the occasional odd-colored pixels in areas which would otherwise be fairly uniform in color". I believe this is the cause of my speckles.

Since this is known and documented behavior, I no longer consider it a bug, merely an unfortunate corner-case of a properly functioning algorithm.

Thank you for your time and attention.