Lottie has come of age and hit all the mainstream UI arenas, filling end-user screens around the world daily. Yet, there are still the holdouts who prefer to use raster animation formats to deliver animations rendered from vector graphics. Some of us just cannot be convinced on the ease of integrating Lotties with websites and mobile apps, or on how every mainstream browser and mobile device now supports them.
Perhaps the only way to clear our doubts is to do a proper comparison of Lottie and raster animations. So, here goes.
A raster animation is a sequence of frames that are each composed of pixels. Each frame’s pixels have colour data associated with them. Since each frame has the same width and height, they each have the same number of pixels.
If a frame’s width was 1,000 pixels and height was 500 pixels, it would be represented by 1,500,000 bytes (1.44 MB), given the use of YUV colour system with each channel represented by 8 bits. This payload can be further reduced to 367 KB using 4:2:2 chroma subsampling. If an animation were 1 second long, at a playback speed of 30 frames per second, then the total payload would be 10.76MB. Additional reduction in size could be achieved using various prediction and compression techniques.
Let us assume that the initial frame of some animation consisted of pixels of the same colour except a white box at the bottom-left corner, which had a size of 4x2 pixels.
Let us also assume that the raster animation format we are using for this animation started with two 8-byte integers that depicted the width and height, respectively, and allowed pixels of the same colour to be ‘filled’ using a height-offset followed by a width-offset. If so, assuming always that this raster animation has 4:2:2 YUV subsampling, the first frame could be described in a payload of 136 bytes.
Now let’s say that this animation had 120 frames, playing at the speed of 30 frames per second, and that the white box starts moving along a path that starts from a point A in the 1st frame and ends at a point B in the 120th frame.
Let us now assume that our raster animation encoding format allowed us to use height and width offsets to only change the pixels that were different from the current frame to the next one. In this case, only a total of 16 pixels would change between any two frames, which are the places where the 2x4 white box existed in the current frame and where it will exist in the next frame. Hence, the payload of each frame after the first one would be 120 bytes.
Therefore, the size of this entire animation would be 14.2 KB.
If the previous animation were to be recreated in Lottie, then it would be described entirely using vectors. Lottie would use a Bezier curve to define the path that the white box would move across. This means that the path would be described simply using, the start point A, end point B, two respective tangent vectors and the frames that they fall on – point A in the 1st frame and point B in the 120th frame.
Therefore, increasing the duration of this Lottie animation beyond 120 frames will not have any bearing on the size of it. If the duration were increased to 240 frames with a playback rate of 30 frames per second, then the animation would simply look slower. If at 240 frames the rate was changed to 60 frames per second, then the animation would look smoother but play at the original speed.
When this animation is output to a Lottie using the LottieFiles After Effects Plugin, the total size is just under 1.2 KB.
So far we have only compared Lotties with a theoretical raster animation encoder of our own creation, which does not include versioning, frame sequencing and various other metadata.
A real world raster animation format that is as lightweight as our hypothetical one is Animated PNG (APNG). So, the vector animation sequence above was exported to a series of 120 PNGs using Adobe After Effects, and those were then stitched together into an APNG using PNG Animator (published by Giuseppe Cigala on Mac App Store).
To round up the comparison with existing formats, the animation was also exported as a GIF sequence and as an MPEG2 movie. Both exports were done using the default settings for the exporter. In the case of MPEG2, an additional step removed the audio channels from the movie, using ffmpeg.
The resulting payloads for the three formats were very different.
APNG comes out on top as the most lightweight animation format, with a payload of 11 KB. This is very close to the hypothetical encoder we concocted earlier in this article, whose payload was 14 KB. It means that APNG is not heavy on metadata. The additional 3 KB saved by APNG would likely come from its compression algorithm – whereas our hypothetical encoder has none.
Unlike APNG, GIF can be played from a stream. That is, the entire GIF need not be available to the player before starting playback, which is not the case in APNG. This is the reason why GIF has a much larger payload, at 142 KB.
MPEG2’s payload is even bigger, at 246 KB, which is attributable to the use of bidirectional predicted picture frames (B-frame) in this format. B-frames greatly improve reverse playback, particularly from streaming sources. Additionally, the loss of a B-frame in a cluster of contiguous frames does not hinder the prediction capability of the difference between received frames – even a heavy loss of B-frames would reduce the detail of predicted content, but would not result in dropped frames.
In the context of comparing Lottie animations with raster ones, the three key differentiators are size of payload, picture clarity (or quality) and colour accuracy.
The biggest takeaway from the above discourse is that Lottie animations are considerably smaller than raster ones. For animations that are 120 frames long, a Lottie is about a 10th of the size of the payload generated by our hypothetical raster animation encoder. As the duration or frame rate – or both – of the animation increases, the Lottie’s size remains unchanged, whilst the raster animation payload grows proportionately.
When it comes to real world examples, the best comparator to our hypothetical encoder is APNG. Its output outperforms that of our hypothetical raster animation encoder by a margin of about 20% due to the APNG’s compression algorithm. However, the APNG payload is still about 10 times bigger than Lottie.
Animated GIF and MPEG2 payloads are considerably larger, but their formats have the advantage of streaming playback. This is very important for very large content, or live streaming. Lottie’s answer to this is LottieFile’s own dotLottie, which allows the encapsulation of multiple Lotties into one source file and their sequencing. We will explore dotLottie in a later article. For now, the economy of Lottie with short animations means that streaming playback capability is irrelevant since their payloads are small enough to download in their entirety in an instant.
One of the techniques used by raster animation encoders is chroma subsampling, which reduces the size of animations, but at the cost of removing a part of the colour information of pixels. In the case of 4:2:2 YUV subsampling, 3/4th of the colour data is removed. Because of this loss, small elements like the 2x4 white box in our example will lose sharpness. Additionally, the overall colour quality would also be reduced. In the case of Lottie there are no such losses.
In the hypothetical raster animation example used above, we prescribed the YUV channels as having 8 bits per each. The colour gamut at 8-bits per channel would be very poor and perhaps even displeasing to behold. In contrast, a Lottie leverages the colour gamut of the computer system that renders it. If the system supported wide gamut colours, at 16-bits per channel, the Lottie renders would be unparalleled.
The only type of animations Lotties cannot be used for are those that are created from video captured by cameras. Such videos are real-world visuals, analogous in nature, encoded into a digital format.
However, for delivering any other type of animation content, Lotties are vastly superior to raster animations. They are smaller in size by as much as an order of magnitude compared to the most efficient animation formats. Their renders do not lose any colour information or quality. Lotties are always rendered at the best visual quality that the host computer can muster.
In fact, with the rapidly growing array of libraries and tools out there, Lottie animations are also getting ready to beat out its vector animation counterparts. But that is a discourse for another time…
For now, it is safe to conclude that Lottie is the future of animation.