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.

A feature I thought would be cool for my GIF editor at some point was the possibility to directly draw on the images. Changing the contents of an image within a GIF is one of those things that normally is a bit of a hassle and comes with problems, as we will see in a bit. Of course, being able to change the images on a pixel level calls for a way to get the image data out of the GIF and, after changing it, putting it back. This decompression and compression I already had implemented at some point, and my last post was a rather long explanation of how the LZW algorithm on which these procedures are based works.

A milestone in my GIF editor, and something I first had left as a problem for future me, was the compression and decompression of images. Because of the way that GIFs work, a lot of information is easily manipulable; changing colors or reordering images in general was not a hard thing, so I simply saw no need to actually implement the LZW algorithm that GIFs use early on. But eventually the need to display images and also me wanting to actually change colors of specific pixels was there, and so I had to read and understand how one of the more important parts of GIFs works.