Fifth International World Wide Web ConferenceMay 6-10, 1996, Paris, France
Fifth International World Wide Web ConferenceThe Phoenix image server is intended to address the need for creating a central place to store large numbers of images. The system itself is composed of widely available resources and could be easily reproduced at other sites at very little expense. A Phoenix server can be queried from any Web page or browser and delivers an image which has been watermarked. This watermarking is intended to assert ownership of the image in an obvious but unobtrusive fashion. The server is managed using a database which ensures that picture IDs are unique throughout the server. A variety of output styles are supported, including the image in its full size, a reduced version of an image, and a dynamically generated HTML information page. Images may also be returned in a variety of graphic formats. Future enhancements should include Web page-based administration tools, support for authenticated users to view non-watermarked images, and more advanced file management. Through these and other enhancements, the Phoenix Project should fill a critical gap in the effort to make images available on the Web.
The impetus for the Phoenix image server[1] project was the realization that while the Web has made possible the retrieval of images over the Internet, there is no widely available technology for storing and delivering large numbers of images in an organized fashion. Until there exists a mechanism to do so, there is little impetus to digitize historical photographs and make them available.
Case Western Reserve University's historical archives provide an excellent example of the dilemma we chose to address. The CWRU Archives hold a collection of over 70,000 photographs, some of which date back to the mid-nineteenth century. For scholars researching the history of CWRU, or of Cleveland, or of private universities, it would be very convenient to have on-line access to these images, or at least representations of them.
However, the task of creating and storing a Web page for each image or set of images is monumental, to say the least. In addition, there would be no good way to search through the images except manually, which is an unacceptable method for such a large collection. Finally, the organization of the images would be determined by the person creating the pages. He might, for example, organize the images by the year in which the photographs were taken, so that there is a page for 1906, one for 1907, and so on. This is a perfectly reasonable approach, but is less than helpful to a researcher looking for all images of a certain building, regardless of what date the pictures were taken.
We felt it would be far better to simply create a repository for these images which could be called upon from a Web page, a catalog system, or any other context. Given the issues of being able to search for images meeting certain criteria, we focused on the challenge of accessing the images via a catalog system, but were always sure to make the system accessible from Web pages or browsers independent of a catalog system.
The Phoenix system is not intended to directly compete with expensive, high-end commercial solutions offered by large corporations. The Phoenix system provides watermarking functions, but they are not nearly as advanced as those found in other systems; Phoenix is no doubt much slower than most commercial systems; and the Phoenix system itself does not offer much of a search mechanism.
Despite all this, we still feel that Phoenix is a unique and highly useful tool because it is highly flexible, both in terms of present and future features; it makes a reasonable effort to assert ownership of images; and because it is simple to set up and maintain. Not every company or institution will need, or even want, the advanced features which are part of the price tag that commercial systems inevitably carry. We felt that it would be more often the case that an organization would be in need of a basic image server with a basic set of useful features and a high degree of openness.
In addition, while the Phoenix system does not offer features such as are found in commercial systems, there is nothing which prevents it from doing so-- except the time and expertise required to upgrade the system. Finally, the Phoenix system itself is free. The only costs associated with the operation of a Phoenix server (besides the cost of acquiring hardware, if necessary) are in time invested.
In addition, the Phoenix system need not stand alone; it can easily be used in a supporting role in more ambitious image cataloging projects. For example, assume a searchable database of images which are classified and indexed using specific criteria unique to the images in the database. A good example of this is the Art Image Browser[2] created at the University of Michigan's School of Information and Library Studies. In an environment such as this, a Phoenix server could be used to conveniently store and manage the images themselves, and provide both thumbnails and watermarked display images to the user. For each image record, the database would contain references to the image kept on the Phoenix server. In effect, Phoenix would be a back-end storage mechanism for the advanced database and its powerful search engine.
Because the Phoenix system source code[3] is freely available, it is our hope that the Internet community will contribute to the development of the Phoenix system and help make it better than we have yet imagined.
Based on the reasoning given in the Introduction, we have thus far identified two primary uses for an image server of the type we describe:
Currently, items in a library catalog system such as CWRU's EuclidPLUS are typically limited to monograph and journal materials which the library owns. In a setting which includes a Phoenix image server, a patron can use a Web-based interface to the catalog system to search for a certain topic or artist. Among the search results would be records for various images. Selecting one of these for more detailed study will lead the patron to view the image's record, which is served from the catalog system, and the image itself, which is served from the Phoenix machine.
Another way images in the system can be used is by image collection maintainers creating on-line "galleries" of images; that is, a set of Web pages which contain images and text about those images, rather like an on-line museum exhibit. The Web pages of these on-line galleries are not stored on the Phoenix server; instead, the Phoenix server provides watermarked and thumbnail versions of the images for the gallery's Web pages without the need for the images to be stored locally by the gallery's maintainer. We anticipate this function being used by museums and archivists, who may choose to create on-line gallery shows of certain artists or periods of time, as well as by professors who create pages of images related to their class subject.
A fundamental concern driving the Phoenix project is protection of copyright and assertion of ownership. This is primarily handled through the use of "watermarking". Watermarking creates a display image by combining a small image over the source image, thereby altering the source image enough to make it difficult to remove the watermark but not so much as to make the display image impossible to view. The default watermark consists of the CWRU logo [Figure 1], although a different watermark file may be used.
![[ Picture ]](wm-CWRU.gif)
This sort of protection is obviously limited, as it does not allow for any sort of comprehensive usage tracking. The user is able to view the image as many times as he wishes, and is able to copy the display image off of the Web client page to be used elsewhere. Images may also be stored in Web browser caches and proxy caches. For these reasons, the logs of the Phoenix server cannot be used as the basis of an accounting mechanism by which users may be charged for image access.
All access to the images must occur through the Phoenix system-- in fact, there no way to access the images on the Phoenix server without first going through the Phoenix system. The watermarking step cannot be bypassed by the user, although it can be surpressed by collection maintainers, if they choose to exercise this option.
It was decided early in the project that in order to simplify storage issues, the server would keep a single unmodified copy of each image. From this one file, the Phoenix system can produce watermarked images, thumbnail images, scaled images, and converted images in a variety of graphic formats.
As we saw it, the alternative would be to require that each image be stored in its original state, a watermarked state, a thumbnail style (which would limit the system to a predefined thumbnail size), and conversions of the image, in both original and watermarked states, to a variety of graphic formats. We felt this approach to be inimical to our basic goal of designing a server with simple maintenance requirements.
By simply storing the original image, the system is given a great deal of flexibility. Addition of new system features, or redefinition of existing features, is accomplished by altering the Phoenix system's code. There is no need to alter any pre-generated images, or to create new images, because the original is the only stored image and it does not need to be changed.
As described above, the source images are stored on the hard drive in their original state, and are watermarked, scaled, and converted (if necessary) on-the-fly. Performing this sort of image processing in real time is both memory and CPU intensive, and must therefore be optimized to the best of our ability.
A large amount of memory is used by the number of simultaneous connections requesting various images, and by a small series of utilities connected by UNIX pipes. The CPU is used in the calculations of the watermark over the source image, as well as the scaling. The CPU demands can be somewhat reduced by having the Phoenix server cache recently requested images, as well as those images which have been most often requested. The Phoenix system also lends itself to multiprocessor and distributed computing environments.
The image format conversion is a natural extension of the tools used for the image processing, and we consider the added benefit to be well worth the CPU overhead required, which is not unreasonable. We are considering moving to a more powerful UNIX-based server equipped with specialized image-processing hardware should demand for this service increase beyond the abilities of our current server.
It was our intention to create a system which was of low cost, high reliability, and which was simple to replicate in other environments. Thus, we have avoided the creation and use of proprietary software whenever possible. Instead, we have relied on the use of existing software tools and Internet standards, thereby ensuring full compatibility with existing Web software (both servers and browsers). For example, the machine we are using is a Sun workstation, but nothing in the project is dependent on Solaris itself; any variety of UNIX should suffice. The other components of the Phoenix system are either freeware or shareware, keeping the cost to a minimum.
The Phoenix system runs on a UNIX machine (our current server is a Sun SparcStation 20 with Solaris 2.5) running an HTTP server. A PERL script called imagesrv.pl forms the basis of the request mechanism. The various output styles (full-size, thumbnail, and so on) are aliased to imagesrv.pl using the ScriptAlias directive in the Web server's "srm.conf" configuration file. When imagesrv.pl receives a request, it checks the validity of the input and makes sure that the proper utilities exist to perform the requested conversion. For this, it must be able to convert the source file into the PNM internal format, and then after watermarking convert it from PNM into the requested graphic format.
Error control and logging are also performed by imagesrv.pl. After processing the input and determining what step must be taken, the script strings together a series of UNIX commands. These commands are then passed to the shell (via the open command) in order to perform the image processing. The NetPBM utilities and add-ons are used to convert the source image into the internal PNM format, perform the watermarking and scaling functions, and to convert the internal PNM format to the image format requested by the user by means of the image's URL.
The following components are used:
The Phoenix system is managed by an index of the images stored in the system (hereafter called imageDatabase) which maps each unique collection name-image name combination to a file in the UNIX directory system. This database is used to speed retrieval of images and allows collection maintainers to create manageable hierarchies of images.
One goal of the system is to use a relatively flat URL space to define an image. Thus, external URLs are short and easy to remember, which will be appreciated by catalogers and users alike. The URL of a Phoenix image is in the form:
http://images.cwru.edu/outputStyle/imageCollection/imageName.ext
where outputStyle represents the requested format of the image (thumbnail, full-size, etc.), and is an alias (in both the srm.conf file and the UNIX file system) to imagesrv.pl. imageCollection is a unique collection name on the Phoenix server containing a group of related images, imageName is the name of an image which is unique within in that collection, and the ext, if any, specifies a particular graphic format (see "Image Conversion" below).
While it is possible for an image collection to contain thousands of individual images, it is not efficient for a UNIX directory to contain thousands of directory entries. The image collection maintainer can create subdirectories of images based on a logical structure that is meaningful to the collection maintainer, but which remains invisible to the end user. As described above, imageDatabase maintains a flat URL space within the system and speeds location of source image files.
This database maintains at least three pieces of information for every image on the server: the imageCollection and the imageName, which as a pair form a unique key in the database, and the actual pathname of the image. For example, an image with imageName of "lit41124" which is part of the collection whose label is LIT might actually have the server pathname /images/lit/jan96/p1/lit41124.gif. The URL of this image at full size would be:
http://images.cwru.edu/full/LIT/lit41124
The Phoenix system receives the above request from a Web browser. It searches through imageDatabase for the collection LIT and then within that collection for the image lit41124. It finds the following entry in the database:
LIT:lit41124 /images/lit/jan96/p1/lit41124.gif
The system will then load the file into memory, watermark it, and deliver the resulting display image to the browser.
The Phoenix system allows for hierarchical image collections. A hierarchical system permits the sharing of watermark files and management responsibility. The name of each image collection continues to be unique across the system so that the flat URL namespace can be maintained. For example, all collections held by the University Libraries might be part of the "UL" collection.
As a basis of the ownership assertion scheme, the image server takes a smaller image, called the watermark, and combines it with the source image. The watermark file is typically 50 by 50 or 100 by 100 pixels in size, and is stored in PPM format. The watermark is repeatedly tiled over the source image [Figure 2] so that as much of the image as possible is altered.
![[ Picture ]](wm-grid.gif)
Watermarking is accomplished by changing the color and brightness values of the source image based on the content of the watermark file [Figure 3].
![[ Picture ]](wm-in-action.gif)
It should be mentioned that the watermark is as visible as it is for a reason. The assumption we made was that the image's publisher would want the ownership to be immediately obvious to anyone who sees a watermarked image. This is a different approach than that taken by companies such as Digimarc[10], which offer highly persistent but effectively invisible "digital signatures." This is a very useful technology, but it is somewhat beyond the scope of our project assumptions (as well as being available already; we would not think to attempt to re-invent it).
Of course, there is no barrier to storing digitally signed images on the Phoenix server; they would be watermarked, of course, but if the un-watermarked image is delivered to a user, then the digital signature would still persist.
In addition to the tiled watermark, in the full-size output style, a copyright ownership statement is placed in or beside the source image. The placement of this statement depends on the size of the source image, the size of the watermark file, and the size of the copyright statement. In priority order, the copyright ownership statement is positioned:
![[ Picture ]](wm-in-image.gif)
![[ Picture ]](wm-horizontal.gif)
![[ Picture ]](wm-vertical.gif)
If the copyright information cannot be placed in or appended to the image in any of the preceding ways, then the source image is placed in a black field and the copyright information is centered at the bottom of the field [Figure 4d].
![[ Picture ]](wm-in-field.gif)
Watermarking (as we have defined it) is a difficult business. It is important that the watermark be visually obvious, but not so obtrusive that it destroys the image for purposes of viewing. In order to account for the fact that images will often have widely varying brightness and color values, we have implemented a system which dynamically measures the color values of each pixel in the source image and applies the watermark accordingly.
In broad terms, the system works as follows. The source image is loaded into memory and converted to the PNM internal format. The watermark file is also loaded and converted. This watermark file is a grayscale image, typically smaller than 100 by 100 pixels (although the watermark could be larger if desired). The overall color range of the source image is calculated. The program then scans through the source file a pixel at a time, applying the appropriate watermarking to each pixel. The watermark file is tiled in order to cover the entire source image.
At each pixel, the system determines the color values for that pixel. This is compared to the color range of the entire image, and a scaling factor is derived from this comparison. The brightness of the source image's pixel is then modified by the brightness of the watermark's pixel multiplied by the scaling factor. Assuming a system which uses 8-bit color, this roughly translates to:
scale = (sourcepixel / sourcerange) output = sourcepixel + scale*(watermark - breakpoint)
where watermark and breakpoint are typically values in the range 0-255, and breakpoint is usually 127. This creates a situation where watermark pixels dimmer than 50% black (value 128) cause the source image's pixel to be darkened, and watermark pixels lighter then 50% black cause a lightening effect. This is modified by the scaling factor so that the watermark does not become too obtrusive.
The local library catalog, which at CWRU is called "EuclidPLUS," provides a powerful mechanism for the cataloging of images. The cataloging of each image record conforms to USMARC and AACR2 standards. At this time, all images in the Phoenix server are cataloged in EuclidPLUS, with index points of "title", "author", and "Library of Congress (LC) Subject Heading." Each cataloging record will include one or more links to images on the Phoenix server via MARC standard 856 fields[11]. Subfield u is the URL for the image in the database and subfield z is a free-text description that is used as the link text when the record is displayed in the EuclidPLUS Web gateway. An IMG tag may also be included in subfield z of the record so that a thumbnail of the image is displayed when the record is retrieved.
The EuclidPLUS catalog is searchable using a World Wide Web browser at URL http://catalog.cwru.edu/. Users who access the EuclidPLUS catalog through a traditional VT100 interface will not see links to the images, but will instead see item records with the location "CWRUnet resources."
Images in the Phoenix server can be stored in any graphic format that can be converted using the NetPBM and associated utilities. The format of the image stored on the server is represented by the file's extension. In other words, GIF files are stored on the server with the extension .gif, JPEGs have the extension .jpg (or .jpeg), and so on. This extension does not need to be part of the URL which requests an image. In fact, the URL could contain a different extension entirely.
Images can be output in any format supported by the NetPBM utilities. The user specifies the graphic format to be received from the server by appending the appropriate extension to the URL. If the user does not specify a graphic format, a GIF image is returned by default for maximum compatibility with existing Web browsers. The appropriate "Content-Type" header is returned as part of the HTTP response. (See the HTTP Content-Type specification[12] for details.)
Thus, a JPEG image may be stored on the server as lit6294.jpg. A request for lit6294.gif would return the watermarked image in GIF format. A request for lit6294 would also return a GIF image, as the system defaults to GIF output. In order to receive the image in its original JPEG format, the request would need to be lit6294.jpg (or lit6294.jpeg).
At the present time, the following graphic formats are supported: GIF, JPEG, PNG, TIFF, Windows BMP, and PICT.
http://images.cwru.edu/full/LIT/lit12538
![[ Picture ]](full.gif)
http://images.cwru.edu/thumb/LIT/lit12538
![[ Picture ]](thumbnail.gif)
http://images.cwru.edu/info/LIT/lit12538
![[ Picture ]](info-window.gif)
Another useful feature of the Phoenix system is the ability to specify certain rules for a collection. This information is kept in a file called collection.info, which is stored in the collection's UNIX directory. The maintainer can include the pathname of a watermark file to be used in the place of the system's default watermark file. This value would be left blank if no watermarking is desired; in this case, the entire watermarking procedure, including the insertion of a copyright statement, is skipped by the Phoenix system. The image is delivered in its original state, and converted to any requested graphic format. The maintainer can also give the collection a title such as "LIT Test Image Collection."
In the future, the main source for image information such as title and author/publisher will be a catalog system database. This information will most likely be retrieved using a Z39.50 connection (reference: Yahoo's Z39.50 index[13]). We realize that not all images will be cataloged in such a system, so it would be valuable to store that information in the Phoenix system itself. In order to store title, copyright ownership, and author/publisher information in Phoenix, we have added fields to the imageDatabase which will store the required information. We have considered and rejected the use of graphic-file text fields such as are found in PNG graphics, as this is an extremely format-dependent solution and therefore counter to the basic design principles of the project.
There may be times when the server cannot deliver a requested image. This can happen in circumstances where the image does not exist, either due to a mistyped URL or removal of an image from the server, or if access to the image has been temporarily restricted. If an error occurs, the system instead returns a small image containing text to the effect that the requested image is not available. [Figure 6]
![[ Picture ]](server-error.gif)
Error messages are delivered as images, and not as text, because in many cases the Phoenix system will be referenced using an IMG tag in a Web page.
After an image is converted and sent to the user, it is stored in a disk cache for faster retrieval in the future. The Phoenix system uses a time-based cache system where the oldest images are removed as new images are converted and stored in the cache. This weeding process is performed as a cron job that runs periodically throughout each day. A cron job is used so that the removal process does not impact the performance of imagesrv.pl. The system also keeps cached versions of images which are most frequently requested. This should dramatically increase the speed with which popular gallery pages are loaded.
The script imagesrv.pl can be extended in a number of ways. The most obvious and common are:
Copyright ownership information and author/publisher information is usually stored in the bibliographic record found on a catalog system such as EuclidPLUS. We propose retrieving this information from the catalog system and then watermarking it into the image. We intend to use a lookup mechanism to retrieve this information; one scheme under consideration would employ Z39.50.
Using mechanisms similar to those discussed above, the Phoenix system's information page output style would be improved by including a link to the image's catalog record, if any. This will bring up issues of identifier skew-- that is, what happens when the image name on the Phoenix server is different than the catalog system's ID number, and how such a situation is handled.
At present, the Phoenix server system uses a generic copyright statement for insertion into the image (or appending using the black-bar scheme described previously). We intend to create the capability of adding Author and Publisher information to this copyright statement.
For those authenticated to do so, the system will offer an output style that is a non-watermarked version of the image. We would anticipate that this would be used by the staff members who maintain the image collections. We also would like to propose a system where a one-time or limited time key can be issued by the manager of an image collection so that a user can retrieve an un-watermarked version of the image (presumably after negotiating a usage agreement with the copyright holder/maintainer of the image archive).
It would be fairly simple to add the ability to browse through the files on a Phoenix server using an FTP directory-style interface. This might also include the ability to request "overview" screens. This output style would return a page containing a thumbnail of every picture in a given collection. Additional information, such as each image's original size, might also be included. Consideration needs to be given to whether the entire contents of the Phoenix server, or of specific collections housed on the server, will be indexable by the various World Wide Web robots and indexers. If so, support for the robots.txt file may need to be added.
Right now, the image maintenance is done by hand using standard UNIX commands plus a few PERL scripts to maintain imageDatabase and other internal Phoenix functions. The use of shell accounts to update and maintain the server is not desirable in a distributed work environment, as it represents unacceptable security risks. We will be creating an administration system made up of WWW pages, CGI scripts, and FTP-only accounts on the Phoenix server itself, that will allow image collection maintainers to perform all of the functions necessary to maintain their archive.
Collection maintainers will be able to FTP source images and watermark files to a staging area on the Phoenix server, and then use the Web/CGI-based administration tools to move around in the image collection. The Web/CGI tools will automatically perform updates to imageDatabase and ensure proper permissions (e.g., one collection maintainer cannot view or manipulate images in another collection).
Since we are using the NetPBM utilities to perform the watermarking function, we have the advantage of using the other image manipulation tools in the NetPBM software suite to modify images. One modification which could be added is the ability to specify scaling factors for an image as it is returned. These scaling parameters would be appended to the image URL, such as "/scale=1.2" to increase the image size by 20%. We could also add the ability to lighten and darken images, specify absolute size(s), and perform other transformations. Implementation of these will be investigated as users of the system request them.
We are considering moving to an object-oriented database, which may offer significant advantages over the current directory-structure approach. This will depend on the versatility and universal availability of the products we study. Use of a commercial database would never be more than an option, as it is vital that the Phoenix system remain a low-cost alternative.
As we have shown, there is nothing inherently difficult about creating an image server of the type described-- in fact, most of the effort in creating an image server will be in scanning and indexing the images themselves. Almost all of the software components of the system are freely available and widely supported by the Internet community. The only exception is the Phoenix system program which locates a requested image and watermarks it before returning the final image to the browser. However, as the program is written in PERL, it should be easily portable to almost any serious Internet server. It is being made freely available to the Internet community and may be found at http://images.cwru.edu/source/.
The fiscal costs of setting up a Phoenix-type image server are minimal, and the time required to complete setup should be similarly minor. The use of well-established standards ensures compatibility with existing Web servers and browsers. In situations where an institution or corporation wishes to put large numbers of images on-line, the advantages of such a system should be obvious. It is our hope that the Internet community finds this to be a useful addition to the Web.