It has been a long and bumpy ride, GIF initially appeared 33 years ago, and improved the next year by supporting animation. In the 90’s, GIF rocked the yet young internet, being the first image format supported by most browsers of the time.
It was extremely limited by today’s standards. It only supported 256 different colours, but you could choose those from any of the 4 billion colours supported. And until 1992, it was the only really usable image format in the internet. Not only that, but you could also do animations, small movies. Back in the early 90’s that was amazing.
Well, then JPEG and PNG appeared, and GIF was all but replaced by those superior formats. JPEG supports full 32bit color, at each of it’s pixels, and with a very respectable compression ratio, and good quality. On the other hand, PNG took care of all the lossless image use cases, again at 32bit color. Except for one thing. Still today, GIF is the most used format for small animations. You can see them on Skype, WhatsApp, Facebook, Reddit. It’s still the undisputed format for animations. And why ?
Well, for several reasons.
The actual movie formats designed over the years, MPEG-1, MPEG-2 and latter H.264, they’re all too computationally intensive to be rendered by a software decoder, by the hardware of the time. Not only that, but browsers never properly supported them in a way capable of being displayed normally. In fact, only with the appearance of the video tag, were those formats even supported.
Then, one would expect that a PNG derivative format would take over, bu then and not one but two independent formats appeared. Both MNG and APNG were designed to finally replace GIF on the role it still played. However, there’s one thing worse than having one good solution. That is having two not-so-bad solutions. The outcome? Between issues with the code size, and lack of support from some browsers, neither of those actually took off, and animated GIF continued to rule.
Enter Google
When Google bought On2 technologies, in 2009, it was because it needed to build a patent arsenal, which it eventually did successfully when it acquired Motorola Mobility. However, Google has the “nasty” habit of actually taking something from its purchases. In this case, Google continued to develop On2 video encoding technology, at the time known as VP8. Now, VP8 was never particularly successful, however its sucessor, VP9, actually reached encoding performance that … well, Google believes it was at par with the industry’s standard of the time: H.265.
Google never learned how to specify video encoding formats (but that’s for another time). What Google does better than likely everyone else is to take advantage of the immense ocean of tools, applications, services and opportunities. And an opportunity Google did see.
By 2013 Google, had enough of Apple, and decided to make its own path by creating its own browser: Chrome. So, Google got all too interested on all web technologies. Not because it wasn’t before, it just got obsessive. So Google though: if we have a very decent video encoding technology, why not use it to replace the ageing technologies of the time: GIF and JPEG?
What makes a video codec also a good image encoder? EVERYTHING!
JPEG is just slightly younger than GIF, and by 2008 it was already showing its age. By then, H.264 hardware decoding was already a common feature on media chipsets, so why not try to use H.264’s I-frames to encode single images? H.264 was an amazing technology at the time, and using I-Frames to encode still images just made sense. In fact, H.264 was between 40% and 60% more effective at compressing still images, and the we could use the hardware decoder to render high resolution still images. It was nearly perfect, except for one not so small detail: no web browser supported it. Again for a good reason: no one standardised the H.264 I-frame as a image format. As such, it was only a possibly on niche purposes, where the need for a browser wouldn’t be a requirement.
I-Frame compression is the most important task of a video encoder, as I-Frames are responsible for most of a video stream payload. So, how efficiently a codec handles those frames defines how effective a codec can be. Now, going back to Google and VP8. VP8 has very basic I-Frame encoder (compared with H.264) and, it adds a new feature: lossless encoding. So Google went to take a few extra steps:
- Define an image format based on VP8 I-Frame, and wrap it within a RIFF container
- Add support for the new image format on the most used browser, which Google controls
The outcome? Not one, but two new image formats: WebP and WebM.
WebP was designed as a JPEG drop-in replacement, as it serves exactly the same purpose. It’s implementation is almost exactly a VP8 I-Frame within a RIFF container. Adoption has however been limited, and as never been the default format for any device, smartphone, or camera. JPEG is by far not a perfect image format, but its shortcomings are not sufficient for users to replace it:
- Lack of support for alpha transparencies. However, this is not relevant for photos, so not relevant for most users.
- Ineffective compression. JPEG files are bigger than equivalent WebP files with the same quality. However, this is no longer an issue, as both internet access speeds and the additional storage space are sufficiently higher to be worth the change
- No hardware acceleration on most platforms. WebP is in fact hardware accelerated on some platforms, but again, modern CPUs are already quick enough for instantaneous decoding.
However, it’s fast replacing GIF, and together with the regular WebM format, also replacing animated GIF. Well… WebM isn’t exactly an image format, but… It replaces one. WebM is the native VP8 container which itself is based on Matroska. However, by using the tools made available by VP8, it effectively replaces animated GIF. Very effectively, as it addresses all of the GIF the shortcomings:
- Support for 32bit colour. In fact it supports up to 48bit color, and 8 bit transparency
- Extremely improved compression ratio, especially on lossless use cases
- Support for lossless animations, with alpha transparency on one single package
- Supported by most used browsers: Chrome and Firefox, Edge and Safari (starting from OSX 11), plus all the browsers from all Android derived platforms. Those browsers now exceed 97% of the user base.
Using WebP
WebP is now supported on most modern image manipulation tools, including Adobe Photoshop and GIMP, ImageMagik and GraphicsMagik, and finally, the native tools from the WebP team. However, if you’re looking for the best possible results, always choose the native tools, which ensure ultimate compression and compatibility. So, let’s just demonstrate how WebP works with the native tools
Compressing single frame lossless image
Using cwebp is mostly strait forward, especially when comprising single frame images with transparency. The relevant flags to compress single images, using lossless compression are the following:
-lossless – Sets the encoder to lossless compression. However, this doesn’t actually produces lossless images if a a transparency layer is present, unless -exact is also used
-z <0-9> – Sets the lossless compression method, from faster to slower. Always use 9 for (create once, render many) production grade assets.
-m <1-6> – Sets the lossless compression method. Overrides -z if present. Most of the time, -z 9 actives better compression performance at the expense of processing time.
Which results on the following command example:
cwebp -lossless -exact -z 4 11-2-animation-png-hd.png -o 11-2-animation-png-hd_min_exact_z4.webp
Lets take this image from freePNGImg.com as reference for comparison. This image is 1008×2066 with transparency weighting 362.470 bytes.
| WebP options | Download file | Size | Compression compared with PNG |
| WebP with z = 4 and -exact | Download | 230.012 Bytes | 63% |
| WebP with z = 6 (default) and -exact | Download | 228.764 Bytes | 63% |
| WebP with z = 9 and -exact | Download | 223.386 Bytes | 61% |
It’s as simple as this. A simple conversion between 32bit transparent PNG to an equivalent WebP file saves you between 37% and 39%. Plus, you gain hardware acceleration on some platforms. Results may vary a bit depending on the exact file used, but the trend is maintained: WebP is always superior to PNG for lossless compression.
So, this settles the conversation as far as simply, full color with transparency goes. Now, to animations.
Using WebP to replace animated GIFs
There are two different aspects we need to consider:
- Simple conversion from animated GIFs – From an 8bit palleted color scheme with 1bit transparency to an exact match file
- Conversion from uncompressed raw animation – Including full 32bit color with 8-bit transparency
Conversion from animated GIFs is as strait forward as it gets:
gif2webp -min_size -m 6 input_file.gif -o output_file.webpThere aren’t any real options here, but lets get through each of the parameters:
-min_size – Optimizes each frame in order to obtain the minimum file size. By defaults also enables lossless compression.
-m <1-6> – Sets compression complexity. 0 less effective compression and faster. 6 more effective compression and slower.
Lets then analyse the conversion results with some reference animations:
| Original File | WebP file | WebP File Size | |
| Book shelf Loader Icon by Hoang Nguyen |  2.346.580 bytes |  2.058.346 Bytes | 88% |
| Pumpum cloud By Muxxi |  2.610.318 bytes |  2.410.402 bytes | 92% |
Testing two cases is far from a representative sample. However, this does represent the best case scenario for GIFs. It’s content designed around GIF’s 256 color limitations. However, even on this best case scenario, WebP is always superior.
Then, let’s remove the shackles imposed by GIF’s limited number of colours. For this, we need original content. Not content which was previously available on animated GIFs, or by any other lossy compression method such as WebM lossy, or H.264. We need to use raw, uncompressed media. For this we used Blender’s demo content as reference, m0re specifically, Big Buck Bunny. For this analysis, a sequence of 50 frames were extracted from the uncompressed sources, and converted into respective files for each test case.
| Case | Size | Comments |
| 50 uncompressed images using PNG 256 × 144 | 2.527.890 Bytes | This is the baseline |
WebP at 32 bit color 256 × 144 | 2.028.706 Bytes | Animating the PNGs into a WebP. Compression ratio 80%. |
GIF 256 × 144 | 1.200.821 Bytes | Animating the same original sources using GIF. Image degradation is clearly visible. |
WebP palleted to 256 colors 256 × 144 | 938.070 Bytes | Limiting the sources to 256 colours and compressing with WebP. Compression ratio 78% when compared with the equivalent GIF file. |
This is the harsh reality. WebP exceeds GIF’s, and even PNG’s capabilities on all cases, and you should consider outright stop using GIF and PNG right now. Simply migrating from PNG to WebP results on a more than 25% file size savings. Using we compare a GIF file, savings might be smaller, if you don’t mind about the 256 color limit. Even in that case, you get >20% file size savings.
A praise
Don’t get me wrong. It took 33 years, millions of dollars and the push of the 5th largest company of the world for GIF to be laid to rest. This is nothing short of amazing, and Steve Wilhite should be seated besides giants of computer sciences such as Bjarne Stroustrup, Richard Stevens, Brian Kernighan, Dennis Ritchie or Jon Postel.
For the past 33 years, GIF always kept a fundamental role. From the first picture format usable on the very basic networks the internet started from, until the XXI century animations used on Facebook, Skype and all instant messaging services out there.