Image Formats on the Web

     Image. We'll use "image". That seems to cover a wide enough topic range.

     I went to my reference books and there I found that "graphic" is more of an adjective, as in "graphic format." You see, we denote images on the Internet by their graphic format. GIF is not the name of the image. GIF is the compression factors used to create the raster format set up by CompuServe. (More on that in a moment).

     Before getting into where we get all 44, and there are more than that even, let me back-peddle for a moment.

     There actually are only two basic methods for a computer to render, or store and display, an image. When you save an image in a specific format you are creating either a raster or meta/vector graphic format. Here's the lowdown:

     If your pixel is denoted with only one bit-per-pixel then that pixel must be black or white. Why? Because that pixel can only be a one or a zero, on or off, black or white.

     Bump that up to 4 bits-per-pixel and you're able to set that colored dot to one of four colors. If you go even higher to 8 bits-per-pixel, you can save that colored dot at up to 256 different colors.

     Does that number, 256, sound familiar to anyone? That's the upper color level of a GIF image. Sure, you can go with less than 256 colors, but you cannot have over 256.

     That's why a GIF image doesn't work overly well for photographs and larger images. There are a whole lot more than 256 colors in the world. Images can carry millions. But if you want smaller icon images, GIFs are the way to go.

     Raster image formats can also save at 16, 24, and 32 bits-per-pixel. At the two highest levels, the pixels themselves can carry up to 16,777,216 different colors. The image looks great! Bitmaps saved at 24 bits-per-pixel are great quality images, but of course they also run about a megabyte per picture. There's always a trade-off, isn't there?

      The three main Internet formats, GIF, JPEG, and Bitmap, are all Raster formats.

     Some other Raster formats include the following:

Pixels and the Web

     There is a delicate balance between the crispness of a picture and the number of pixels needed to display it. Let's say you have two images, each is 5 inches across and 3 inches down. One uses 300 pixels to span that five inches, the other uses 1500. Obviously, the one with 1500 uses smaller pixels. It is also the one that offers a more crisp, detailed look. The more pixels, the more detailed the image will be. Of course, the more pixels the more bytes the image will take up.

     So, how much is enough? That depends on whom you are speaking to, and right now you're speaking to me. I always go with 100 pixels per inch. That creates a ten thousand pixel square inch. I've found that allows for a pretty crisp image without going overboard on the bytes. It also allows some leeway to increase or decrease the size of the image and not mess it up too much.

     Where the Meta/Vector formats have it over Raster is that they are more than a simple grid of colored dots. They're actual vectors of data stored in mathematical formats rather than bits of colored dots. This allows for a strange shaping of colors and images that can be perfectly cropped on an arc. A squared-off map of dots cannot produce that arc as well. In addition, since the information is encoded in vectors, Meta/Vector image formats can be blown up or down (a property known as "scalability") without looking jagged or crowded (a property known as "pixelating").

     So that I do not receive e-mail from those in the computer image know, there is a difference in Meta and Vector formats. Vector formats can contain only vector data whereas Meta files, as is implied by the name, can contain multiple formats. This means there can be a lovely Bitmap plopped right in the middle of your Windows Meta file. You'll never know or see the difference but, there it is. I'm just trying to keep everybody happy.

What's A Bitmap?

     If you're using an MSIE browser, you can view this first example. The image is St. Sophia in Istanbul. The picture is taken from the city's hippodrome.

     Against what I said above, Bitmaps will display on all browsers, just not in the familiar <IMG SRC="/ew_img/common/content/article/19980924/hg_imageformats/--"> format we're all used to. I see Bitmaps used mostly as return images from PERL Common Gateway Interfaces (CGIs). A counter is a perfect example. Page counters that have that "odometer" effect () are Bitmap images created by the server, rather than as an in-line image. Bitmaps are perfect for this process because they're a simple series of colored dots. There's nothing fancy to building them.

     It's actually a fairly simple process. In the script that runs the counter, you "build" each number for the counter to display. Note the counter is black and white. That's only a one bit-per-pixel level image. To create the number zero in the counter above, you would build a grid 7 pixels wide by 10 pixels high. The pixels you want to remain black, you would denote as zero. Those you wanted white, you'd denote as one. Here's what it looks like:

     See the number zero in the graph above? I made it red so it would stand out a bit more. You create one of those patterns for the numbers 0 through 9. The PERL script then returns the Bitmap image representing the numbers and you get that neat little odometer effect. That's the concept of a Bitmap. A grid of colored points. The more bits per pixel, the more fancy the Bitmap can be.

     Bitmaps are good images, but they're not great. If you've played with Bitmaps versus any other image formats, you might have noticed that the Bitmap format creates images that are a little heavy on the bytes. The reason is that the Bitmap format is not very efficient at storing data. What you see is pretty much what you get, one series of bits stacked on top of another.

     "Compression" is a computer term that represents a variety of mathematical formats used to compress an image's byte size. Let's say you have an image where the upper right-hand corner has four pixels all the same color. Why not find a way to make those four pixels into one? That would cut down the number of bytes by three-fourths, at least in the one corner. That's a compression factor.

     Bitmaps can be compressed to a point. The process is called "run-length encoding." Runs of pixels that are all the same color are all combined into one pixel. The longer the run of pixels, the more compression. Bitmaps with little detail or color variance will really compress. Those with a great deal of detail don't offer much in the way of compression. Bitmaps that use the run-length encoding can carry either the common ".bmp" extension or ".rle". Another difference between the two files is that the common Bitmap can accept 16 million different colors per pixel. Saving the same image in run-length encoding knocks the bits-per-pixel down to 8. That locks the level of color in at no more than 256. That's even more compression of bytes to boot.

     Here's the same image of St. Sophia in common Bitmap and the run-length encoding format. Can you see a difference?

     If case you're wondering, the image was saved in Windows version run-length encoding (there's also a CompuServe version) at 256 colors. It produced quite a drop in bytes, don't you think? And to be honest -- I really don't see a whole lot of difference.

     GIF, which stands for "Graphic Interchange Format," was first standardized in 1987 by CompuServe, although the patent for the algorithm (mathematical formula) used to create GIF compression actually belongs to Unisys. The first format of GIF used on the Web was called GIF87a, representing its year and version. It saved images at 8 pits-per-pixel, capping the color level at 256. That 8-bit level allowed the image to work across multiple server styles, including CompuServe, TCP/IP, and AOL. It was a graphic for all seasons, so to speak.

     CompuServe updated the GIF format in 1989 to include animation, transparency, and interlacing. They called the new format, you guessed it: GIF89a.

     There's no discernable difference between a basic (known as non-interlaced) GIF in 87 and 89 formats. See for yourself. The image is of me and another gentleman playing a Turkish Sitar. ") }

     Even the bytes are the same. It's the transparency, animation, and non-interlacing additions to GIF89a that really set it apart. Let's look at each one.

Animation

     For a long while, GIF ruled the Internet roost. I was one of the people who didn't really like this new JPEG format when it came out. It was less grainy than GIF, but it also caused computers without a decent amount of memory to crash the browser. (JPEGs have to be "blown up" to their full size. That takes some memory.) There was a time when people only had 8 or 4 megs or memory in their boxes. Really. It was way back in the Dark Ages.

     JPEGs are "lossy." That's a term that means you trade-off detail in the displayed picture for a smaller storage file. I always save my JPEGs at 50% or medium compression.

     Here's a look at the same image saved in normal, or what's called "sequential" encoding. That's a top-to-bottom, single-line, equal to the GIF89a non-interlaced format. The image is of an open air market in Basra. The smell was amazing. If you like olives, go to Turkey. Cucumbers, too, believe it or not.

     The difference between the 1% and 50% compression is not too bad, but the drop in bytes is impressive. The numbers I am showing are storage numbers, the amount of hard drive space the image takes up.

     You've probably already surmised that 50% compression means that 50% of the image is included in the algorithm. If you don't put a 50% compressed image next to an exact duplicate image at 1% compression, it looks pretty good. But what about that 99% compression image? It looks horrible, but it's great for teaching. Look at it again. See how it appears to be made of blocks? That's what's meant by lossy. Bytes are lost at the expense of detail. You can see where the compression algorithm found groups of pixels that all appeared to be close in color and just grouped them all together as one. You might be hard pressed to figure out what the image was actually showing if I didn't tell you.

Progressive JPEGs

Which image do I use where?

• Small images, like icons and buttons: GIF (usually non-interlaced)

• Line art, grayscale (black and white), cartoons: GIF (usually non-interlaced)

• Scanned images and photographs: JPEG (I prefer sequential. I'm not a fan of Progressive)

• Large images or images with a lot of detail: JPEG (I prefer sequential)

     That said, I also follow the thinking, "Do people really need to see this image?" Can I get away with text rather than an image link? Can I make links to images allowing the viewer to choose whether to look or not? The fewer images I have on a page, the faster it comes in. I also attempt to have the same images across multiple pages, if possible. That way the viewer only has to wait once. After that, the images are in the cache and they pop right up.

How do I save in these formats?

     To get these formats, you need to make a point of saving in these formats. When your image editor is open and you have an image you wish to save, always choose SAVE AS from the FILE menu. You'll get a dialogue box that asks where you'd like to save the image. Better yet, somewhere on that dialogue box is the opportunity for you to choose a different image format. Let's say you choose GIF. Keep looking. Somewhere on the same dialogue box will be an OPTIONS button (or something close). That's where you'll choose 87a or 89a, interlaced or non-interlaced, formats.

     If you choose JPEG, you'll get the option of choosing the compression rate. You may not get to play with the sliding scale I get. You may only get a series of compression choices, high, medium, low, etc. Go high.

Do you edit and create images in GIF or JPEG?

That's That...

     Just remember, there are no right or wrong answers when creating images. Pretty much anything goes.

Enjoy!