Smaller JPEG Files
by Ben Summers
JPEG is rather more complicated than GIF, and it's useful to have a basic idea of how it works to get the best out of it.
JPEGs are compressed in two stages. The first is lossy compression, which removes information from the image, and is why JPEGs never look quite the same as the original image.
This stage splits the image data into three components, one of which is brightness and the other two colour. Since the human eye is much less sensitive to colour than brightness, the colour data is reduced to a quarter of it's original size by averaging 2x2 blocks of pixels into a single pixel.
The next stage is to work on 8x8 blocks of pixels, and to turn this data from 'brightness' values into another representation where we record how much the values change at each frequency, rather than the values themselves. This is much like the spectrum analyser on your hi-fi, and just as human ears are less sensitive to higher frequencies, human eyes are much less sensitive to faster changes in brightness. This is where the lossy part of JPEG comes in - we use a 'quality' table (derived from the quality setting you gave when compressing the file) to lose information from the higher frequencies, which represent the faster changes. This table says how much information to remove from each frequency, and since each component is compressed separately, each can have its own quality tables.
All this doesn't actually reduce the amount of data stored to represent the picture very much, it just turns it into a form which is more compressible. So the second stage is a lossless compression technique called Huffman compression. This is an old, but effective, method of compressing files.
The image data is now a simple list of numbers, and because many of the higher frequencies have been 'removed', a lot of the numbers are the same, namely zero. Huffman compression is very good at storing this kind of data, so the file size is reduced dramatically.
JPEG isn't good for all images. In general, if the image has continuous tone colour, such as a photographic image, then JPEG is your best bet, but if it's a more 'iconic' image, such as a logo or navigational element, then GIF is going to be smaller, and represent the image more cleanly.
This type of photographic image is ideally suited to JPEG compression.
The image is split into three channels.
The black and white picture represents the 'brightness' component. The two colour channels are only half the resolution of the brightness channel.
Television images are very similar in that they have a relatively high resolution black and white component overlaid on a lower resolution colour one.
There are fewer possible options with JPEG files than there are GIF files, but the results of using them are less predictable. The major control over file size is the quality setting. Ideally, your web graphics application should let you choose values from 0 to 100 - low, medium and high simply don't give enough control.
It should also allow you to change the colour quality independently from the brightness quality. As for the quality values to set, just choose the lowest quality setting acceptable for your particular purpose.
You should be able to use a lower 'colour' quality than 'brightness', especially on images which are predominantly one colour.
This exaggerated example shows the blockiness introduced into a crisp, flat image by JPEG compression because so much information has been discarded during the process.
This is what is meant by the term 'lossy.'
Some JPEG optimisation programs allow you to adjust the 'quality' setting over the image, so some more important areas have higher quality than others. This is done either by specifying the important areas, or by the program working this out automatically (which can give good results, as the frequency data from the first stage gives a good idea of what quality that block needs).
This can be useful in some cases, although it is an abuse of the JPEG standard and the results will have higher file sizes than you'd expect had you estimated a file size in proportion to the number of pixels at each quality setting. If you are really fussy, you might be better off splitting the image up into sections, each with different quality settings, and recombining them within a HTML table.
You could also consider using progressive JPEGs, but bear in mind that they're less well supported by browsers than normal JPEGs. Only use this option if you're sure that the majority of your visitors will be using version 3, or above, browsers. Their advantage is that they give a good impression of what the final file will look like from the beginning of the download without having to wait for the entire file.
They also have a reputation for being a little bit smaller than normal JPEG files, but this is inaccurate. If your web graphics application is written correctly, the extra optimisation which causes this effect should be performed on normal JPEGs as well, so you should find that progressive JPEGs are slightly larger than normal JPEGs, since they actually contain more data.
When creating JPEG files, it's especially important that you check what your images will look like in the browser in a 256 colour screen, and on the PC or Mac whichever you're not using, since they store many more levels of brightness than GIF files and consequently, more possible differences on varying hardware. The best approach is to work in a 24bpp colour depth, and use the simulation features of your web graphics application to approximate how others will see your image while you're working on the optimisation of the graphic.
Your web graphics application should ideally offer one click simulation of 256 colour screens and Mac or PC simulation, so it's easy to see the effects.