Description
I merged 2 previously made animated GIFs onto the walls of an art gallery. The guy walking across the room was done one frame at a time using an undocumented component of Gimp-Gap (Layer>Transparency>Foreground Extract Via Selection). The animations on the walls were made with a range of Gimp plugins and scripts including Gmic-qt, gimp-gap and were aligned with the perspective tool. The 3 animations were merged with 'Wills Script Pack animation merge'. Merging is quite easy if you work from a base animation and add new ones with an alpha channel on every layer. Made entirely in Gimp.

Wow! That sounds very involved. How long did it take to do all of that?

A stunning creation

Thanks Pat625 and Steve.
Steve, I was going to use your script if the animation merge script didn't work. I'm yet to learn the difference in the scripts. It appears Wills animation merge preserves the timing of individual animations. I think the LHS animation is going faster than the one on the RHS. That was unexpected.

Time taken. I try to use elements as components so don't know how long in total. I had a clear idea to start with that was also a comment on 'modern art'. Steve showed how animations could run in front or on top of each other. PhotoMaster showed us how to build an animation layer by layer. I get inspiration from racer-x and you guys. I feel my work has improved since I joined Gimp Chat.

If Wills animation merge script is giving the results you want then that's the one to use

The difference between Wills script and mine, is Wills merges two gifs into one, mine will merge numerous gifs into one so long as the rules are followed.

I designed it so that if I was working on say a space animation scene with 20 different objects each having 15 layers, I can work on and save each object as a stand alone gif. I can then stack all, some or a combination of the stand alone gifs in gimp and run my script to shuffle and merge them into one gif. If I disliked how one of the objects looked I could easily rerun the script minus that one object.

As to preserving the timing of individual animations, my script is designed only to stack, shuffle and merge gifs, I don't think it alters any of the layer timings but I can't be sure of this, perhaps someone who is more knowledgable on how gifs work could throw some light on this

This is extremely impressive! Gives me some great ideas!

Pretty good, considering you went the very long way to do this.

I would've done something like this in Aviutl (free) in about 10 minutes total time. Here's an interesting animation I did when I first started learning Aviutl:


I had to decimate the frames to lower file size, so it's not as smooth as it really is in full 1080p resolution.

Thanks for the thumbs-up TimeLord and PhotoMaster.

Hi racer-x. Panning across the screen in that clip is very good. Running an animation in front of another animation
is a different process.
http://gimpchat.com/viewtopic.php?f=25&t=15700&p=217388&hilit=Steve+animation+merge#p217388
It maybe harder to have the planet in Steve's animation pass in front of the asteroid
I would like to do a comparison of the animation merge scripts.

racer - have you found that fade-outs don't really work in GIFs?

Tas_mania - just want to say that I am so impressed with this animation combination, just brilliant. I think you should offer it to the MONA in Hobart, it would go down very well in that gallery.

It took less than 2 minutes to create this second version with the planet in front

In the original gif the three .xcf files were opened in the order of asteroid, planet and background, in this second version the order was changed to planet, asteroid then background.

Awesome Tas_mania and a great subject, thankyou.

Thanks OMG and RJKD.

Steve I was using the shuffle and merge script today and wanted to ask if the 2nd and 3rd animations have to be smaller than the background animation?
I have adopted a technique where the the merged animations share the same canvas size as the background, except
they have an alpha channel switched on. That way you know exactly where they will appear in the finished 'canvas'.

Same size is best, as you say, you know exactly where they will appear in the finished 'canvas'. I used smaller image sizes in my example to keep the file size down, it worked in my example because I wanted the planet and asteroid in the centre, which is where they are positioned if they are smaller than the canvas