INET Conferences


Conferences


INET


NDSS

Other Conferences


[INET'98] [ Up ][Prev][Next]

Bringing Museums to the Web: An Architecture for a Virtual Exhibition

Lutz NENTWIG <lutz.nentwig@isst.fhg.de>
Sonia MANHART <sonia.manhart@isst.fhg.de>
Andreas KAMPA <andreas.kampa@isst.fhg.de>
Andreas WENDT <andreas.wendt@isst.fhg.de>
Fraunhofer Institute for Software and Systems Engineering
Germany

Burkhard ASMUSS <asmuss@dhm.de>
Wolfgang ROEHRIG <roehrig@dhm.de>
German Historical Museum
Germany

Thomas SCHNEEMELCHER <schnee@hdg.de>
Haus der Geschichte of the Federal Republic of Germany
Germany

Abstract

In a joint project with the Fraunhofer Institute for Software and Systems Engineering, the German Historical Museum in Berlin and the Haus der Geschichte of the Federal Republic of Germany in Bonn are developing a virtual exhibition of German history for the Internet. This paper deals with the Internet technologies (Virtual Reality Modeling Language, HTML, streaming video, Web camera) and the architecture used in the LeMO project.

LeMO is a project of the DFN-Verein (Association for the Promotion of a German Research Network) with financial support from Deutsche Telekom Berkom GmbH.

Contents

1. Introduction

The World Wide Web is now being used increasingly as an information service by cultural institutions. Many museums, for example, are already using the WWW to publicize exhibitions or to show exhibits. However, the form these presentations take seldom goes beyond scanned photographs with accompanying text.

The LeMO project -- Lebendiges Museum Online -- is adding a new dimension to the Internet presentations of two large historical museums. In a joint project with the Fraunhofer Institute for Software and Systems Engineering ISST, the German Historical Museum (DHM) in Berlin and the Haus der Geschichte of the Federal Republic of Germany in Bonn are developing multimedia applications for the Internet: Within a virtual tour of the 20th century, 3-D animations as well as film and sound archive material are linked to the museum exhibits, giving a comprehensive picture of German history. In addition to the exhibits themselves (images, graphics, photographs, historical artifacts), videos, sound recordings, and 3-D animations are to be integrated. To make the virtual museum visit an interactive experience, video images are transmitted live from the museums' rooms via a camera which can be remotely controlled by the viewer.

Access to the virtual exhibition and information searching is realized via a three-dimensional VRML (Virtual Reality Modelling Language) environment. Each period of 20th century history is represented by a separate virtual space containing multimedia museum objects which in turn provide access to further information and artifacts related to German history.

LeMO is a joint project involving computer scientists, designers, museum experts, and historians. This ensures that the requirements made on the project are not of a purely technical nature but are also influenced by the content, the concept, and the design of the exhibition. This cooperation between different disciplines is a special feature of the project.

LeMO is a project of the DFN-Verein (Association for the Promotion of a German Research Network) with financial support from Deutsche Telekom Berkom GmbH.

Aims

The LeMO project has the following aims:

Information transfer via three-dimensional representation plays an important role. The project will examine the level of user acceptance for information access via VRML environments. This is also related to the quality and handling of the VRML environment, which depends on the quality of the network connection and the performance of the user's PC.

In addition to the information transfer aspect, the project will also examine the suitability of the architecture for the construction of infrastructures in the cultural sector.

The most important aim, however, is to make available large amounts of information on German history, in an exhibition that can only be visited in one place in the world: the Internet. The exhibition opens in 1998.

This paper deals with the architecture of the LeMO project. The LeMO approach is not based on a purely technology-driven architecture, but takes into account the technologies used, the bandwidths they require, and the presentation of content as well as the varying quality of the workstation (PC) (including network connections) in use at the receiving end.

2. Architecture

The LeMO project is characterized by the use of Internet technologies, thus ensuring that any user with Internet and WWW access can go on a virtual journey through history.

The experimental character of the LeMO project consists in the use and combination of different multimedia technologies under the single "roof" provided by the WWW. The architecture takes the various presentation media into account and is characterized by the integration of different technologies.

The outer layers of the LeMO architecture consist of the DFN-Verein [1] high-speed network (B-WiN) with its protocols on the network side and conventional WWW browsers at the user end. B-WiN is based on ATM technology with a transmission capacity of up to 34 MBit/s. It provides high-speed access to other European networks, to the USA, and to the still relatively low-bandwidth Internet. The LeMO architecture therefore consists of components which support users with both high- and low-bandwidth network connections.

On the client side, the user requires a WWW/VRML browser (plug-in) (e.g., [2]) to access 3-D information. However, 2-D access is also provided (via HTML) for users with a low-bandwidth network connection.

Direct selection of information is supported by a search system that uses search terms and provides direct access to HTML information pages and VRML exhibition spaces.

The LeMO architecture is centered on different servers which provide the various services of the LeMO system (see fig. 1):

  • WWW server for the management of HTML pages and VRML environments
  • Video server for direct video playout (video on demand) using streaming video technology
  • WebCam server for transmission from live sources
  • Database server for information requests from museum databases

The transmission of data between the client (WWW browser) and the servers is realized using various protocols (HTTP, video streaming protocols, RTP [3], RSVP [4]).

The LeMO architecture is characterized by this (fig. 2) layer model.

The servers used in the museums are Unix servers, while workstations with Internet access (e.g., a PC) are required for the user clients.

The virtual exhibition is accessed via a WWW browser such as Netscape Communicator or Internet Explorer. In addition, plug-ins must be installed for a VRML browser and a video player.

The user arrives via the LeMO home page, where a choice is given between branching off immediately into the VRML period rooms or viewing the exhibition exclusively via HTML pages. The exhibition is divided into historical periods. There is a separate VRML room for each period within the 20th century. Clicking on exhibits within these rooms opens a new browser window with additional information. These HTML pages contain texts, images, and videos as well as links to other HTML pages.

Users can use a LeMO search engine to access specific information at the corresponding (HTML or VRML) pages.

The LeMO home page also provides live access to exhibition spaces at the museums via a Web Camera.

The following sections deal in detail with the implementation of the various services -- in particular the Web Camera and the Live Video Server.

3. VRML environments for information transfer

The LeMO project uses the current VRML standard 2.0 [5] which enables interactive navigation in three-dimensional space.

The architecture of the VRML spaces has been designed from scratch and does not correspond to existing rooms or exhibition spaces at the DHM or Haus der Geschichte.

For performance reasons, the VRML period rooms are created using simple geometrical objects (planes, cubes, cylinders). In order to make them as realistic as possible for the viewer, these objects are given a surface texture. Floors can be covered with stone tiles, and columns can be given a marble surface. The storage requirement for rooms of this kind is less than 100 KBytes.

The objects on display in the VRML spaces are from both museums. Photographs of the objects are either scanned in or taken from the museums' object databases. Each image then forms the surface of a simple element (planes, cubes, cylinders) and is placed within the appropriate VRML period room.

Fig. 3 is a snapshot from the period room "Das Wilhelminische Deutschland (1900-1914)."

In the featured room "Das Wilhelminische Deutschland," there are 40 exhibits. When compression techniques are used, the storage volume for these images is still 7 MBytes. Large virtual exhibition spaces thus require the user to have high bandwidth if the 3-D environments are to be loaded in an acceptable time. The distinction must be made clear between data transmission and the subsequent computing of the virtual environment. Once loading via the Internet is complete, the delay before the environment appears on the screen depends on the speed and performance of the individual local computer. The speed of navigation similarly depends on individual performance parameters. A fast computer gives the user a smoother journey through 3-D environments.

One problem with VRML environments is their file size. The larger the environment, the greater the requirements on PC and bandwidth. For this reason, the LeMO project is also developing smaller VRML environments. Instead of designing one large room with many exhibits for each period, some of the periods are broken down into several smaller rooms (VRML spaces).

This concept is linked to another of the project's aims. In order to differentiate the virtual exhibition from traditional museum structures -- where visitors pass through rooms and view exhibits -- the VRML environments also include interactive components, such as slideshows or animations, beyond which further events are to be found.

The VRML space shown in fig. 3 is very close to the structure of a real museum room. But in order to experiment with the possibilities of the VRML/Internet medium, other rooms are given different architectures. Thus, for example, the VRML space on the subject of the First World War (see fig. 4) is without gravity. The user cannot be sure whether he or she is on the floor, the ceiling, or one of the walls.

4. Video server

The LeMO exhibition makes a large amount of archive film material available via the Internet. The videos are transmitted using streaming video technology.

The technical possibilities for video transmission via the Internet have improved a great deal over the last 2 years. The state of the art in this field is streaming video which allows video data to be transmitted via the network in real time and displayed immediately, instead of having to download the complete file before viewing (e.g., VDO [6], RealVideo [7], Vosaic [8]).

Both video-on-demand and live broadcasting of events and news programs can now be implemented with relative ease in satisfactory quality. This is due in part to the increased speed of PCs and modems on the receiving end and to the faster data transfer rates resulting from the development of networks. However, the most important developments in video transmission came in the software field with new transfer protocols and video compression techniques.

At present, there are two different approaches to video transmission. In the server-free approach, the videos are downloaded from a WWW server, while in the server-based approach, the client receives the video data from a special streaming video server.

For the LeMO project, a server-based approach was chosen using the Vosaic video server.

The advantage compared to a purely WWW-based approach is that a higher quality of video transmission can be assured. As the number of clients increases, a Web server soon becomes overloaded, whereas video servers are specially designed to serve larger numbers of clients.

The main reason for choosing the Vosaic server was that it supports a variety of video formats (video for Windows, H.263, and MPEG 1). This is important for the LeMO project as the museums already have a large number of videos in MPEG format.

The Vosaic server uses a proprietary transport protocol (Video Datagram Protocol VDP). The videos are stored on the server at different compression densities with various levels of quality/bandwidth, thus ensuring that all users can view the videos regardless of the bandwidth of their network connection.

The disadvantage of streaming video is that the videos have to be deposited on the video server in a given quality. Parameters specified include depth of color, width, height, frame rate, frame quality, and compression format. This means that video servers are not necessarily suitable for live video broadcast.

For this reason, a new solution for live video transmission (video-on-demand) via the Internet was developed in the LeMO project.

5. WebCam and live video server

Several research and development projects in the fields of multimedia and network technology are currently being devoted to the special demands made on data transfer technology by video and audio applications. Much of the work from these projects is still in the development or test phase and is therefore not widely available (e.g., ATM, RSVP). To ensure that these new developments can be taken into account, we chose a generic architecture for the live video server (WebCam server). This architecture is intended to reflect current research results and represents a generalization of the most important principles, so that new technologies can be easily integrated into the video server as soon as they become available.

The nonuniform deployment of such technologies continues to create a heterogeneous user community. A video server should be capable of providing image sequences of the best possible quality for each individual user. Most existing video servers provide a single video format for all users. In a heterogeneous environment, this gives unsatisfactory results. In our model, a live video server is able to provide various frame sizes and frame rates simultaneously, so that users with different bandwidths all receive satisfactory video pictures.

The design of the live video server for LeMO is based on the assumption that the video data will be transmitted via network connections of varying quality. The majority of clients have a modem or an ISDN line and thus a relatively low-bandwidth connection to the Internet. However, both of the museums in question -- DHM and Haus der Geschichte -- have a broadband B-WiN link, thus ensuring high quality video transfer, as long as suitable technology exists at the receiving end.

Our aim is both to ensure that Internet users worldwide receive the best possible quality according to their available bandwidth and also to make use of ATM technology wherever available. This approach leads to a generic, object-oriented architecture whose basic protocol is interchangeable. In the actual implementation this is reflected in the abstract classes which can be subsequently adjusted to any possible type of connection.

The transmission of live video images from the museums was implemented using Java (Java Development Kit 1.1) [9] as the platform and the programming language. This enables users to view video sequences from the museums using a WWW browser without installing special plug-ins. Java was also used for camera control for the same reason.

Fig. 5 shows the interaction of the various components. The data is transferred from the server workstation in the museum to the user's PC via the Internet. A camera is attached to the workstation which sends video images to the computer via the video capture interface. At the same time, the camera can be controlled (up, down, left, right, zoom, etc.) from the workstation via the serial port (RS 232). The user's PC is connected via the Internet to the workstation which acts as a server, providing the video images and the functionality for camera control. In addition to Internet access, the user requires a standard WWW browser which supports Java.

Three different servers running on the workstation at the museum provide the communication between the server computer and the PC. The user's WWW browser downloads the classes of the Java applet from the WWW server via the HTTP-protocol and executes the applet. Two applets are displayed in one HTML page: one for the video image and one for camera control. The video image applet sets up three Internet connections to the live video server. One of these connections sends video data via the RTP/UDP protocol from the server to the video applet. The video is then displayed if the available bandwidth is sufficient. But before video data is transmitted, a stream control connection is set up between the video applet and the live video server. This connection is used by client and server to negotiate which format (picture size, frequency, etc.) and which protocol (RTP/UDP or other) are to be used for transmission of video data. As these parameters may change during live transmission, the stream control connection is maintained even after the video data connection has been set up.

The third connection, the traffic monitor, is used to adapt the data stream to the available bandwidth. The video applet calculates the currently available bandwidth by measuring the delay with which video data is received. This information is passed to the server at regular intervals in the form of statistical reports.

The camera control applet communicates via a proprietary control protocol with the camera control server which provides the camera control functionality for a given user. User selection is also carried out by the camera control server.

Architecture of the live video transmission

Live video transmission can be broken down into three main parts:

  • Data stream components which process the video data and pass it on for display as image sequences
  • Traffic monitor objects which monitor the data stream and adapt it to the processing speed of the data stream components and bandwidth availability
  • Stream control, which initializes, connects, and where necessary alters the data stream and traffic monitor objects

The architecture was designed to allow simultaneous usage of different types of network connections and image formats. Parameters are set dynamically. This allows a wide range of user requirements to be taken into account.

There are three classes of parameter for every video connection. The first class consists of video parameters representing video encoding properties such as image resolution in pixels (width and height), color resolution, and time resolution (image repetition frequency). This class also includes compression-related parameters such as type of compression and quality factor.

The second class of parameters determines the type of network connection to be used for the transmission. It includes parameters such as the transport protocol (e.g., RTP/UDP, TCP, AAL5), addressing parameters (e.g., IP address and port number), the feedback protocol (Traffic Monitor), and further features of the connection such as multicasting and quality of service (QOS).

The third class specifies the time-related behavior of the video stream. It includes parameters such as maximum and average delay times, delay variance, and bandwidth as well as data loss and error rates. These parameters relate above all to the QOS properties of the network used, but they can also be applied to the individual components of the data stream and are thus used by the traffic monitor objects for measurement and control of the data stream.

Architecture of the camera control server

The camera control server has to perform two main tasks: It must provide the camera control functionality and select the user who is to control the camera for a limited time. The components involved are shown in fig. 6. The user is given access to the camera control functions via the Java applet interface and the commands are transmitted in the camera control protocol via the Internet. The access control component controls access for the individual users. The camera control device converts the movement commands into camera movements.

The control sequence is as follows. Once the user's browser has loaded the applet code from the WWW server, the user interface appears in the browser. The user can now state whether he or she wishes to move the camera, after which the connection to the camera control server is set up. Client and server now communicate via the camera control protocol. First, the client announces itself to the server. Then it waits until the server enables it to move the camera (start). This is shown on the screen. The user can now use the displayed control functions to move the camera. When the client receives a stop message, the user's access to the control functions is ended. This is also shown on the screen.

Access control is required to select one of a number of Internet users wishing to use the control functions at the same time and to provide that user with a limited period of access. All the other users who wish to use the camera must join a waiting list. The control functions include asking the current camera position and turning the camera around two axes (horizontal and vertical), as well as setting the zoom.

6. Conclusion

The preceding sections contain a description of the architecture of the LeMO system, a particular feature of which is the use and integration of a wide range of Internet and multimedia technology.

The system architecture was designed to do justice to the current requirements in the field of culture and of museums in particular. All cultural institutions have at their disposal huge amounts of information in the most varied media and the WWW is the perfect medium for providing worldwide access to this material. The LeMO project makes a point of working with all the multimedia technology the Internet has to offer in order to support and experiment with the museums' text, image, film, and sound archives.

Although the LeMO exhibition is not due for Internet release until summer 1998, initial results are already available.

  • Display quality depends mainly on bandwidth and the performance of the user's PC. This applies in particular to the loading and calculation of the VRML environments and the transmission of the video streams.
  • The VRML environments look different when viewed using different browsers, as the browsers don't strictly conform to the VRML 2.0 standard.
  • WWW browsers are repeatedly caused to crash by problems with the interoperation of the various multimedia technologies, e.g., the simultaneous use of VRML and streaming video.
  • In order to provide the service required by the users, the museums need high bandwidth Internet connections, e.g., in order to process a number of video streams at the same time.
  • On the protocol level, the LeMO system is characterized by its use of various transport protocols (HTTP, VDP, RTP). The system's stability and performance will depend on how the various data streams behave in a common context.

The success of the virtual exhibition will therefore depend not only on content and presentation but also on the quality and stability of the multimedia Internet technology, for which a high-bandwidth Internet connection like the German B-WiN is essential.

The LeMO architecture and its components are a good example to show other museums or cultural institutions what is possible on the Internet today. So LeMO is a good basis to establish an information and communication infrastructure for the cultural sector.

7. References

1. DFN-Verein (Association for the Promotion of a German Research Network), http://www.dfn.de/

2. VRML-Browser: CosmoPlayer: http://cosmo.sgi.com, WorldView: http://www.intervista.com

3. Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V.: RTP: A Transport Protocol for Real-Time Applications, Request for Comments RFC 1889, January 1996

4. Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.: Resource ReSerVation Protocol (RSVP), Version 1 Functional Specification, Internet-Draft, May 1997

5. Ames, A.L., Nadeau, D.R., and Moreland, J.L.: VRML 2.0 Sourcebook, John Wiley and Sons, 1997

6. VDOnet Corp., VDO, http://www.vdo.net

7. Progressive Networks Inc., Real Audio Video, http://www.real.com

8. Vosaic Corp., VOSAIC - Video on the Web, http://www.vosaic.com

9. Java: http://www.javasoft.com

Acknowledgments

We would like to thank Kai Albrecht and Dr. Lutz Walther for content preparation and Stefan Scheil, Wolfgang Schwanke, and Heike Walter for their assistance in the implementation.

[INET'98] [ Up ][Prev][Next]