|
|
|
|
VISFILES |
Vol.34 No.1 February 2000
|
Harnessing the Web for Scientific Visualization![]() Bill Hibbard
|
I always learn something during Ken Brodlie’s presentations, so I have asked him to contribute this issue’s VisFiles column. His topic is the Web as a medium for visualization, which is certain to be increasingly important to all of us. - Bill Hibbard
Ken Brodlie
| ||||||
|
Figure 1: Air quality visualization service using IRIS Explorer on server - pollution over London (ozone at 8 hour average). Figure 2: The threads of Web-based visualization. |
Wood et al [15] took a different approach again. Rather than transfer visualization data or software across the Web, they proposed a system in which the visualization was executed on a remote server, and the resulting graphics returned over the Web for viewing in a browser. An air quality visualization service was developed in which a user enters details of data and visualization technique on a form; the form is processed by CGI script which invokes the IRIS Explorer visualization system on a server; and returns VRML to the browser - see Figure 1. In Figure 2 we try to reflect the distinction between these three approaches. They can be seen as separate threads, differing in what is sent over the Web to the browser - either visualization data, or software, or graphics - and differing too in the additional software required at the client side. We now examine how each thread has developed, and indeed how the threads have intertwined. Examples of the different approaches can be found at our website [14]. Transferring Visualization DataThis thread makes minimal use of the Web, relying on it simply as a data communication medium and exploiting the MIME-typing concept to divert data to a particular application. Users continue to use their own software, on their own platform. The idea has been explored by Hibbard in the Vis5D system [11]. Meteorological data can be tagged with MIME-type ‘application/vis5d’, and a browser configured to pass data of that MIME-type to Vis5D. The user then selects the options in Vis5D to create whatever visualization is required. This approach can be extended to any turnkey system with fixed functionality. It does not generalise so well, however, to the popular Modular Visualization Environments (or MVEs) such as IRIS Explorer and AVS. These are programmable systems, in which the user connects modules together in a dataflow pipeline (using either a visual editor or a scripting language). Here one wants to be able to send not only the data, but also the specification of the pipeline to process it. We have prototyped this idea using IRIS Explorer as MVE [4, 14]. The server hosts an instruction file specifying the data to be visualized, and the initial pipeline to be created. A typical instruction file will have commands to fetch a dataset, fetch an IRIS Explorer ‘map’ (i.e. a pipeline of modules) and launch IRIS Explorer. On receiving this file, the browser invokes an application that interprets the file and executes the commands. The command set can also include a series of instructions to control the subsequent interactive session, changing parameter values on modules and so on. This opens up some interesting opportunities: for example, it could be used in a consultancy context to deliver a visualization solution over the Web to a customer. They would download the instruction file and a presentation would be automatically executed. This is similar to the ‘pilot’ and ‘passenger’ model used in FAST expeditions [3]. Notice that this approach of sending data, and the pipeline to process it, is an intertwining of the data and software threads in Figure 2. The software framework and the modular components of the MVE are assumed resident on the client, but the programmable connections arrive over the Web. We see a similar intertwining in the next section. Transferring SoftwareThis thread is the Java applet approach whose origins we can trace to early examples such as the NPAC Visible Human Viewer [7]. These examples were designed for cases where the data was closely associated with the software, and indeed located on the same server. (So in these early cases, the ‘data’ and ‘software’ threads were really intertwined.) However for many applications this is inappropriate - the data usually is associated with the user rather than the software provider. One of the first instances of an applet to process user data was VizWiz [6] - an applet for isosurfacing. This circumvented a Java security requirement that insists an applet can only read files on the host from which it is downloaded. VizWiz uses the browser file upload facility to upload data from client to the server as a temporary arrangement, for the applet to then retrieve it back again. This data transfer can be an issue for large datasets. We have experimented with similar applet-based approaches, extending the concept to allow visualization of data from any location on the Web. This is achieved by having a ‘data server’ running on the applet host, which fetches the data from a specified URL [14]. There remains the problem of data transfer to and from the server. Today applets can be ‘signed,’ giving them authority to read the local filestore. This will avoid the data transfer overhead, and essentially separates the ‘software’ and ‘data’ threads to give a pure ‘software’ thread. Another important development is Java3D, which will allow visualization applets to include scene graph based rendering. Indeed this can be taken further with the emergence of VisAD [12], a visualization system developed as a set of Java classes - so applets can be built from the visualization system directly. There is an interesting way to combine the Java applet idea with the concept of MVEs. We have experimented with the idea of embedding Java classes within IRIS Explorer modules, allowing the Java code to be fetched from a central repository at run time [14]. This general area of using Java in a component-based approach is developing fast with growing use of Java beans. Transferring GraphicsThis thread originated with the server-based system of Wood et al [15]. Again it is a very general approach, and several similar systems have been proposed. For example, the authors of the VTK visualization toolkit [8] explain how to build a VTK server-based visualization service. The form-based interface of these systems is simple but inflexible. Trapp and Pagendarm [9] in their Vis-a-Web system replace the form interface with a more flexible Java applet interface. This intertwines the ‘software’ and ‘graphics’ threads - the user interface being downloaded as software, the visualization as graphics. A logical extension of this approach in the case of MVEs is to split their operation into two parts: a Java-based front-end that can execute on the client, generated automatically from the pipeline of an MVE application which runs on a server. Again we have experimented with this idea in the context of IRIS Explorer [14], as has Treinish [10] for IBM Data Explorer. What Next?There remain many ideas to explore - either as extensions of the threads, or an intertwining of threads. We look at these under the headings:
InteractionIn the server-based approach, where the visualization is generated remotely and only graphics returned, interaction is often limited. However combining the ‘graphics’ and ‘software’ threads, we can program interaction into the visualization. This approach has been tried in Web-based virtual reality applications in the medical area [5, 2] where simple surgical simulations combine VRML representations of anatomy and instruments, with interaction code in Java - linked through the Java EAI for VRML. The same approach could be used in data visualization to allow more complex interaction than afforded by VRML on its own. VRML itself is evolving. Its successor, X3D [13], uses XML and defines a core set of nodes - plus an ability to include new nodes. Thus it may be possible to include visualization controls alongside the geometry capabilities. A different approach for the ‘graphics’ thread is to do all the rendering on the server side and simply transfer images to the client. One could envisage a simple Java applet on the client being used to control the camera. This can take advantage of high quality rendering software provided on a server to give better image quality than a VRML viewer. This close coupling of visualization and rendering may also improve the ease of interacting with the underlying data - in the VRML model where visualization and rendering are distributed, one has to send data as well as graphics in order to support interrogation of data values. Here data, visualization and rendered image would be co-located. | ||||||
|
Figure 3: Collaboration using a tree to record previous air quality investigations. |
CollaborationCollaborative Web-based visualization allows groups of users to build on each other’s work. We have experimented with this for the server-based approach [16]. The IRIS Explorer air quality visualization system was given a measure of persistence, by allowing a user to have their parameter selection on the form stored in a database on the server. This selection can then be made visible to subsequent visitors to the site. In fact a sequence of ‘snapshots’ can be recorded, forming a tree of exploration. This is illustrated in Figure 3 where we see the tree built up over a period of collaborative study. MonitoringThere are a growing number of applications where the data being visualized is constantly changing - whether it is stock market prices or patient heartbeat (which may indeed be correlated!). This will also occur when we link visualization on line to a simulation, for example in computational fluid dynamics. One could envisage here a Java applet approach, in which the applet has a direct socket connection to a constantly updated data source. Final Thoughts - Intertwining and Disentangling the ThreadsThe Web has had a profound effect on almost all aspects of computing, and visualization is no exception. The three original threads of ‘data,’ ‘software’ and ‘graphics’ continue to develop, to intertwine and to disentangle. The combination of Java applets acting as front-ends to a visualization system on a server intertwines the ‘software’ and ‘graphics’ thread; if the applet also retrieves data for some simple analysis at the client side, then all three threads become intertwined. We are still learning different ways to harness the potential of Web-based visualization, and the examples mentioned here are only a selection of what has been tried to date. We are building a live repository of examples of Web-based visualization on our website - http://www.scs.leeds.ac.uk/ vis/webvis. Please let us know if you have an example we can add. AcknowledgmentsMany students have helped us over the years in our understanding of Web-based visualization. Special thanks are due to Abraham Kee, Peter Stanton, Edward Teong, Alan Yeo, Alex Coyle, Nuha El-Khalili and Ying Li, who have prototyped some of the ideas described here and whose work is summarised at our website. Much of the work has been carried out within the University of Leeds IRIS Explorer Centre of Excellence. References
Bill Hibbard's research interests are interaction techniques, data models and distributed architectures for numerical visualization. He leads the SSEC Visualization Project and is primary author of the Vis5D and VisAD systems. He has degrees in mathematics and computer science from the University of Wisconsin - Madison. | ||||||
|
Ken Brodlie,
Stuart Lovegrove and
Jason Wood
|
|
Reader Survey Archive Join the ACM and SIGGRAPH Join SIGGRAPH Calendar - Upcoming Events Contacts SIGGRAPH 99 SIGGRAPH 2000 The SIGGRAPH home page Professional Chapters |