Add to bookbag
Author: Michael Greenhalgh
Title: Learning from Images over the Web
Publication info: Ann Arbor, MI: MPublishing, University of Michigan Library
September 2002

This work is protected by copyright and may be linked to without seeking permission. Permission must be received for subsequent distribution in print or electronically. Please contact for more information.

Source: Learning from Images over the Web
Michael Greenhalgh

vol. 5, no. 3, September 2002
Article Type: Article

Learning from Images over the Web

Michael Greenhalgh

The Sir William Dobell Professor of Art History
The Australian National University
Canberra, Australia
Server (ArtServe):


This paper will review the use of digital media and the web in learning. It will use examples from Art History, but its discussion of the various technologies is relevant to any discipline using images. The problem with commercially available software is that it is not tailored to teaching and learning, so specially written programs/scripts are required to prepare sets of images for lecturer/student use. Hence this paper will discuss various programs/scripts written in-house for just this purpose: IMAGE-SERVE, to prepare image databases for web display; RICH-IMAGE, for writing text-rich catalogues associated with images for the web; LIGHT-TABLE, for organising images for lecturing purposes; and then RDBWEB, which allows both the writing of image databases over the web from an existing collection of images, and the populating of a database from web materials.

The paper addresses the question: if the web is to replace 35mm slides in regular lectures and seminars, then what are the other value-added aspects of the technology? The paper continues by considering types of images which add more "context" to artworks than is possible with "flat" slides, assessing the viability of panoramas (linked, hotspotted, or stand-alone), stereo, and virtual reality (in the shape of VRML). It concludes with a question: will the classroom survive in any form, or will it soon be replaced by a computer (or some other display technology) fed by the web?

.02 Introduction

The web is now accepted as potentially a useful learning medium, and one of its attractions is the ability to handle multimedia (- still images, including panoramas and imagemaps, sound, video and even various computer-constructions such as VRML) from a consistent interface that works with all machines, namely the web browser. Given the flexibility of this "window", it seems unlikely that developers will ever again need to resort to stand-alone programs, and thereby deny themselves the flexibility, richness and variety the web now offers. Multimedia is generally recognised as a useful supplement to teaching and learning, whether in museums or in academic institutions; but both its penetration and knowledge of its likely effectiveness are patchy [Marcia J Bates, Catharine Hulsy & Geoffrey Jost, "Multimedia research support for visiting scholars in museums, libraries, and universities", Information Technology and Libraries 21.2, June 2002, pp.73-81].

The discipline of Art History is perhaps facing a dilemma in the presentation of image lecture materials: slides are expensive to purchase, maintain and replace; but although the web already offers a suitable delivery medium for illustrated lectures, appropriate software is not yet available. Packages such as WebCT and Blackboard [Blackboard - - and WebCT -] offer channels for students to learn, but they are not set up to deal adequately with multimedia (such as the image-intensive work needed by art historians), nor are they able (or intended?) to facilitate teaching in a lecture theatre. Indeed, there is a great difference webwise between learning and teaching: to learn one may ferret around a website or sites, not necessarily in any particular order. Serendipity may rule and triumph in searching a library or the web (and teach the student something in the process), but it is unprofessional in a lecture. It is impossible to leave students to make cogent sense of the web via search engines, which are imperfect and unlikely to improve until users produce better-structured web pages [Mei Kobayashi & Koichi Takeda, "Information retrieval on the web", ACM Computing Surveys 32.2, June 2000, pp.144-73]. The problem is not the quantity of images available (this continues to increase), but the need to regiment and index them in various ways. My scripts and programs detailed below exist because of the need to do this at the level of individual machines; but given that it is unlikely that individual "image generators" will develop suitably rigorous methods, it is at the search-engine level that the techniques of librarianship are needed [cf Helene E Roberts, "A picture is worth a thousand words: Art indexing in electronic databases", Journal of the American Society for Information Science and Technology 52.11, Sept 2001, pp. 911-16] - precisely because the digital age highlights their organisational skills [Deanna Marcum, "When Everyone Will Be a Librarian: The Future of Libraries", JAHC 5.1, May 2002 at].

This point needs emphasising: having accessible websites with the necessary images is but the first step in lecturing using the web. For to teach using web multimedia, "regimentation tools" are needed. The visual materials must be to hand - all the ducks must be in a row before the lecture starts, since the students can surf the web for themselves, and need their lecturer to have everything assembled (after all similar skills to those we demand of a student essay or presentation). This is especially the case in disciplines such as art history, where the images, usually shown two by two for comparative purposes, are the primary documents. Although there are myriad software packages to aid the manipulation and display of individual images on computers, none are set up explicitely to aid presentation of large quantities for comparative purposes via a web browser, and so I have commissioned a series of software tools to help with the important tasks required to prepare image databases using the web, and then the selection of images from these databases for use in the lecture theatre.

Various educational institutions have mounted sets of lecture-images [excellent examples include the "Renaissance to Modern" course at Wisconsin -, or the course in Islamic art at Colorado College -], and the art-historical community is beginning to gather very useful suites of images for teaching use [such as the AMICO Library - - the Art Museum Image Consortium "enabling educational use of museum multimedia"], but most lecturers will want to "roll their own" until much greater quantities of images are available over the web.

The aim of these software tools is wherever possible to use the web as the vehicle for preparing and displaying images, and never to use proprietary packages where this can be avoided, the argument being that simple flat-file databases defined, edited and interrogated via perl scripts over the web are more flexible than proprietary packages, and don't get adventitious and unnecessary upgrades. Getting locked into proprietary packages can stunt development and expansion, as well as being expensive financially.

The examples below deal with "ordinary still" images; but the same techniques work well with stereo imagery and with large panoramas, some samples of which are given in Appendix I.

.03 Lecture Theatre Facilities

To lecture using the web, the following are required:

  • large whitish wall or two large pull-down screens;
  • computer linked to the network, with a web browser;
  • video projector to throw the computer image onto a large screen;
  • Digital OHP so that photographs, illustrations in books, documents etc may be projected to the second screen;

As the technology gets cheaper and resolution better, we may hope that all lecture theatres are fitted with video projectors of at least XGA standard (1024x768). And we really need a resolution of something like 1280x1000 or better if we are to do justice to our ever-improving digital images. This should side-step the old complaint that digital images are not up to the quality of 35mm slides (just as 35mm slides were not of the same standard as 6x6s...); and it would certainly be silly to equip lecture theatres expensively for computer/video projection and then to offer lower-quality images than under the old dispensation.

.04 Necessary Tasks

The tasks I require (and which I assume anyone in a similar situation would need) in various stages of the preparation of lectures are as follows:

  • To lay out the computer directories in a uniform fashion, and provide tools for renaming files, creating thumbnails, and writing HTML index files. Without directory uniformity, programs which offer batch processing (i.e. accessing more than one directory or suite of directories) cannot locate the images they need - which is why all my image filenames are numerical. (But such details are at the level of housekeeping, so will not be dealt with below.)
  • To write a database file for directories of existing images. i.e. we start with what we have, namely the images. This is considerably less time-consuming than writing the database file, and then fitting images to them, because this will undoubtedly generate errors;
  • To enable interrogation of such web databases via required fields dumped into scrolling lists or static HTML pages so the user can choose any combination;
  • To develop a way of handling text-rich databases and indexing not only the catalogued items but also all the text - this is the computer/web version of the standard art-historical catalogue of an artist's works;
  • To allow the lecturer or student to select image materials from web-based databases and regiment them into pairs (or whatever) for class presentation; and to store them so they can be recalled;
  • To provide students with a way of testing themselves using the same web databases;

There are no cheap, flexible and open-source programs that perform these tasks satisfactorily, and so the in-house writing of various tools was essential if images were to be dealt with adequately. This is not to say that pre-packaged procedures such as WebCT and Blackboard are not available for "image-light" disciplines, and used successfully in universities throughout the world.

.05Interrogating web databases: imageserve

This program (perl scripts again) takes any specified database fields, orders them alphabetically, and writes them into scrolling lists on the browser page. The user selects the parameters required, and the software goes off, retrieves the records that fit, writes index files, and the constructs links to display pages of thumbnails (click for the fullsize image) with the database record underneath. The scripts are called "imageserve" because they do indeed serve up the images to the user of the web browser.

Since imageserve is one of the building-blocks of light-table, its functionality will be illustrated below.

.06 Defining, editing and interrogating web databases: rdbweb

Why use the web for defining and editing databases? Not only because if the web is the medium for delivery it might as well be that for creation as well, but because the scripts allow the actual cataloguing to proceed via a web browser and, in addition, the images can reside on any machine as long as the cataloguer can see them in the web browser - and the cataloguer might be in Canberra or Toronto, with the server and images in Los Angeles, or wherever. If sophisticated and fine-grain searching ever becomes a reality [Weiyi Meng, Clement Yu & King-Lup Liu, "Building efficient and effective metasearch engines", ACM Computing Surveys Volume 34.1, March 2002, pp.48-89].

rdbweb is a set of bolt-together perl scripts, each of which performs a specific task. These allow the user to define the database parameters in the usual way (and to change them as required); relations are allowed (hence the package's name; but we keep things simple flat-file), and the definition of how the data are to be entered - type-in box, pull-down list, or both. Latency may be used: since images often go in series, the parameters can be repeated from one record to the next, or the usual changes made (e.g. "take the last number, and add one"). Most importantly, the cataloguer always sees the context of the suite of images, with thumbnails of the last five catalogued at the top of the page, the current target in the middle, and the next four in line along the bottom of the browser window. Clicking on any thumbnail brings up the full-size image. When a record is stored, the target image moves to the top of the page, the top-left image disappears, the bottom-right image becomes the target, and a new image appears bottom-right - which makes it easy to see why the program used to be called bus-queue or image-queue. The database can be interrogated from the data-entry screen; the records can be updated or edited as required; and the datafile can be written to disk with whatever field separators prove useful, as well as in tabular format with thumbnails already in place. This datafile then becomes the input for the following program.

The originality of rdbweb lies in the context it gives image-wise, and in its ability to catalogue via a web browser. This means that neophytes can safely be allowed to try their hand at cataloguing: not only can their work be revised, but the neophytic datarecords are not then inextricably tied up with the images - for the images remains wherever you want them to be on disk. Indeed, it is perfectly possible to envisage two different databases feeding from the same images (as could easily happen - two people don't necessarily need the same data from any one set of images).

.07 Writing databases direct from the web: rdbweb-webimage

Although many collections of images may be made on the home server, because of the growing availability of useful images out there on the web, there are many instances where rdbweb can be pressed into use to pull down images from the web and write the datarecord on the spot, allowing the software to store the image and generate a thumbnail.

.08 Writing text-rich catalogues for the web: richimage

The majority of web image databases in art history can be boiled down to the basics of artist-title-date-location, but what if we want a free-form database with full catalogue entries, discussion, quotes from other authorities, references, and of course images as well? The anwer is another set of perl scripts which we call "richimage". This is not really a strict database because, beyond the basics, it is not essential to have the same elements in each record, or even to indicate their omission by blank fields - there are no fields. But to use it we nevertheless need the following:

  • A list of numbered records (NB these could be generated by rdbweb above);
  • A collection of images with the same numbers - e.g. record 2 goes with 2.JPG, and so on;
  • The body text, references, quotations etc for those records which require any or all of these;

When the software is pointed at a-b-c above, the following actions are executed:

  • A set of HTML pages is generated, one to each record, and with the same name as the image and the record - so record 2 sits on 2.html and displays 2.JPG;
  • An HTML index page is generated giving hotlinks to all the record pages underneath it;
  • a script recognises certain kinds of cross-refernces as such, and hotlinks them, enabling the user to hop immediately to any number of listed comparable records;
  • A complete A-Z listing of of all words in the whole catalogue is generated, with its own index page, and with all the terms hotlinked, so that the index can be used to jump directly to any term found in any record. Common stop-words can be specified, but an omount of hand-editing is still required to clean up these files;

This process may be illustrated using a catalogue of The Inscriptions of Roman Tripolitania, which consists of a titlepage with hotlinked access to all the records, the record files named from 1.html to 849.html, various prefaces to discrete sections of the work, and automatically generated indexes. Here are illustrations:

Left: Access by record number
Right: A record (NB the hotspot links to other records at the bottom - and all hotspots and crosslinks are automatically generated by the perl script)
Left: View a suite of images by record number
Right: Automatically generated index of all the text

.09 Selecting databases images for lecturing: light-table

The imageserve scripts described above give us a database which can be interrogated, and show us retrieved records as thumbnails with datafields underneath. We now need a program to select and order what we need for our lecture, which might come from one or several databases. This program is Light-Table, named after the illuminated tables on which a lecturer would shuffle around, reselect, regiment, throw out and re-order 35mm slides; it allows all the same processes from within a web browser and, in addition, allows the lecturer or student to store the resultant lectures on disk, for recall when the lecture is given; and even to bundle up the images-and-records and transmit them across the web to somewhere else, or onto a CDROM or whatever for those who don't wish to rely on the network providing access when it is required.

.10 How Light Table Works


  1. First of all, select a database, and mark the tick boxes for the image required
  2. Go back to the database for more images if required;
  3. Tick the boxes of the required images;
  4. Sort the images by any of the fields in the database (or do a custom sort);
  5. Finally, format the images with their data records into discrete HTML pages, which may be used over the web in a lecture, stored on disk, or printed out;

NB although primarily intended as a tool for the lecturer, students could easily use the storage and download facility for private study and for seminar presentations. Indeed, the download facility recreates the exact structure and layout of the original on the new disk, and has two further useful features: (1) it will work in its new location with only a browser (i.e. no server required); and (2) all the original links and connections are still hot - so the user can also go back to the original server and interrogate the database(s) further.

.11 Student self-testing: image-quiz

Finally, we need a program to allow the student to reinforce what has been learned on a unit, or in the area of a particular database. Image-Quiz allows the student to control the level of difficulty of the quiz, and the software puts up a series of images in the area selected by the students, together with multiple-choice scrolling boxes; and it them tells the student how many (and also which fields) are correct, and which not. This quiz works completely without lecturer-intervention: the images for each run are chosen by a random number generator, and NOT set up by the lecturer. Obviously, the larger the database, the richer the quizzing experience is likely to be.

.12 How image-quiz Works


  1. Choose the parameters of the database you wish to address (perhaps artist, title);
  2. Examine the images (clicking on the thumbnail brings up the large JPEG;
  3. Highlight what you think are the correct responses;
  4. Submit your answers, and the program tells you which of the selected fields are in/correct;

.13 Conclusion: where to from here?

It is ironic that academics may be driven toward "flexible learning" using the web because it is perceived to be cheaper than maintaining traditional establishments - when we should of course be searching for methods that will make learning better (whether the web can be used effectively for teaching is a much more tricky question). Multimedia should be able to improve the quality of learning (and expressions of trust aboud [Bonnie Halsey-Dutton, Artifacts in cyberspace: A model of implementing technology into art history education Art Education 55.4, Jul 2002, pp. 19-24]) - but issues such as digital equity [Gwen Solomon, "Digital equity: It's not just about access anymore", Technology & Learning 22.9 April 2002, pp.18-26] are overshadowed by the huge costs of changing from analog teaching to digital learning, and the technology's ability to upset existing power-structures [Fiona Harvey, "Class action on web lessons: Educational publishers are taking the BBC to court over plans to develop an online curriculum for schools", Financial Times London Jun 11, 2002, p.30].

The same problem is faced in museums and galleries, where technology has thus far had a similarly patchy penetration to that seeb in university teaching, but where the need to coherent databases for often huge collections (to which are now added the commercial imperatives and "public face" required by the web) have long ensured a necessary engagement with technology [Maxwell L Anderson, "Museums of the future: The impact of technology on museum practices", Daedalus, 128.3, Summer 1999, pp. 129-62], and where we might hope (which springs eternal) that the not invented here syndrome, so prevalent in the early years of museum databases, and a brake on co-operation and hence progress, has been eliminated.

If suitably mixed with face-to-face tutorials and the kinds of lectures outlines above, web learning in Art History could eventually save money, if only because digital images should soon undercut 35mm slides in cost as they do in relability and flexibility. All that will remain to be done (an enormous problem) in the generation of online lectures and tutorials (beyond finding the images to use) is to sort out Intellectual Property - namely who owns the material ported to the web - the university per se or the individual academic?

If mixed with a continuing respect for research in well-stocked libraries, then searching the web offers added value - and, indeed, the quality of available materials has improved in reach and depth. For private study in any image-based discipline, the web is unbeatable, and I expect it to develop as follows in our area in the next couple of years:

  • better-equipped lecture theatres with better video projectors (and eventually wall-sized TFT-like screens, obviating the need for projectors at all;
  • students equipped with network-capable laptops, downloading assignments/materials from bankomat-like devices; or, perhaps, matchbox-sized computers few by wireless protocols;
  • live lectures (using digital images) broadcast (or rather multicast) to students in various locations; and seminar rooms equipped for such multicast sessions, with large screens on at least two walls (many of the images accessible from Appendix I would not be effective on a small screen);
  • seminars conducted in a similar fashion;
  • the establishment of large, searchable stores of some of the valuable but fugitive sites on the web, so students and lecturers can be sure of finding what they need just when they need it;
  • Networks restricted to serious institutions such as universities, so that our networks are not drenched in rubbish, and slowed down in consequence;
  • Some structure given to the web or its successor, so that materials may be catalogued and hence retrieved in a matter analogous to those from a physical library.
  • Serious cost-benefit analysis before trying to implement virtual reality setups using VRML: although this technology is superficially attractive and potentially useful [Hannah Slay, Bruce Thomas & Rudi Vernik, "Tangible user interaction using augmented reality", ACM International Conference Proceeding Series, Third Australasian conference on User interfaces - Volume 7, 2002, Melbourne, Victoria, Australia, pp.13-20], the costs involved are high for the output currently available, especially in comparison with simpler methodologies mentioned above.

Appendix I: Manipulating images: some examples

  • image databases written with thumbnails, as for italian renaissance art; this is done using a flexible perl script called salami, which slices up whole directories, puts in only the fields required, and writes index pages as well, hotlinked to the HTML pages containing the images;
  • high-quality suites of images, as here for the Great Mosque at Cordoba (with zoom function; cf item 3 below); and here with a database attached;
  • magifying images: software controlled by the server (a cgi-bin script) allowing the user to "zoom in" on the details of an image; hence a lecture can talk about details, because the user will be able to see them! I routinely use this device (which is not a true zoom) with all my large files; cf. the example at Medina del Campo. As images get larger, this technology will increase in value, because it works with JPEGs of any size;
  • user-selectable image sizes: another option is to offer two or more resolutions for all images, which may be presented wrapped in tables; this generally takes up more disk-space, which is a large consideration on a server already containing 190,000 images. Since today's digital cameras routinely offer five megapixels (over 1Mb of data) and will soon offer much larger sizes, plans are afoot for a script which will serrve up a user-requested image-size from the single-size image on disk.
  • annotating images: software allowing you to place "hooks" on an image of a work of art, upon clicking on which the user can be taken to (a) another image; (b) another page of text; (c) another website; (d) audio or video files which open automatically; the Project designers might also, conversely, hotspot various images so clicking on them leads directly to the text of your lecture;
  • panoramic views where appropriate; these can be of any angles up to 360 degrees, and can give an effective "being there" feeling to architectural sites, gallery or country house interiors, paintings, etc. (mine are far from perfect, but they are usually serviceable.) Again, "hooks" can be inserted in panoramas allowing for text, other web pages, video and the like; Simple panorama examples are:; panoramas can also be vertical, for example:; or in this example here in Oxford Cathedral.
  • panorama segments can also be useful for study, even if they are not to be welded together into coherent large images; hence I store as sets of adjacent images the building blocks of panoramas, as here at the martorana (Palermo);
  • the size of panoramas can as big as the machine/network will support, as here for Castel Sant'Angelo, and here for the Capella Palatina in Palermo. These could be viewed using the zoom function (see above), and hence be made more manageable over slowish networks.
  • maps and floorplans: Another way of dealing with large panoramas (which can be disorienting) is by the provision of a map or floorplan which shows there the user is facing, and at what level of zoom, as in this example from Christ Church Cathedral, Oxford, which uses java: ; this is intricate, but not difficult, to produce - perhaps 40 minutes for this example;

Appendix II: Large projects: trying to recreate the world in three dimensions

  • Borobudur: the greatest of all Buddhist stupas. The whole presentation, which includes a database, plus VRML "virtual reality" model, is here; and screenshots of the VRML model are here;
  • First draft-sketch of a multimedia learning package devoted to Piazza del Popolo, Rome, and including an 18,000-image (badly mis-catalogued) database, plus panoramas, .MOV video, and some stereo pairs;

Appendix III: ArtServe: Some Statistics

My main server (ArtServe: went live on 4 January 1994; it receives over 120,000 "hits" every day; it contains about 95Gb of data (over 180,000 images, with some 15,498 HTML pages), and over 8,242 servers link into it worldwide (cf the National Galleries in Canberra: 1,573; London: 4,005; Washington: 20,437). I have taught "live" using the web since 1998, and students have been able to purchase a CDROM of course materials for each unit.

In a review in Le Monde in 2000, ArtServe was chosen as one of 15 sites world-wide for mention, and the only one in Australia. Others include the Guggenheim, Louvre, Beaubourg, Museum of Modern Art (NY), Metropolitan, and Hermitage: (c'est un formidable outil de travail).

Unfortunately funds are short, and much work needs doing to bring the site up to a standard which distinguishes it from the usual sloppiness of the web.