Incorrect looking output when creating gif with `-layers optimize` option

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by snibgo »

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).
snibgo's IM pages: im.snibgo.com
Kevin
Posts: 11
Joined: 2016-12-08T12:55:56-07:00
Authentication code: 1151

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by Kevin »

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

Code: Select all

magick convert img_0000.png -colors 256 output.png
on my checkerboard test case, I get the same artifacts as when I was trying to make a gif.
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by fmw42 »

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)

Code: Select all

magick -delay 50 image1.png image2.png -colorspace gray -loop 0 anim7_no_opt.gif
Alternately, you can try to force the two image to have the same 256 colors colormap using -remap.
Kevin
Posts: 11
Joined: 2016-12-08T12:55:56-07:00
Authentication code: 1151

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by Kevin »

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.")
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by fmw42 »

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.
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by snibgo »

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.
snibgo's IM pages: im.snibgo.com
Kevin
Posts: 11
Joined: 2016-12-08T12:55:56-07:00
Authentication code: 1151

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by Kevin »

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:

Image

Code: Select all

magick convert input.png -colors 256 +dither output.png
output.png:

Image

Zoomed detail of input.png:

Image

Zoomed detail of output.png:

Image

Highlight of speckles in zoomed detail of output.png:

Image

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).
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by snibgo »

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's IM pages: im.snibgo.com
Kevin
Posts: 11
Joined: 2016-12-08T12:55:56-07:00
Authentication code: 1151

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by Kevin »

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.
Kevin
Posts: 11
Joined: 2016-12-08T12:55:56-07:00
Authentication code: 1151

Re: Incorrect looking output when creating gif with `-layers optimize` option

Post by Kevin »

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.
Post Reply