Gimp is not the best tool for creating animated gifs (instead of using the 256 color limit for the frame, this applies to the entire gif).
In this case, you can support Gimp with the great capabilities of ImageMagick.

Download:
ImageMagick-7.0.9-14-Q16-x64-dll.exe
https://imagemagick.org/script/download.php#windows

This plugin is based on code (implemented) ofn-export-layers.py by Ofnuts:
https://sourceforge.net/projects/gimp-t ... s/scripts/

and information contained on:
ImageMagick Examples - Animation Basics
http://www.imagemagick.org/Usage/anim_basics/

ImageMagick is mainly used from the command line - but since python can replace it, you can try something for Gimp.

In menu Gimp: Filters->Animation->Animated gif using ImageMagick...
Tested only on Windows10 for Gimp 2.10

Quality comparison:

Does not work in Linux. It produces the PNG files, but not the GIF.

Hi Racer-X.

Thank You for testing.
Maybe it's just a matter of the characters used ( " and forward slashes \ ) - I've corrected it so that it works correctly with Ubuntu bionic 18.04 WSL for Windows10 installed (generally WSL very troublesome to use and I forgot a lot of details on how to use Linux ).
But it's still just a test for Windows - Can You try again ?


Ver 0.2
- "\" has been replaced on os.sep,
- extended function "Alpha Channel (for all layers)" : Remove, Add, Semiflaten.

I think I know where the problem (for me anyway) is. I'm running Gimp AppImage and those python directories are in mounted TMP directories when I launch Gimp. Those directories are read only.

I wonder if someone that has a normal installed Gimp can test it out? I don't have one to test.

It works Kubuntu 18.04 / Gimp 2.10.14

Surprised that the appimage does not work, not sandboxed like a flatpak.


Linux users should un-comment the registration



Just a note on ImageMagick versions. Strictly version 6 uses "convert" and version 7 uses "magick" Not sure how many linux installations have a default version 7, can not be many, but something to look out for.

Playing with this yesterday alongside command line gifsicle and gifclrmp. No good checking colormaps in Gimp. As soon as an animation is imported you lose the separate colormaps but I can check with gifclrmp and it looks pretty good. Gifsicle does produce a slightly smaller animated gif (at least it does here) which works ok. Gimp version RGB and gifsicle indexed? will have to check

Thanks for the tip rich2005. After some editing, I got it working. attached is a Linux working version.

@Racer-X.

Thank you for test and posting the Linux version and example.

@Rich2005.

Thank You for joining the test and additional information.
I have only been learning about ImageMagick for three days.
To test its capabilities, I had to try something simple at the beginning (and the plugin is based mainly on code on the proven Ofnuts code ofn-export-layers.py) - so when I "I found" pages about animation in ImageMagick - hence this plugin.
I also read about it that you should replace "convert" to "magick" but for Windows and IM 7.0.9 64bit only "convert" works (from the command line and through Python - but maybe only in this particular case - or as you wrote - that this applies to only Linux, which is also weird).

As long as it works, and your script works ok. The horrible tedious ImageMagick story is:

For Windows
convert is already a MS command for converting one file system to another so the IM people changed to using magick. Should work in a terminal like this:



For linux
IM v6 is a dependency for so many graphics applications, making IM v7 a default is a lot of work. So IM v6 remains and so does the convert command.
Have to confess, I keep a home-made IM v7 for some things, webp support for example, and using magick in your script also works.

I like the higher resolution but these are just 2 frame slideshows. They are not 'animation'.
Something like this is animation

The point is you can have more than 256 colours in a (more than a single layer) gif but not using Gimp. An animation produced by Gimp uses a common 256 (or less) colours. You often see this when joining two animations and the colours of the second are changed to match the first.

Of course each frame then has its own colormap which makes for big files. Never going to be much use for that clever 200 frame animation, but can be used for say, a changing web page banner using completely different images and yes that is a slide show.

My opinion. Going to be redundant anyway. Webp seems to be gathering traction with the backing of the evil Google. Alternatives, apng failed and does anyone use heif ? (apart from Apple users)

The problem with webp is there are no free image hosting sites that I know of that will support it natively. Otherwise I would use it.

I completely agree with the with all comments - the future belongs to the webp format but sometimes gif is the only solution.

For the test I tried two variants of use ImageMagic with the webp format:
- create gif from individual webp files - result: size larger than created from png.
- conversion of animated webp to gif - result: small file but image very deformed.


Ver 0.3 (due to lack of prospects of the "gif" format - for me the final version)
Add options: Optimize, Resize.

A little commentary on "Optimize"

The most important note: keep the original work as xcf - because the result may be unexpected.

There are various basic methods in ImageMagick of "minimizing" file size in .
Generally optimization of the gif size depends on the type of animation (Disposal Methods and transparency) and the basic methods are:

Deconstruct: find areas that has changed between images.
Given a sequence of images all the same size, replace the second and later images, with a smaller image of just the area that changed relative to the previous image.
The resulting sequence of images can be used to optimize an animation sequence, though will not work correctly for GIF animations when parts of the animation can go from opaque to transparent.

Optimize-frame: Optimize a coalesced animation, into GIF animation by reducing the number of pixels per frame as much as possible by attempting to pick the best layer disposal method to use, while ensuring the result will continue to animate properly.
There is no guarantee that the best optimization is found. But then no reasonably fast GIF optimization algorithm can do this. However this does seem to do better than most other GIF frame optimizers seen.

Optimize-plus: As 'optimize-frame' but attempt to improve the overall optimization by adding extra frames to the animation, without changing the final look or timing of the animation. The frames are added to attempt to separate the clearing of pixels from the overlaying of new additional pixels from one animation frame to the next.
If this does not improve the optimization (for the next frame only), it will fall back to the results of the previous normal 'optimize-frame' technique.
There is the possibility that the change in the disposal style will result in a worsening in the optimization of later frames, though this is unlikely.
In other words there no guarantee that it is better than the normal 'optimize-frame' technique.
For some animations however you can get a vast improvement in the final animation size.

Optimize-transparency: Given a GIF animation, replace any pixel in the sub-frame overlay images with transparency, if it does not change the resulting animation by more than the current -fuzz factor.
This should allow a existing frame optimized GIF animation to compress into a smaller file size due to larger areas of one (transparent) color rather than a pattern of multiple colors repeating the current disposed image of the last frame.

Ver. 0.3 works well I think. The optimization gives a well needed reduction in file size. The banding you see in the second image is due to re-importing the gif back into Gimp to change the delay for the 1st and last frames. The banding wasn't there before that. I used Optimize-Plus, though I didn't notice a difference with the other optimizing choices on this test example.

I was thinking about treating the first and last frames separately (in IM this is possible).
However, a simpler solution is to duplicate selected layers.
Optimize-plus will merge them into one frame and the times will sum up (so you can set the time of each frame - by multiples).

Yes, I see what you mean about "Optimize-Plus" combining duplicate frames.

Hi racer, test2 is very impressive in terms of resolution to file size.
Good work MareroQ