Wesleyan UniversityDAC Home Page

dac > educational programs > learning objects >

Zoomable Image Information

As the DAC Digital Imaging Initiative moved to higher-resolution image capture in 2001, we experimented with various means of making detailed images available in pedagogically useful ways on the museum website. This page offers some technical details.

Our zoomable image page offered proof-of-concept for a client-side JavaScript application requiring no special server software, file formats, plug-ins, Java, or cookies. While (and since) testing this approach, we continued to assess multi-resolution file formats and image servers. Those formats can offer such features as draggability and non-fixed coordinates for detail views, but they require more server customization than was available for this test. The lack of a non-proprietary standard for such images further dissuaded us from committing to early adoption of any one contending format. As prospects for wide support of JPEG 2000 have begun to mature, however, we are likely to move to that standard for future pan-and-zoom image delivery (see notes at end).

Here's some information about this testbed as it was developed in 2001. The master source image began as a 5000x3750-pixel raw capture file made with a Schneider Makro-Symmar lens and a Better Light scanning back. Capture-stage color balance was adjusted with reference to a GretagMacbeth ColorChecker card.

After slight cropping of the master image as needed, square views were made at five resolution levels that zoomed in by a factor of about 1.8 each. Each of these views then was scaled to 400-pixel dimensions. This number of levels and these dimensions struck a workable balance by:

  • Enabling the highest viewing resolution to preserve resolution very close to that of the raw source image
  • Enabling users with less than huge monitors still to view and navigate through these detailed images
  • Enabling users with slow network connections to see selected details without waiting for long downloads
  • Producing a manageable number of component image files (341 before removing certain deeper-level duplicates; the comparable number with six zoom levels would be 1,365)
  • Allowing four deeper-level images to nest in each shallower-level image with a bit of overlap. This makes any one tiny detail visible in undivided form in at least one view. By showing points of reference in adjacent views' shared edges, this also helps users maintain their visual orientation when moving between adjacent views (partially compensating for the usability downside of non-draggable images with fixed coordinates).

Because it yields increasingly large numbers of component images overlapping by varying numbers of pixels at higher resolutions, this process has the added benefit of making the reconstruction of a complete image at full resolution too much work to be practical. This difficulty of reassembly can pose a useful disincentive to unauthorized use of images. One tradeoff in taking this multiple-file approach is the need for increased storage space. For example, after removing duplicate component images at deeper zoom levels, the Dürer image requires 262 JPEGs occupying about 14MB; a flashpix file made from the same master image came in at about 8MB.

All views are exactly 400 x 400 pixels. The full view was padded to square dimensions, views at the second level were cropped from each image corner, and views at each deeper level were taken from each successive corner, always with about 10 percent overlap at each level.

This procedure resulted in varying amounts of overlap between some adjacent views at higher resolutions, but its systematicity enabled consistent image production and reasonably straightforward navigation functions (with offset compensation for the trickle-down effects of cutting square second-level quadrants out of non-square full views). The resulting images were treated with Photoshop's Unsharp Mask (with parameters optimized for each level) and exported with the HVS JPEG plug-in, which at the time afforded optimal control over file parameters.

The consistency of this production workflow was designed to make semi-automated processing of source images possible. Having been developed by means of one-off manual work on the Dürer image used here to test this workflow (as well as naming scheme, scripts, user interface, and so on), these processes were designed to support automation with Photoshop actions and AppleScript.

As for the JavaScript itself, MuseZoom 0.9.7 (source code) works in most versions of Netscape 4 and Explorer 5 for Macintosh and as far we're aware--but with less extensive testing--in some Windows browsers; some Windows users may see layout oddities and (due to differences in monitor gamma, not script issues) images darker than would be ideal. All navigation functions except one (which jumps to a new area based on a click in the small image map) worked in early variants of Netscape 6 for Mac; that same function works on Windows in some versions of Netscape but breaks in IE5.5. (The script does not work in some minor browsers such as iCab, which thinks it's swamped with reentrant calls.) In its current state, MuseZoom is a development version that mostly did its job.

In 2001, implementing JavaScript-based image navigation bumped up against browser-dependent issues of the sorts noted above, but this was foreseen as becoming less of an issue in subsequent years as browser developers would implement standards-based Document Object Models (DOMs), event handling, and rendering of Cascading Style Sheets. As those practices have settled down to some degree since then, browser glitches for JavaScript applications have indeed diminished. Above all, this is due to improved browser support for the W3C DOM--a model for which such support was scarce in 2001, and with which this testbed had been made only partially compatible when its development was suspended (rather than chasing endless incremental DOM quirks) pending better compliance by browsers.

As a prototype, this testbed offered proof-of-concept for panning and zooming images with no dependency on proprietary file formats, plug-ins, Java, cookies, or special server software. The project showed that this was technically feasible even with 2001-vintage browsers. As to the future, growing support for two key standards now offers diverging paths and a clear choice. The first such standard is the W3C DOM, for which improved browser support now could make further development of this JavaScript tool easier than it was in a time of deeply idiosyncratic DOMs (and thus of branching code, obscure markup, etc.); but that path would entail further commitment to a non-standard, even if non-proprietary, approach.

The second key standard is JPEG 2000. After years of seemingly unrealized promise, this has begun to be a format supported by an expanding range of image-server software and image-viewer clients. As support for navigating within JPEG 2000 files becomes more widespread, moving towards that standard will be more sustainable than maintaining an in-house application--since an underlying collection of JPEG 2000 files should be usable down the road with various delivery tools. This will neatly address the need for such resources' digital longevity, something ill-served by reliance on proprietary file formats and less than assured by in-house systems of tiled files. Future navigable images from the DAC are quite likely to use JPEG 2000 files, probably delivered as part of a campus-wide implementation of an image server and related software.

Return to the zoomable image page.

Find at DAC Wesleyan  
Show   results per page. Searching will take you out of the DAC site; your browser's "Back" button can return you to it. Powered by Google.
press informationsite search tipscollection searchcontact info DAC Home Page site directorydirectionsDAC homeWesleyan home

Content created by the Davison Art Center and not identified as "Open Access"
is copyright © 1996-2013 Davison Art Center, Wesleyan University,
301 High St., Middletown, CT 06459-0487. Privacy Policy.