Image Formats:
It doesn’t take much experience with images on computers to run into a GIF file. GIF is a popular format that constitutes a significant portion of images used on the Web. But GIF is only one of a number of different graphics standards. JPEG, PCX, TIFF, and others are also widely used image file types (not all used on the Web). Is it possible to use any image format in an IMG tag? The short answer is no. Among all the various formats, the browser itself can handle only a handful. Basically there are three (possibly four) that are used in an IMG tag, GIF, JPEG, and XBM (check for PNG support). Other formats can still be displayed on the Web, but not by using the IMG tag and they usually require a special plug-in or application helper. Each of the three formats that can be displayed by an IMG tag has different characteristics. Examining these might make deciding which standard to use easier.

XBM
XBM is an X Window bitmap, and only supports two colors. Most PC and Mac browsers can display these, but if you don't have UNIX, you might have a problem finding the utilities that create them. GIF and JPEG, on the other hand, are standard formats for both the PC and the Mac.

GIF
GIF (Graphics Interchange Format) supports a maximum of 256 colors and is generally preferred when you want crisp lines (such as when text appears in the image, as in some icons), or have images with large blocks of single colors.

JPEG
JPEG (Joint Photographic Experts Group) supports up to 16.7million colors and is very good at compressing photographic and photo-realistic images. You can control the amount of compression, trading size for quality.

Performance Considerations

Taking Control of your ImagesIf Web performance (time it takes a page to load) is to be improved, two primary factors are to be considered, #1) the speed of the Net connection and #2) the amount of data that needs to be transferred. There may be a vast number of communications vehicles in-between the server that houses a page and the browser that reads it. The slowest vehicle is usually the home connection, which is typically achieved using a low-speed connection via analog modem and standard telephone lines. A page that might take a few seconds to load from work (on a high-speed workstation using a broadband connection) might take five minutes on a bandwidth challenged home system using a standard telephone modem. Therefore when a Web author is optimizing images for the Web he/she must take into account not only the type of browser (surfboard) the user is surfing with but also the type of connection (wave) the surfer is riding on.

The 30 Second Rule
Millions of people using the major Online Services (AOL, Prodigy, exc.) and Internet Service Providers (ATT, Bell, exc.) are dialing in at speeds ranging from 9,600bps to 56,000bps (bits per second). It was once believed by Web authors that 30 seconds of load time for a Web page was a good rule of thumb, however this needs to be explained further. This does not mean it should take 30 seconds for something to appear on the display, this means 30 seconds to download the entire page (all content). The user should see text before the page has completely loaded. All relevant text should appear on the display before the first 10 seconds have expired and all small images (5k and under) should be displayed before the 20 second mark. The Web is the domain of the attention deficit populous of the right-here and right-now. After 30 seconds, all bets are usually off as to gaining and keeping their attention. If the user did not get what they were looking for or at least a pleasant surprise that was unexpected, they're gone. However the 30-second rule does not take into account Net congestion or overloaded servers.

The Two Screen Rule
Web authors have another rule of thumb that suggest that you should not put more than two screens worth of information on one HTML page (the amount of information that two screens constitutes will vary with font size, monitor size and screen resolution). HTML markup and text should load in much less than 30 seconds, but inline images on your page may take longer. Tuning these images can significantly impact the transfer speed of your page.

Four Factors you Control
The size of an inline image determines how quickly it can be loaded and is a key factor in optimizing images for the Web. You can manipulate four characteristics of an image to improve your page performance:

Dimensions

Number of colors

Type of compression

Reusability

Dimensions
The dimensions of an image describe the size of an image in pixels. One way to speed up performance is to specify these dimensions in the markup. Doing this allows the browser to block-out a space for the image first, then begin displaying text instead of waiting for the image to load. Because the browser knows what part of the screen the image will occupy, it does not need to load the image right away; it can load text first and then load images. The overall transfer time is not significantly different (the browser still has to transfer the same amount of information overall), it just appears faster. The user does not have to wait to start viewing text content and the frames for the images pop up in the document right away. In HTML 3.2 and up the IMG tag has options for WIDTH and HEIGHT that correspond to the pixel size of the image. These options allow you to define the size so that the browser can block-out the area for images and start displaying text.

For example, a quarter-screen image (1/4th of 640 x 480) would be 320 x 240 pixels, your HTML image tag would look something like this:

IMG WIDTH=320 HEIGHT=240 SRC="my_image.gif"

Number of Colors
GIF images can contain 256 colors; JPEG images can contain as many as 16 million colors. Most browsers compatible with Windows display about 50 colors. Windows 9.x OS's generally use 16 colors from their 256-color palette (for SuperVGA systems), the rest are used by the browser for it's menus, buttons, and so on, leaving about 50 entries in the palette free. Windows uses some very complex color palette combinations that are beyond the scope of this article. However you need only know that your inline images on a Web page will not be displayed in 256 colors and definitely not in True Color (this may be different under Windows 2000 and future Windows offerings). Until browsers support 16 million colors (when the Net supports the transfer of a file with 16 million placeholders for color values that takes less than two weeks to download) you will want to analyze your image to see how many colors are really need. Before an image has been optimized for the Web it may have color values that will not be used by the browser. Getting rid of these values means smaller file sizes. The optimized image will (in most cases) still look as good as its predecessor.

You may be wondering how so many different colors can be displayed in your browser with such a limited option of colors for your browser to access. Take into consideration that color combinations are used to create colors that are not available in the palette (or something close). A good example would be an InkJet printer, most only use 3 different colors of ink (cyan, magenta, yellow) (some new models use 4 colors) to produce all of the different colors we see on our colored printouts.

If you want to see "Number of Colors" optimization techniques in practical application you should try the following:

Use your favorite search engine to find and download "LVIEW". Open a GIF image using LVIEW. Select "Retouch, Color Depth". Click the "Palette image button" and the "Custom Number of Colors button" and set the number of colors to 50. After you enter 50 in "Custom Number of Colors" click "OK". LVIEW calculates what mix of 50 colors will best represent your image. Compare the two files (before and after) and see if there is a noticeable difference. Try using different "Custom Number of Colors" settings to get the best match of colors and image quality with the smallest file size. You'll notice that saving the file results in a new file size that is dramatically lower than the previous. Since 1K equals about one second of transfer time, you could shave several seconds off of your image file download time.

Type of Compression
Most browsers support both GIF and JPEG as inline images however there are variables to consider when using either.

JPEG is better at storing full-color photographic or gray-scale images, especially if you want your scenes to have realism and image depth.

GIF is best used for black-and-white images or images with only a few, distinct colors (as opposed to color blends). It works well with line drawings, and graphics that contain text.

If you are scanning pictures to use as images on the Web, you should consider the compression style used by either format. GIF gets rid of a lot of color information when it compresses. Compression ratios will range from 2:1 to 5:1.

JPEG achieves 10:1 to 20:1 compression ratios easily on full-color images, and can go as low as 100:1 in some cases.

When JPEG was first introduced, converting an image in GIF to JPEG could produce some very strange results. However up-to-date graphic conversion utilities can usually handle the conversion with ease producing eye-pleasing results. As a matter of fact, many of these utilities give tremendous customization control over the quality of the conversion. Nevertheless, you should decide which format you need when you originally create the digitized image and stick to it. However this is not always possible, especially if you're not the one creating the images. If you're just implementing the images into the Web page and not creating them you may have to work with an image file format that is undesirable. It may be necessary to convert the image into a more manageable and user-friendly (not to mention compatible) format.

Reusability
No, this is not a new type of recycling project started by the neighborhood tree-huggers. I am referring to the ability to re-use images, graphical menus and other Web page elements. The performance of your pages can be significantly improved by re-using page elements, especially images. You should use the same navigational bar or buttons on all your pages, which helps the user by making them only download these images once. As browsers go from page to page on the Web, they keep images they've already downloaded cached (stored on the local disk or in memory). This prevents the browser from having to retrieve the images again from the server; the image can be retrieved from cache, which is much faster for a browser to access than the server is. This provides a graphical template for moving around your documents while actually downloading only the new HTML markup and text.

This technique not only works with navigational bars and buttons but with graphical bullets and rules as well. You should avoid decorating your lists with bullets of all colors of the rainbow. Each bullet will need to be retrieved separately, multiplying the time it takes to render your page. If you use a single bullet image, the bullet will be downloaded once and re-used for each list item. This will be achieved in a much faster load time than downloading a different bullet for each menu item. It should be duly noted that using the same image also means the same image name. Often times when someone uses a WYSIWYG editor (what you see is what you get) to create Web pages the code generated by these editors will give strange names to page elements such as images. One such application that will remain nameless (MS Publisher, cough, cough) will assign numbers to images that have been cut and pasted, copied, or inserted onto a page (example: image1.gif). These types of applications will use this method of keeping up with images even if you paste or insert the exact same image multiple times during the creation of the Web document. You may end up with a bullet that is used throughout the site 47 times with 47 different names (example: image1.gif, image2.gif, etc.).

If this sloppy design architecture is not cleaned up before the pages are loaded on the server you will end up with multiple copies of the same image under different file names. This will cause a users browser to download multiple copies of the same image which will totally negate your attempts at reusability. Therefore if you're using a WYSIWYG editor be sure you view all of your source code and edit it as necessary. Hand coding is a valuable skill and should be learned and practice fervently, (however, that's another topic).