The following paper was originally published in the
`Proceedings of the 4th USENIX Conference on Object-Oriented Technologies and Systems (COOTS)
`Santa Fe, New Mexico, April 27-30, 1998
`
`The Design and Performance of MedJava
`
`Prashant Jain, Seth Widoff, and Douglas C. Schmidt
`Washington University
`
`For more information about USENIX Association contact:
`1. Phone:
`510 528-8649
`2. FAX:
`510 548-5738
`3. Email:
`office@usenix.org
`4. WWW URL: http://www.usenix.org/
`
`Apple/Twitter
`Ex. 1017
`IPR3 of U.S. Pat. No. 7,765,482
`
`

`
`The Design and Performance of MedJava
`A Distributed Electronic Medical Imaging System
`
`Developed with Java Applets and Web Tools
`
`Prashant Jain, Seth Widoff, and Douglas C. Schmidt
`fpjain,sbw1,schmidtg@cs.wustl.edu
`Department of Computer Science
`Washington University
`St. Louis, MO 63130, (314) 935-4215
`
`This paper appeared in the th USENIX Conference on
`Object-Oriented Technologies and Systems (COOTS), Sante
`Fe, New Mexico, April 1998.
`
`performance-sensitive distributed applications where C and
`C++ are currently used.
`
`Abstract
`
`1
`
`Introduction
`
`The Java programming language has gained substantial popu-
`larity in the past two years. Java’s networking features, along
`with the growing number of Web browsers that execute Java
`applets, facilitate Internet programming. Despite the popu-
`larity of Java, however, there are many concerns about its ef-
`ficiency.
`In particular, networking and computation perfor-
`mance are key concerns when considering the use of Java to
`develop performance-sensitive distributed applications.
`This paper makes three contributions to the study of Java for
`performance-sensitive distributed applications. First, we de-
`scribe an architecture using Java and the Web to develop Med-
`Java, which is a distributed electronic medical imaging sys-
`tem with stringent networking and computation requirements.
`Second, we present benchmarks of MedJava image processing
`and compare the results to the performance of xv, which is an
`equivalent image processing application written in C. Finally,
`we present performance benchmarks using Java as a transport
`interface to exchange large medical images over high-speed
`ATM networks.
`For computationally intensive algorithms, such as image
`filters, hand-optimized Java code, coupled with use of a JIT
`compiler, can sometimes compensate for the lack of compile-
`time optimization and yield performance commensurate with
`identical compiled C code. With rigorous compile-time opti-
`mizations employed, C compilers still tend to generate more
`efficient code. However, with the advent of highly optimiz-
`ing Java compilers, it should be feasible to use Java for the
`
` This research is supported in part by a grant from Siemens Medical En-
`gineering, Erlangen, Germany.
`
`Medical imaging plays a key role in the development of a reg-
`ulatory review process for radiologists and physicians [1]. The
`demand for electronic medical imaging systems (EMISs) that
`allow visualization and processing of medical images has in-
`creased significantly [2]. The advent of modalities, such as
`angiography, CT, MRI, nuclear medicine, and ultrasound, that
`acquire data digitally and the ability to digitize medical images
`from film has heightened the demand for EMISs.
`The growing demand for EMISs has been coupled with a
`need to access medical images and other diagnostic informa-
`tion remotely across networks [3]. Connecting radiologists
`electronically with patients increases the availability of health
`care. In addition, it can facilitate the delivery of remote diag-
`nostics and remote surgery [4].
`As a result of these forces, there is also increasing de-
`mand for distributed EMISs. These systems supply health care
`providers with the capability to access medical images and re-
`lated clinical studies across a network in order to analyze and
`diagnose patient records and exams. The need for distributed
`EMISs is also driven by economic factors. As independent
`health hospitals consolidate into integrated health care deliv-
`ery systems [2], they will require distributed computer systems
`to unify their multiple and distinct image repositories.
`Figure 1 shows the network topology of a distributed EMIS.
`In this environment, medical images are captured by modali-
`ties and transferred to appropriate Image Stores. Radiologists
`and physicians can then download these images to diagnos-
`tic workstations for viewing, image processing, and diagnosis.
`High-speed networks, such as ATM or Fast Ethernet, allow the
`
`1
`
`

`
`DDXX
`IIMMAAGGEE
`SSTTOORREE
`
`AATTMM
`LLAANN
`
`AATTMM
`MMAANN
`
`DDIIAAGGNNOOSSTTIICC
`SSTTAATTIIOONNSS
`
`AATTMM
`LLAANN
`
`CCLLUUSSTTEERR
`IIMMAAGGEE
`SSTTOORREE
`
`MMOODDAALLIITTIIEESS
`((CCTT,, MMRR,, CCRR))
`
` CCEENNTTRRAALL
`IIMMAAGGEE
`SSTTOORREE
`
`Figure 1: Topology of a Distributed EMIS
`
`transfer of images efficiently, reliably, and economically.
`Image processing is a set of computational techniques for
`enhancing and analyzing images.
`Image processing tech-
`niques apply algorithms, called image filters, to manipulate
`images. For example, radiologists may need to sharpen an
`image to properly diagnose a tumor. Similarly, to identify a
`kidney stone, a radiologists may need to zoom into an image
`while maintaining high resolution. Thus, an EMIS must pro-
`vide powerful image processing capabilities, as well as effi-
`cient distributed image retrieval and storage mechanisms.
`This paper describes the design and performance of Med-
`Java, a distributed EMIS developed using the Java environ-
`ment and the Web. The paper examines the feasibility of us-
`ing Java to develop large-scale distributed medical imaging ap-
`plications with demanding performance requirements for net-
`working speed and image processing speed.
`To evaluate Java’s image processing performance, we con-
`ducted extensive benchmarking of MedJava and compared the
`results to the performance of xv, an equivalent image process-
`ing application written in C. To evaluate the performance of
`Java as a transport interface for exchanging large images over
`high-speed networks, we performed a series of network bench-
`marking tests over at 155 Mbps ATM switch and compared the
`results to the performance of C/C++ as a transport interface.
`Our empirical measurements reveal that an imaging system
`implemented in C/C++ always out-performs an imaging sys-
`tem implemented using interpreted Java by 30 to 100 times.
`
`2
`
`However, the performance of Java code using a “just-in-time”
`(JIT) compiler is 1.5 to 5 times slower than the performance
`of compiled C/C++ code. Likewise, using Java as the transport
`interface performs 2% to 50% slower than using C/C++ as the
`transport interface. However, for sender buffer size close to
`the network MTU size, the performance of using Java as the
`transport interface was only 9% slower than the performance
`of using C/C++ as the transport interface. Therefore, we con-
`clude that it is becoming feasible to use Java to develop large-
`scale distributed EMISs. Java is particularly relevant for wide-
`area environments, such as teleradiology, where conventional
`EMIS capabilities are too costly or unwieldy with existing de-
`velopment tools.
`The remainder of this paper is organized as follows: Sec-
`tion 2 describes the object-oriented (OO) design and features
`of MedJava; Section 3 compares the performance of MedJava
`with an an equivalent image processing application written in
`C and compares the performance of a Java transport interface
`with the performance of a C/C++ transport interface; Section 4
`describes related work; and Section 5 presents concluding re-
`marks.
`
`2 Design of the MedJava Framework
`
`2.1 Problem: Resolving Distributed EMIS De-
`velopment Forces
`
`A distributed electronic medical imaging system (EMIS) must
`meet the following requirements:
` Usable: An EMIS must be usable to make it as convenient
`to practice radiology as conventional film-based technology.
` Efficient: An EMIS must be efficient to process and de-
`liver medical images rapidly to radiologists.
` Scalable: An EMIS must be scalable to support the grow-
`ing demands of large-scale integrated health care delivery sys-
`tems [2].
` Flexible: An EMIS must be flexible to transfer different
`types of images and to dynamically reconfigure image pro-
`cessing features to cope with changing requirements.
` Reliable: An EMIS must be reliable to ensure that medi-
`cal images are delivered correctly and are available when re-
`quested by users.
` Secure: An EMIS must be secure to ensure that confiden-
`tial patient information is not compromised.
` Cost-effective: An EMIS must be cost-effective to mini-
`mize the overhead of accessing patient data across networks.
`
`Developing a distributed EMIS that meets all of these re-
`quirements is challenging, particularly since certain features
`
`

`
`conflict with other features. For example, it is hard to develop
`an EMIS that is efficient, scalable, and cost-effective. This is
`because efficiency often requires high-performance computers
`and high-speed networks, thereby raising costs as the number
`of system users increases.
`
`2.2 Solution: Java and the Web
`
`Over the past two years, the Java programming language has
`sparked considerable interest among software developers. Its
`popularity stems from its flexibility, portability, and relative
`simplicity compared with other object-oriented programming
`languages [5].
`The strong interest in the Java language has coincided with
`the ubiquity of inexpensive Web browsers. This has brought
`the Web technology to the desktop of many computer users,
`including radiologists and physicians.
`A feature supported by Java that is particularly relevant to
`distributed EMISs is the applet. An applet is a Java class that
`can be downloaded from a Web server and run in a context
`application such as a Web browser or an applet viewer. The
`ability to download Java classes across a network can simplify
`the development and configuration of efficient and reliable dis-
`tributed applications [6].
`Once downloaded from a Web server, applets run as appli-
`cations within the local machine’s Java run-time environment,
`which is typically a Web browser. In theory, therefore, applets
`can be very efficient since they harness the power of the local
`machine on which they run, rather than requiring high latency
`RPC calls to remote servers [7].
`The MedJava distributed EMIS was developed as a Java ap-
`plet. Therefore, it exploits the functionality of front-ends of-
`fered by Web browsers. An increasing number of browsers
`(such as Internet Explorer and Netscape Navigator and Com-
`municator) are Java-enabled and provide a run-time environ-
`ment for Java applets. A Java-enabled browser provides a Java
`Virtual Machine (JVM), which is used to execute Java applets.
`MedJava leverages the convenience of Java to manipulate im-
`ages and provides image processing capabilities to radiologists
`and physicians connected via the Web.
`In our experience, developing a distributed EMIS in Java is
`relatively cost effective since Java is fairly simple to learn and
`use. In addition, Java provides standard packages that support
`GUI development, networking, and image processing. For
`example, the package java.awt.image contains reusable
`classes for managing and manipulating image data, including
`color models, cropping, color filtering, setting pixel values,
`and grabbing bitmaps [8].
`Since Java is written to a virtual machine, an EMIS devel-
`oper need only compile the Java source code to Java bytecode.
`The EMIS applet will execute on any platform that has a Java
`
`Virtual Machine implementation. Many Java bytecode com-
`pilers and interpreters are available on a variety of platforms.
`In principle, therefore, switching to new platforms or upgraded
`hardware on the same platform should not require changes to
`the software or even recompilation of the Java source. Conse-
`quently, an EMIS can be constructed on a network of hetero-
`geneous machines and platforms with a single set of Java class
`files.
`
`2.3 Caveat: Meeting EMIS Performance Re-
`quirements
`
`Despite the software engineering benefits of developing a dis-
`tributed EMIS in Java, there are serious concerns with its per-
`formance relative to languages like C and C++. Performance
`is a key requirement in a distributed EMIS since timely diag-
`nosis of patient exams by radiologists can be life-critical. For
`instance, in an emergency room (ER), patient exams and med-
`ical images must be delivered rapidly to radiologists and ER
`physicians. In addition, an EMIS must allow radiologists to
`process and analyze medical images efficiently to make ap-
`propriate diagnoses.
`Meeting the performance demands of a large-scale dis-
`tributed EMIS requires the following support from the JVM.
`First, its image processing must be precise and efficient. Sec-
`ond, its networking mechanisms must download and upload
`large medical images rapidly. Assuming that efficient image
`processing algorithms are used, the performance of a Java ap-
`plet depends largely on the efficiency of the hardware and the
`JVM implementation on which the applet is run.
`The need for efficiency motivates the development of high-
`speed JIT compilers that translate Java bytecode into native
`code for the local machine the browser runs on. JIT compil-
`ers are “just-in-time” since they compile Java bytecode into
`native code on a per-method basis immediately before calling
`the methods. Several browsers, such as Netscape and Internet
`Explorer, provide JIT compilers as part of their JVM.
`Although Java JIT compilers avoid the penalty of interpreta-
`tion, previous studies [9] show that the cost of compilation can
`significantly interrupt the flow of execution. This performance
`degradation can cause Java code to run significantly slower
`than compiled C/C++ code. Section 3 quantifies the overhead
`of Java and C/C++ empirically.
`
`2.4 Key Features of MedJava
`
`MedJava has been developed as a Java applet. Therefore, it
`can run on any Java-enabled browser that supports the standard
`AWT windowing toolkit. MedJava allows users to download
`medical images across the network. Once an image has been
`downloaded, it can be processed by applying one or more im-
`age filters, which are based on algorithms in the C source code
`
`3
`
`

`
`from xv. For example, a medical image can be sharpened by
`applying the Sharpen Filter. Sharpening a medical image en-
`hances the details of the image, which is useful for radiologists
`who diagnose internal ailments.
`Although MedJava is targeted for distributed EMIS require-
`ments, it is a general-purpose imaging tool that can process
`both medical and non-medical images. Therefore, in addition
`to providing medical filters like sharpening or unsharp mask-
`ing, MedJava provides other non-medical image processing
`filters such as an Emboss filter, Oil Paint filter, and Edge De-
`tect filter. These filters are useful for processing non-medical
`images. For example, edge detection serves as an important
`initial step in many computer vision processes because edges
`contain the bulk of the information within an image [10]. Once
`the edges of an image are detected, additional operations such
`as pseudo-coloring can be applied to the image.
`Image filters can be dynamically configured and re-
`configured into MedJava via the Service Configurator pattern
`[6]. This makes it convenient to enhance filter implementation
`or install new filters without restarting the MedJava applet. For
`example, a radiologist may find a sharpen filter that uses the
`unsharp mask algorithm to be more efficient than a sharpen
`filter that simply applies a convolution matrix to all the pixels.
`Doing this substitution in MedJava is straightforward and can
`be done without reloading the entire applet.
`Once an image has been processed by applying the filter(s),
`it can be uploaded to the server where the applet was down-
`loaded. HTTP server implementations, such as JAWS [11, 12]
`and Jigsaw, support file uploading and can be used by MedJava
`to upload images. In addition, the MedJava applet provides a
`hierarchical browser that allows users to traverse directories
`of images on remote servers. This makes it straightforward to
`find and select images across the network, making MedJava
`quite usable, as well as easy to learn.
`To facilitate performance measurements, the MedJava ap-
`plet can be configured to run in benchmark mode. When
`the applet runs in benchmark mode, it computes the time (in
`milliseconds) required to apply filters on downloaded images.
`The timer starts at the beginning of each image processing al-
`gorithm and stops immediately after the algorithm terminates.
`
`2.5 The OO Design of MedJava
`
`Figure 2 shows the architecture of the MedJava framework de-
`veloped at Washington University to meet distributed EMIS
`requirements. The two primary components in the architecture
`include the MedJava client applet and JAWS, which is a high-
`performance HTTP server also developed at Washington Uni-
`versity [12, 11]. The MedJava applet was implemented with
`components from Java ACE [13], the Blob Streaming frame-
`work [14], and standard Java packages such as java.awt
`
`MMeeddJJaavvaa
`
`GGUUII
`
`JJAAWWSS
`
`UURRLL
`LLooccaattoorr
`
`IImmaaggee
`PPrroocceessssoorr
`
`FFiilltteerr
`RReeppoossiittoorryy
`
`IImmaaggee
`RReessppoossiittoorryy
`
`IImmaaggee
`DDoowwnnLLooaaddeerr
`
`IImmaaggee
`UUppLLooaaddeerr
`
`FFiilltteerr
`CCoonnffiigguurraattoorr
`
`BBlloobb
`SSttrreeaammiinngg
`
`JJaavvaa AACCEE
`
`BBlloobb
`SSttrreeaammiinngg
`
`CCoommmmuunniiccaattiioonn PPrroottooccoollss
`ee..gg..,, HHTTTTPP,, DDIICCOOMM,, HHLL77
`
`Figure 2: MedJava Framework
`
`and java.awt.image. Each of these components is out-
`lined below.
`
`2.5.1 MedJava Applet
`
`The MedJava client applet contains the following components
`shown in Figure 2:
`
`Graphical User Interface: which provides a front-end to
`the image processing tool. Figure 3 illustrates the graphical
`user interface (GUI) used to display a podiatry image. The
`
`Figure 3: Processing a Medical Image in MedJava
`
`MedJava GUI allows users to download images, apply image
`processing filters on them, and upload the images to a server.
`
`4
`
`

`
`URL Locator: which locates a URL that can reference an
`image or a directory. If the URL points to a directory, the con-
`tents of the directory are retrieved so users can browse them
`to obtain a list of images and subdirectories in that directory.
`The URL Locator is used by the Image Downloader and Image
`Uploader to download and upload images, respectively.
`
`Image Downloader: which downloads an image located by
`the URL Locator and displays the image in the applet. The
`Image Downloader ensures that all pixels of the image are re-
`trieved and displayed properly.
`
`GUI
`
`MedJava
`Applet
`
`1: GET
`~pjain/xray.gif
`HTTP/1.0
`
`Browser
`
`HTML
`Parser
`
`Requester
`
`2: xray.gif
`
`JAWS
`Server
`
`Protocol
`Handlers
`
`Dispatcher
`
`Image Processor: which processes the currently displayed
`image using the image filter selected by the user. Processing
`an image manipulates the pixel values of the image to create
`and display a new image.
`
`Image Uploader: which uploads the currently displayed im-
`age to the server from where the applet was downloaded
`from.1 The Image Uploader generates a GIF-format for the
`currently displayed image and writes the data to the server.
`This allows the user to save processed images persistently at
`the server.
`
`Filter Configurator: which downloads image filters from
`the Server and configures them in the applet. The Filter Con-
`figurator uses the Service Configurator pattern [6] to dynami-
`cally configure the image filters.
`
`2.5.2 JAWS
`
`JAWS is a high-performance, multi-threaded, HTTP Web
`Server [11]. For the purposes of MedJava, JAWS stores the
`MedJava client applet, the image filter repository, and the im-
`ages. The MedJava client applet uses the image filter repos-
`itory to download specific image filters. Each image filter is
`a Java class that can be downloaded by MedJava. This design
`allows MedJava applets to be dynamically configured with im-
`age filters, thereby making image filter configuration highly
`flexible.
`In addition, JAWS supports file uploading by implementing
`the HTTP PUT method. This allows the MedJava client ap-
`plet to save processed images persistently at the server. JAWS
`implements other HTTP features (such as CGI bin and per-
`sistent connections) that are useful for developing Web-based
`systems.
`Figure 4 illustrates the interaction of MedJava and JAWS.
`The MedJava client applet is downloaded into a Web browser
`from the JAWS server. Through GUI interactions, a radiolo-
`gist instructs the MedJava client applet to retrieve images from
`JAWS (or other servers across the network). The requester is
`
`Graphics
`Adapter
`
`Communication Protocol
`(e.g, HTTP)
`
`OS Kernel
`OS I/O Subsystem
`
`Network Adapters
`
`OS Kernel
`OS I/O Subsystem
`
`Network Adapters
`
`Network
`
`Figure 4: Architecture of MedJava and JAWS
`
`the active component of the browser running the MedJava ap-
`plet that communicates over the network. It issues a request for
`the image to JAWS with the appropriate syntax of the transfer
`protocol (which is HTTP in this case). Incoming requests to
`the JAWS are received by the dispatcher, which is the request
`demultiplexing engine of the server. It is responsible for cre-
`ating new threads. Each request is processed by a handler,
`which goes through a lifecycle of parsing the request, logging
`the request, fetching image status information, updating the
`cache, sending the image, and cleaning up after the request
`is done. When the response returns to the client with the re-
`quested image, it is parsed by an HTML parser so that the
`image may be rendered. At this stage, the requester may is-
`sue other requests on behalf of the client, e.g., to maintain a
`client-side cache.
`
`2.5.3 Blob Streaming
`
`Figure 5 illustrates the Blob Streaming framework. The frame-
`work provides a uniform interface that allows EMIS appli-
`cation developers to transfer data across a network flexibly
`and efficiently. Blob Streaming uses the HTTP protocol for
`the data transfer.2 Therefore, it can be used to communicate
`with high-performance Web servers (such as JAWS) to down-
`load images across the network. In addition, it can be used to
`
`1Due to applet security restrictions, images can only be uploaded to the
`server where the applet was downloaded from. In addition, the Web server
`must support file uploading by implementing the HTTP PUT method.
`
`2Although the current Blob Streaming protocol is HTTP, other medical-
`specific communication protocols (such as DICOM and HL7) can also be
`supported.
`
`5
`
`

`
`Receiver
`
`2: pull(image_name)
`
`JAWS
`Server
`
`3: image
`
`ATM
`SWITCH
`
`IMAGE
`STORE
`
`1: push(image)
`
`Sender
`
`Figure 5: Blob Streaming Framework
`
`communicate with Web servers that implement the HTTP PUT
`method to upload images from the browser to the server.
`Although Blob Streaming supports both image download-
`ing and image uploading across the network, its use within a
`Java applet is restricted due to applet security mechanisms. To
`prevent security breaches, Java imposes certain restrictions on
`applets. For example, a Java applet can not write to the local
`file system of the local machine it is running on. Similarly, a
`Java applet can generally download files only from the server
`where the applet was downloaded. Likewise, a Java applet
`can only upload files to the server where the applet was down-
`loaded.
`Java applets provide an exception to these security restric-
`tions, however. In particular, the Java Applet class provides
`a method that allows an applet to download images from any
`server reachable via a URL. Since the method is defined in the
`Java Applet class, it allows Java to ensure there are no secu-
`rity violations. MedJava uses this Applet method to down-
`load images across the network. Therefore, images to be pro-
`cessed can reside in a file system managed by the HTTP Server
`from where the MedJava client applet was downloaded or can
`reside on some other server in the network. However, Blob
`Streaming can only be used to upload images to the server
`where the MedJava applet was downloaded.
`
`2.5.4 Java ACE
`
`Java ACE [5] is a port of the C++ version of the ADAPTIVE
`Communication Environment (ACE) [15]. ACE is an OO net-
`
`6
`
`work programming toolkit that provides reusable components
`for building distributed applications. Containing 125,000
`lines of code, the C++ version of ACE provides a rich set of
`reusable C++ wrappers and framework components that per-
`form common communication software tasks portably across
`a range of OS platforms.
`The Java version of ACE Contains 10,000 lines of code,
`which is over 90% smaller than the C++ version. The reduc-
`tion in size occurs largely because the JVM provides most of
`the OS-level wrappers necessary in C++ ACE. Despite the re-
`duced size, Java ACE provides most of the functionality of
`the C++ version of ACE, such as event handler dispatching,
`dynamic (re)configuration of distributed services, and support
`for concurrent execution and synchronization. Java ACE im-
`plements several key design patterns for concurrent network
`programming, such as Acceptor and Connector [16] and Ac-
`tive Object [17]. This makes it easier to developing network-
`ing applications using Java ACE easier compared to program-
`ming directly with the lower-level Java APIs.
`Figure 6 illustrates the architecture and key components in
`Java ACE. MedJava uses several components in Java ACE. For
`
`DISTRIBUTED
`SERVICES AND
`COMPONENTS
`
`FRAMEWORKS
`AND CLASS
`CATEGORIES
`
`TOKEN
`SERVER
`
`LOGGING
`SERVER
`
`NAME
`SERVER
`
`TIME
`SERVER
`
`ACCEPTOR
`
`CONNECTOR
`
`SERVICE
`HANDLER
`
`ADAPTIVE SERVICE EXECUTIVE (ASX)
`
`JAVA
`WRAPPERS
`
`SYNCH
`WRAPPERS
`
`SOCK_SAP
`
`THREAD
`MANAGER
`
`LOG
`MSG
`
`TIMER
`QUEUE
`
`SERVICE
`CONFIGURATOR
`
`JAVA VIRTUAL MACHINE (JVM)
`
`Figure 6: The Java ACE Framework
`
`example, Java ACE provides an implementation of the Service
`Configurator pattern [6]. MedJava uses this pattern to dynam-
`ically configure and reconfigure image filters. Likewise, Med-
`Java uses Java ACE profile timers to compute performance in
`benchmark mode.
`
`3 Performance Benchmarks
`
`This section presents the results of performance benchmarks
`conducted with the MedJava image processing system. We
`performed the following two sets of benchmarks:
`
`1. Image processing performance: We measured the per-
`formance of MedJava to determine the overhead of using Java
`for image processing. We compared the performance of our
`MedJava applet with the performance of xv. Xv is a widely-
`used image processing application written in C. The MedJava
`
`

`
`image process applets are based on the xv algorithms.
`
`2. High-speed networking performance: We measured the
`performance of using Java sockets over a high-speed ATM net-
`work to determine the overhead of using Java for transporting
`data. We compared the network performance results of Java to
`the results of similar tests using C/C++.
`
`Below, we describe our benchmarking testbed environment,
`the benchmarks we performed, and the results we obtained.
`
`3.1 MedJava Image Processing Benchmarks
`
`We benchmarked MedJava to compare the performance of
`Java with xv, which is a widely-used image processing appli-
`cation written in C. Xv contains a broad range of image filters
`such as Blur, Sharpen, and Emboss. By applying a filter to an
`image in xv, and then applying an equivalent filter algorithm
`written in Java to the same image, we compared the perfor-
`mance of Java and C directly. In addition, we benchmarked
`the performance of different Web browsers running the Med-
`Java applet.
`
`3.1.1 Benchmarking Testbed Environment
`
`Hardware Configuration: To study the performance of
`MedJava, we constructed a hardware and software testbed
`consisting of a Web server and two clients connected by Ether-
`net, as shown in Figure 7. The clients in our experiment were
`
`Filter
`Server
`
`Internet
`Explorer
`
`Micron Millenia PRO2
`
`WWW
`Server
`
`Network
`
`XV
`
`Image
`Server
`
`Netscape
`
`Micron Millenia PRO2
`
`Micron Millenia PRO2
`
`Micron Millenia PRO2
`Figure 7: Web Browser Testbed Environment
`
`Micron Millenia PRO2 plus workstations. Each PRO2 has 128
`MB of RAM and is equipped with dual 180 Mhz PentiumPro
`processors.
`
`7
`
`JVM Software Configuration: We ran MedJava in two
`different Web browsers to determine how efficiently these
`browsers execute Java code. The browsers chosen for our
`tests were Internet Explorer 4.0 release 2 on Windows NT and
`Netscape 4.0 on NT. Internet Explorer 4.0 on NT and Netscape
`4.0 on NT include Java JIT compilers, written by Microsoft
`and Symantec, respectively.
`As shown in Section 3.1.4, JIT compilers have a substan-
`tial impact on performance. To compare the performance of
`the xv algorithms with their Java counterparts, we extracted
`the GIF loading and processing elements from the freely dis-
`tributed xv source, removed all remnants of the X-Windows
`GUI, instrumented the algorithms with timer mechanisms in
`locations equivalent to the Java algorithms. We compiled this
`subset of xv using Microsoft Visual C++ version 5.0, with full
`optimization enabled.
`Image filters can potentially require On time to execute.
`For large images, this processing can dominate the loading and
`display times. Therefore, the running time of the algorithms is
`an appropriate measure of the overall performance of an image
`processing application.
`
`Image processing configuration: The
`standard Java
`image processing framework uses a “Pipes and Fil-
`ters” pattern architecture [18].
`Downstream sits an
`java.image.ImageConsumer that
`has
`registered
`with
`an
`upstream java.image.ImageProducer
`for pixel delivery.
`The ImageProducer invokes the
`setPixels method on the ImageConsumer, delivering
`portions of the image array until it completes by invoking the
`ImageComplete method.
`The Pipes and Filters pattern architecture allows the
`ImageConsumer subclass to process the image as it receives
`the pieces or when the image source arrives in its entirety. An
`ImageFilter is a subclass of ImageConsumer situated
`between the producer and consumer who intercepts the flow of
`pixels, altering them in some way before it passes the image to
`the subsequent ImageConsumer. All ImageFilters in
`this experiment override the ImageComplete method and
`iterate over each pixel. The computational complexity for each
`filter depends on how much work the filter does during each
`iteration.
`We selected the following seven filters, which exhibit dif-
`ferent computational complexities. These filters are available
`in both xv and MedJava, and are ranked according to their
`usefulness in the domain of medical image processing.
`
`1. Sharpen Filter: which computes for each pixel the
`mean of the “values” of the 33 matrix surrounding the pixel.
`In the Hue-Saturation-Value color model, the “value” is the
`maximum of the normalized red, green, and blue values of
`the pixel; conceptually, the brightness of that pixel. The new
`
`

`
`value for the pixel is: value(cid:0)p mean value
`, where p is a value
` (cid:0)p
`between 0 and 1. The filter exaggerates the contrast between a
`pixel’s brightness and the average brightness of the surround-
`ing pixels.
`2. Despeckle Filter: which replaces each pixel with the
`median color in a 33 matrix surrounding the pixel. Used for
`noise reduction, the algorithm gathers the colors in the square
`matrix, sorts them using an inlined Shell sort, and chooses the
`median element.
`3. Edge Detect Filter: which runs a merging of a pair of
`convolutions, one that detects horizontal edges, and one that
`detects vertical edges. The convolution is done separately for
`each plane (red, green, blue) of the image, so where there are
`edges in the red plane, for example, the resultant image will
`highlight the red edges.
`4. Emboss filter: which applies a 33 convolution matrix
`to the image, a variation of an edge detection algorithm. Most
`of the image is left as a medium gray, but leading and trailing
`edges are turned lighter and darker gray, respectively.
`5. Oil Paint Filter: which computes a histogram of a 33
`matrix surrounding the pixel and chooses the most frequently
`occuring color in the histogram to supplant the old pixel value.
`The result is a localized smearing effect.
`6. Pixelize Filter: which replaces each pixel in each 44
`squares in the image with the average color in the square ma-
`trix.
`7. Spread Filter: which replaces each pixel by a random
`one within a 33 matrix surrounding the pixel.
`
`Figure 8 illustrates the original image and processed images
`that result from applying four of the filters described above.
`Although some of these filters are not necessarily useful in
`the medical domain, they follow the same pattern of spatial
`image processing: the traversal or convolution of a fixed size
`or variable size matrix over pixels surrounding each pixel in
`the image array. In principle, therefore, the performance of
`this set of filters reflect the performance of other more relevant
`filters of comparable complexity.
`
`3.1.2 Performance Metrics
`
`We measured the performance of MedJava in comparison with
`the NT port of