<!-- Guides & Articles

Image File Formats

If you're deploying images on the web, as part of designing for the web, there are quite a few considerations that relate the Image File Formats. Just knowing, vaguely, that line-art should be saved as PNG or GIF, while photographs should be saved as JPEGs, doesn't cover nearly as much as what one needs to know in order to effectively make choices concerning the various options that the different image formats, and the different compression methods, provide. This document attempts to cover the more important, implementation-specific points that relate to making these choices.

The File Formats

There are three major bitmap image formats in use on the web today: PNG, JPEG, and GIF. I'll start by covering the PNG and GIF file formats, since they share many properties, and are completely different than the JPEG file format.
When you save an image, the PNG and GIF file formats encode the information so that individual pixels keep their exact value. If the pixel at X by Y has the value of #FFCC00, then the image will save that exact value when you save the images to a file.
Allow me to clarify something at this point: When you save an image to a file in whichever image editor that you're using, it (the editor) may take steps to prepare the image for saving to the file. These steps may involve changing the values of colors around the bitmap to serve a certain purpose (reduce the amount of colors used in the image, for example, in order to reduce the image file size). The change in color values in this case would be the result of these steps, not any particular restriction on the part of the image formats (I'll get into the GIF color-count limit in a moment). This means that you should be able to be more specific when you're saving the image, telling your image editor exactly what steps to take so that you get what you want, and not the default behaviour. I'll elaborate on the different encoding methods of the PNG and GIF formats so that you know what to look for.

The properties I describe below apply only to the PNG and GIF file formats. The JPEG file format is covered separately later in the document.

Saving a Palette-Based Image

The PNG file format supports both true-color (24 Bits per pixel, and 32 Bits per pixel with alpha channel) and palette-based image data encoding. The GIF file format only supports palette-based image data encoding.
A palette-based system is a method of saving the image color information separately from the pixel location information within the image file. Instead of each pixel location containing the bits needed to describe the color in one color depth or another, all of the colors within the image are placed into a look-up table beforehand, and each is given a specific 'reference number'. When the image is saved to the file, each pixel location contains a reference number that refers the drawing mechanism to the corresponding color value on the color lookup table.
So, for example, if there are 256 colors in an image, then there are 256 reference numbers on a 256-color palette. This is convenient, because you can define a number between 1 to 256 (actually, it's between 0 and 255) using one byte. This means that while it would take you three bytes to describe one 24-bit color, it would only take you one byte to place a color reference in each pixel location. This greatly reduces the size of the image, and the less colors there are, the smaller the image will be. Actually, to be perfectly accurate, you would need to drop one bit from the color reference's size in order to reduce the image size by a predictable amount: 256 colors can be defined by eight bits, while 128 can be defined by 7 bits. This keeps shrinking as you devide the amount of colors by 2 each time: You need 6 bits for 64 colors, 5 bits for 32 colors, 4 bits for 16 colors, 3 for 8 colors, and 2 for 4 colors. You only need one bit-per-pixel to describe a black-and-while image: with black being 0, and 1 being white.

Keep in mind that the color table also takes up space, so less colors in general means a smaller image. Here are three images, each reduced to a different color count, with their file size indicated:

16-Color Image
Size: 2,791 Bytes
64-Color Image
Size: 3,643 Bytes
256-Color Image
Size: 5,179 Bytes
The 16-color image is almost half the size of the 256-color image, but it's also a very noticeable compromize in terms of quality. The 64-color image is a relatively good place in between, if there are many images on the page and/or there's a strict bandwidth limitation. Otherwise, in this particular case, most designers would probably choose the 256-color image, considering it's not that far, in terms of file size, from the 64-color image.
This is case-specific, however. I chose an image where it would be very obvious where the lack of color depth would take its tole, but in line-art images, charts, graphs, etc., the difference in file size would be much greater. Also, the larger the image area (its X by Y dimentions), the more pronounced the size difference will become when saving it using a color palette.

Then there are the palettes themselves. As mentioned, they're color tables that associate the reference numbers with the actual color values. Here are the three images with their corresponding color palettes:


16-Color Palette
64-Color Palette
256-Color Palette

Palette-Based Vs. True-Color

So far, the images shown were PNG files, but you could achieve the result in either the PNG or the GIF file format. Now I'll show an example of something that the GIF file format is not capable of doing: Displaying an image in full, 24-bit true-color. In this case, each pixel stores three bytes of information, and there's no limit to the amount of colors that the image can store (actually, there is, but it's over 16 million colors, and for the purpose of displaying images on the web, that's practically all you'll ever need, even though you could technically opt to store 48-Bits per-pixel, if you chose to do so). As previously mentioned, PNG images store exact information, and, when saving true-color images, you're not losing any information at all -- you're keeping all of the image's original detail.
This kind of fidelity comes at a price, however. Here's an example of two 200-by-200 pixel images. The first is saved in true-color, and the second it saved using a 256-color palette. Notice the differences in file sizes, color-counts, and image qualities:


True-Color: 16,781-Color Image
File size: 47,497 Bytes.
Palette-Based: 256-Color Image
File size: 14,302 Bytes.
There's something you can tell right off the bat: No matter how clean and pretty the 24-Bits of color look like, ~47KB for 200-by-200 pixels will warrent serious considerations for an image that will consistently be displayed on a page's design, unless you're certain that bandwidth will not be of any concern to you or your viewers. Unless that image makes up the page's figurehead, and/or it will be displayed repeatedly, as-is, throughout the entire site (so that you know it will be cached on the user end), images of this file size, of this resolution, aren't optimal for the web. If that was a scenery photo of around 800-by-600 pixels, it would easily take up a MegaByte. This is where the JPEG file format comes in, but we're not done covering the PNG and GIF formats, so it'll have to wait a bit.
This also shows how much a palette-based image can cut down the size of the image. It's no coincidence that it's about one third of the size: The palette-based image stores one byte-per-pixel, instead of three. In only has to store the color table, containing the exact color deinintions, once for the entire image.

Granted, for this type of image, palette-based not ideal. However, if the 'color distribution' was more around one channel of color around the image (for example, a green/brown nature scene), you could have wound up with around the same color reduction (maybe even more), but the end result would be much less noticeable in terms of 'loss of quality'. This is one of many considerations you should make when saving an image. It's not just which file format to use -- it's how to prepare the image beforehand, and which format settings to used.

Transparency

When you save either a PNG or a GIF using a palette, you may opt to select one color which will act as the transparent color. This will not change the file size of the image (ok, maybe by a few bytes), since there won't be any extra colors added. You're simply indicating, within the image file information, that one color within the color table should act as the transparent color.

Here are a couple of images; both are exactly the same, with the exception that the right one has an indicator on its color table telling it that one of its colors (the green hue) should be transparent:


Palette-Based: 256-Color Image
File size: 6,429 Bytes.
Transparent color indicated.
Palette-Based: 256-Color Image
File size: 6,416 Bytes.
No transparent color indicated.
Anything 'behind' the image with the transparent color will show through the transparent color. This includes background colors behind the image, background images behind the image, even other images, if the IMG is absolutely positioned. This implementation of transparensy is actually more inclusive within the browser than you might imagine: Stacked images, each with their own transparent color will keep showing through their transparent color until an opaque color is reached. You could have several different images, all absolutely positioned, one on top of the other, with different z-indexes, and they will seem like pieces of paper with cut-outs that are overlapping in just the parts you'd expect them to physically. This can be very advantageous in reaching varied effects in the design process.

To be clear, the transparent indicator, within the image file, is nothing but a 'tag' within the file's color table area. It's up to the renderer of the image (in this case, the browser) to interpret that as the color that should not be 'filled', but rather should be 'seen through'.

Translucency

Translucency is the property in physical objects which allows for some, but not all, light to pass through the object. In the physical world, a truely transparent material has yet to be found, and technically we only consider 'space' to be transparent (because even air isn't completely transparent, nor are any of the individual gasses that it's made up of). But then, this isn't the physical world, it's the digital world, where everything is absolute. When referring to transparent areas of an image in the paragraphs above, these areas were absolutely transparent -- it's as if they did not exist visually.

It's also possible, using various methods, to define to the browser's renderer a translucent area, where only some of the color behind it will show through. One of these methods is using a PNG image, which is saved using 32-Bits per-pixel.

Allow me to elaborate on the amount of bits which define a pixel. There are eight Bits in a single Byte, and I had mentioned earlier that three Bytes were enough to define True Color, which is 16,777,216 possible hues. This is something you're already familiar with from Web design: When dealing with colors, you're often defining colors as hexadecimal numbers, like: #FFCC00. This is just such a 24-Bit color definition -- the first two digits (A though F are considered digits when dealing with hex codes) make up the first byte, which represents the Red channel. The second two digits represent the Green channel, and the third represents the Blue channel. If the number FF in hexidecimal is equal to 256 in decimal, then FFFFFF would be equal to 256*256*256, which is equal to 16,777,216.

Why, then, would we save an image using 32-Bits per-pixel? Because we're adding a fourth channel: The Alpha Channel. This fourth channel is independant from the color channels, it does not effect the hue of the color. When you save an image in 32-Bits, you're still 'only' getting the 16+ million colors you'd get if you had saved it using 24-Bits per-pixel.
What you're getting in return for this added byte of data is the ability to 'tell' the renderer of the image (again, in this case, the browser), in what intensity you're like the pixel to be drawn. This is the level of translucency of the pixel. The range is, as you can deduce from it being a single byte: From 0 to 255, where 0 means completely transparent, and 255 means completely opaque.

At this point I should give an example of what this means in practice. The following two images are exactly the same (they're the same exact file). One was placed on a white background, and the second was placed on a blue background. Here's how they appear in the browser:


32-Bit Per Pixel
File size: 23,269 Bytes.
32-Bit Per Pixel
File size: 23,269 Bytes.
Disregard for a moment the fact that the file sizes are extremely large, I intentionally picked images that would accentuate the effect of the alpha channel. As you can see, the shadow of the object completely adpated to the background. There's both a perspective shadow, and a shifted one, and both of them are blurred. Still, the shadows adapted dynamically to their backgrounds. The importance of this feature is impossible to overstate from a design perspective.

There's a lot more you can achieve with some creative implementation. Just placing a background-image behind the image with the Alpha Channel will yield some remarkable effects:


This is just the tip of the iceberg. Just like with transparent images you can overlay several images one on top of the other, and each of their respective translucencies will be taken into account. I have to keep the implementation examples on this page to a certain limit (it's already a massive page in terms of download size), but I'll cover more of these techniques in the CSS section.

Choosing Between PNG and GIF

As you've seen from the examples given so far, the PNG file format is superior in virtually every way to the GIF file format. It allows you to save images in 24-Bits per-pixel, 32-Bits per-pixel, Palette mode, single-color transparency, and 8-Bit Alpha Channel translucency. The PNG's compression scheme will even compress images to smaller file sizes than GIF's compression algorithm.
There is one feature that the GIF file format provides which PNG is incapable of: Animation. The GIF file format supports an animation mode, in which it can store multiple 'frames' within a single image, and even compress these frames so that the file itself does not contain too much redundant information about sequential frames. Animated GIFs are not covered here, because they are gradually being phased out in terms of circulation, and their importance in light of other technologies is diminishing.
In any other case other than short animations, the PNG file format is the better choice of image format for the aforementioned types of images. The only thing to consider when implementing PNG images is that 32-Bit PNG images which use the Alpha Channel will not correctly display in Internet Explorer 6 if they are placed 'normally' -- which is to say that they will appear as non-translucent images. This is something that must be considered when implementing a design, and there are work-arounds to this which involve scripting. However, keeping in mind that there are solutions to this problem, and that it only effects the images which implement the Alpha Channel, it again leads to the PNG file format being the preferred image file format.
In essence, this leaves two image formats which should cover your bitmap image needs for the web: PNG, and JPEG. Hence, here come the JPEGs...

The JPEG File Format

The JPEG image file format is designed to compress/store photographic images, or images with photographic characteristics, such as textures. The method in which the JPEG image format encodes images is completely different from how the PNG image format encodes images. Where PNGs (and GIFs) store individual pixels at individual locations on an X by Y matrix (or, more accurately, they decompress to this result), the JPEG image format stores an approximation of the original image. When you save a JPEG image file, it will always be a lossy procedure: that is to say, data will always be modified/lost in the process, and there will be no way to reverse that process, and retrieve that data, if you only have the JPEG image result to work with. This is why it's important, even if the original image was already a JPEG, to always make sure that you have a copy of the original image, because concurrent compressions will lead to cumulative loss of data.

The JPEG image format was, and still is, an amazing method of compression. If you were to take a photograph, in its absolute form, where every pixel was stored using 24-Bits of data, and then encoded that image using an average compression ratio of the JPEG file format, it's not rare to find that an image 1/20th of the original file size is almost indistinguishable from the original, as far as the human eye is concerned.
The JPEG image format saves images (or rather, compresses the information in such a way) in 24-Bits per-pixel. It would be more accurate to say that the images display in 24-Bits per pixel, because the exact color data is not preserved, it is approximated as part of the compression scheme.
Before I go into the compression options (or rather, as you'll see, option), I'll first give a single example of how effectively the JPEG image format can compress visual information:


PNG image file
File size: 47,497 Bytes.
JPEG image file
File size: 6,889 Bytes.
In exchange for a few position-specific distortions, also known as artifacts (more on this later), a true-color image was reduced to 1/7th of its original file size. Amazingly, this isn't an ideal image for compressing using the JPEG image format, since while it contains a high color count, across a wide area of the spectrum, it also contains sharp, graphic edges, and smooth surfaces.

Method of Compression

The JPEG image file format was designed specifically for the human eye. This may sound implied, since, after all, it's humans that are going to be viewing these images when they're displayed, but there are many other considerations. The TIFF image file format, for example, is designed to be extensible and allow various types of different image information to be stored in a single file, for example. On the other hand, while TIFF will employ some compression, it is definitely not one of its strong points.
The JPEG image file format, on the other hand, considers various elements of human visual perception when encoding an image. One of these considerations is that the human eye is more sensitive to variations in brightness (the intensity of light) than variations in color (which spans of the wavelength are being sensed by the eye), so the image format devides the brightness component from the color component when storing the image, and gives more 'weight' to the brightness element, while approximating the color elements so that they take up less space.
In fact, most JPEG images do not store color data using the Red/Green/Blue "color space" that most computer-related devices use. Instead, it stores the data using a color space called Y/Cb/Cr, which devides the components that define the image into Brightness (Y), Blue (Cb), and Red (Cr). The Cb and Cr components represent the Chrominance, and are close to each end of the visible spectrum. This is somewhat of a technical aspect, in terms of how these elements can be turned to and from the Red/Green/Blue color space, but suffice it to say that it is one of the methods used to conserve storage space in the JPEG file format.

Another element which is taken advantage of, in terms of how humans process visual information, is that we're much more aware of detail of edges than we are of broader, more gradual changes in surface-related color and/or texture variance. That is, after all, how we distinguish objects that we see, and how we perceive most of our spacial information. Think about cartoons: they're drastically different than anything we're used to seeing in real life, but we easily understand what the intent of the imagery is. The fact that a part of a surface that's closer to a light source should be brighter is relevant, but much less so than where that surface's boundaries are. This, again, it taken into account when compressing the image. It's referred to, within the specification, as "Block Splitting": the image is 'sliced' into 8-by-8 pixel blocks, and each block is compressed relative to the type of brightness change/variation information that it stored within it. Large surfaces with mild changes will not take up much space, since they'll be approximated into more 'generic' representations, whereas areas with a lot of edge detail, where the contrast between short distances is high, will be given more 'attention'.
One of the downsides of this particular element of the compression method are the Visual Artifacts that are created around edges, and that are more pronounced the more the image is compressed. This is the particular reason why images like line art, clean typography, solid surfaces with distinct edges, and other 'artificial-looking' images are better stored using the PNG image file format.

Level of Compression

There are several options that may be adjusted when saving a JPEG file, however the most important one is the Compression Ratio. This is a number between 1 to 100 which indicates to the compression algorithm how agressively to apply the methods of approximation and space-saving described above. There is some confusion at times when referring to the compression ratio, vs. the level or intensity of compression. There actually need not be: The compression ratio is the scale from 1 to 100 that represents the quality of the image, which means that the quality (sometimes referred to as Q in the context of the JPEG image format) of the image is highest and the compression is lowest at 1 (Q=1). On the other hand, the level of compression is simply a scale which is the opposite of the quality scale: A level of compression of 1 means, predictably, that the quality of the image is highest.
Most often, when saving an image in a software application, it will ask for the compression level, which means at what intensity to compress the image. The higher the value, the smaller the image file size, and the lower the quality of the image.

The image that was displayed above, next to the PNG image, was compressed at a level of 20. to give you an idea of how other levels of compression apply to the same image, here it is in other levels of compression:


JPEG image file
Compression: 5
File size: 15,574 Bytes.
JPEG image file
Compression: 20
File size: 6,889 Bytes.
JPEG image file
Compression: 30
File size: 4,708 Bytes.
JPEG image file
Compression: 40
File size: 3,463 Bytes.
This particular image is not ideally suited for JPEG compression or palette-based compression, which is why I chose it to show how each one handles the ups and downs of its own methods. Here, you can see that at a level of 30, the surface of the disc is already showing blocky artifacts, and at a level of 40 it's no longer an acceptable representation considering the minimal gain in space saving. Further compression will only yield diminishing returns.

A scenery photograph, on the other hand, will represent JPEG's compression efficacy much better:


Compression: 10
File size: 29,864 Bytes.
Compression: 20
File size: 19,100 Bytes.
Compression: 30
File size: 11,543 Bytes.
Compression: 40
File size: 7,742 Bytes.
First, you can barely see a difference between the image compressed at a level of 10 and the image compressed at the level of 20, even though the second image is ~33% smaller in file size. You can start to notice differences at the image compressed at 30, but they're not major flaws, and at this point, you're at one third of the file size of the image compressed at 10. At the compression level of 40, the water begins to show blocky areas, and at this point you're not gaining all that much anymore in terms of space, so for this particular photo, a 30 would suffice if bandwidth is a concern, whereas you may want to get closer to 20 if you'd like to keep more of the original detail.

As initially mentioned, the JPEG file format is a boon for displaying photographic images on the web. By "photographic", I also mean textures, various tile fills, 'organic' images of most types, and of course anything taken with a camera.

The Permutations are Endless

Considering that even if you do use the GIF file format, you're still only really left with two methods of compression, the range you can achieve and the manner in which you can tweak each of them is quite broad. For example, you could decide that the image of the CD above would be best displayed using ~500 colors, and so you would split that image into two separate files, and save each with its own palette. Or maybe you have a photo like the waterfall, where the water portion doesn't compress well while the rest of the image does -- you could split the image into the water area, and the rest of the photo, and save each using a different compression level. This doesn't exactly make the images more portable, but if you're designing for the web, and the images are part of a web site, then these are perfectly applicable tricks. You could save one image using 32-Bits with an Alpha Channel in a PNG, and place it over a JPEG-compressed texture, combining the best of both methods on the same area within the screen.

Being a proponent of Free Software, I really couldn't end this document without pointing you to the GIMP. This is a cross-platform, open-source, and free image manipulation program which is extremely poweful once you get a handle on its subtleties. The amount of features it provides you with is astonishing, and it's extremely customizable. Here are a few screenshots of the GIMP in action, here is a link to the GIMP for Windows, and here is a link to the GIMP for MacOS-X.