For a brief article on the topic, please follow this link.

This is a demonstration of embedding images in a self-contained
HTML document.  The images on the left use an img tag.
The ones on the right are embedded in this file.
The data for the embedded images are stored in ascii-encoded strings and are unpacked
dynamically.  This method works for Netscape, Mozilla, Firefox, and Internet Explorer.
The run-length encoding (RLE) is used less for compression
than it is for savings of the number of table cells needed to represent all
pixels.  With natural images (like the top one) you'll see little to no space saving
and possibly some inflation.  With artificial images, like the one on the bottom,
you tend to get better compression results.

Why RLE:
Runs of repeated values are represented as single, wide table cells
whereas runs of disparate values are represented with one table cell per pixel.
This technique for embedding image data will work across browsers, but does
have a limitation:
   Image size must be kept fairly small if you don't have truly sparse
   data, as the 2nd example does.  Unless the target machine is fairly beefy,
   you don't want to go over 128x128 in most cases. 64x64 images unpack
   pretty quickly whether or not the data is sparse.

A note on printing: there is an optional 2nd argument to the JSImage.display()
method that indicates whether or not the decoded image needs to be printable.
The tradeoff is that printable images require more DOM structure and thus take
longer to unpack.  So if printing is not an issue, pass false or no argument.
If it is an issue, pass 'true' as the 2nd argument to JSImage.display().
The first example was displayed as a printable image, the 2nd not, so if you do a print preview
you should only see the first image.

The only real penalty you pay for going from 6 to 8 bit data is a slight increase in
data size.  I was not able to detect any real performance loss.

For other examples of usage of this technique or to some other projects
of mine, go to http://www.bennherrera.com.

For the source code to the java program used to convert the image data, please
email me at benn@bennherrera.com.
Please include information as to your project or intended application in your message
(as opposed to just 'please send the source code').  This serves two purposes:
1) It satisfies my engineering curiosity about how people are using this
   (I do NOT restrict content or usage - 1st Amendment all the way)
2) It can save you some trouble. I've been dealing with the issues
   surrounding this for some time, and often a few early suggestions can prevent
   hours of debugging and frustration.

Below is a demonstration of image re-use without the need for repeating the decoding pass.