GIF (It’s Pronounced “GIF”)

When it comes to image formats on the Web, the Graphic Interchange Format (GIF) may no longer be the king of the castle, but it certainly is its oldest resident. Originally created in 1987 by CompuServe, the GIF image format was one of the first portable, nonproprietary image formats. This gave it a distinct advantage over the many proprietary, platform-specific image formats when it came to gaining support and adoption on first Usenet, then the World Wide Web.

The GIF format was established at a time of very limited networks and computing power, and many of the decisions about how to structure the format reflect this. Unfortunately, as we’ll see, this limits its ability both to portray rich imagery as well as to compress.

47 49 46 38 39 61

47 49 46 38 37 61

Animation

Animated GIFs are everywhere on the Web today. Thanks to social media, they’ve seen a resurgence in popularity. It makes good sense, too: they’re pretty easy to make and because they’re GIF files, they work in every major browser without any need for additional development work.

Animation was built into the GIF89a file format. The way it works is that each frame of the animation is a separate image, stored within the file. A series of extension blocks are used to tell decoders how to transition between these images.

The application extension block is used to indicate how many times the animation should loop. Immediately following the application extension block, you’ll find a graphic-control extension, which provides information about how the file should move between the different images (or frames) in the file and how long the delay should be.

While the portability and broad support of the format may seem appealing, there are much better options.

Remember: the GIF format is showing its age. It has a limited color palette that makes it poorly equipped to show detailed images, and it was formalized before incredibly useful compression techniques, such as chroma subsampling (which you’ll learn about in Chapter 4) or specific compression techniques targeted at video data.

With every frame of the animation requiring another image to be stored inside the GIF file, and with the format itself lacking many of these advanced compressed techniques, animated GIFs very quickly become frighteningly heavy and bloated.

An increasingly popular (and more bandwidth friendly) alternative is to use a video instead—something like the MP4 format. Much like image formats have specific compression steps built in that are tailored for compressing image data, video formats have additional compression techniques available that are tailored for compressing video. As a result, using an MP4 can significantly reduce the size of the file.

Consider the image of Eadweard Muybridge’s famous “The Horse in Motion” in Figure 3-1. Sadly, you’ll have to take our word that it’s an animated GIF. Just squint and use your imagination to pretend the horse is galloping.

Figure 3-1. An animated GIF of “The Horse in Motion”

The animated GIF contains 15 frames—which means there are actually 15 images bundled up in this file. Compressed, it weighs in at a whopping 568 KB.

We can use the open source tool FFmpeg to convert the GIF to an MP4 file (Example 3-1).

fffmpeg -f gif -i horse.gif horse.mp4

The resulting MP4 is only 76 KB—around 14% of the size of the GIF itself. Not bad for a one-line command.

You can now use the <video> element to include your new, bandwidth-friendly animation (Example 3-2).

<video autoplay loop>
	<source src="horse.mp4" type="video/mp4" />
</video>

Transparency with GIF

The GIF format also allows for transparency. Just as with animation, transparency support is indicated within a graphic control extension block, this time using a transparency color flag that is either set to “0” if there is no transparency in the file, or “1” if we would like the image to have a transparent component.

In Chapter 2, you learned that transparency can be handled using an alpha channel—an additional byte of information for each color indicating the level of transparency. The GIF format, however, takes a different approach.

In GIF images, we accomplish transparency by signifying that one color in the palette should be treated as transparent. For example, we may indicate that any white pixels should be transparent. This has the advantage of not requiring nearly as much additional data as having a full-blown alpha channel, but it also brings a significant limitation. Having a single color represent a transparent pixel removes any ability for partial transparency: it’s all or nothing. As a result, transparency in GIFs frequently looks very jagged and low resolution.

LZW, or the Rise and Fall of the GIF

The GIF format boasted a lossless compression algorithm known as Lempel-Ziv-Welch, or more commonly, LZW. This algorithm allowed GIF to improve compression significantly over other lossless formats of the time, while maintaining similar compression and decompression times. This file savings, paired with GIF’s interlace option, which allowed a rough version of an image to be displayed before the full image had been transmitted, made GIF a perfect fit for the limited networks and hardware of the Web’s early days.

Unfortunately, the same compression algorithm that made it such a great format for the Web also directly led to GIF’s fall from grace. As it turns out, the algorithm had been patented by Unisys. In December 1994, Unisys and CompuServe announced that developers of GIF-based software (e.g., compression tools) would be required to pay licensing fees. As you might imagine, this didn’t sit well with developers and the community at large.

There were many repercussions of this announcement, but none more notable than the creation of the PNG image format in early 1995.

The PNG File Format

Depending on who you ask, PNG either stands for Portable Network Graphics or, as a bit of recursive humor, PNG not GIF (we programmers have a very finely tuned sense of humor). The PNG format was the community’s response to the licensing issues that arose around GIF.

The early goal of creating the format was pretty straightforward: create an open alternative to GIF to avoid all the licensing fees. It didn’t take long for everyone involved to realize that they wouldn’t be able to do this and maintain backward compatibility in any way. While everyone loves a seamless fallback, the advantage was that this meant the folks creating the PNG format could be more ambitious in their aims—if they weren’t going to be able to maintain backward compatibility, why not make PNG better in every possible way? For the most part, it would seem, they succeeded.

Understanding the Mechanics of the PNG Format

PNGs are composed of a PNG signature followed by some number of chunks.

1 2 3 4 5 6 7

1 1 1 1 1 1 1

Interlacing

Both GIFs and PNGs have an interlacing feature that, similar to the progressive JPEG feature you’ll learn about in the next chapter, enables an image to be rendered quickly as a low-resolution version, and then be progressively filled in at each successive pass. This interlacing approach allows the browser to give the user some sense of the makeup of the image earlier than the typical top-down approach to image rendering.

The GIF approach to interlacing is a one-dimensional scheme; that is, the interlacing is based on horizontal values only, focusing on a single row at a time. GIF’s approach to interlacing has four passes. First, every eighth row is displayed. Then, every eighth row is displayed again—this time offset by four rows from the first pass. For example, in an image composed of eight rows of pixels, pass one would display row one and pass two would display row five.

The third pass displays every fourth row, offset by two rows from the top. So in our 8-px by 8-px example, pass three would fill in the third and seventh rows. The fourth and final pass displays every other row. You can see how each row of an image is displayed using GIF interlacing in Figure 3-2.

Figure 3-2. How rows of an image are displayed using GIF interlacing

In contrast, PNG’s interlacing method is a two-dimensional scheme. Instead of analyzing a single row at a time, PNG’s interlacing method involves looking at the individual pixels within the row.

The first pass involves filling in every eighth pixel—both horizontally and vertically. The second pass fills in every eighth pixel (again horizontally and vertically) but with an offset of four pixels to the right. So given an image eight pixels wide and eight pixels high, pass one would fill in the first pixel in the first row, and pass two would fill in the fifth pixel on the first row.

The third pass fills in the pixels that are four rows below the pixels filled in by the first two passes. Using the same 8×8-pixel image, pass three would fill in the first pixel on row five as well as the fifth pixel on row five.

The fourth pass displays the pixels that are offset by two columns to the right of the first four pixels, and the fifth pass fills in the pixels that fall two rows below each of the prior displayed pixels.

Pass six fills in all remaining pixels on the odd rows, and the seventh and final pass fills in all pixels on the even rows.

That’s a lot of numbers, and is quite possibly as clear as mud at this point. For those more visually minded, Figure 3-3 shows which pixels are filled in for each pass.

Figure 3-3. A visual of which pixels are filled in per pass

While the PNG method of interlacing involves more passes, if you were to assume the same network conditions and compression levels, an interlaced PNG image would be on pass four by the time the GIF image had completed its first pass. Why? Because the first pass of GIF interlacing involves 1/8 of the data of the GIF image itself (1 in every 8 rows), whereas the first pass of PNG interlacing involves only 1/64 of the data (1 pixel in every 64 pixels—8 pixels horizontally multipled by 8 pixels vertically). The impact is particularly noticeable on any images with text, as the text becomes readable much more quickly using the PNG approach to interlacing.

Progressive loading, higher fidelity much earlier than the GIF counterpart—PNG interlacing sounds great, right? Unfortunately, it’s not all sunshine and roses. The consequence of PNG’s approach to interlacing is that it can dramatically increase the file size because of its negative impact on compression.

Remember all those filters we talked about? Because each pass in the PNG interlacing process has different widths, it’s far simpler to treat each pass as a completely separate image for filtering. The consequence is that the filtering process has less data to work with, making compression less effective. On top of that, the benefits of progressively loading images have been debated with no definitive conclusion. When you combine the severe reduction in compression with the questionable value of interlacing in the first place, PNG interlacing starts to make a lot less sense. Typically, you’re better off ignoring interlacing on both PNGs and GIFs altogether.

Image Formats

PNG images can be saved in five different formats: indexed, grayscale, grayscale plus alpha, truecolor, and truecolor plus alpha.

The difference is in how many bytes are needed to describe each pixel’s color and, optionally, transparency.

Indexed PNGs use a palette to list all the colors included in the image. These palette-based PNGs are commonly grouped together as PNG8, which is technically short for 8-bit PNGs. Somewhat confusingly, that doesn’t necessarily mean that each pixel value is actually 8 bits deep. You can actually have 1-, 2-, and 4-bit pixels as well. Each just means you have potentially smaller color tables. For example, an 8-bit PNG can support 256 colors, while a 2-bit PNG can only support up to 4 colors.

Grayscale PNGs are similar in that they use a palette, but they also add support for 16-bit pixels for highly detailed grayscale-based imagery (think things like medical imagery).

Truecolor PNGs are what are referred to when you hear about PNG-24s, and they do not use a palette at all. Instead of referring to a palette table, each pixel directly specifies a color using the RGB format. This provides the ability for PNG-24s to cover the full color spectrum (hence “truecolor”), but is also the reason why PNG-24s are much heavier than their 8-bit counterparts.

Transparency with PNG

Like the GIF format, PNGs support transparency. The PNG format, however, is much more powerful and flexible in its support.

If you recall, we accomplish transparency in GIFs by specifying an individual color in the color table to be displayed as transparent—it’s entirely binary, leaving room for partial transparency.

On the other hand, PNG support for transparency takes a few different flavors.

For palette-based images, we handle transparency by adding one or more entries of alpha information to the tRNS chunk. Truecolor and grayscale images can also use the tRNS chunk, but only to define a single value as transparent. Because we’re referring to specific entries in the palette table, you don’t have the ability to make, say, two different white pixels in your image display with two different alpha values.

If you want more flexibility and access to partial transparency, the truecolor and grayscale formats also allow for the addition of an alpha channel—each pixel now receiving its own alpha value. This is much more costly than the indexed approach to transparency, as we’re not adding merely a table, but a full channel of information to every single pixel.

Knowing this, as well as the golden rule of image compression (the more similar colors, the better), we can take a few steps to ensure that our transparent PNGs are as light as possible.

As we just discussed, if you’re using a truecolor PNG and making a large number of those pixels fully transparent, that alpha value is added to each individual pixel. But what about all the RGB data? That doesn’t go away. Even if we marked those pixels as fully transparent so that they will not display, there may still be dozens and dozens of unique RGB data values associated with them.

To maximize compression, we can use an image editor to convert all of those fully transparent pixels to be the same color—red, for example. Now, when we make them fully transparent, their full RGBA values will be identical and PNG’s compression algorithms will happily gobble up all that unnecessary data, leaving us with a much smaller file size.

There Can Be Only One!

So given all the preceding information, here’s the ultimate question: when do you use a GIF and when do you use a PNG? The answer is to favor PNGs for all except the smallest of images. Likewise, if you want to use animation at all, GIF is the way to go (though as we’ve seen above, you could argue MP4s are even better).

Basically, while the GIF format helped pave the way for formats like PNG, its time has come and gone. If you are ever considering putting a GIF in a page, take a step back and consider if another alternative would work better.

Summary

In this chapter we looked at the two most popular and widely supported lossless image formats on the Web, GIFs and PNGs. We looked at how each format is encoded and compressed, as well as what tweaks we can make to maximize those savings. Now that you know all about lossless formats, not only can you impress your friends with your in-depth knowledge of filtering and compression algorithms, but you can also start to save precious bytes with every image you produce.

In the next chapter, we’ll dig into JPEGs—the Web’s favorite lossy image format—and learn how to optimize them as much as possible.