- 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.

"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

Table 1

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

http://www.issil.com/corwin/platonic.txt

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:

Registration

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

Registration

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.

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.

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

• = 900KB / 10
• = 90KB

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

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

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.

Statistics

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

Table 2

Conclusion

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.

Acknowledgements

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.