This is a resource page about graphics formats from the point of view of W3. Other good resources include the FAQ lists on graphics formats, color space, compression, etc.
To add information to this list mail timbl@w3.org.
On the web, images may be represented in many different formats. Clients vary as to the set of formats they support, and servers vary in the formats which they provide. The data is transferred in whatever seems to be the "best" format which the client and server have in common. The web standards do not specify a graphics format you must use.
In practice, the graphics formats you provide will be influenced by the availability in clients, the data size (and therefore transfer time), the image quality, and whether transparency is available, and whether the format is an open standard or a commercial one subject to copyright or patent fees.
Clearly, it is useful to have a lingua franca so that you know that if you support that, you will be able to read from or supply to anyone. For hypertext, HTML is mandated to be supported by all WWW clients, but for graphics there is no equivalent. Until December 1994, GIF played that role, but at that time Unisys's persiut of patent license fees moved it from an open standard into the proprietory domain. The following pointers are made available to help developers and information providers make appropriate choices.
Here is a summary of just a few of the graphics formats around.
Graphics Interchange Format is a commercial format which was widely use on the web, until atthe end of December 1994 Unisys announces that they would be suing for patent fees for all developers of GIF software, because of GIF's use of proprietory LZW compression. GIF is a proprietory specification of Compuserve Information Services. Here are some statements on the subject by others:
After GIF, there will probably bee GIF24
GIF had been used very extensively and is available (Dec 94) in all browsers which can handle graphics. It allows 1 bit transparency (a pixel is either transparent or opaque). It allows a palette of a maximum of 256 colors, so representation of 24 bit color images in GIF involves loss.
The JPEG (Joint Photographic Experts Group) standard is an excellent standard for most realistic images (photos for example, but not line drawings or logos). It uses a powerful, though nominally "lossy", compression method. JPEG is best suited for truecolor original images; avoid using it on images that have already been forced into a 256-color palette.
Using JPEG for a photographic image for example can produce 10:1 savings compared to GIF, as well as permitting much better display quality on truecolor-capable displays. Netscape handles inline JPEG; most older browsers need to use an external JPEG viewer.
The particular format usually used for JPEG-compressed images on the Web is JFIF. A newer format called SPIFF is under development; when released, it is expected to be compatible with JFIF readers.
Although the "baseline" variety of JPEG is believed patent-free, there are many patents associated with some optional features of JPEG, namely arithmetic coding and hierarchical storage. For this reason, these optional features are never used on the Web.
(Previously known as: PBF, Portable Bitmap Format.)
A new zero loss proposal by Thomas Boutell, which uses LZ77 compression, is alledged to be patent-free and to be put into the public domain. A deliberate replacement for GIF, PNG contains a number of enhancements. It allows true colour, including an opacity channel. Features Tom has been encouraged to include include gamma value statement, hypertext links, and progressive resolution.
Postscript is another proprietory format. However, use of the Postscript standard is free, and free software such as ghostview and Ghostscript is available to display it. Postscript is a turing-complete reverse polish programming language with drawing primitives based on Bezier curves. It can be extremely compact for drawings. For bitmaps, however, it has a hopelessly verbose format.
Postscript has the advantage that almost all applications can produce it, as it is a common printer command language. Howerver, often the postscript produced by applications has a lot of unoptimized header macro definition which can lead to enormous files. Another problem is that the exact definition of what should be in a postscript file for interchange is not defined. Browsers such as Midas allow postscript for embedded images.
TIFF, "Tagged Interchange File Format" suffers from its expensibility: there are extensions to TIFF suhc that it is not easy to know what application will accept what TIFF file. TIFF files are uncompressed, and if large must be compressed for transmission. The version adopted by NeXTStep/OpenStep allows a transparency ("alpha") channel which allows semitransparent effects which are powerful for icons.
The CERN HTTPD server allows images to be stored in serveral formats. For example, this allows a browser equipped with JPEG to get a faster copy of a file than a browser which only has GIF.
To set this up, make sure that the server knows (from the httpd.conf configuration file "Suffix" entries, or from the precompiled HTSInit.c) how to associate file extensions on your machine with the MIME type labels.
You can weight the quality of each type so that for example your server will preferentially send JPEG instead of GIF.
You could of course write a CGI script to automatically generate and cache alternative representations of your files.
Map *.gif /translate/*.gif Exec /translate/* /usr/local/cgi/translate
See the CERN HTTPD manual for how to create ISMAP clickable images, etc.
This is very incomplete, and I hope to be able to fill it out with pointers to more information: let me know of resources for these or other graphics formats.
webmaster@w3.org