Fitting images to the so-called "Netscape browser-safe" 6x6x6 palette - a recommendation that's frequently seen for use on the WWW - may not be the best choice.
This note discusses the issues, and suggests ways of recognizing the different situations.
See Conclusions.
Based on a usenet discussion in June 1997, reviewed from time to time since, and last worked-over in Sept 2000. My thanks to (in chronological order) Gary J. Weiner, jeremy howard todd, Lanny Chambers, David Matthewman, anyone else who got missed, and especially to Tom Lane for some spot-on suggestions. And later to Greg Roelofs for filling-in details about PNG.
In this note I've concentrated on principles rather than techniques. Everyone will have their own favourite image software and ways of using it, and in practice (as we will see from the link to Todd Fahrner's page) quite subtle techniques are possible; but the principles are still the key to understanding why there is an issue, and ways in which to address it.
Quoth Lanny Chambers: "Folks need to realize that, on the WWW, simple is good. Gratuitous ornamentation is not."
Netscape, and some other browsers, particularly when displaying in-lined images or backgrounds, are known to use a particular 6x6x6 palette, based on RGB values that are multiples of hex33 (decimal 51). It is often claimed that converting images to this palette will produce improved results on popular browsers. The conclusion reached from this discussion will be, however, that the reality is somewhat more complex; fortunately, the different situations aren't too hard to recognize, and the potential benefits of making the right choice will repay the little extra care.
One key issue is the image format that is in use. GIF is an "indexed color" format, based on an 8-bit palette. PNG also has an 8-bit-palette "indexed color" format, and this is the type of PNG image most commonly recommended for WWW use: the "truecolor" PNG format, although excellent for archival purposes due to its lossless nature, is generally less suitable for WWW use, where JPEG offers a more flexible (though lossy) tradeoff between image quality and file size. Remember, JPEG is not a palette-based format.
Just a word now about the accuracy of this term "the Netscape browser-safe palette". Well, the palette isn't by any means exclusive to Netscape - other browsers use it too, though not all of them, and especially not if the display system isn't an 8-bit one; and this palette isn't always used, even by Netscape. - on X Windows based 8-bit-depth systems, for example, Netscape may (and often does) find itself unable to allocate 216 colours, and falls back to allocating a 5x5x5 or worse. Browsers may use different display techniques for rendering an individual image, for rendering an image background to an HTML page, and for rendering a collection of images in-lined into a page, and these techniques differ according to browser version, platform, and the colour-depth of the available display.
Taking a GIF that has been dithered to 6x6x6 and trying to display it in such a situation causes what Tom Lane neatly described as a "double whammy" - the image gets re-dithered to the new palette, with results that are much worse than they need have been in this already adverse display situation.
So, "the Netscape browser-safe palette" isn't "the", it isn't specifically "Netscape", and it isn't truly "browser-safe". The word "palette" is accurate, though ;-)
One often sees recommendations that are (whether tacitly or overtly) based on a desire to improve the result for 8-bit-depth displays, which might be in use either from necessity or from ignorance of alternative configurations, used from one of the mass-market browsers.
They therefore recommend fitting GIFs to the customary 6x6x6 palette.
One needs to ask, though, what are one's priorities:
to get best results for those users who can use the best results, leaving those who have inferior systems to do the best they can with the material provided, or
to work-around the shortcomings of certain mass market browsers, particularly on 8-bit colour systems, while accepting the risk that this will impair the results for those who cared enough to get a better browsing situation (truecolour display, better-designed browser, purpose-designed helper application etc.), plus the additional risk that it will seriously impair the results for readers in certain low-end situations (specifically: 8-bit-depth X-based displays).
These two aims are incompatible (except for a few special kinds of image). Thus, one may need to compromise, by trading off the display quality in the one case against that in the other. This note can't tell web authors what their priorities ought to be, but it does suggest avoiding choices that make for significantly worse display in one case while obtaining only marginal gains in the other.
The customary advice - the one that I've already mentioned - aims at the second option. That may not be the best choice; or you may be able to find a solution which meets both criteria, as we will see.
The point has already been made that GIFs and indexed PNGs are palette-based image formats, whereas the JPEG image format is fundamentally different. Truecolor PNGs are not considered here in any detail. For brevity we will use the term "indexed images" to refer collectively to GIFs and indexed-color PNGs.
Are you designing indexed images from scratch, or are you making them out of some other kind of material? There is a big difference.
If you design them from the outset using only colours from that 6x6x6 palette, I don't see a problem. You will have a compact image file, that correctly represents your original design, and is capable of being rendered faithfully on a browser that uses the same 6x6x6 palette (as faithfully as browser/platforms ever do, given the fact that only PNG offers gamma correction, and even there it is not widely used in a WWW context). [Aside - don't overlook the fact that even better file size savings can be made if you reduce the number of colours used below successive powers of 2, as long as you have software which takes advantage of this.]
As already mentioned: on some display systems (e.g X Netscape) the display might be done with a different palette, e.g 5x5x5. Your images would then get dithered by the browser; but users who are in that position are accustomed to this happening, and there is little you can do to improve the results they get. By wrong actions, though, you can seriously impair the results for them - specifically, by sending them images that have already been dithered to a different palette than the one they are using.
The issue of gamma has been potentially relevant to the WWW for as long as web browsers have displayed images, but as yet there had seemed little enthusiasm for solving the problem. Users of PCs and Macs (which assume quite different nominal gamma values) still comment adversely on images that were intended for the other platform! I have a small page about gamma, and to learn more (it gets very technical!) about this issue you could visit Poynton's Color FAQ.
Of the image formats discussed in this note, only the PNG format has provision for specifying the nominal gamma. With appropriate software and a calibrated display, this would allow a much more uniform and predictable rendering of images. Unfortunately, few browsers support this feature of PNG (yet?).
Gamma issues are also relevant to the colour specifications used in CSS (and the now-deprecated features of HTML3.2). CSS definitely calls for gamma-correction of its colour specifications, although this is not widely implemented (yet?). HTML colour handling is less well specified, and should anyway become less important with time.
The consequence of all this is that getting an image that exactly colour-matches some specified colour (Pantone number, say) isn't feasible in a WWW context. Getting text to precisely colour-match the images is also impractical. So the bottom line, as so often on the WWW, is to go for a flexible design that does not rely too heavily on the details of colour-matching between different components of a web page.
The key problem arises when you take some existing image and represent it as an indexed image format. First and foremost, and vitally important, is to determine whether your material is better represented as a JPEG. Tom Lane's JPEG FAQ gives excellent advice on this, and it's usually quite obvious whether a given image is more appropriately represented as a JPEG on the one hand, or in an indexed format on the other hand. Using the wrong representation, JPEG versus GIF/PNG, is the worst mistake one can make - worse than any of the detailed issues we are looking at here. (The corollary to this is that purpose-built web graphics should be designed from the outset to the strengths and limitations of one format or the other. But we are here also discussing how to adapt an image that was not purpose-designed for the WWW).
Reminder: JPEG does not use a palette: it represents images in a quite different way, which eliminates the need to reduce the image to a limited palette, but which is less able to represent hard edges. Do not try to convert a JPEG into a palette-based format such as GIF, or vice versa: instead, go back to the original material (24-bit high-quality archived original, say) and make the web image from that. (This is all explained much better in the JPEG FAQ, which you should definitely read.)
There's one consideration that might swing things towards using an indexed format, and that's if transparency is desired, since JPEG format does not support transparency. Transparency is usually best avoided for photo-like materials, though. Due to GIF format's lack of an alpha channel, transparency works best when the image content has a hard edge (PNG format can handle transparency with soft edges better, although there's little point in using this until a reasonable proportion of browsers actually support the alpha channel). Sure, you could make your image with a soft edge against your intended background colour, and many authors do that: but there will be situations on the WWW where readers will be displaying your images against their choice of background colour, and then the image will appear to have a curious-looking halo around it.
OK, let's suppose you decided indexed-color format is appropriate. There are basically two questions:
From a theoretical point of view, the adaptive palette is the representation that most accurately represents the original image. The problem is that browsers might fail to take advantage of that, and produce results that are somewhat inferior to an image that has been well-fitted to the browser's 6x6x6 beforehand.
Dithering will inevitably cause the size of the GIF to be larger, maybe significantly so, which is always a disadvantage on the WWW: the question to ask yourself is, Does it produce a corresponding benefit?
If, in fact, the image looks so much better with dithering than without it, you might want to reconsider that original choice between GIF and JPEG - it's quite possible that you're dealing with the kind of image for which JPEG would be the more appropriate representation.
The advice that is (as I said) frequently offered is to fit the image to that 6x6x6 palette, it usually being assumed that this would be done with dithering. The advice is specifically targetted at the 8-bit Netscape-like viewing situation; well, one thing to say about that is "there's still quite a lot of it about", which you might feel is what you are aiming for - but you risk inferior results in other browsing situations: newer systems are rarely limited to 8-bit colour depth, and more and more users are learning how to take advantage of that. The consequences of that "conventional" approach are:
you produce an inferior result in situations that would have been able to use an adaptive palette. The effect is particularly crass for greyscale, or images that contain many subtle shades of the same colour.
your image is already dithered, so in those situations where a different palette (e.g 5x5x5) is used by the browser, the result will be double-dithered, which produces results that are even more dreadful than what those users (e.g X Windows) have learned to put up with.
The second disadvantage can be circumvented by disabling dithering when you fit to the 6x6x6 palette. The colours will shift to the nearest palette colour, so the image won't be faithful to the original, but it may well be apt for its purpose in spite of that. In effect you have produced a new image, whose adaptive palette is the same as the 6x6x6 palette. So, for WWW use it's often a reasonable compromise to accept the colour shift.
If, after all, you decide that the colour shift is unacceptable, then I would suggest that you consider using an adaptive palette, still without dithering. The result will be a compact file that well represents the original, and that is capable of being rendered well by those browsers/plaforms that are able to take full advantage of the image. The worst that can happen on less-performant browsing situations (i.e typically 8-bit-depth displays, especially when viewing several images in-lined to a page) is that they get somewhat crudely dithered by the browser: if the reader is interested in seeing them better, they would be well advised to view them individually, or to fire up an external viewer application that can control the palette.
This document has not explained how to use any particular image manipulation package. It's assumed that you know how to use your chosen package in terms of the technical details described here. If, in fact, your chosen package hides away the details of what it's doing, in terms of palette control, dithering etc. then I'd recommend that you examine it more closely, or consider getting something more suitable.
It's a serious mistake (and one that is often seen on the WWW, unfortunately - indeed in the early days I'm sure I made this mistake often enough myself, through ignorance) to start from a high-quality, say 24-bit, image format and reduce it, whether deliberately or inadvertently, to an 8-bit format and then lose the original. Some image manipulation packages may even do this by default, without telling you. Once that has happened, your image has been irretrievably ruined for any further manipulations. You should look upon image reduction, to a specific palette, as very much a last step in the process of publishing a GIF to the WWW: keep the original in your archive so that you can go back to it for any further processing (resizing, refitting to a different palette, conversion to JPEG etc.) that you might decide to do later.
When fitting your image to a specified palette, or producing a JPEG if that was considered more appropriate, it is vital that you start again from a high-quality original, and do the reduction from that. Trying to massage an already-reduced image to a new palette, or to a JPEG, is at best a third-rate damage-limitation exercise.
This note hasn't dealt with a number of other image formats, such as SVG, MNG, JNG, because - interesting and valuable though those formats are in theory - my perception is that support is not yet widespread enough for it to be useful to discuss them here.
Tom Lane's JPEG FAQ, already recommended, cites some excellent resources.
See also the introduction to PNG.
Todd Fahrner (formerly of Metrius/Verso) offers some subtle advice in Dithering: good, bad and ugly. The key to the techique (if I can summarise it briefly) is to maintain flat areas as far as possible without dithering, using the "web safe" colours, in order to avoid the spotty appearance that otherwise occurs. However, in transition areas, the spottiness is much less noticeable, and needs to be used to achieve colour transitions without producing banding effects. Anyhow, read the article (and get the software) for yourself if you're interested.
Greg Roelofs offfers a gamma consistency test.
A Webmonkey article, Death of the Websafe Color Palette?, explores some issues with the "safe" palette, including details of rendering on 15- and 16-bit color-depth systems. I found myself uneasy with their detailed approach, but it does, after all, contain some useful strategies (numbers 5 and 6, to be specific) as well as mentioning, apparently in all seriousness, some which I would have thrown right out (such as confining oneself to 22 supposedly really-safe colours!). The art of producing images for the web is not to achieve an exact colour/match, which seemed to be one of the things on their unstated agenda - that's impossible in a WWW context anyway. Rather, I'd say it's to produce a flexible result that's capable of delivering a pleasant, attractive display across a wide range of browsing situations, while optimising the size of the image file(s).
One of the points that came out in their presentation was that the same nominal colour might be rendered slightly differently as a background image than in an in-lined image. This is certainly something one would want to take into account in designing a web page where an in-lined image is supposed to fit seamlessly onto the background, because the eye is very sensitive to even quite a modest edge. So, go for a design that avoids the problem: one possibility is to make the inlined image transparent where it's meant to fit into the background. Or to only attempt it with colours that are unlikely to cause a problem (full black, full white, etc.). Or to make a "feature" of the image border, instead of trying to hide it. Well, in the end it's your choice: I'm only offering suggestions.
Finally we have the "conventional wisdom": fitting to the 6x6x6 palette with dithering. It increases the file size, risks inferior results on high-end browsing situations, and it gives absolutely dreadful results on non-standard low-end browsing situations such as the X Netscape 5x5x5 palette. All for the benefit of slightly improved results in one particular kind of minority browsing situation.
OK, this is the compromise that you have to make for yourself. But as browser design improves with time, you might find yourself re-making all your images to remove this dependence on the properties of specific browser implementations; whereas, if you take the appropriate choice from the options listed above, I reckon you'd have little need to ever have to re-make your images just because a better browser had come out.
Original materials © Copyright 1994 - 2006 by A.J.Flavell