weird resize when joining gifs

[pirad]

Hi. I have a .png picture (background) of size 743x644 and a few animated data in .miff format, the same size. But when entering (command line) "convert a.png b.miff c.miff d.miff -layers optimize abcd.gif" I get a .gif-file of the size 642x643. What will be my mistake? I want the full 743x744 animated gif.

(By the way: I just want pictures in around 500 pages of one (or more) pdf files one after another animated.)

[fmw42]

try without the -layers optimize

[anthony]

You can not very clear about what your mean by 'animated GIF' The are lots of ways animated GIF can be joined together, tha the hardest type is merging multiple animations do they animate together!

[omrom2]

I'm having the same problem, using IM 6.7.4-10.
Creating an animated GIF from 2 static GIF's (512x512 pixels each) results in a 514x512 pixels GIF, if using "-layers optimize".
Please advise how to remedy!

[fmw42]

I'm having the same problem, using IM 6.7.4-10.
Creating an animated GIF from 2 static GIF's (512x512 pixels each) results in a 514x512 pixels GIF, if using "-layers optimize".
Please advise how to remedy!

Perhaps you should post your command and also links to your two input images. Then others can test what you are doing and try to suggest remedies. Perhaps your gifs have virtual canvas offsets (if gif supports that -- I am not sure). You can try to add +repage after reading in the gifs.

[pirad]

I somehow found a workaround and don't have the samples any more.

[omrom2]

I'm having the same problem, using IM 6.7.4-10.
Creating an animated GIF from 2 static GIF's (512x512 pixels each) results in a 514x512 pixels GIF, if using "-layers optimize".
Please advise how to remedy!

Perhaps you should post your command and also links to your two input images. Then others can test what you are doing and try to suggest remedies. Perhaps your gifs have virtual canvas offsets (if gif supports that -- I am not sure). You can try to add +repage after reading in the gifs.

The images are here and here.

The command is:

Code: Select all

convert -delay 50 radar1.gif radar2.gif -layers optimize anim.gif

[fmw42]

I can verify your results. It could be a bug, but I don't know all the ins and outs of -layers optimize. Anthony would have to comment.

identify radar1.gif radar2.gif
radar1.gif GIF 512x512 512x512+0+0 8-bit PseudoClass 256c 97.6KB 0.000u 0:00.000
radar2.gif[1] GIF 512x512 512x512+0+0 8-bit PseudoClass 256c 98.3KB 0.000u 0:00.000

convert -delay 50 radar1.gif radar2.gif -layers optimize -loop 0 radar_anim.gif
identify radar_anim.gif
radar_anim.gif[0] GIF 512x512 514x512+0+0 8-bit PseudoClass 256c 113KB 0.000u 0:00.000
radar_anim.gif[1] GIF 510x512 514x512+2+0 8-bit PseudoClass 256c 113KB 0.000u 0:00.000


The virtual canvas seems to be expanded relative to the size of the image.

So reset the virtual canvas using +repage. That seems to work.

convert -delay 50 radar1.gif radar2.gif -layers optimize +repage -loop 0 radar_anim.gif

[omrom2]

The virtual canvas seems to be expanded relative to the size of the image.

So reset the virtual canvas using +repage. That seems to work.

convert -delay 50 radar1.gif radar2.gif -layers optimize +repage -loop 0 radar_anim.gif

Unfortunately this workaround does not work nicely when I apply it to the entire animation scheme (144 images) after the optimization. The frames seem misplaced, probably since the optimization cuts them into smaller pieces, and "repage" aligns them back to 0x0. I'll be happy to hear if you have another solution.

[fmw42]

I am not an expert on animations. So you will likely need to wait to hear back from Anthony when he gets back online. Sorry I don't know what further to suggest.

[anthony]

I have see this once before, but was not given images that caused the fault for me to try an track it down.

It seems that the second image was given a +2 offset which translated to a canvas size increase,
But why it was given this offset is a mystery.

If you can send me the images, I'll look into it when I can get some time. My email address is as perl IM Examples
A.Thyssen AT griffith.edu.au

[anthony]

When I try this on my machine (latest version of IMv6) I get...

Code: Select all

convert radar1.gif radar2.gif -layers optimize info:
radar1.gif[0] GIF 512x512 512x512+0+0 8-bit PseudoClass 256c 3.880u 0:00.620
radar2.gif[1] GIF 510x512 512x512+2+0 8-bit PseudoClass 256c 3.870u 0:00.620

identify radar_anim.gif
radar_anim.gif[0] GIF 512x512 514x512+0+0 8-bit PseudoClass 256c 113KB 0.000u 0:00.000
radar_anim.gif[1] GIF 510x512 514x512+2+0 8-bit PseudoClass 256c 113KB 0.000u 0:00.000

So I can see the problem but it is NOT with the optimizer, but the GIF codec, which I have not been involved with. I don't know why the codec is changing the base canvas size. It seems strange that it changed it at all!

However looking at the images they should optimize a lot better than they do. I have a feeling it may be because of dither noise in the image...
http://www.imagemagick.org/Usage/quanti ... _sensitive

Adding a 'fuzz' factor to make IM think 'near colors' ar the same during optimization helps with this...
And it does to an extent..

Code: Select all

convert radar1.gif radar2.gif -fuzz 10% -layers optimize info:
radar1.gif[0] GIF 512x512 512x512+0+0 8-bit PseudoClass 256c 3.670u 0:00.589
radar2.gif[1] GIF 499x506 512x512+9+5 8-bit PseudoClass 256c 3.660u 0:00.589

Though the radars still get a lot of 'single pixel specks' of color changes occurring - whcih considering what the image is
is probably valid and not dither-noise.

Do you have access to the images before they were covered to GIF. Remember GIF is 'lossy' as it needs to reduce the number of colors in the image. leaving that until after optimization can help A LOT!

See IM Examples.. Animation Optimization, Color Optimization
http://www.imagemagick.org/Usage/anim_opt/#color_opt

[omrom2]

Anthony and fmw42, thanks a lot for your support on this issue!

The -fuzz option does reduce the animation size significantly - thanks for that!
Unfortunately I do not have access to the raw images, only the GIF's.

However, even the -fuzz doesn't help maintain the original canvas size with the full animation sequence (144 images that I have sent you in PM). Even though all images involved are 512x512, the final animation becomes 634x518 pixels...

Code: Select all

anim.gif[0] GIF 512x512 634x518+0+0 8-bit PseudoClass 256c 1.529MB 0.000u 0:00.000
anim.gif[1] GIF 503x506 634x518+4+4 8-bit PseudoClass 256c 1.529MB 0.016u 0:00.015
anim.gif[2] GIF 504x506 634x518+5+4 8-bit PseudoClass 256c 1.529MB 0.016u 0:00.015
...
anim.gif[141] GIF 9x13 634x518+121+5 8-bit PseudoClass 256c 1.529MB 0.016u 0:00.015
anim.gif[142] GIF 10x13 634x518+121+5 8-bit PseudoClass 256c 1.529MB 0.016u 0:00.015
anim.gif[143] GIF 355x489 634x518+121+5 8-bit PseudoClass 256c 1.529MB 0.016u 0:00.015

Do you think it will be resolved soon?
I don't mind downgrading to a version where this bug did not exist, but I do not know which version it would be.

[anthony]

I have forward my note about the source of the error to the main development coordinator.

[omrom2]

I have forward my note about the source of the error to the main development coordinator.

I have checked version 6.7.5-5, and I am happy to report that the problem is fixed!
Thank you for all the help!