Hi, I am fiddling with animations in Gimp, maybe a bit more complex than intended, but hey, if it works, it works!
What I am doing is an animation where each frame has multiple layers. This is doable enough by specifying the topmost layer as the intended duration, say (200ms), while the others below belonging to the frame as (1ms). There is a slight flicker, but it is fine for working on it.
While figuring this out, I noticed that (0ms) is not supported, that is, it is completely ignored, and a default of probably around 50ms is applied.
Would like to raise this as a feature request: Allow the animation filter to recognize (0ms), and just do its best to combine the layers. Of course I can understand it could go deep thinking about doing it properly (like should it automatically combine those layers when optimizing for GIF and similar), but the simplest approach of just allowing that 0ms to be recognized could already help a lot (shows the intent better, I imagine would also reduce or possibly even eliminate flicker if it wouldn’t time that 1ms any more).
Gimp 2.10.22 (maybe a bit old, as comes with Debian stable, but searching around didn’t find any indication of this changed in newer versions)
This isn’t a Gimp issue but a GIF format issue because the spec says:
vii) Delay Time - If not 0, this field specifies the number of hundredths (1/100) of a second to wait before continuing with the processing of the Data Stream.
So the delay must be different from 0. And even a very short delay maybe too short for your favorite browser that could round that up to something bigger.
But why go through all these hoops when you can just merge the layers before exporting?
This doesn’t address your question but if you’re just interested in using GIMP for animations and not committed to using its native support for animations, this might be of interest to you, anyway. I have been working on animations using GIMP and/or ImageMagick in combination with Flowblade.
I looked at GIMP’s support for animations and they seemed rather limited to me. I may be wrong about this, but I think it only supports animated GIFs. With Flowblade, you can produce MPEG4 files, which is what I’ve been doing. It may be possible to produce other forms of output, I don’t know.
If you export your images from GIMP in PNG format and choose sequential names, e.g., drawing000.png, drawing001.png, drawing002.png, etc., then you can import them into Flowblade and then put them onto the timeline all at once with a single command.
One thing I’ve done is to use ImageMagick to convert small sets of PNGs into mp4 files that I then import into Flowblade. It doesn’t work to combine them into a longer mp4. It seems that when you do this, you can’t change the length of the clip afterwards in Flowblade, but I’m not sure if this is always the case.
It should be possible to call GIMP as a batch job for conversion and “mogrifying” instead of using ImageMagick; I just haven’t gotten around to learning how to do this.
If you’re interested, you could take a look at some of my results on my YouTube channel: https://www.youtube.com/channel/UC6iUmx-xIGXxN5_gC_Xfl7w
There is more information in some of the descriptions along with links to my source code, shell scripts, etc.
Indeed you’re wrong, other than gif, GIMP support animated webp, as well as animated MNG and if you have the GAP plugin you can even export as a video AVI format as well.
Also there is a recent feature request to add support for animated jxl
Thank you for the information. I’ll take a closer look at the documentation. However, I don’t think I will switch to a different format for my own animations.
Guess we think a bit differently here - probably indeed doing a bit unconventional stuff here.
To give an idea, I am toying with hand-drawn animation, where I draw outlines, and later fill in with colours every frame, over a background layer - so that’s 3 layers per frame: the background, the fill colours, and on top, the outlines (think old-school traditional animation with a character walking in front of a background).
Yes, the idea for the final animation when exported to GIF or other format (Laurence: including solutions you mentioned above) is to merge the layers, however while drawing the animation, it needs to be in separate layers, and of course I would prefer to check often how the animation flows. For this I found that (1ms) doing sort of okay, the flicker is annoying, but tolerable enough to see what I need to see.
So just to clarify, I would never intend to have the layer stack / frame preserved in any export format, it is there for working on the animation, only as long as it is in Gimp’s native XCF.
I thought (hoped!) that the layer name tags used for the animation filter are independent of GIF (that is, GIF just being a possible export format similar to others, expectedly losing detail compared to what can be stored in the XCF).
Whatever works for you. I find that for “flipping” drawings, I prefer to put them into PDFs. I’m also working on hand-drawn animation (and I even bought some cells and cell paint!) but I haven’t done much actual figure animation yet. You can see how I make the PDFs here: Laurence Finston's Website
With the computer-generated animations, which I make with GNU 3DLDF and MetaPost, I can have MetaPost output either EPS, PNG or SVG. For the PDFs, I export EPS, which I can include in a TeX file using the \epsffile macro from the dvips package. I run TeX to create a DVI file and dvipdfmx to convert it to PDF. Another possibility is to include PNG files in the TeX file and run pdftex to create the PDF. I’ve done this a few times but mostly use dvipdfmx. The ‘*.txt’ files linked to on my website are TeX files.
For hand-drawn drawings or animations, I can use GIMP to convert scanned images to PNG or EPS for inclusion in the TeX files.
I see - though as far as I see those are stills only moved and rotated, not fluid character movements.
For an example of what sort of complexity I am looking at, this is a retro game I did, with every visual detail wholly drawn using Gimp: Flight of a Dragon is completed!
The prototype animations there were done before any code was created - so they were done with Gimp’s basic animation support as it is. For these by their nature it is really necessary to be able to see the animation running while editing it - so it is not really an option to go through exporting it every time you want to hit “play” after tidying up a few lines.
Now I am doing more complex stuff, like old cartoons as I described above, requiring a stack of layers per frame. Maybe a bit of a stretch for Gimp, but not sure if there is any open source software where you could simultaneously draw and view the animation sequence, and Gimp is really near (I mean if I squint and just get over with that darn flicker, it is passable sort of near) to be able to do it even in this complex use-case.
Of course in the end I can merge the layer stacks and export to get the intended final animation in whatever format I like.
I see - though as far as I see those are stills only moved and rotated, not fluid character movements.
Of course, but then all animation is just stills, displayed in sequence. I don’t claim that the ones with the actual drawings are anything close to fluid animation; I’m working on that. In fact, what I was working on recently, before I got involved with some other things, was to make actual physical cut-outs using print-outs of the drawings. I plan on doing some traditional fully hand-drawn animation sometime soon, but I have a lot of other things that I’m working on.
With the computer animation, it’s not difficult to make them appear more fluid by adding more in-between frames.
GIMP is great for using layers as though they were cels, without the negative aspects of the latter, e.g., not being completely transparent. I use layers a lot, in particular in combination with masks for color replacement. I just use them for individual frames, often by compositing multiple images. I don’t use multiple layers in a single XCF file for multiple frames. I don’t think there’s anything wrong with doing that, except possibly that the files might become extremely large. I’ve found that where I’ve used JPEGs which are scans of watercolor and gouache backgrounds, e.g., in this image (with watercolors): Alhambra 207 Color Replaced Watercolor Version 2 by LaurenceFinston on DeviantArt
It’s possible Blender could be used to draw and view the result immediately (or at least quickly). I’m interested in using Blender for rendering but haven’t gotten around to looking into it seriously.
Using MetaPost and TeX to create PDFs isn’t immediate, but it’s relatively fast. They don’t cause a bottleneck in my work flow. Anyway, I’m just making suggestions in case you or anybody else is interested in trying them. My methods work for me but probably aren’t suitable for everyone.
A bit quirky, but here is what I ended up doing: Animated wobble cycle
Really the greatest hurdle for this sort of stuff was the lack of that 0ms option, in the later stages sometimes requiring me to go through manually merging up the layers just to see the animation going without flicker.
(If that wasn’t the case, I would have needed to do that only once, when finished with all the work, ready to create the master with every frame flattened to export publishable files from)
I can’t see how the above mentioned solutions would help with these types of animations involving a lot of traditional 2D image editing while having to be able to see how the animation flows by a few clicks.
Looking at Gimp-GAP that might or might not do - certainly it would be able to do it without the lack of 0ms issue, but as far as I see, for it the frames are from separate XCF files, which adds some difficulty to editing (copying around pieces between frames maintaining position, quickly switching layer visibilities to check the transition between two frames, setting a slight layer translucency to see a layer of the previous frame below, such things - doable between separate XCFs, but then that’s more tedious having to copy around and manually position things between them).
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.