Beckman Institute, University of Illinois at Urbana-Champaign, Urbana, Illinois 61801

Corresponding author: Nick Kisseberth, Beckman Institute, University of Illinois, 405 North Mathews Avenue, Urbana, Illinois, 61801. Tel: 217-244-6928; email: nkissebe@itg.uiuc.edu

This paper describes the Web-based application "JavaScope TEM." JavaScope is an "exploration/browser" tool for operating a Philips CM200 Transmission Electron Microscope and viewing digital images remotely. The primary use of the application is as a collaborative tool for remote consultations.

Introduction

JavaScope is a web-based application designed to operate a Philips CM200 Transmission Electron Microscope (TEM) and to view digital images remotely. Remote control and observation of TEM images is potentially useful in at least three separate areas: Collaboration, Teaching, and Service. As a collaborative tool the JavaScope application allows consultation across the country or world in that a colleague is able to view and manipulate a specimen and provide real-time input on the quality of the data. As a teaching and demonstration tool it can provide a "bulletproof" interface to the instrument for naïve users and spectators. As a service tool it can be used by expert technicians to illustrate and explore specific problems with an instrument. This allows for a straightforward determination of the nature of a problem which benefits both customer and service provider. In this paper we will describe the implementation of the JavaScope application and discuss some of the benefits and disadvantages of the system.

This project was originally conceived as an experiment in the use of Java (Arnold and Gosling, 1996) for remote instrumentation, and an illustration of the capabilities of such a system. At the same time we were also collaborating with a number of investigators across the country on a project to automate the acquisition of large numbers of TEM images (Potter et al, 1998a,b). During this project we had a need for a tool that enabled consultation with remote collaborators, ideally enabling them to view and manipulate TEM specimens interactively and thus provide insight and advice as to the quality of the specimen. With this goal in mind we wanted to limit the requirements at the remote site to be simply an Internet connection and a standard "out-of-the-box" web browser (such as Netscape Navigator or Internet Explorer). No browser plug-in installations or browser revision requirements were to be allowed.

Given the goal of producing a user interface for our TEM using only the capabilities available in the standard distributions of Internet Explorer 3.x and Netscape Navigator 3.x there were only two possible implementations. The simplest was to use a combination of HTML forms and CGI scripts as was traditional at that time. The more complex possibility was to use the new Java support provided in those browsers. The first attempt used the simpler HTML Forms/CGI scripts method (Kisseberth et al., 1996). While it was partially successful, continued use of this simple system would have severely limited future expandability. Java as an alternative allowed the creation of a platform independent application with few operational

What is Java? Java is an object-oriented programming language designed to be compiled into bytecode. Bytecode is essentially machine language instructions that can be executed by a Java Virtual Machine (JVM). Java Virtual Machines have been developed for all major computing platforms and are built into Netscape and Microsoft Web Browsers. Java applications are written as a collection of classes (functions related to an object); these classes can be written in Java or compiled into the native machine language of the JVM host computer. The Abstract Window Toolkit (AWT) is a standard class library compiled native to the machine running the JVM which provides high-level user interface components that the Java application can use. The AWT translates user interface components from the Java AWT specification to the local computer’s native user interface. This results in applications with a "native" look and feel, but also results in applications which look and behave slightly differently depending on which platform the JVM/AWT is running.

Java applications run from a Web browser are known as Applets and have restricted access to the computer running the JVM. This prevents Applets from reading private data from your computer or otherwise acting in an unauthorized manner. While it is possible to bypass this security restriction with signed Applets, this has not yet been implemented in all web browsers and it is not consistent even in those where it has. We thus decided to operate within the restrictions of an unsigned Java Applet.

The JavaScope Applet requires only a few basic controls:

The only limits the Applet environment places on our application is the inability to save images to disk or to contact a computer over the internet other than the one the Applet was loaded from.

JavaScope has been written as a client/server application (see figure 1). The JavaScope applet is the client and presents the application interface to the user. JavaScope responds to actions by the user by sending commands to a camera control server (SSCd) and microscope control server (RCMd) that run on a Unix workstation attached to the TEM and CCD Camera. These servers are responsible for controlling the TEM and digital camera using applications and libraries already developed as part of the emScope library (Kisseberth, 1997).

The emScope library was developed as part of a project whose goal is to provide complete automated control of a TEM. emScope consists of a set of software tools that were designed to be (i) easily ported between microscopes and across computer platforms, (ii) readily extended and modified and (iii) distributed over a network so that a long acquisition process could be monitored from a remote computer. A small modification to the emScope remote control server allowed the JavaScope applet to control the TEM.

Usage

JavaScope consists of 19 class files. These class files are placed on a web server running on the same workstation running the SSCd and RCMd emScope daemons. This is necessary as the Java applet can only communicate over the Internet with the machine from which the applet was originally loaded. A basic web page is developed that starts the applet, providing a button that starts the JavaScope application interface. The applet is loaded into a web page with an HTML tag similar to:

<APPLET CODE="JavaScope.class" width=120 height=40></APPLET>

Access control can be added to this page to password protect or otherwise restrict access to the Applet. This is the responsibility of the web server configuration.

When the Java Applet is started it connects to the SSCd and RCMd server processes on the host from which the applet was loaded. The applet queries the current state of the microscope and camera and presents this information to the user via the user interface as shown in figure 2.

The left-hand window displays the last image acquired. Several options are available to determine how the image is acquired and transferred to JavaScope.

Transfer: If "compression" is selected, the SSCd compresses the image (JPEG) prior to sending it to JavaScope. Otherwise the data is sent in its full and uncompressed form. When accessing the scope from outside the local area network using the compression option can significantly speed up the image acquisition process with almost no discernable sacrifice in image quality.

Mode: Images can be acquired either singly or in continuous acquire mode. In "single frame" mode the applet updates the image on each press of the "Acquire" button. In "continuous acquire" mode the applet continuously updates the image after the "Start" button is pressed until the "Stop" button is pressed or the acquisition mode is changed. This provides a "live" view from the instrument. At best this will update the image several times a second, in practice it can take several seconds per image over a relatively slow network such as the Internet.

Size, Binning, and Exposure: These control the basic parameters of the CCD camera acquisition process. Exposure is the number of seconds to expose the CCD to the electron beam; binning is the number of CCD elements which make up a pixel, and size is the pixel dimensions of the image to be acquired (after taking binning into account, 128x128 binned by 8 covers the entire 1024x1024 element field of view of the CCD).

The right-hand window displays a basic microscope control panel.

Magnification: Allows the magnification of the TEM to be adjusted to any of the listed values. The intensity of the electron beam is automatically adjusted to account for the change in magnification so as to maintain a consistent average illumination.

Intensity: Allows the intensity of the electron beam to be modified. The units are currently uncalibrated so it takes some trial and error to effect a reasonable change.

Focus: Allows for some control over focus. Manual focus allows free control of the focus to any selected value. The current level of defocus can be measured using the button supplied. If the specimen has some structure, is not too dark and is not too far from focus (<25 um from focus for example) this method returns a reasonable estimate of the current defocus. The autofocus option functions by first measuring the defocus and then changing it to the appropriate value. During measure- or auto-focus procedures, image acquisition is unavailable as the camera is being used to perform the focusing routines on the server.

Goniometer controls: Four buttons are provided to allow the image to be shifted in the directions corresponding to the axes of the acquired image. The size of movement can be selected ranging from a pixel to a full screen. The specimen can also be moved using the left mouse button: clicking this button on a feature of the image will cause that feature to be moved to the center of the field of view.

The basic application as originally conceived, i.e. a readily accessible tool for remote consultation and exploratory grid browsing, is successful. In our project for developing automated data acquisition tools, JavaScope has been used by our collaborators in California (Research Institute at Scripps Clinic) to control the TEM in Illinois and provide advice as to the worth of acquiring data from a particular specimen. It has also had an additional benefit in providing students at the microscope with a means by which they can consult with an advisor who might be located at a remote location (i.e. across campus).

This initial investigation of the use of Java as a tool for remote control and image viewing has however illustrated a number of areas where Java does not provide the required solutions. Java has evolved rapidly over the past several years, generally improving with each revision, but the suppliers of web browsers have not done as well in keeping their JVM and AWT implementations current. Consequently different versions of each web browser support a different version of Java; for example:

^*AWT 1.1, Printing, New Event Model available only for Windows 95/98/NT and UNIX versions.

As a further complication, various vendors have developed a technology called the Just-In-Time (JIT) Compiler. This allows the JVM to compile Java bytecode into native machine language in blocks and keep the compiled chunks around in case they are needed again. This vastly improves performance over the standard JVM which interprets the Java bytecode one chunk at a time and then has to re-interpret a short while later. Java 1.2, not yet widely implemented, promises further improvements in cross platform consistency and performance enhancements. There are also numerous extensions available (class libraries often compiled native to the JVM host computer) which can be added to the JVM environment. These range from 3D graphics to database integration but are not provided "out-of-the-box" with the JVMs provided with current web browsers.

JavaScope design goals necessitated writing this applet for the lowest common denominator (JDK and AWT 1.0.2) which had a number of practical and negative impacts. It has severely restricted what can be done with the interface and made it difficult to develop an interface that appeared identical across Windows, Macintosh and Unix platforms. Also the amount of memory Java can access is variable depending on the version of web browser used and it is often not possible to increase the amount of memory available. As a result the current implementation of JavaScope can not handle 1024x1024 images. Furthermore, as Java is an interpreted language it is very slow at handling large amounts of data (although some implementations work quite well as they include JIT compilers). Given these restrictions, our conclusion is that Java is not an unqualified success as a cross-platform web-based application development too. This negative opinion would be modified if we could assume the availability of Netscape Navigator 4.0.6 or Internet Explorer 4.x or later, in which case we could assume Java AWT 1.1 was available. In addition, if the user is running Windows 95, 98 or NT we could assume a good JIT compiler is in action which would allow the Java applet to do more. However, placing these restrictions on the user of the application would defeat the primary initial goal of the project which was to supply a universally available and simple interface to the TEM.

Since JavaScope is a qualified success as a collaborative and consultation tool we plan to add some simple extensions to it in the form of an improved user interface, faster applet loading, and possibly the ability to save and print images. These future versions will require more recent versions of Java, currently Internet Explorer 4.x or Netscape Navigator 4.06 or later. These improvements will be at the expense of serving the lowest common denominator in web browsers and computer systems. It is clear that developing a Java application that works well cross-platform and with many different generations of browsers is difficult at best. This makes it impossible to develop any application and expect it to run "out-of-the-box" in all cases. To get the most out of Java it is necessary to specify which release is required and even possibly what implementation patches may be required for each platform explicitly supported.

In addition to Java there are other alternative web-based application delivery mechanisms. The emScope project (on which the server end of this application is based) has adopted the use of the scripting language Tcl/Tk (Ousterhout, 1994). Internet Explorer and Netscape plug-ins exist on most major platforms for running Tcl/Tk scripts. Unlike Java, Tcl/Tk is a relatively simple scripting language with remarkable power and extensibility. While complex Tcl/Tk applications are difficult to develop organizationally, small to moderate sized applications are relatively easy to develop. For example, while JavaScope took months to develop, a similar Tcl/Tk stand-alone application was developed in two weeks. This would appear to indicate that developing applications of this size in Java may not be worth the software development time if Java is not otherwise the primary development platform of the group.

Would we use Java to develop another application? Probably not. But if we did we would do so with lower expectations. To succeed with Java the software developer will have to use the latest release of Java available and target a particular implementation to get the best performance and visual layout. Also it is clear that Java is not a simple, easy-to-use software development system. It can be as complicated as developing with C++ and certainly requires planning and considerable design before coding. This complexity comes with rewards for the seasoned developer, but is often at odds with software development in the scientific research community.

Financial support and equipment was provided by the National Science Foundation (DBI-9730056) and the International Business Machines (IBM) Shared University Research program. We are grateful to both the Beckman Institute and the National Center for Supercomputing Applications for institutional support.

Kisseberth, N., Whittaker, M., Weber, D., Potter, C.S. and Carragher, B. (1997) emScope: A Tool Kit for Control and Automation of a Remote Electron Microscope. Journal of Structural Biology 120, 209-319

Kisseberth, N., Potter, C.S., Brauer, G. E., Lindquist, J. A., Jatko, M. K. and Carragher, B. (1996) Webscope.Tem: A modular system for distributed TEM. Microscopy Society of Am. 54th annual meeting, Minneapolis, MN. 390-391.

Ousterhout, J.K. (1994) Tcl and the Tk Toolkit. Addison-Wesley.

Potter, C.S., B. Carragher, H. Chu, B.J. Frey, R. Josephs, C. Lin, N. Kisseberth, K.L. Miller and K. Nahrstedt, Microscopy and Microanalysis 4 Supp. 2 (1998) 259.

Potter, C.S., B. Carragher, H. Chu, B.J. Frey, R. Josephs, C. Lin, N. Kisseberth, K.L. Miller and K. Nahrstedt, Proc. 14^th International Congress on Electron Microscopy, Vol 1 (1998) 8.