→ Version en français ici
Table of Content
* A good workflow
* Publication on the web (SVG)
* Telegram Bot
[rlottie C++ library, as well as WASM version, that allow to play them and has binding for several programming languages. Qt has an included Lottie reader, and there are several tools to create them.]
The multiplatofmr free software Glaxnimate allow to make them with a Graphical User Interface, familiar with people creating animation on computers. His main author also made a Python library, python-lottie (AUR: python-lottie-git, pip: Lottie), that allow procedural generation of them. Both alow to convert them to several formats (export animated SVG, Lottie JSON, HTML page all ready, Telegram, mpeg4, PNG, wepb, gif, and I probably forgot some other), and as input to vectorize animated gif, etc… The 2D vector animation Synfig also have a Lottie exporter, but also Blender3D, a plugin made by Glaxnimate author (distributed with python-lottie) for this last one. There are so several choices to create them.
Glaxnimate allow to easily create animations in Lottie format, including .TGS, a version with more limited specifications and gzip compressed for Telegram. This format is more compact but has some constraints, that didn’t stop some artists to make very great artworks since 2 years:
* 512×512 pixels
* 3 secondes
* 64 KB by animated sticker..
* Animated stickers can be grouped in a sticker pack corresponding to several expressions (like emoticons/emoji).
Why for 512×512 pixels with a vector format? Telegram client application render the animation in this dimension. This dimension is already big for some mobile screens. This vector format allow to reduce bandwidth usage and to have a high quality animation (generaly computed by the GPU, SVG accelerators was already in Nokia and Symbian made phones in 2000s). WeChat/微信 choose animated GIF about one decade ago. GIF are probably converted in MPEG nowaday? The instant messaging Discord, populare in Far West, also use the Lottie format since Jully 2021, following Telegram after 2 years.
As a refecence, top of this page animation is:
* 1109 bytes (1,1 KB) in TGS (binary compressed Telegram format)
* 4682 bytes (4.5 KB) in JSON uglified (no more indentation, or carriage return)
* 508054 bytes (500 KB) in WebP
* 9710 bytes (9.6 KB) in animated SVG (there was an useless animated path, I don’t know why for).
* 1804 bytes (1.7 KB) in ainmated SVGZ (gzip compressed SVG). It is more interesting today to let the server compress using Brotli format (Nginx, Apache) or to precompress them (.br). It is really well supported by web browsers
* 6114 bytes (6.1 KB) in SVG, Inkscape optimised compressed (based on Scour)), it’s possible to reduce size more. Today if the option to reduce digits after comma (floats) is less than 3, it will be still kept at 3 digits. In animation parts still not managed there are six 0 (1.000000 or 0.000000 for example). It is still possible to optimize by hand until thes options are added (See sed usage, below), so :
* 5827 bytes (5.8 KB) in SVG, a bit hand finished.
* 5559 bytes (5.5 KB) by removing some useless intermediate groups (warning to don’t break all, try group by group) and replacing numbers like 1.0 by 1
One of the main problems of optimized SVG output from Glaxnimate is that Lottie heavily use groups, where SVG allow to made most of these operation in the objects themselves. So transformation matrix are all in groups containing the objects, instead of in objects themselves. you can see at right the XML source inf Inkscape. This still ask lot of handcrafted work on files nowaday. It should be possible to improve it.
It looks like there are more efficient methods withSVGO, but based on Node.js, and it breaks animations, some of its optimisation methods could be used in python one. I don’t like Node at all due to bad habits of lot of devs around Node. The Inkscape plugin, “inkscape-svgo” is still in this spirit, if we try to compile it with included Makefile, it doesn’t test if Nodes modules are already installed but forcee download Node JS version 11 (and x86_64 only, so not multi-architecture), and recompile all the dependenccies. So one more time with Node, we wast lot of earth limited resources, wit an extention of tens of Megabytes (75 MB, where Inkscape is 145 MB and the Node SVGO library itself is only 5 MB), where it should only be few KB.
Continue reading →