Image Preparation

Image Preparation	Email me SiteMap
Consulting Soapbox Notes NotesFor... Links Outline

So you want to use that picture...
We've all seen sites that take forever to load and have poor graphics that cause the problem, including some ads in ZDNet's DB generated pages. Later on this page I have included an example, and the last part of this page includes a discussion of colors and compression.

The steps in creating effective graphics are:

Decide what you want to express, and the impression desired. An additional consideration is if it is reusable. It takes the same storage used once or on 20 pages. Once in cache, it is refetched from cache, so later uses load faster.
Plan your approach- a small, sharp punctuation, a mood, detailed information, which will determine if it is to be a 100x100 GIF in primary colors, a pale background, or a sharp 600x300 picture. Your audiance will determine if you can use the big, fancy full frame picture (broadband) or if that will stop them cold on dial-up, so use a 10Kb picture, not 5Mb.
Select your image with a critical eye as to how it will read.
Aquire and crop your image. Remember the square rule: 32x32=1K; 64x64=4K; 96x96=9K; 128x128=16K; size growth is exponential, which without compression translates directly to transmission time, so limit size to the smallest useful size.
Massage the image to be as readable as possible, insuring it is bright enough to read, and as clear as you desire. An exclamation point probably should be a high contrast three color GIF (background, outline, image), while a mood background will probable be low contrast (allow reading text over it), and light. If a GIF, you may opt for a transparent background or white (the most compressible color). If the background does not add detail to the image, try making it white (when the object, not the context is important).
Reduce colors as much as possible. Compression depends on replacing a pattern in the image data with a code, so the less insignificant information included in the image, the more it will compress, even for continuous tone JPG images. Yes, this is a trade off item.
Resample it to the minimum useful size. Keep your previous work, for this can effect color, and you may want to go back a step.
Compress and test. Repeatedly. JPG has three color reduction schemes, and the best one is the one that includes just enough color information. For JPG, you then need to try for the maximum compression without degrading the image, since JPG compression is lossy, meaning the displayed image will NOT be the same as the original. If it looks like an air brush job with a clogged nozzle, it's too much compression, so test compression up to this point, and back off a notch. GIF uses LZW compression, which is not lossy, so color replacement and reduction are the variables. Line art is best used as a GIF, but resampling it to the minimum useful size is your only real option.
The final step is placement in your HTML code. Be sure to include the height and width information, so the browser can reserve the space for the image and display your text while receiving the image data. Place it so the reader has something to look at while the image is received, be it at the top in a table, or below the first screenful.

An Example

Here is an example of processing an image, with links to the image at the evaluation points[ use Right-Click: Open in New window to be able to jump back and forth]. The image used for this is a very poorly exposed snapshot sitting on my desk that doesn't require a release that I just scanned in. The steps are included by links so you can see the load size and time. [NOTE: When loading these, watch the transmission information at the bottom of the browser. You will see size and transmission speed to help you judge the effects of doctoring. To re-check, clear cache, in both memory and on disk. Return by your "back" button. Without clearing cache, you see fetch time from cache.] To see the original scan (demanding tolerance for a wait) now. It is too dark to see the details at all, and the cropping is sloppy.

First, you want to SEE the picture, so doctor it. Push the RGB gamma up to where there is some image to see (that may be 1.2 up to 2.0 or more!) and then see if jacking up the brightness helps, an maybe compensate some with increasing the contrast. This all helps visual value of the image.

Now, crop it as closely as possible. Reduced size is the fastest way to shrink load time. If you can eliminate background detail, replacing it with a non-dithering color (white is great), it will compress more. Insignificant detail still takes transmission of additional information, and may detract from the significant portion of the graphic. Set the resolution to screen values (Win=96dpi). Resampling to the smallest useful size helps. Shrinking an image with the HTML size parameters requires all the time of transmitting the whole picture, and more for the browser to resample it.

Now comes the slow part. You know the song, "If you want to play the Blues..." Reduce colors as much as you can. For continuous tones, or a bit prettier on the big, expensive, high resolution screens, you get to do several saves with differing settings for jpeg. You get three choices of color sampling; try each, and use the most restrictive that looks OK. Then see how much compression you can use. If it looks like an air brush job with a clogged nozzel, try less compression. This 193x240 image was 443K originally, and that with little compression became 81K of file. With the work, it became 21K .

While a GIF is not so hot for continuous tones and subtle variations, for line art, solid color graphics, and some advantage in displaying, it beats the stuff JPG does to some images, and can be smaller with fidelity. And remember, Murphy says if you didn't check it with your browser, you will wish you had. Converting it to "256 color indexed" is a misnomer, for fewer colors are used with browsers, so convert using "6-6-6" levels. LZW compression can help the size a lot, and size of the transmitted file translates into seconds (or worse) in transmission time. This time the result is 20K, 1 K smaller than JPG (5%; 3 sec when the Net is crawling at 350 Bytes/sec).

Colors and Compression, GIF vs JPG

These six images are from the same original, the Netscape color set, with different options used in saving them, with one trick demonstrated. The first is a tiny GIF with an HTML size spec the same as the others (180x180). The colors are the Netscape color set which are not dithered, with six levels for Red, Green, and Blue, with the remainder of the 256 indexed colors coming from your system.
The GIFs use LZW compression. JPG allows selection of color sampling (none, yuv422, and yuv411), and a compression ratio. The lower right is 90% yuv411, for near maximum compression. Note JPG is lossy, and generally bigger, but does better with continuous range, and variegated tones, i.e. faces, while GIF does better with solid colors in the set, and is used extensively in net ads.


NSC0.GIF 1040 byte file, Expanded by browser	NSC1.GIF 8085 byte file, Full size GIF, LZW compression, 32400 bytes in memory	NS0.JPG 16016 bytes file, 10% compress, no subsample, 97200 bytes in memory, as all the JPG examples (24bit color)

NS1.JPG 5799, 40% compress, subsampled (yuv422)	NS2.JPG 5082, 40% compress, 2nd level subsampled (yuv411)	NS3.JPG 2427, 90% compress, 2nd level subsampled (yuv411)

Various backgrounds used in this site show how design can dictate the choice while maximum throughput is sought (check file size vs decompressed content size, which can be Much larger).
GIF tends to make clouds look blotchy, and poster-like, and is less memory intensive with 256 or less colors, while JPG tends to speckle the background and solid areas, looking more air brushed, and pays for 24bit and greater color potential with more memory use. In both cases, the fewer the colors in the image, the better it compresses.

The poster effect of GIF vs the subtle shading, variegation, and color fidelity of JPG may dictate the format for an image. On the other hand, practical considerations of load time and memory usage may dictate what image can be used. Strong, hard edged images can make backgrounds that make the foreground text hard to read. A company logo will often do better as sharp, strong GIF, than as a fancy, shaded 3D graphic due to the load time. It is better that I see your text and company logo while waiting for the CEO's picture, than cursing it when it finally loads. The satellite shot of GOES 9 is worth the wait to me for it to fill my screen because the detail is what I need. I would rather see your content when I select your site. This is also why stating the height and width in the HTML is important, for then the browser can show the text while waiting for the image. A picture can be worth a thousand words; it is up to you to make sure those words have more than four letters.

Note that things keep changing. A company with a claim to a piece of the compression algorithm is demanding royalties of all commercial users. As a result, PNG was started, and is likely to become dominant because it is explicitly intended to remain free for all, and now handles all the tricks a .gif can do, and is constantly having additional methods being added.

Some useful resources

GIF Wizard from Raspberry Hill Publishing Inc. A great resource and service. They also can help (for a fee) with JPG and some other images.
Non-Dithering Colors in Browsers
REF08- Web Publishing Links has a bunch of references, including lots for graphics.