Legacy ImageMagick Discussions Archive

ImageMagick version:
7.0.3-9 Q16 x64 2016-12-05, installed about an hour ago using ImageMagick-7.0.3-9-Q16-x64-dll.exe.
Also reproducible with:
ImageMagick 7.0.2-0 Q16 x64 2016-06-12

OS:
Windows 10 Pro
And
Windows 7 Home Premium

Steps to reproduce:
1) download the two .png images at http://imgur.com/a/X8loQ into an empty directory
2) rename them to "img_000.png" and "img_001.png"
3) From that directory, execute the command: Expected behavior:
output.gif should have two frames, each one having a black background with six gray squares and one full green square.

Observed behavior:
output.gif has two frames, both of which have zero gray squares, and the second frame has a corrupted-looking green square. See output.gif at http://imgur.com/a/X8loQ.

Additional information:
- I asked some peers to attempt to reproduce (see http://chat.stackoverflow.com/transcrip ... 4#34496894). Two volunteers could not reproduce using Debian and RedHat respectively. Unfortunately, no Windows users volunteered.
- the corruption seems to be deterministic. It appears exactly the same if I run the command multiple times, if I copy the images to a new directory and run the command there, if I run the command from an administrator command window, and if I reboot and run the command.
- The gif generates properly, free of any corruption, if I instead execute the command:

Kevin wrote:The gif generates properly, free of any corruption, if I instead execute the command:

Code: Select all

magick convert -delay 50 img_*.png output.gif

It seems some changes have been introduced to the way IM7 handles the alpha channel when we let it manage according to its defaults. In my experience these changes seem to appear particularly in association with "-layers" operations. I can make your first command output the GIF correctly (or what looks like correctly) by adding "-alpha on" or "-alpha set" immediately after bringing in the input images. This works for me (IM 7.0.3-9 on Windows 10)...
I'm not a developer, so I don't know what may have changed under the hood, why it affects the output the way it does, or whether it's something actually broken or just something changed. But when something doesn't work the way I expect, and there's a "-layers" operation involved, specifying "-alpha on" after the input image(s) will often resolve it for me.

Including the `-alpha on` option as you suggest, does cause correct output to be produced. Thank you for suggesting this workaround.

As to whether this behavior is something "actually broken" or simply just IM working as intended but in a surprising way, I'm still inclined to think that it truly is a bug. I believe this because the documentation says that `-layers optimize` "is currently a short cut to apply both the 'optimize-frame', and 'optimize-transparency' methods", which implies that this command should produce identical corrupty output:
... But this command produces output with no corruption. The outputs of two ostensibly equivalent commands are different, so one of them has got to be wrong, yes?

Some other observations I have made that may be useful:

- The behavior still occurs if img_000 and img_001 are .bmps, so the problem is not related to reading .png files.
- The behavior still occurs if I write to output.png instead of output.gif, so the problem is not related to writing .gif files.

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ http://www.imagemagick.org/download/beta/ by sometime tomorrow.

I apologize for my late reply. I've installed the most recent release and I am still getting the same incorrect output as before.

Version: ImageMagick 7.0.4-2 Q16 x64 2017-01-02
OS: Windows 10 Pro

I have confirmed that I am not accidentally using an old version of ImageMagick, as I am explicitly specifying the path:
If it helps, I have another set of input data which produces incorrect output using this same command: http://imgur.com/a/kodkQ

Interestingly, while GeeMack's `-alpha on` workaround still works for my original "green squares" input, it does not work for my new "infinite checkerboard" input - the artifacts are still there regardless of whether I use the `-alpha` flag. This makes me suspect that the problem doesn't have anything to do with opacity at all.

Your problem is that you have a 16-bit gray looking pair of images, but they are really color. So you have too many colors in the two image so that they do not have a common colormap. The animated gif will use a common colormap and will change pixels to use the common colormap. Thus it will modify some pixels, which are the ones you see. You can convert to grayscale and depth 8 and that seems to work for me.
If that fails, then you need to convert the images to depth 8 grayscale, extract the colors from img1 (-unique-colors) and use them as a lookup table and remap (-remap) img2 to have the colors from img1. Or selected a set of 256 colors and -remap both images to some common set of colors.

Thanks for your reply. I considered the possibility that "gifs can't have as many unique colors as pngs" might be the cause of the problem, but even if I execute the command:
... There are still artifacts in the output pngs, even though the gif file format is seemingly not involved anywhere. Alternatively, if unique color count restrictions are still in place anyway, it's strange to me that this would cause parts of the blue sky to change. The entire sky rectangle in the input image is a single color*, so reducing the color map ought to affect either the entire sky or none of it.

Executing your `colorspace gray -depth 8` command does produce output with no artifacts, but I'm not convinced that the root problem is because of color spaces.

(*except for a single pixel high horizontal stripe just above the horizon due to antialiasing)

As far as I know -layers optimize is not relevant to png output. It is for a multi-frame gif animation.

So you're saying that the `-layers optimize` flag enforces gif color limitations even though the output isn't a gif? Ok, that seems reasonable. But even so, the sample input from my first post only has three unique colors, so the "artifacts appear due to colormap reduction" theory doesn't seem like it would apply there. (Sorry if it seems like I'm moving the goalposts here, if you were only trying to give a theory why the second sample input was failing. I've just got a gut feeling that there's one cause for the problems of both sets of inputs)

The issue with the image pair I tested was solved simply by -colorspace gray -depth 8.

I suspect you are still running into an attempt to use -layers optimize, which may need a common colormap, otherwise you get those issues.

Do you have a set of images that fails when using -layers optimize with -colorspace gray -depth 8? If so, then you need to make both images have the same colormap before using -layers optimize. That is my guess at what is happening here.

The issue with the image pair I tested was solved simply by -colorspace gray -depth 8.

If you're suggesting that as a general-purpose workaround, I don't know if I'd go as far as calling it a "solution", because I don't want my output to be grayscale. (To be clear, the sky in the checkerboard images is not gray, but a low-saturation blue. This might not be obvious on certain monitors. I apologize for the ambiguity of my input.)

Do you have a set of images that fails when using -layers optimize with -colorspace gray -depth 8?

Yes, I do. When I run the command:
... On the two pngs at http://imgur.com/a/X8loQ, I get this output: http://imgur.com/a/PKKyY, which has a prominent artifact in the second frame.

If so, then you need to make both images have the same colormap before using -layers optimize.

Both images do have the same color map. Each image is composed of exactly three colors: #000000, #00FF00, and #202020. This is considerably less than the 256 color maximum of gifs, so I very strongly suspect that the problem is not due to color map limitations.

Re Kevin's last post:

Removing "-layer optimize" cures the problem, in IM v7.0.3-5.

With IM v6.9.5-3, the command works with no problem.

I think this is a bug in v7.

Incidentally, why do you "-coalesce"? It should do nothing to these input images, but I can't see why it would be needed for inputs that aren't animated GIF.

This is definitely a bug in IM 7 -layers optimize. I tested with IM 6.9.7.2 Q16 and 7.0.4.2 Q16 Mac OSX

Input:




IM6

IM7

Try this command:
The -alpha on option will not be necessary in ImageMagick 7.0.4-4 Beta when its posted sometime tomorrow.

Although that works with the following command, why should one have to enable the alpha channel, since neither input image have any transparency? That does not make sense to me. Also it works fine without -alpha on in IM 6.9.7.2.