GIF 2.0 is coming!
Move over, WebP; step aside, PNG; look out, VP9: a new and improved format for image sharing is coming soon: GIF 2.0 (GIF 26a, really, as that will be the new version in the header).
A consortium of geeks and old format heads seems to have taken a big sip from their "let's show the youngins how it's done" juice, and word is that a specification for a brand new GIF version is making its way to being published rather fast.
There is, however, some bad coming with the good. While there are tons of improvements and exciting new features that you can read about below, the new specification is unlikely to be backwards compatible, as key GIF concepts are fundamentally changed. This, of course, means that even if the specification is out soon, the implementation and overall adoption could take a while.
Bigger color spaces
GIFs, in the olden days, relied on color tables with a maximum of 256 entries. And while through various tricks you could end up with more colors on-screen, especially for single images, that was never a great thing. The new specifications are going to allow for 8, 16, and even 24 bits of color depth. Additionally, the transparency channel is going to be that, a full channel instead of a simple binary choice between no color or full color.
How the richer color palettes will be handled in terms of color tables seems to be not completely clear as of yet. It does seem that they will still be around, especially because a global color table is quite efficient for a longer animation than having the colors in the compressed data, but we will see.
Talking about colors, while the 26a specification is still going to deal in good old RGB(A) values, there are whispers that in the future other color spaces like the one defined via DIN 6176 might be directly supported too, or at least via Application Extensions. The Image Descriptor is getting a new entry to signal which color space is used, and that implies to me that we would be able to include images with differing color representations in the same GIF!
Better compression and security
While GIF versions 86a and 89a both use the old LZW algorithm, the new version is focusing on better and more efficient ways to compress the data. Still, only images are compressed, but with the bigger color depths supported, I would not be too surprised if color tables will also see some type of compression.
For this better compression, state-of-the-art machine learning paradigms are applied to practice; the kind of stuff people are writing their PhDs about. The short version, from what I understand, is that a so called "color confuser" gets created, a theoretical mathematical space in which the image is merely an embedding. Then this confuser gets, well, confused; for me it sounds like a locally trained artificial neural network, but I hope it becomes more clear once the specification is out.
The advantage of this approach, allegedly, is that while the encoder has to do a bit more work, the decoder is going to be as fast as lightning, allowing GIFs 26a to actually reach those 100 fps that before were only theoretically possible (most browsers could only handle 33 fps).
Another, completely new, aspect is security. GIFs wore their heart on their sleeves, so to say; everyone could easily change whatever was in them, be it metadata or even the images. Now, for most people, that is, of course, desirable. What use is an image format if the image is unwatchable? And don't worry, the new changes are not a must-have implementation but another added Application Extension that introduces Vollbit Verschlüsselung (full-bit encryption).
With this, users will be able to share sensitive pictures or NSFW animations for their Patreons and be sure that only the people who should be able to see them can do so. A security layer within an image format is, of course, not that common, and it will be interesting to see if the idea will be copied by other formats in the future.
And with all of that, thank you for reading, and I wish you a happy April 1st.