- Email: [email protected]
JavaScope: A Web-Based TEM Control Interface
Journal of Structural Biology 125, 229–234 (1999) Article ID jsbi.1999.4084, available online at http://www.idealibrary.com on
JavaScope: A Web-Based TEM Control Interface Nick Kisseberth, Gregory Brauer, Benjamin Grosser, Clinton S. Potter, and Bridget Carragher1 Beckman Institute, University of Illinois at Urbana–Champaign, Urbana, Illinois 61801 Received October 20, 1998, and in revised form January 7, 1999
IMPLEMENTATION
JavaScope is a Web-based java applet that implements 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. r 1999 Academic Press Key Words: automated computer control; Java; remote TEM.
This project was originally conceived as an experiment in the use of Java (Arnold and Gosling, 1996) for remote instrumentation and as 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 limitations. 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
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 naive 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 that 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. Additional information, and the applet source code itself, is available on-line at http://www.itg.uiuc.edu/ resources/javascope.
1 To whom correspondence should be addressed at Beckman Institute, University of Illinois, 405 North Mathews Avenue, Urbana, Illinois, 61801. Fax: (217) 244-8371. E-mail: [email protected].
229
1047-8477/99 $30.00 Copyright r 1999 by Academic Press All rights of reproduction in any form reserved.
230
KISSEBERTH ET AL.
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 that look and behave slightly differently depending on which platform the JVM/AWT is running. Java applications that are 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 been implemented. We thus decided to operate within the restrictions of an unsigned Java applet. The JavaScope applet requires only a few basic controls: Camera controls
Microscope controls
Binning Exposure Size Continuous/single frame
Magnification Intensity Focus controls Goniometer movement
The only limits the applet environment places on our application is the inability to save images to disk or
FIG. 1.
to contact a computer over the Internet other than the one the applet was loaded from. This prevents remote users from actually saving any images they are viewing, which prevents this application from being a data collection tool. Future versions, which will use more features of Java 1.1 and perhaps signed applets, will allow us to overcome this restriction if further development of Java-based tools is warranted. Other alternatives such as ‘‘virtual film’’ have been considered in which images are stored on the server and distributed to remote users via a Web page from which the users can then download the images they want. JavaScope has been written as a client/server application (see Fig. 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 et al., 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
Architecture underlying the JavaScope user interface.
JAVASCOPE: A WEB-BASED TEM CONTROL INTERFACE
control the TEM. It is our intention that the emScope library be ported to other microscopes. To this end it will soon be ported to control a Philips Environmental scanning electron microscope and the same JavaScope applet should be able to control this new instrument. See Kisseberth et al. (1997) and (http:// www.itg.uiuc.edu/resources/emscope) for more information. 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 communicate over the Internet only 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 onto 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 Fig. 2. Two windows are presented to the user, one for control of the image acquisition and one for microscope control. The image acquisition variables take effect as soon as they are entered and the next image acquired will reflect the changes made. The microscope controls operate independent of the image acquisition, so there is some delay before the change in the image will be displayed. Depending on the frame rate images are received at, it takes a couple of seconds to see the result of a microscope control change. On a local network the delay is less than a second. Some improvements could be made in this area, but the Java/applet/browser environment places a lot of overhead on the system. The left-hand window displays the last image acquired and the image acquisition controls. 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
231
JavaScope. Otherwise the data are sent in their full and uncompressed form. When accessing the scope from outside the local area network, using the compression option can significantly speed 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. Whether in continuous or single-frame mode each new image is displayed after it has been completely received. Depending on the implementation of Java the user interface remains active during each image acquisition or there is a significant period of unresponsiveness during image transmission. 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 that make up a pixel, and size is the pixel dimensions of the image to be acquired (after taking binning into account, 128 ⫻ 128 binned by 8 covers the entire 1024 ⫻ 1024 element field of view of the CCD). The right-hand window displays a basic microscope control panel. Magnification. This 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. This allows the intensity of the electron beam to be modified. The units are currently uncalibrated so it takes some trial and error to affect a reasonable change. Focus. This 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 µm 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 autofocus procedures, image acquisition is unavailable as the
232
KISSEBERTH ET AL.
FIG. 2.
Java applets responsible for camera control (left) and microscope control (right).
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. DISCUSSION AND CONCLUSIONS
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
JAVASCOPE: A WEB-BASED TEM CONTROL INTERFACE
California (The 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 site (i.e., across campus). Currently communication between the remote user and the local operator is limited to conventional means such as telephone. This has proved sufficient for initial use, but clearly is not optimal. This initial investigation of the use of Java as a tool for remote control and image viewing has, however, illustrated a number of areas in which 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, JDK
AWT
Internet Explorer 3.x 1.0.x 1.0.x Internet Explorer 4.x 1.1.x 1.1.x Netscape Navigator 3.x 1.0.x 1.0.x Netscape Navigator 4.0-4.05 1.1.xa 1.0.x Netscape Navigator 4.06⫹ 1.1xa 1.1.xa aAWT 1.1, Printing, New Event Model available only for Windows 95/98/NT and UNIX versions. Furthermore during preparation of this paper it was discovered that the current version of JavaScope could not display compressed images when using Internet Explorer 4.x under Windows or MacOS and operated very poorly under all browsers under MacOS. We were able to work around the problem with Internet Explorer under Windows. The difficulties with the MacOS browsers elude us (previous versions of JavaScope worked reasonably well under MacOS). We hope to have a solution to the MacOS problems in the near future. This shows the relative instability of the Java platform for cross-platform development. 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 reinterpret a short while later. Java 2.0 (formerly called 1.2), only just recently announced, promises further improvements in cross-platform user inter-
233
face consistency and performance enhancements. There are also numerous extensions available (class libraries often compiled native to the JVM host computer) that 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. It is unclear how rapidly these new versions and extensions will be adopted by the Web browser vendors. At first glance it does not appear the adoption will be quick. 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 cannot handle 1024 ⫻ 1024 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 tool. This negative opinion would be modified if we could assume the availability of Netscape Navigator 4.06 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 of JavaScope will require more recent versions of Java, such as 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.
234
KISSEBERTH ET AL.
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 alternative Webbased 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 2 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. Will we continue to develop this application using Java? Probably. However, we may readdress exactly what Java’s role will be. Rather than using one Java applet, other alternatives include taking a step back and revisiting traditional Web techniques of CGI applications. It is possible that a combination of techniques such as CGI applications, JavaScript, and smaller Java applets may prove to be the most portable and powerful techniques currently available. These are the options being considered for our next project, which has similar requirements of universal accessibility (Netscape 3, MacOS, as well as latest browser offerings). Despite some of our initial problems it is clear that a Web-based approach still offers tremendous value to the project. It allows an easy delivery mechanism, is highly customizable, and promotes collaborative activity almost by definition.
Would we use Java exclusively 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 were 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. REFERENCES Arnold, K., and Gosling, J. (1996) The Java Programming Language. Addison-Wesley, Reading, MA. 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, J. Struct. Biol. 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 America 54th annual meeting, Minneapolis, MN, pp. 390–391. Ousterhout, J. K. (1994) Tcl and the Tk Toolkit. Addison-Wesley, Reading, MA. Potter, C. S., Carragher, B., Chu, H., Frey, B. J., Josephs, R., Lin, C., Kisseberth, N., Miller, K. L., and Nahrstedt, K. (1998a) Microsc. Microanal. 4(Supp. 2), 259. Potter, C. S., Carragher, B., Chu, H., Frey, B. J., Josephs, R., Lin, C., Kisseberth, N., Miller, K. L., and Nahrstedt, K., (1998b) Proceedings of the 14th International Congress on Electron Microscopy, Vol. 1, p. 8.
JavaScope: A Web-Based TEM Control Interface Nick Kisseberth, Gregory Brauer, Benjamin Grosser, Clinton S. Potter, and Bridget Carragher1 Beckman Institute, University of Illinois at Urbana–Champaign, Urbana, Illinois 61801 Received October 20, 1998, and in revised form January 7, 1999
IMPLEMENTATION
JavaScope is a Web-based java applet that implements 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. r 1999 Academic Press Key Words: automated computer control; Java; remote TEM.
This project was originally conceived as an experiment in the use of Java (Arnold and Gosling, 1996) for remote instrumentation and as 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 limitations. 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
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 naive 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 that 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. Additional information, and the applet source code itself, is available on-line at http://www.itg.uiuc.edu/ resources/javascope.
1 To whom correspondence should be addressed at Beckman Institute, University of Illinois, 405 North Mathews Avenue, Urbana, Illinois, 61801. Fax: (217) 244-8371. E-mail: [email protected].
229
1047-8477/99 $30.00 Copyright r 1999 by Academic Press All rights of reproduction in any form reserved.
230
KISSEBERTH ET AL.
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 that look and behave slightly differently depending on which platform the JVM/AWT is running. Java applications that are 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 been implemented. We thus decided to operate within the restrictions of an unsigned Java applet. The JavaScope applet requires only a few basic controls: Camera controls
Microscope controls
Binning Exposure Size Continuous/single frame
Magnification Intensity Focus controls Goniometer movement
The only limits the applet environment places on our application is the inability to save images to disk or
FIG. 1.
to contact a computer over the Internet other than the one the applet was loaded from. This prevents remote users from actually saving any images they are viewing, which prevents this application from being a data collection tool. Future versions, which will use more features of Java 1.1 and perhaps signed applets, will allow us to overcome this restriction if further development of Java-based tools is warranted. Other alternatives such as ‘‘virtual film’’ have been considered in which images are stored on the server and distributed to remote users via a Web page from which the users can then download the images they want. JavaScope has been written as a client/server application (see Fig. 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 et al., 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
Architecture underlying the JavaScope user interface.
JAVASCOPE: A WEB-BASED TEM CONTROL INTERFACE
control the TEM. It is our intention that the emScope library be ported to other microscopes. To this end it will soon be ported to control a Philips Environmental scanning electron microscope and the same JavaScope applet should be able to control this new instrument. See Kisseberth et al. (1997) and (http:// www.itg.uiuc.edu/resources/emscope) for more information. 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 communicate over the Internet only 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 onto 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 Fig. 2. Two windows are presented to the user, one for control of the image acquisition and one for microscope control. The image acquisition variables take effect as soon as they are entered and the next image acquired will reflect the changes made. The microscope controls operate independent of the image acquisition, so there is some delay before the change in the image will be displayed. Depending on the frame rate images are received at, it takes a couple of seconds to see the result of a microscope control change. On a local network the delay is less than a second. Some improvements could be made in this area, but the Java/applet/browser environment places a lot of overhead on the system. The left-hand window displays the last image acquired and the image acquisition controls. 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
231
JavaScope. Otherwise the data are sent in their full and uncompressed form. When accessing the scope from outside the local area network, using the compression option can significantly speed 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. Whether in continuous or single-frame mode each new image is displayed after it has been completely received. Depending on the implementation of Java the user interface remains active during each image acquisition or there is a significant period of unresponsiveness during image transmission. 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 that make up a pixel, and size is the pixel dimensions of the image to be acquired (after taking binning into account, 128 ⫻ 128 binned by 8 covers the entire 1024 ⫻ 1024 element field of view of the CCD). The right-hand window displays a basic microscope control panel. Magnification. This 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. This allows the intensity of the electron beam to be modified. The units are currently uncalibrated so it takes some trial and error to affect a reasonable change. Focus. This 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 µm 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 autofocus procedures, image acquisition is unavailable as the
232
KISSEBERTH ET AL.
FIG. 2.
Java applets responsible for camera control (left) and microscope control (right).
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. DISCUSSION AND CONCLUSIONS
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
JAVASCOPE: A WEB-BASED TEM CONTROL INTERFACE
California (The 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 site (i.e., across campus). Currently communication between the remote user and the local operator is limited to conventional means such as telephone. This has proved sufficient for initial use, but clearly is not optimal. This initial investigation of the use of Java as a tool for remote control and image viewing has, however, illustrated a number of areas in which 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, JDK
AWT
Internet Explorer 3.x 1.0.x 1.0.x Internet Explorer 4.x 1.1.x 1.1.x Netscape Navigator 3.x 1.0.x 1.0.x Netscape Navigator 4.0-4.05 1.1.xa 1.0.x Netscape Navigator 4.06⫹ 1.1xa 1.1.xa aAWT 1.1, Printing, New Event Model available only for Windows 95/98/NT and UNIX versions. Furthermore during preparation of this paper it was discovered that the current version of JavaScope could not display compressed images when using Internet Explorer 4.x under Windows or MacOS and operated very poorly under all browsers under MacOS. We were able to work around the problem with Internet Explorer under Windows. The difficulties with the MacOS browsers elude us (previous versions of JavaScope worked reasonably well under MacOS). We hope to have a solution to the MacOS problems in the near future. This shows the relative instability of the Java platform for cross-platform development. 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 reinterpret a short while later. Java 2.0 (formerly called 1.2), only just recently announced, promises further improvements in cross-platform user inter-
233
face consistency and performance enhancements. There are also numerous extensions available (class libraries often compiled native to the JVM host computer) that 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. It is unclear how rapidly these new versions and extensions will be adopted by the Web browser vendors. At first glance it does not appear the adoption will be quick. 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 cannot handle 1024 ⫻ 1024 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 tool. This negative opinion would be modified if we could assume the availability of Netscape Navigator 4.06 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 of JavaScope will require more recent versions of Java, such as 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.
234
KISSEBERTH ET AL.
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 alternative Webbased 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 2 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. Will we continue to develop this application using Java? Probably. However, we may readdress exactly what Java’s role will be. Rather than using one Java applet, other alternatives include taking a step back and revisiting traditional Web techniques of CGI applications. It is possible that a combination of techniques such as CGI applications, JavaScript, and smaller Java applets may prove to be the most portable and powerful techniques currently available. These are the options being considered for our next project, which has similar requirements of universal accessibility (Netscape 3, MacOS, as well as latest browser offerings). Despite some of our initial problems it is clear that a Web-based approach still offers tremendous value to the project. It allows an easy delivery mechanism, is highly customizable, and promotes collaborative activity almost by definition.
Would we use Java exclusively 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 were 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. REFERENCES Arnold, K., and Gosling, J. (1996) The Java Programming Language. Addison-Wesley, Reading, MA. 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, J. Struct. Biol. 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 America 54th annual meeting, Minneapolis, MN, pp. 390–391. Ousterhout, J. K. (1994) Tcl and the Tk Toolkit. Addison-Wesley, Reading, MA. Potter, C. S., Carragher, B., Chu, H., Frey, B. J., Josephs, R., Lin, C., Kisseberth, N., Miller, K. L., and Nahrstedt, K. (1998a) Microsc. Microanal. 4(Supp. 2), 259. Potter, C. S., Carragher, B., Chu, H., Frey, B. J., Josephs, R., Lin, C., Kisseberth, N., Miller, K. L., and Nahrstedt, K., (1998b) Proceedings of the 14th International Congress on Electron Microscopy, Vol. 1, p. 8.