Legacy ImageMagick Discussions Archive

Using the following command and end up with what can be seen at http://devacs.za.net/sensors.gif. Not so good.
The images involved are http://devacs.za.net/lcars_screen_1b.png http://devacs.za.net/lcars_anim2.gif http://devacs.za.net/fwscan.gif
Please help me fix this.

Altered the command to and it now looks a bit better but not right as yet. See http://devacs.za.net/sensors2.gif and you may agree.

stockton wrote:Using the following command [...] Please help me fix this.

Building an animated GIF from more than one set of other animated GIFs can be tricky, but if you follow along, I think we can help you understand how it's done.

In a comment in your other thread one of the experts here, snibgo, mentioned an operator called "-coalesce". It looks like that might help you here. One or both of your animated GIFs has been optimized, and "-coalesce" will turn them back into sets of complete images to use further along in the command.

Another issue you're dealing with here is one of your overlay animated GIFs has 8 frames, and the other has 24 frames. You can find this with a simple command like...
So your final image will require 24 frames, the 8 frame image being repeated 3 times. (You're lucky the numbers divide so evenly, otherwise it would require applying some more complicated math.)

Start by bringing in your background image "lcars_screen_1b.png", which is a single frame.

Then bring in the "null:" built-in we used in your other project. Remember that's to separate the two groups of images so the "-layers composite" can alternate between using one from the group before the "null:" and using one from after it.

Next bring in the 24 frame animated GIF "lcars_anim2.gif" and "-coalesce" the frames to make them all complete images. So far the command, not yet complete, looks like this...
Now you specify the geometry which will determine the location of the "lcars_anim2.gif" frames as they get composited onto the "lcars_screen_1b.png" image, then apply the operator "-layers composite". After that the image stack contains 24 frames, each one is the background image with a single frame from the first animated GIF.

At this point in the command it's like you're just starting with a 24 frame animated GIF, so... Put another "null:" image in there to separate those first 24 images from what will come after. And after that you'll bring in the "fwscan.gif" animated GIF, but remember it has only 8 frames, so you have to bring it in 3 times to match the number of frames you have before the "null:" separator. Apply the "-coalesce" operator to those 24 frames, too. Your command isn't complete yet. You're up to here...
Keeping those groups of images separated in parentheses isn't always necessary, but sometimes it helps us keep track of what the command is actually doing. And in some cases, it is absolutely required.

Now you have the background with 24 frames of your first GIF overlaid onto it, and you've brought in your second GIF and made it into 24 frames. Specify the geometry for compositing those on the background, and "-layers composite" them onto it.

Finish by compressing the whole thing with "-layers optimize" which tries to reduce the output file size by eliminating the parts that are duplicated from frame to frame throughout the animation.

Give it an output file name, and you're done!
I use Windows not *nix. I'm pretty sure those backslashes "\" are where they need to be to make this command work. If they're not exactly correct, maybe someone else can explain what you need to do to get it right.

That looks good. I'll make one comment.

( fwscan.gif fwscan.gif fwscan.gif -coalesce )

This reads from a file and creates in-memory copies of all the frames. Then it does that again, and again. Then it decompresses all the frames.

An alternative is:

( fwscan.gif -coalesce ( -clone 0--1 ) ( -clone 0--1 ) )

This reads the file etc just once, and decompresses. Then all the frames are cloned, which means pointers are built. So this is quicker and uses less memory.

The difference isn't worth bothering about with a few small GIF frames, and it's harder to explain and understand, but the improvements can be worthwhile.

snibgo wrote:This reads the file etc just once, and decompresses. Then all the frames are cloned, which means pointers are built. So this is quicker and uses less memory..

Thanks for the additional hint. I use IM for a lot of stuff. A lot. Like building yearbook pages from hundreds of scanned images, assembling the cells of mazes into grids sometimes over 20,000 parts, making animated radar maps from NOAA originals, and manipulating/combining space satellite images from 4096x4096 NASA files. I don't worry much about memory and speed in the little down-and-dirty things, but it can be important to improve the efficiency in the more complicated projects.

Thank you guys, especially GeeMack. I have obviously got a lot to learn but thank you GeeMack for such an excellent explanation and your final command worked perfectly for me.