Probably my proudest work so far is the GIF editor. It actually existed before this blog and is more or less the reason I decided to put anything of mine online for public observation. It also is the culmination of my GIF obsession and the want to be able to edit every aspect of a GIF, something I found most image or video editing software lacking.

By clicking on the image below, you will be forwarded to the editor and able to change or create your own GIFs. It even comes with its own tutorial, in GIF form.

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.

After the first entry was a bit of a downer, let us have some cool GIF-related fun this time. And by fun I mean a discussion on how we can achieve a thing and the inevitable realization why it won’t work. 

As you might know, GIFs are not made for very color-rich images. This is because a singular image within a GIF can only have up to 256 individual colors, leading most programs that convert a graphic or video into a GIF to somehow reduce the number of colors in the process. But what if we want more? What if we are not content with our lot in this world and strive to defy the very machine gods some people are trying to build? Can we do it? Can we achieve a GIF that has more than 256 colors on-screen at the same time? YES, WE CAN!! But it is not a great idea.

After letting my little GIF editor rest for a while, I thought that maybe some writing about GIFs and why they are cool is in order, intermixed with maybe some retrospective posts about the editor itself. So this is hopefully the first of many GIF-related posts!

Let us start this series with a sad fact to keep the mood low enough for the current media climate: GIFs are not living up to their full potential, and you probably did not even know it. What I mean by that is that there are features in the GIF specification that are really cool and not supported by a lot of programs displaying GIFs.