Image Formats

Use these to jump around or read it all…

     I did something yesterday that was very unlike a computer professional. I actually took the time to read the back of the box that contained my new PaintShop Pro version 5.0 graphics program. Toward the bottom, the box proclaimed the program supported 44 different image formats. Wow!

     On the Net, luckily, we really only have to deal with three main types of images: CompuServe GIF, JPEG, and Bitmaps. At the moment, those are the only three that are roundly supported by the major browsers. But what’s the difference between them? What does it mean if a GIF is interlaced or non-interlaced? Is a JPEG progressive because it enjoys art deco? Does a Bitmap actually offer directions somewhere? And the most often asked question:

     I’ve been meaning to write this tutorial for a while. I offer it as a catch-all answer to the many questions I get about images and their use.

Image or Graphic?

     Technically, neither. If you really want to be strict, computer pictures are files, the same way WORD documents or solitaire games are files. They’re all a bunch of ones and zeros all in a row. But we do have to communicate with one another so let’s decide.

     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).

     So, they’re all images unless you’re talking about something specific.

44 Different Graphic Formats?

     It does seem like a big number, doesn’t it? In reality, there are not 44 different graphic format names. Many of the 44 are different versions under the same compression umbrella, interlaced and non-interlaced GIF, for example.

     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:

Raster

     Raster image formats (RIFs) should be the most familiar to Internet users. A Raster format breaks the image into a series of colored dots called pixels. The number of ones and zeros (bits) used to create each pixel denotes the depth of color you can put into your images.

     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 16 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

     Since I brought up pixels, I thought now might be a pretty good time to talk about pixels and the Web. How much is too much? How many is too few?

     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.

     The lowest I’d go is 72 pixels per inch, the agreed upon low end of the image scale. In terms of pixels per square inch, it’s a whale of a drop to 5184. Try that. See if you like it, but I think you’ll find that lower definition monitors really play havoc with the image.

Meta/Vector Image Formats

     You may not have heard of this type of image formatting, not that you had heard of Raster, either. This formatting falls into a lot of proprietary formats,
formats made for specific programs. CorelDraw (CDR), Hewlett-Packard Graphics Language (HGL), and Windows Metafiles (EMF) are a few examples.

     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?

     I get that question a lot. Usually it’s followed with “How come it only works on Microsoft Internet Explorer?” The second question’s the easiest. Microsoft invented the Bitmap format. It would only make sense they would include it in their browser. Every time you boot up your PC, the majority of the images used in the process and on the desktop are Bitmaps.

     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=”–“> 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 inline 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

     I said above that a Bitmap was a simple series of pixels all stacked up. But the same image saved in GIF or JPEG format uses less bytes to make up the file. How? Compression.

     “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.

     So, why not create a single pixel when all of the colors are close? You could even lower the number of colors available so that you would have a better chance of the pixels being close in color. Good idea. The people at CompuServe felt the same way.

The GIF Image Formats

     So, why wasn’t the Bitmap chosen as the King of all Internet Images? Because Bill Gates hadn’t yet gotten into the fold when the earliest browsers started running inline images. I don’t mean to be flippant either; I truly believe that.

     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

     I remember when animation really came into the mainstream of Web page development. I was deluged with e-mail asking how to do it. There’s been a tutorial up for a while now at http://www.htmlgoodies.com/tutors/animate.html. Stop by and see it for instruction on how to create the animations yourself. Here, we’re going to quickly discuss the concepts of how it all works.

     What you are seeing in that example are 12 different images, each set one “hour” farther ahead than the one before it. Animate them all in a row and you get that stopwatch effect.

     The concept of GIF89a animation is much the same as a picture book with small animation cells in each corner. Flip the pages and the images appear to move. Here, you have the ability to set the cell’s (technically called an “animation frame”) movement speed in 1/100ths of a second. An internal clock embedded right into the GIF keeps count and flips the image when the time comes.

     The animation process has been bettered along the way by companies who have found their own method of compressing the GIFs further. As you watch an animation you might notice that very little changes from frame to frame. So, why put up a whole new GIF image if only a small section of the frame needs to be changed? That’s the key to some of the newer compression factors in GIF animation. Less changing means fewer bytes.

Transparency

     Again, if you’d like a how-to, I have one you for you at http://www.htmlgoodies.com/tutors/transpar.html. A transparent GIF is fun but limited in that only one color of the 256-shade palette can be made transparent. Here’s an example:

     As you can see, the bytes came out the same after the image was put through the transparency filter. The process is best described as similar to the weather forecaster on your local news. Each night they stand in front of a big green (sometimes blue) screen and deliver the weather while that blue or green behind them is “keyed” out and replaced by another source. In the case of the weather forecaster, it’s usually a large map with lots of Ls and Hs.

     The process in television is called a “chroma key.” A computer is told to hone in on a specific color, let’s say it’s green. Chroma key screens are usually green because it’s the color least likely to be found in human skin tones. You don’t want to use a blue screen and then chroma out someone’s pretty blue eyes. That chroma (color) is then “erased” and replaced by another image.

     Think of that in terms of a transparent GIF. There are only 256 colors available in the GIF. The computer is told to hone in on one of them. It’s
done by choosing a particular red/green/blue shade already found in the image and blanking it out. The color is basically dropped from the palette that makes up the image. Thus whatever is behind it shows through.

     The shape is still there though. Try this: Get an image with a transparent background and alter its height and width in your HTML code. You’ll see what should be the transparent color seeping through.

     Any color that’s found in the GIF can be made transparent, not just the color in the background. If the background of the image is speckled then the transparency
is going to be speckled. If you cut out the color blue in the background, and that color also appears in the middle of the image, it too will be made transparent.

     When I put together a transparent image, I make the image first, then copy and paste it onto a slightly larger square. That square is the most hideous green I can mix up. I’m sure it doesn’t appear in the image. That way only the background around the image will become clear.

Interlaced vs. Non-Interlaced GIF

     The GIF images of me playing the Turkish Sitar were non-interlaced format images. This is what is meant when someone refers to a “normal” GIF or just “GIF”.

     When you do NOT interlace an image, you fill it in from the top to the bottom, one line after another. The following image is of two men coming onto a boat we used to cross from the European to the Asian side of Turkey. The flowers they are carrying were sold in the manner of roses we might buy our wife here in the U.S. I bought one. (What a guy.)

     Hopefully, you’re on a slower connection computer so you got the full effect of waiting for the image to come in. It can be torture sometimes. That’s
where the brilliant Interlaced GIF89a idea came from.

     Interlacing is the concept of filling in every other line of data, then going back to the top and doing it all again, filling in the lines you skipped. Your television works that way. The effect on a computer monitor is that the graphic appears blurry at first and then sharpens up as the other lines fill in. That allows your viewer to at least get an idea of what’s coming up rather than waiting for the entire image, line by line. The example image below is of a spice shop in the Grand Covered Bazaar, Istanbul.

     Both interlaced and non-interlaced GIFs get you to the same destination. They just do it differently. It’s up to you which you feel is better.

JPEG Image Formats

     JPEG is a compression algorithm developed by the people the format is named after, the Joint Photographic Experts Group. JPEG’s big selling point is that its compression factor stores the image on the hard drive in less bytes than the image is when it actually displays. The Web took to the format straightaway because not only did the image store in fewer bytes, it transferred in fewer bytes. As the Internet adage goes, the pipeline isn’t getting any bigger so we need to make what is traveling through it smaller.

     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

     You can almost guess what this is all about. A progressive JPEG works a lot like the interlaced GIF89a by filling in every other line, then returning to the top of the image to fill in the remainder. The example is again presented three times at 1%, 50%, and 99% compression. The image is of the port at Istanbul from our hotel rooftop.

     Obviously, here’s where bumping up the compression does not pay off. Rule of thumb: If you’re going to use progressive JPEG, keep the compression up high, 75% or better.

Reader’s Image Questions

Which image do I use where?

     There’s just not a good answer to this question. No matter what I say, someone else can give you just as compelling a reason why you should do the opposite. I’ll tell you the rules I follow:

• 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?

     You have to have an image editor. I own three. Most of my graphic work for the Web is done in PaintShop Pro. I do that because PaintShop Pro is shareware and you can get your hands on the same copy I have. That way I know if I can do it, you can do it.

     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?

     Neither. I always edit in the PaintShop Pro or Bitmap format. Others have told me that image creation and editing should only be done in a Vector format. Either way, make a point of editing with large images. The larger the image, the better chance you have of making that perfect crop. Edit at the highest color level the image program will allow. You can always resize and save to a low-byte format after you’ve finished creating the file.

That’s That…

     Now you’ve got the lowdown on the images that work over the World Wide Web. If you haven’t already, try your hand at creating your own graphics. I
enjoy it. It’s the adult version of finger painting.

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

Enjoy!