Programming Examples: Image Filtering

We all like a nice looking web page, right? One of the many ways to spiff up a web page is to include transparent gif images so that they seem to be an integral part of the graphical display of material. Another technique to improve web page appearance is to ensure that your images don't suffer from aliasing artifacts like "jaggies". Unfortunately with gif-format images use of these two techniques can sometimes be mutually exclusive. There are three pieces of background information that we need before we can clearly describing the problem of using gifs to contain images that have transparency and anti-aliasing.

1. The Limitations of Pseudo-Colour

When you try to incorporate a gif image in your html pages, web browsers viewing the page try to load and display that image. If you are using a 24-bit colour display then this is a simple process. Some computer displays provide less than 24-bit colour. Often the technology involved is what is called pseudo-colour display; you can use 24 bits to describe a colour, but the display can't show more than a small number (typically 256 or 65536) colours at the same time. When a colour isn't available to a web browser the browser can do one of three things:

1. Pick available an available colour from its current colour palette that approximates the 24-bit colour value specified in the gif image, and use that colour instead.
2. Use a combination of colours to paint a collection of pixels needing the unavailable colour. This technique is called dithering.
3. Sacrifice some other colour in the palette to make room for the desired colour. This could cause other pixels being displayed in the browser or elsewhere on the screen display to change their colour. In extreme cases were most of the colours outside of the browser display area temporarily change this effect is sometimes called flashing.

Which of these techniques will be used and how effective the results will be in approximating the proper appearance of the gif image varies from image to image and from browser to browser. Techniques for improving the odds of getting a good colour mapping are beyond the scope of the current discussion.

2. Transparency in GIFs

When you decide to make a gif transparent, you pick a single colour value and declare it to be transparent. When the gif is painted on the web page by your browser, any pixels that use the transparent colour value are totally invisible; to all intents and purposes those pixels were never painted in the first place, so the background colour or image will show through. All the non-transparent pixels are painted into the display as you would expect.

3. Anti-Aliasing

The way you remove the jagged edges in a picture with highly-defined lines or curves is to average out the colour values of some of the pixels on the borders. When you produce a gif image, the colour averaging is performed against nearby pixel values which typically have some particular background colour. For example, if you have a bright red object on a white background, anti-aliasing techniques will produce pixels on the border of the object that have varying shades of red or pink. These pixels will make object borders in the image appear reasonably smooth.

With that background information in place, we can now describe the transparency+anti-aliasing problem. If you try to use anti-aliasing techniques with a transparent gif image, the anti-aliased pixels on the border of an object in the image may have the wrong colour. Here are the situations that can cause this to happen:

• Let's say you have a solid background colour in your gif against which you perform the anti-aliasing. The background colour you chose is the same as the default background colour in your web browser. If somebody viewing your page doesn't have the exact same default background colour, then the border pixels in the image will obviously be the wrong colour.
• Maybe you think you'll stack the odds in your faviour by using the BGCOLOR attribute in the BODY tag of your web page to specify the background colour for your web page. That way you'd figure that the user will see exactly background colour that you used when producing the anti-aliased gif. Unfortunately, if one or both of you are using a pseudo-colour display, you may not see the exact background colour value that BGCOLOR specified. This isn't a hypothetical situation. If you take the default grey value used as a background in Mosaic and specify it as a BGCOLOR value for a page viewed in Netscape, the actual grey value displayed by Netscape is obviously lighter on an 8-bit colour Sparc 5 display.
• What if you want to use your anti-aliased image on a page with a dramatically different background colour or pattern than the background you had used when producing the image in the first place? Then people viewing your page will notice that the colours of the border pixels are entirely incorrect.

Here is an example of a gif image that was anti-aliased against the default grey background typically displayed in Mosaic. If you are viewing this page in a browser that supports BGCOLOR then background will be white, the image will be red, and there will be a greyish band of pixels around the borders of the lines in the image.

So, what is the solution? The proper solution is to construct images in a four-channel colour format so that you can specify a degree of transparency for border pixels. In other words, you don't average the colour of border pixels on an object against the background colour. Instead, you make the border pixels more or less transparent according to how much of the pixel contains a portion of the object. That is basically what anti-aliasing is all about.

While it is best to generate the 4-channel image from the original artwork, sometimes for simple images we can fix the problem after the fact. In the image shown, we know that our "true" image is based on a single colour value, and the background was also based on a single (different) colour value. We can use the amount of colour averaging in the border pixels to reconstruct a reasonable approximation of the corresponding degree of transparency. Note that this approach generally wouldn't be feasible if either the object or the background contained a pattern using more than one colour. Also note that we have no way to do this within a gif file itself; a pixel is either totally transparent or totally opaque, we can't have different levels of transparency.

If your browser supports Java applets, here is the output of an applet that estimates the transparency. The applet is actually used twice. The first image uses a fudge value of 0.80 and results in thin lines that suffer from the jaggies, while the second image uses a lower fudge value of 0.40 to get thicker lines and slightly less-obvious jaggies. If the fudge value were dropped further the lines would get even thicker and would be more noticeably fuzzy at the boundary. By doing this we are telling the applet to recognize a wider range of pixel values as being close to the single "true" colour value used by the original image before any anti-aliasing techniques were applied.

The way the applet works is as follows:

• Get the applet parameters that specify the image, the background colour, and a fudge parameter (described below).
• Create an image filter that takes the RGB colour value of a pixel, converts to HSB, and then uses the saturation component to determine the transparency. This value is adjusted divided by a user-supplied fudge factor that estimates the true colour saturation of the original object. This could have been worked out statistically, but it would have made the source much more complicated.
• Take the specified image, filter it, and paint it over the background colour.

To show that we really do have clean borders with varying amounts of pixel transparency and not just something that looks good against a white background, here is a slight variation of the applet source to paint the image against a background pattern that is scaled to fit the entire applet display area:

We've just seen an example of the problems faced when creating images without considering the limitations that a web user may face in viewing that image on their particular computer with their particular browser. As a closing note we must also realize the importance of considering possible interactions between a Java applet and that same environment. To see an example of what I mean, move your mouse to place your cursor in one of the applet regions on this page. Once that is done, leave the cursor where it is and try using keyboard methods of moving up and down through your web page (eg: Page Up, Page Down, Up Arrow, etc.). You might find that they don't work until the cursor is moved out of the applet region. Why this happens will be a topic for another programming example.