Delivering the Graphic Goods

By Phil Stevens

A picture's said to be worth a thousand words. But can you get a 1KB graphic to say as much as a couple hundred words of text?

Delivery bottlenecks can be ulcer inducing for administrators and end users. The most generous contributors to those bottlenecks are the very things that make the Web the richest content space on the Internet: graphics and multimedia.

To make page loads snappier, look at several areas where speed might be improved: image file optimization, site layout, and server performance tuning.

Image optimization technologies Various vendors See below for URLs and pricing details.

Image Compression from LuraTech and Elecard

If you need to shrink photographic images or documents at high ratios and can't accept the quantization artifacts (blockiness and loss of edge data) inherent in lossy JPEG compression, try wavelet technology. No top-level MIME types currently exist for browsers to render these images, so you must display them with plug-ins or helper applications. But because wavelet compression uses mathematical functions that introduce fewer errors in the quantization window, it can preserve more visual detail while creating dramatically smaller files. LuraTech provides a series of wavelet compression tools, and a stand-alone encoder and Java viewer are also available from Elecard.

I tried LuraTech's free SmartCompress stand-alone, the LuraWave Photoshop plug-in ($79), a free Linux version of XV with the LuraWave wavelet compression engine, and the free Java viewer and Netscape plug-in. I also downloaded a shareware ($20) Wavelet Image codec and free Java viewer from Elecard.

LuraWave SmartCompress installed with no fuss, and is fairly full-featured for a freebie—its only limitations are image size (800 x 600) and 24-bit color on input reduced to 8-bit. The app supports several popular formats and can convert among them. To save an image as a wavelet file, specify either a quality factor, a compression ratio, or a target file size. Installation and image saves with the LuraWave Photoshop plug-in were also simple and intuitive, and the results were stunning.

The LuraWave-enhanced XV trial started smoothly with a freshly unpacked tar file on a Red Hat Linux 6.2 system with Gnome and the Enlightenment window manager. Figure 1 shows a side-by-side comparison of an image compressed with the wavelet functions versus with JPEG. When I compressed an image with the wavelet functions and compared it to JPEG, even at extreme rates of 150:1 the output image was still very intelligible. A JPEG at 125:1 looks like a low-rent Mondrian impersonation.

Working with the Elecard app was a bit slower and I wasn't able to specify a compression ratio directly, so I had to adjust an arbitrary compression factor and guess a lot. The two-pane document interface was a nice touch, allowing a preview of the processed result next to the source. Image quality was similar to LuraWave, with a few more noticeable artifacts at higher ratios.

The Elecard algorithm's visual "gestalt" was still convincing at the extreme compressions. This would probably depend on the source, and is a purely subjective analysis. But this observation points out the greatest strength of wavelet compression: The details that matter most to the human eye can be mostly preserved, even when nearly all the original pixel data is gone.

Just In Time with LizardTech's MrSID

Another way to keep pages slim is by using thumbnails that can be linked to larger and higher resolution versions of the image. The downside is the loss of page focus when the user clicks through to a linked image. You can remedy this with a frameset, but that's like inviting a crocodile into your home to remedy a mouse problem.

A more attractive way to zoom thumbnails interactively is the use of just-in-time (JIT) image delivery. Conceptually, JIT image servers maintain "layers" of a graphic file, starting with the small low-res thumbnail that gets served with the page, and progress down with increasing resolution or display size. The client side is typically a browser plug-in or a Java application that takes user input and renders the layer as the server sends it. The browser experience is visually fast because only a single, small (typically 20KB or smaller) file is served when the user clicks on the thumbnail. High compression ratios are also used for transfers to the client, and additional bells and whistles like frame animations and 3D walkarounds may be included in the lightweight formats.

Several vendors are offering JIT image servers, including LizardTech. I downloaded the free MrSID Image Server and installed it on a Red Hat Linux machine. It's available as a compressed tar archive, and the install went successfully on the first try.

I had the MrSID scripts, executables, and Java classes in a set of directories under my Web server's document root. After a few minor adjustments to my Apache configuration, it was running happily and serving "sliced" zoomable demo images to various clients. With MrSID Photo Edition ($49 or free for non-commercial use) I was able to encode a 900KB scanned photo as a 46KB sid image, which I then FTPed to the Web server.

I then connected to the MrSID Image Server admin page at my Web server's address, and used the forms provided to enter the image and associated information for retrieval. Then, I pointed a couple of different browsers to the site—instant zoomable thumbnails were displayed, and the image slices came across as tiny 2KB to 3KB files via the plug-in. Visual quality was perfectly acceptable, and looked like a lossless JPEG. Rendering in the Java applet was slower, and there was also the additional overhead of serving the applet itself. Without the plug-in, the slices were served to the browser as JPEGs, and the file size was up to ten times larger depending on the zoom level and display dimensions.

Other products include Xippix ImagePump, MGI Software's Zoom, and MediaBin by Iterated Systems. Expect more on the JIT image horizon: The Digital Imaging Group has released an Open Source protocol for Flashpix object transport with interoperability guarantees, called the Internet Imaging Protocol (IIP). Many digital image acquisition and transfer hardware vendors are using the Flashpix format for layered, resolution-independent imaging. IIP is designed to allow client/server negotiation of transform objects and metadata to accompany image information.

Accelerating with the Squid Web Proxy Cache

Page loading can vary across browsers and platforms, depending on plumbing issues such as socket limits and keep alives, and the way their rendering engines treat display objects. You can design a caching server to feed content to the requesting browser so a page is viewable more quickly than if the same page were served directly from a Web server.

The popular UNIX-based Squid Web Proxy Cache has an accelerator mode designed for this very purpose. I installed Squid 2.3 on a Linux notebook using the source distribution. This method is not for the faint of heart, but once completed, the setup for cache acceleration is easily enabled in the configuration file. I had to manually create a couple of directories and set permissions. After the first few attempts to start, the cache bombed out with multiple errors. Fortunately, the error messages were informative enough that I could fix the issues, and in about 10 minutes I had a Squid accelerator running on my LAN.

I set up a test bed with the Java-based VeloMeter load simulator from VelociGen to retrieve the same group of URLs from the Apache server and the Squid cache. With a run of 50 users cycling 500 times through two pages, each loaded with about 200 inline images. Squid served up the requests nearly 25 percent faster because the accelerator retrieved the files directly from RAM, instead of seeking them out and reading from disk as a traditional Web server. When I added a Perl script request to the batch, the average turnaround for both platforms slowed to a crawl as the Apache server was overwhelmed by all the script execution processes, but the Squid performance was still better by almost 15 percent.

Using Squid to help out one or more Web servers could be a valuable tool, but you'll need to spend time on setup and system tuning details.

Intelligent Caching

Client-negotiated optimization is a new development in the quest to put content out more quickly. The first commercial entry in this realm is Workfire Server. It's currently available for Linux, with beta versions for Solaris and NT. I installed it, as with Squid, on a separate Linux machine—it's possible to run it on the same physical host as the Web server, but you'd better have loads of headroom. The one on my LAN doesn't, and I wouldn't expect any appreciable benefits from taxing the server with an accelerator stealing cycles from the very application it's meant to accelerate.

Workfire installation process is straightforward, with a series of queries to help the sysadmin set it up correctly the first time—far easier to get up and running for a non-propellerhead than the Squid distribution. If you need to make changes, these are handled in text-based configuration files.

It took a couple of false starts before I got the DNS kinks worked out. I ran two sets of tests with smaller user pools walking the same URL lists as the Squid trials. Using the image-laden HTML pages, the plain-Jane Apache server (AMD K6-200) pretty much smoked the shorts off the Intel Celeron 400-powered Workfire accelerator, by a factor of almost three to one. But when I added the Perl script request, the adaptive caching power of the Workfire algorithm really shone.

On its own, the overloaded Web server began to swap out script execution and bog down—maximum turnarounds soared past five seconds while Workfire was able to smooth out the peaks and maintain acceptable latency for all connections. On a high-volume site with lots of CGI executables this feature alone could save the bacon.

Testing the caching and speed enhancement capabilities of Workfire on a LAN doesn't tell the full story, though. With stopwatch on screen I started a fresh browser instance with the local cache wiped clean. I then loaded a big, ugly HTML page comprising dozens of inline images, nested tables, and large blocks of flowable text.

Across versions of IE, Netscape, and Opera, my admittedly crude measurement showed that pages were readable, although not completely loaded, an average of 10 to 20 percent faster with Workfire in the loop, across 10/100MB Ethernet. The same ratios translated to the copper standard, 40KB phone lines can signify several seconds of difference between display times—a critical interval for surfers looking for instant gratification. If surfers can start reading or interacting with the content while images are still loading and rendering, you're less likely to lose them to impatience.

Conclusion

Whatever method or collection of methods you choose to deploy, optimizing your delivery of graphics and other multimedia objects will earn you the gratitude of many. The whole Internet will benefit if Web designers and administrators trim the payload associated with images. Some day, a 6KB picture on the Web will actually be worth a thousand words.

---

Phil is a freelancer, specializing in network consulting, Web development, and digital audio. Contact him at mudshark@euphoria.org.