A&MI home
Archives & Museum Informatics
158 Lee Avenue
Toronto Ontario
M4E 2P3 Canada

ph: +1 416-691-2516
fx: +1 416-352-6025

info @ archimuse.com

Search Search

Join our Mailing List.


published: March 2004
analytic scripts updated:
October 28, 2010

Creative Commons Attribution-Noncommercial-No Derivative Works 3.0  License
Museums and the Web 2003 Papers


An Affordable System for a Thematic Exhibition by Using Internet/Intranet

Loong Wing Tang, Chun Wai Cheung, Kwok Wai Ng and Chi Kin Wong, Hong Kong Science Museum, Hong Kong


The Hong Kong Science Museum presented a special exhibition titled "Flowers in the Mirrors" in May 2002. A Chinese novel that was written in the Qing dynasty (1644-1911) inspired this thematic exhibition. The exhibits were designed in a way to recreate the experience of the two main characters in the novel during their adventures in various "Countries" simply by mirrors. How were the dihedral angles of the mirrors and what were their dimensions became the critical factors of successfully reproducing the desired visual effects. Given to a basic calculation of image reflection by computer, the exhibit developer further ported the data to rendering software to visualize the reflection in full scale. To allow visitors not only saw their image reflections inside the exhibits, an Internet/Intranet Image Capturing Sub-System was also developed to provide picture records to the participants. Visitors would receive their hardcopy of images taken in the museum, they could also email or retrieve them from a web site in the Internet. This paper gives a comprehensive review of these exhibits and how the computer system worked with the Intranet / Internet.

Keywords: Mirrors, Flowers, Qing, Internet, Intranet, IP Camera, Barcode Scanner, and Dihedral Angle



- is the jade tablet that recalls Tang Xiao-shan's memory of the past in the fairyland as the Fairy of a Hundred Flowers
- is the window through which visitors of our exhibition can get a glimpse of the illusory world and appreciate symmetry in Physics.


- is the vanity fair where the Fairy of a Hundred Flowers suffers after she has mistakenly made all the flowers bloom in winter
- is a fantastic art piece demonstrating the beauty of symmetry and Mathematics in nature.

Flowers in the Mirrors, a Chinese novel written in the Qing dynasty, inspired the conception of the exhibition. The fascinating adventure of the main character, Tang Ao, when he has gone astray into a number of outlandish countries and the difficulties encountered by her daughter, Tang Xiao-shan, when she searched for him make up the content of the exhibition.

The Exhibition

The exhibition included three parts: The first was the 11 strange countries Tang Ao had visited. The exhibits, which made use of mirror reflections, enabled visitors to meet queer-looking countrymen. In the "Country of the Three-headed People", the people with 11 heads and 22 arms would greet visitors by waving their hands. In the "Country of the People with Holed Chests", visitors could take a look at the people's chests and guess where their hearts were. Visitors could imagine helping Tang Xiao-shan to find her father in the hallucinating utopia "Little Penglai" (Land of Immortals).

In the second part, visitors would be able to sit the Ministerial Examinations together with all the talented girls in the novel to see how much they knew about mirror reflections and their applications: Could you make a cube with mirrors and a tube? Could you apply multiple reflections to design the safety reflectors for cars, bicycles, and signs? Or could you design a mirror maze that dazzled the audience?

In the third part, visitors would have a chance to play with the 3D models and toys of symmetric structures at the "Verdant Pavilion". They would be able to reveal the secrets of the magic and visualize the special effects created with the use of mirrors, learning about the living organisms and natural phenomena that demonstrated the wonders of symmetry.

There were 29 groups of exhibits presented in this special exhibition. However, we would like to put more emphasis on a special group of exhibits that were heavily dependent on the effectiveness of the transmission of captured images using internet/intranet. This very group of exhibit was the "Country of Three-headed people".

Country of Three-headed people

"This person has three bodies and one head, while that one possesses three heads and one body. May be they would envy each other should they ever meet"
(J. C. LI. Jing Hua Yuan. Chapter 38)

In this country there were five groups of "citizens" with different number of heads. Upon entering each mirror group, a visitor could use the barcode printed at the back of the ticket and the built-in camera to take pictures of himself/herself (the citizen) there.

Computer programs "Adventures in Raytracing" (from Alfonso Hermida 1993 version) and "SolidWorks" (SolidWorks 2001 plus from SolidWorks Corporation) were employed in planning and designing the mirror setting before the actual fabrication. This had greatly helped to reduce the production time and minimize unnecessary work procedures. A table of the five Platonic structures was included as follows:

Five mirror sets related to the Platonic structures


No. of mirrors required

Scale of one typical side length in mm

Dihedral angle in degree





















Table 1

Readers may wish to get more information on the calculation at the following website:


The followings were those computed images and ray diagrams were also presented as the follows:

Fig. 1: Tetrahedron

Fig. 2: A ray diagram of tetrahedron

Fig. 3: Octahedron

Fig. 4: A ray diagram of octahedron

Fig. 5: Dodecahedron

Fig. 6: A ray diagram of dodecahedron

Fig. 7: Icosahedron

Fig. 8: A ray diagram of icosahedron

Fig. 9: Cube

Fig. 10: A ray diagram of cube

We would like to present here a more concrete example of using the computer programs to estimate the possible outcome. After that, an actual large mirror setting of octahedron was built. And a little girl dressed in a flower costume was invited to pose for a photograph. This photograph was well received so it was later used in the exhibition poster to catch more public attention.

Fig. 11: Photo taking of the model: the size of the mirror setting was easily recognized as compared to people working on the spot.

Fig. 12: A satisfactory photograph was obtained

After this photo taking, we obtained a concrete experience of the outcome quality was highly dependent on the position of the camera as well as the lighting control to avoid possible distortion. Therefore, we adjusted our design and planned to drill a hole in the facing mirror in the mirror setting during the fabrication stage.

Platform & Environment

The system used an "IBM e-Server X232" for the Intranet server and the platform was "RedHat Linux 7.2. from Red Hat, Inc" with Intranet database server "MySQL 3.23.41 from MySQL AB". The web server of the system was "Apache 1.3.2 from Apache Software Foundation". Both of database server and web server were run in the IBM Intranet server. All the desktop computers were "IBM Netvista M42" that ran under "Chinese Windows 2000 Professional version". A schematic chart below showed the different functional components of system.

Fig. 13: Schematic of different functional components of the system http://www.lcsd.gov.hk/CE/Museum/Science/fig13.htm

Image Capturing Sub-system (ICSS)

The custom design embedded controller that used a Rabbit 8-bit microprocessor "RabbitCore Module" worked as the core of the image capturing sub-system. It integrated a Barcode Scanner and an IP Camera to perform login identification and image capturing function. The platform of the controller used its own instruction sets that based on Z80/Z180, but had been adapted to be C-friendly. The communication between the ICSS and the Intranet database server was made through Telnet and FTP services by using TCP/IP protocol. There were five IP cameras in total, one installed for capturing real time image at each station.

Fig 14: A block diagram of Image Capturing Sub-System

Algorithms of operation

There were two major sub-systems, the Image Capturing Sub-System (ICSS) and the Snowflake Design Game (SDG). ICSS created JPEG format images while SDG generated transition files that could be interpreted by the Flash program. Both files from ICSS and SDG would be transferred to the Intranet database server by FTP service and be identified by bar code. Bar code label was printed at the back of each admission ticket and the identified number also served the identified key while participant retrieved their images or snowflake at home through Internet.

Operation of ICSS:


To uniquely identify each visitor, a barcode label would be stick to the back of the admission ticket. This barcode should be used to set up database account for storing digital image taken inside each station.

Taking Images

Before entering the mirror exhibits, the visitor's ticket will be scanned by barcode reader to retrieve the visitor's identity. Based on the scanned barcode, the exhibit controller communicated with the data base server via Telnet service to setup an account or add file under the same barcode ID record to existing user account.

Image capturing was triggered by pushing a start button at the nearby location. Followed by an audio alarm and a blanking indicator, the participant would be notified the image capture sequence. The captured image file was transferred to the database server via FTP. Participants were allowed to capture as many images as they wish. However, only the last image captured at each station would be retained. Each new capture at the same station would overwrite the previous one. Therefore, a maximum total of five images would be stored for each participant.

Displaying Images

There were two plasma monitors to display the last 15 captured images from the database server. The real time images captured by the five IP cameras were also displayed at the plasma monitors. Therefore, visitor could preview their images and watched the actions of other visitors inside each mirror exhibit. This could provide an instant feedback to all visitors and enhanced their motivation to participate the game.

Operation of the Snowflake Design Game


Same as the Image Capturing Sub-system.

Snowflake Design

Each visitor could design step by step his own snowflake pattern based on the instruction at each web page in the workstation. There were 2 workstations for participant to design their own snowflake. After that, the pattern file would be transferred to the database server via FTP service.

Retrieving the Image and Snowflake Pattern

Three Workstations were provided for retrieving their images and snowflake patterns. Each workstation was installed a barcode scanner for reading the barcode. The retrieved barcode entered into a field on a web page and was sent to the database server for searching the image taken and snowflake pattern. The images and snowflake pattern could be sent out by email or could be printed out at the two printing stations nearby.

Web pages that were open to the public

An external hosting server was also setup for visitors to retrieve their images that had been taken in the exhibits or their snowflake pattern through Internet by entering their barcode information on the museum homepage. The image taken and snowflake created in the museum were batch updated at interval to the Internet Server through FTP service.

Choice of equipment

At the very beginning of the planning stage, the museum would like to develop an image capturing system installed inside the mirror exhibits to present the illusion image so as to enhance the entertainment factor of the exhibit. As the system might be required attach to the rear size of huge mirror, the equipment should be compact and flexible. Therefore, the reliability would be the primary concern because the maintenance of the system would be performed on the mirror surface and frequent repair was not allowed and not preferable. Owing to time constraint, the number of exhibits and the location could not be confirmed, we could only ensure the system to be distributed all over the exhibition area. The system should be built on the distributed platform and each controller could act as a master or a slave controller as when required. This allowed us for further development by changing or modifying the layout at any time. A Local Area Network (LAN) was also anticipated and TCP/IP was chosen as the system communication layer. Based on the above-mentioned concerns, the choices of equipment for the ICSS were summarized as follows:

Network Camera

Many people first thought to use WebCam for the image capturing function as it was easy to setup and the cost was only a few hundred Hong Kong dollars. But, the main problem was that WebCam had to be attached to a desktop computer that was always not reliable and the drivers of the WebCam adopted the proprietary graphical user interface only. As such, the integration of camera and the control system was very difficult particularly in the control or monitoring of the Webcam behavior through the Windows Operating System of the desktop computer. To eliminate this problem, AXIS 2100 network camera was chosen as it could be attached directly to an Ethernet network and no desktop computer was required. The AXIS 2100 network camera equipped a built-in web (HTML) interface for configuration and monitoring that made the management simple. The AXIS delivered compressed JPEG image at a speed of 10 frames per second that fulfilled the live video presentation on the Video Display Station (plasma monitors). The built-in I/O connector allowed controlling the camera in a straightforward and easier way. The replaceable standard CS mount lens would add the flexibility of changing view angle for different size of captured image as required. As a whole the network camera was a stand-alone unit in the whole system and could integrate to any kind of controller easily at every stage of development

Barcode Scanner

The input device played an important role in the system design. Before choosing any appropriate device, we needed to determine which type of media or technology to store the visitor's identity. Smart card was one of non-contact types of media and it was very fit for our purpose. However, it was expensive and the operation costs, included the programming and production of large quantity of smart cards, were very high. Therefore, it was not a cost effective choice. Another consideration was adapting barcode to hold the identity information since the format of barcode could be programmable by in-house staff and it was compatible with our existing museum pass barcode system. The most important was the cost of barcode sticker could keep to minimum for large amount of barcode printing. After choosing barcode as the proper media, some essential features of barcode scanner should be equipped. Firstly, the barcode scanner had programmable self-holding identity function for serving as exhibit ID. Secondly, the scan pattern should be omni-directional. Eventually, we chose "IS6520 Barcode Scanner from Metrologic" as it could be embedded the programmable prefix in the barcode data for identification and its scan pattern was 5 fields of 4 parallel lines (i.e. omni-directional).

Visitor Detection Sensor

To ensure the capturing of visitor image at a proper position, it was necessary to install a sensor to detect the presence of a visitor standing on a particular position. Diffuse type infrared sensor from "Omron" was used to allow the system enter into image taking state. When the visitor left the exhibit, the barcode data would be cleared. After that the exhibit controller entered into an idle loop and waited for the next visitor to present a barcode.

Exhibit Controller

The core of the image capturing sub-system was a custom designed programmable controller. Theoretically a desktop computer could perform the same function as the controller but there were some limitations such as the bulky size, non-reliable desktop operating system and hardware failure. The critical factors were listed as follows :

  1. Compact size;
  2. Powerful performance;
  3. Flexible I/O included serial, parallel and Ethernet port within a controller;
  4. Master and slave control available; and
  5. Reliable and easy to develop application with data library support.

Based on the above concerns, we decided to use "RCM2100 RabbitCore Module from Rabbit Semiconductor" as the exhibit controller. This embedded controller had additional features such as 56 programmable I/O for serial or parallel as required, integrated slave interface for exchange of data between master and slave control, generated programs that use 512K of data in SRAM and 512K of code in the flash ROM. The specific controller could act as the bridge of communication between serial or parallel and Ethernet.

Fig. 15: Rear Side of IP Camera

Fig. 16: Embedded Controller

Internet / Intranet servers

Fig. 17: System flow chart of updating the images and snowflake record at the server http://www.lcsd.gov.hk/CE/Museum/Science/fig17.htm

As the files created should be shared between the local database server and the external database server, a file synchronization process had been programmed at the local server. This process synchronized from the local server to the external server but not vice-versa because of the followings:

  1. Only snowflake game was available at Internet. No image capturing sub-system record would be created through the museum homepage on Internet.
  2. The snowflake created at the museum homepage would have an ID different from that those created at the museum for easy identification.
  3. It was not available to login the account in museum and get your snowflake created at Internet, since only the barcode on the admission ticket could be used to save the snowflake that was created in the museum.

Therefore, the captured images in the museum would be transferred to the external database server through FTP service and updated the Intranet database table "photo_sys' that indicated those images had synchronized. The process also updated the newest snowflake designed in the database in the museum. This synchronized process was set to carry out once per hour, or right after the printing process of that particular account. The database structure was shown as below:

Fig. 18: Real data of the transactions at the server

Development tools

An html page with an Active-X component embedded, which connected directly to the 5 network IP cameras. The front-end client programs were written by "Flash 6.0 from Macromedia" and "Visual Basic 6.0 from Microsoft". The graphics were created by "Fireworks 4.0 from Macromedia". The synchronized program and other batch programs were written by "php 4.0.6 from PHP". The back-end database was managed by MySQL client.

For the image-capturing controller, the development programme was written by "Dynamic C from Z World". The use of such programme tool was due to its industrial-proven and high reliability nature as well as low license charge.

Network Traffic

The resolution of required JPEG image from the IP camera was 640 x 480 in 24 bit of RGB colour, therefore, the size of each image to be transmitted over the network :

A pixel of a colour image was represented by triplets of RGB data each representing 8 bits, resulting in a total of 24 bits per pixel, the calculation of file size:

  • = 640 x 480 x 24
  • = 7372800 bit
  • = 900KB

Assume the JPEG compression ratio was about 10 for real life, the file size should be

  • = 900KB / 10
  • = 90KB

The bandwidth of the Intranet was 100Mbps, the nos. of image to be transmitted at one time was:

  • = 100M / (90K x 8)
  • = 100M / 720K
  • = 138 nos. of image files maximum

There were five image capturing stations (upload 5 images), three printing stations (each station download 5 images i.e. sub-total was 15 nos.) and two email stations (each station download 5 images i.e. sub-total was 15 nos.). Therefore, the total nos. of image transmitted over the network was about 35 nos. and the loading of the network was:

  • = (35/138) x 100%
  • = 25% approximately

Further to above calculations, the capacity of the network handling the transmission of files was good enough and even for future expansion.

Interface of the system:-

Snowflake Design Game

Snowflake was of hexagonal symmetry. Therefore, when a snowflake was rotated by 60 degrees about its centre, it looked identical with the original one. In this game, users could create their own snowflakes by designing 1/6 of the whole step by step.

Fig. 19: Snowflake design game interface

Print the images

The visitors could select five different images in jpeg format and these files were stored at the Intranet database server. The image print interface allowed visitors to drag and drop a maximum of 5 available images and printed on the pre-designed A4-size paper. There was no limitation on the combination of the five images to be chosen. The visitors could then press the PRINT button and collected the coloured printout within one minute.

Fig. 20: Print image system interface

Email the images or snowflake

There was an interface for sending email with the snowflake or images. The visitors could login their account by using the barcode scanner. The snowflake and images of their accounts would be displayed after connecting to the back-end database. Then they could choose the snowflake or one image and email them to an Internet email address. In order to minimize the file size of this email, the addressee would receive an email with an Active-X component embedded for snowflake. If the visitors chose to email the image, this image would not be sent as an attachment to the email, but download from the remote server when receiving the email.

Fig. 21: Choose one image or snowflake to email to a friend

Fig. 22: Email system interface

Further Development

For the planning of the image capturing sub-system, we would like to reuse the system concept for other projects in future so there was enough space of the controller to develop applications. At the current exhibit model, the front end was the integration of IP camera, barcode scanner and sensor interface. The back end was a database server and the embedded controller performed the bridging function between the two ends. The potential improvements to the exhibit offered by the embedded controller were summarized as follows :

  1. When there was a need to enhance the function of front end interface, for example- record the audio clips or even generate a video footage in a form of motion frames, we could just modify the protocol slightly and reprogram the serial I/O a little bit. Alternately we could change the IP camera to a higher series of model which offered the audio and video output feature if required. On the other hand, any change of back end from server to stand alone browser client to just monitor the exhibit environment was also possible.
  2. If we changed the visitor detection sensor from infrared to ultrasonic type, the system could perform automatic security monitoring system that would transfer the captured image to a monitoring station whenever an object passed through the checkpoint where IP camera was being mounted on.
  3. We could install the spare modified unit of image capturing station in some future exhibit promotion booths in museum and allow visitor take photo with an exhibit backdrop as the background at free of charge. The photo could be sent by email then. This sort of promotion activity was at no additional cost to the museum.
  4. The embedded controller had a built-in web server and we could modify the web page that a number of hyperlinks interact with serial commands to control external device. For the existing control system being used in our exhibition areas, we could install an embedded controller and program it to interact with these serial devices control. This would enable visitor to operate those exhibits remotely through our Intranet in the museum. When coupling with IP camera at nearby exhibits, visitors would even monitor the instant feedback of the exhibits. Furthermore, we could extend this concept to cover all the exhibits in our museum to build a virtual museum on Internet. Such that, the surfers in the Internet could visit our museum and operate the exhibits remotely. The costs were just the embedded controller and could be programmed them to match the existing control system. The Intranet inside the exhibit already existed and we simply modified our web site to redirect the link to the Intranet web server of each embedded controller.
  5. As the visitors could retrieve their images and snowflake back at the Internet, we could design an interface allowing visitors to send e-card with the their own images or the snowflake. This will provide good promotion opportunity to the museum.

Tackling with the Hardware and Software Problems

Change from Wireless LAN to Wire-oriented Approach for Printing Workstation

During the planning stage, the network environment for this exhibition was chosen a wireless LAN protocol 802.11b with client interface in USB connection for the desktop computers. We used the software provided by the USB client installed in a laptop computer in order to check the signal strength in our exhibition area environment. The readout showed promising and signal strength was good enough. Furthermore, Internet surfing also ran on the laptop computer and was found that the connection speed and condition were sufficient.

After the exhibits installed, we found the signal strength between the desktop computer and the data base server became fluctuating. It might be due to the interference from other equipment within the exhibition area and there were some "blind spots". Therefore, we had to revert the wireless LAN environment to wire-oriented approach for the desktop computers and controllers to ensure a proper connectivity.

Timeout Problem for the IP Camera Controller

Before transferring the image from the IP cameras to the Intranet data base server through ftp service, the controller of the IP cameras was first telnet to this server to check if the account contained image or not. If so, the latest image would overwrite the previous one. To allow sufficient time for the server to process the request, the IP camera controller had to be set a two-second timeout. If the last telnet process was not completed within the time-out period, the controller was programmed to reset the telnet process. Then, it would retry the telnet process again. Otherwise, the telnet port might be occupied by the precedent unsuccessful process and affected the next image transmitting process.

Policy Control

All the exhibits were placed in the public areas and a policy control should be in place for them so that visitors could interrupt, terminate or delete the programs from the workstations. Since our client programs for this project were written in Flash, the executable files were generated and the programs were set for full screen mode. Therefore, the desktop of the computer would not be accessible. Furthermore, a track ball with only left button was installed to serve as inputting device. Together with the login can only be done scanning the bar code at the back of the admission ticket by barcode scanner, the policy control could be easily accomplished as there was no keyboard and the right button of the track ball was physically not connected. This arrangement was up to our requirement at the snowflake design game and the print image workstations.

However, this method could not be applied to the email sending workstations, as we had to provide keyboard to the visitors to type the email addresses. Under this circumstance, a software called SecureKeys from Tazion was applied to control which hot-keys at the keyboard were not available. For example, we disabled the Alt+F4 and Ctrl+Alt+Del hot-keys from the keyboard. We also found that SecureKeys worked well with Chinese Windows environment.

Visitor Detection Sensor Fault Signal

The function of the infrared sensor was to detect the presence of a visitor on the right position and the sensor was only sensitive to heat change. Unfortunately, when visitors wore black-coloured trousers would make the body temperature a little bit lower than normal. The sensor might not be able to detect the presence of visitors. Eventually, the system could not resume to the ready mode and halt the next image taking process. To solve this problem, we tuned the sensitivity of sensor to the highest and tilted the angle of sensor 60 degree upward. In this case, the beam pattern of the sensor covered the upper part of body. This would maximize the sensing area.


The exhibition period of the system at Intranet was between 3rd May 2002 and 7th August 2002. As for Internet, the period was between 3rd May 2002 and 21st August 2002. Below was the statistics report for the number of usage for different part of the system.


Local Server : The Intranet exhibit web server in the museum
Remote Server : The Internet web server hosted by ISP
Image 1 : No. of images taken in Tetrahedron
Image 2 : No. of images taken in Octahedron
Image 3 : No. of images taken in Dodecahedron
Image 4 : No. of images taken in Cube
Image 5 : No. of images taken in Icosahedron
Snowflake : No. of snowflake created
Printout : No. of colour printout in the museum
Email Login (Chinese) : No. of email routine login in the museum (for local server) or Internet (for remote server) using Chinese version
Email Login (English) : No. of email routine login in the museum (for local server) or Internet (for remote server) using English version
Send Snow : No. of snowflake sent in the museum (for local server) or Internet (for remote server)
Send Image : No. of image sent in the museum (for local server) of Internet (for remote server)
No. of Participant : No. of barcode registered in the Intranet exhibit web server

Table 2


According to our statistic record, there were more than 100 000 captured images and 20 000 snowflakes created. The Image Capture Sub-System and the Snowflake Design Game were proved to be a reliable system and they were well receiving in the "Flowers in the Mirrors" special exhibition. The systems had been designed and performed up to our expectation and no major breakdown or crash during the whole operation period from May 2002 to August 2002. The TCP/IP also served a vital part in the system. It provided a standard communication protocol and was widely applicable in the Internet by surfers around the world. With the communication protocol had been standardized and the I/O devices were TCP/IP compliance, the system development time could greatly be minimized. The hardware conflict due to the propriety configuration between different vendors could also be eliminated. Integrating the hardware and the application system was no longer dragged by the incompatibility or likewise. The time saving in production allowed the exhibit developer to have more options to change and computer programmer less complication. These advantages would eventually cut the costs down and also the components could be re-used in other projects. Nevertheless, a system like this could extend the usability of computer exhibit from the museum to those participants who connected to the Internet with minimal costs.


The exhibits and computer systems as described in this paper had been used out as a part of the Special Exhibition "Flowers in the Mirrors" presented by the Hong Kong Science Museum, Leisure & Cultural Services Department, the Government of the Hong Kong Special Administration Region. The authors thanked also other members in developing the exhibit contents, designs and fabrications, particularly Mr Chee-kuen YIP, Alvar POON, Henry CHOI and Stanley KWONG in making this exhibition possible.