A Rapid-Prototyping Environment for Ray-Casting-Based Volume Visualizations
Total Page:16
File Type:pdf, Size:1020Kb
Editor: Mike Potel Applications www.wildcrest.com Voreen: A Rapid-Prototyping Environment for Ray-Casting-Based Volume Visualizations Jennis he amount of volume data requiring analysis cessor to another via ports—inports for input and Meyer- is rising signifi cantly in many domains. For outports for output. The type of port determines Spradow, example, in medicine, computed tomogra- which inport/outport pairs are compatible and Timo Tphy and magnetic resonance imaging have changed can thus be connected. Subtypes give further hints Ropinski, from seldom-applied special technologies to stan- about the transferred data content. Although spe- Jörg dard diagnostic tools. Visualization of the acquired cifi c types of connected ports must match, this Mensmann, volume data is challenging. Scanners used in medi- doesn’t apply to the subtypes. and Klaus cal research can create more than 1,000 slices per Voreen’s design is object-oriented (OO), but this Hinrichs scan pass, which aren’t manageable with standard doesn’t apply to the architecture of OpenGL—the University of visualization techniques. Routine medical diagnos- underlying graphics system. In a purely OO environ- Münster tics also need new visualization techniques for fast, ment, objects would manage themselves by trans- reliable analysis of the huge amounts of data. Im- ferring control and data directly. However, because portant information must be depicted concisely. To OpenGL isn’t OO, developers must carefully trade determine what information is important depends off between achieving high graphics performance on what the medical question is and which scan- and following OO design principles. For effi ciency, ning technologies are used—effective visualizations OpenGL’s state is determined by global variables, and are usually specialized. data are accessible from anywhere in an OpenGL To support interactive development of such spe- program. Encapsulating such data into objects would cialized visualizations, our Voreen volume-rendering signifi cantly decrease performance. So, Voreen uses engine provides an rapid-prototyping environment a central instance for managing graphics data and for realizing GPU-based volume ray-casting tech- exchanges these data via references. The central con- niques.1 Voreen is an open source C++ framework troller also schedules processor execution. consisting of processors—autonomous functional building blocks that each perform a specifi c task. Coprocessors Supporting Processors Voreen’s users can fl exibly combine these processors In some situations, data transfer via ports isn’t into data-fl ow networks. The component-based ar- suitable. For example, if one consumer processor chitecture ensures that users can exploit the real- would like to use data that a producer processor ized techniques in interactive applications without provides, the data must be transferred from pro- any performance penalty. Voreen provides processors ducer to consumer. This transfer requires a generic for different volume-rendering and image-processing data representation. However, such a representa- techniques. Users can extend it easily by integrating tion isn’t always feasible, or creating it might be more processors—for example, to support a new vol- time-consuming. For specifi c restricted data usage, ume-processing algorithm. Voreen supports several it’s often suffi cient if the consumer can access the fi le formats for volume data—for example, ICOMD , data indirectly by calling a method of the pro- TIFF, or RAW. Users can easily modify processor ducer. So, we extend the data-fl ow principle: not properties through automatically generated GUI only can data be transferred between processors components and can use the designed visualiza- via ports, processors also can access data by call- tions through either a generic application provided ing the methods of special processors called copro- by Voreen or customized applications. For more on cessors. A coprocessor class can be used to share rapid-prototyping environments, see the sidebar. functionality between different processor classes. Managing Data and Execution Processor Classes On a logical level, data fl ows from one Voreen pro- Here, we describe some important processor classes. 6 November/December 2009 Published by the IEEE Computer Society 0272-1716/09/$26.00 © 2009 IEEE Related Work in Rapid-Prototyping Environments cientists frequently perform volume data analysis and greater flexibility. The first GPU-based solutions for ray Svisualization, and many libraries, applications, and rapid- casting were quite slow. But with the huge improvement prototyping environments (RPEs) have been developed for in GPU technology, ray casting can be extended with sev- this task. Libraries offer much flexibility but require much eral enhancements and still reach interactive frame rates. experience and effort to be beneficial. Applications are MeVisLab contains a GPU-based ray-casting module that mostly easy to handle but aren’t extensible and are thus supports renderer reconfiguration on a per-object basis. limited to the built-in tasks the developer has anticipated. The widely used VTK (Visualization Toolkit; www.vtk. RPEs combine the best of both approaches. They usually org) library supports GPU-accelerated volume render- provide a set of modules, which users can combine to ing with slicing only. The same is true for other librar- achieve their goals. ies such as MITK (Medical Imaging Interaction Toolkit; Many RPEs are available either commercially or for www.mitk.org) or Mercury’s commercial Open Inventor free—for example, Amira (www.amira.com), MeVisLab implementation (www.vsg3d.com). Jesus J. Caban and his (www.mevislab.de), VisTrails (www.vistrails.org), and XIP colleagues have compared several open source libraries (Extensible Imaging Platform; https://collab01a.scr.sie- and applications.2 mens.com/xipwiki). Ingmar Bitter and his colleagues have compared some of these packages.1 Unlike Voreen (see the main article), these RPEs focus on the entire data analysis References process; visualization is only the final step and sometimes 1. I. Bitter et al., “Comparison of Four Freely Available Frame- a minor aspect. For visualization, they use mostly GPU- works for Image Processing and Visualization That Use ITK,” based slicing approaches. However, slicing has inherent IEEE Trans. Visualization and Computer Graphics, vol. 13, no. disadvantages resulting mainly from the inflexibility of the 3, 2007, pp. 483–493. volume’s slice-by-slice traversal. 2 J.J. Caban, A. Joshi, and P. Nagy, “Rapid Development of Ray casting solves these issues because it traverses Medical Imaging Tools with Open-Source Libraries,” J. Digital the volume data set separately for each ray. So, it offers Imaging, vol. 20, no. 1, 2007, pp. 83–93. Because Voreen is extensible, users can easily add new processors. A VolumeSetSource processor lets other pro- cessors access a data set. VolumeSelector selects a specific volume in the data set and specifies as a parameter the desired modality or index (in the case of a series of volumes). An EntryExitPoints processor creates im- ages containing color-coded entry and exit points using a proxy geometry. The color of each proxy geometry vertex encodes the corresponding vertex position. So, the GPU automatically calculates the color-coded entry and exit points when rendering the proxy geometry.1 For cube-shaped volumes, the proxy geometry is an RGB color cube. Because the demands on a proxy geometry can differ, it isn’t created in EntryExitPoints itself, but the processor calls a coprocessor to render a certain proxy geometry. A simple ProxyGeometry Figure 1. Rendering of a human head, with a clipped proxy geometry. coprocessor stores and renders a volume’s bound- You can download the visualization environment shown in this figure at ing box. By modifying the proxy geometry, users www.voreen.org can change the part of the volume data to be visu- alized (see Figure 1). More complex effects can be ProxyGeometry coprocessors illustrate the ad- achieved by applying a ProxyGeometry that uses vantage of interaction between a processor and a mesh representation and relaxes the relation be- a coprocessor via a method call. If we used ports tween vertex positions and colors. So, keeping the instead, we’d need the specific data representation colors constant and changing the vertex positions to be transferred. Not forcing ProxyGeometry to can produce a rendering of a deformed volume. provide information in a certain format relieves IEEE Computer Graphics and Applications 7 Applications 1 Grayscale::Grayscale() 2 { 3 createInport("image.input"); the implementation from any restrictions con- 4 createOutput("image.outport"); cerning the internal representation, provided that 5 program_=ShdrMgr.load("grayscale.frag"); it can render the stored shape. 6 program_–>build(); A RayCaster processor receives entry and exit 7 } points as well as a volume data set. It then performs the ray casting in a fragment program on the GPU (a) using the OpenGL Shading Language (GLSL). It supports different rendering modes—for example, 1 Identifier Grayscale::getClassName() isosurface rendering, maximum-intensity projec- 2 { tion, and direct-volume rendering—by recompiling 3 return ("PostProcessor.Grayscale"; the shader program at runtime. However, small 4 } modifications such as changing parameters—for 5 example, thresholds—don’t require recompilation 6 Processor* Grayscale::create() because uniform variables can pass new values. 7 { Using