Gray artifacts in large gif when using -layers optimize

[wheany]

When creating a large .gif, using -layers optimize causes gray artifacts to appear all over the image.
The source frames I'm using in these commands are in this zip file: http://www26.zippyshare.com/v/rOwQZL3D/file.html and they are originally from this cartoon: https://youtu.be/_2WMLV1UeuM

The version I'm using is the newest available atm, but this bug was also present in some 6.8 version I was using before I updated:

$ convert -version
Version: ImageMagick 6.9.2-6 Q16 x64 2015-11-14 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Visual C++: 180040629
Features: Cipher DPC HDRI Modules OpenMP
Delegates (built-in): bzlib cairo freetype jng jp2 jpeg lcms lqr openexr pangocairo png ps rsvg tiff webp xml zlib

I'm using Windows 7 and cygwin terminal to run these commands, they won't work as-is with the default windows command prompt. I haven't tested if the problem happens in Linux as well.

This command works properly and creates a 1,72 MB gif with no artifacts:
convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 50% -colorspace srgb -quantize lab -fuzz 3% -layers optimize +dither mickey_mustache_small.gif

This command demonstrates the error:
convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 94% -colorspace srgb -quantize lab -fuzz 3% -layers optimize +dither mickey_mustache_big.gif

The only difference between those two is the amount of scaling from the 1080p source files (50% vs 94%)

If you don't use -layers optimize, you get a very big, but working, gif:
convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 94% -colorspace srgb -quantize lab -fuzz 3% +dither mickey_mustache_big_no-optimize.gif

If you don't use fuzz, you get a fairly big, but extremely corrupted gif:
convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 94% -colorspace srgb -quantize lab -layers optimize +dither mickey_mustache_big_no-fuzz.gif

Here is a zip of the resulting gifs: http://www62.zippyshare.com/v/CD2stFbG/file.html

[dlemstra]

This is not a bug in -layers optimize but an issue with your command order. You should put the +dither before your optimize your layers. We get the correct result with the following command:

convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 94% -colorspace srgb -quantize lab -fuzz 3% +dither -layers optimize mickey_mustache_big.gif

[wheany]

Confirmed.

Is there an explanation for why it works the way it does, because I'm confused why it works with the first command and doesn't with the second?

I have seen this before but I don't think I've ever tried moving the +dither command as a fix.

[fmw42]

In IM 6, settings (+dither) should come before operators (such as -colors); otherwise, the operator does not know what setting to use. see http://www.imagemagick.org/Usage/quantize/#colors. Command lines are mostly parsed in sequence. See http://www.imagemagick.org/Usage/basics/#syntax

However, I am puzzled, since I do not see any operator in your command that would be affected by: -quantize, -fuzz or +dither. I am not aware that -layers optimize is sensitive to any of those

[wheany]

I just threw that there because I though that only the color reduction to 256 would be affected by dithering. I haven't had a "set" place for the setting in my gif making before, but I guess I should just put it in the front like with the -delay setting.

Then again I just tried leaving the +dither out entirely, and then explicitly specifying -dither FloydSteinberg as the first option, before the -delay, and I'm getting gray artifacts in both cases.
convert -dither FloydSteinberg -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 89% -colorspace srgb -quantize lab -fuzz 3% -layers optimize mickey_mustache_big_dither.gif

[fmw42]

I am totally puzzled as I said above, since I do not know what operator in your command line is dither sensitive.

What do you get when you leave all that off? Is it the same as putting +dither at the beginning?

convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 89% -colorspace srgb -layers optimize mickey_mustache_big_dither.gif

What version of IM are you using?

[wheany]

the command was convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 89% -colorspace srgb -quantize lab -fuzz 3% -layers optimize mickey_mustache_big_dither.gif
Version is 6.9.2-6 Q16 x64 2015-11-14, the full version output is in the first message.

[fmw42]

I realize that. But I do not see why you have any need for -quantize, -fuzz and +dither. There is no operator there that should be affected to my knowledge. So I wanted to see if you got a decent result or any different result from what you had before with +dither at the beginning. So I asked you to run

convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 89% -colorspace srgb -layers optimize mickey_mustache_big_dither.gif

and there report back any difference.

[dlemstra]

The -layers optimize option will do a color quantization as the last step and that is why +dither affects this. And it seems you get the best result with dithering disabled.

[wheany]

@fmw42 Running convert -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 89% -colorspace srgb -layers optimize mickey_mustache_big_dither.gif causes artifacts.

I use -quantize lab because afaik it treats perceptually similar lighting and color change equally, so it's "the fairest" quantization method. Usually I use ordered dither in the lab colorspace when making gifs, but with some cartoons I've found that it's better to just use quantization.

Also running this command (without -fuzz) balloons the file size from 3.99MB (which is just under my maximum file size of 4MB) to 15.6MB, because every tiny color change in every pixel is treated as a meaningful change. With cartoony source like this, I can sometimes use up to 4% or 5% fuzz without a significant drop in the visual quality.

[fmw42]

Sorry, I did not realize that -layers optimize does a color quatization, as dlemstra points out above. Thus dither, fuzz, quantize would be needed prior to -layers optimize.

[dlemstra]

Do you still have some questions or can we close your issue?

[wheany]

I'm confused about your question. Is the gray artifacting intended behaviour? Especially in this case I added earlier: convert -dither FloydSteinberg -delay 4 frames/mickey_mustache0{08..74}.png -colorspace rgb -resize 89% -colorspace srgb -quantize lab -fuzz 3% -layers optimize mickey_mustache_big_dither.gif

This is the resulting gif, btw: https://i.imgur.com/E93Y4Xl.gif

If gifs made with that command like are supposed to have terrible gray smears all over, then I guess this issue can be closed, but I intended this to be a bug report, because that seems like a bug to me.

[wheany]

It is somehow related to the lenght of the gif, if I only use the first 19 frames, i.e.
convert -dither FloydSteinberg -delay 4 frames/mickey_mustache0{08..27}.png -colorspace rgb -resize 89% -colorspace srgb -quantize lab -fuzz 3% -layers optimize mickey_mustache_big_short27.gif
the artifacts are barely visible with the naked eye. Areas of the image with motion have a very slight grayish color to them.

Could this be caused by some overflow happening in the quantization code? There is a "big number" of pixels. Adding their numbers to the histogram could fail. I haven't looked at Imagemagick's quantization code, but I assume a histogram is built at some point of it.

[urban-warrior]

Try your command with ImageMagick 6.9.2-8.

[wheany]

Hey, it works! No more artifacts.