Visualization elements and capabilities

3D Slicer visualization capabilities support various imaging modalities (e.g., CT, PET, MRI and Ultrasound) and can be used for visualization of 2-, 3- and 4-dimensional datasets. Support of 3-dimensional datasets (MRI, CT, PET) has enjoyed most attention based on the substantial number of use cases and resulting in a large number of tools developed specifically for this kind of data. Although support of the newer and less commonly applied 2- and 4-dimensional modalities is possible, it is a fertile ground for the future development. Data visualization in Slicer is enabled by the 2D and 3D viewers. The 2D viewers allow visualization of cross-sections from 3D or 4D image volumes, and support the associated image operations such as: basic image manipulations (zoom, window/level, pan), multiplanar reformat, crosshairs and synchronous pan/scroll for the linked viewers. Advanced capabilities of 2D viewers enable display of various types of glyphs for visualization of tensors and vector fields. Lookup tables (LUTs) support the mapping between the image values and the colors displayed in 2D viewers (e.g., grayscale LUT is typical for CT images, but color can be preferred for PET). Each 2D viewer supports three image “layers”: the user can select “background” and “foreground” image volumes as well as a “label” image volume (which can represent segmentations), and fuse the three layers by adjusting transparency. 2D viewers also support a “Lightbox” mode, where multiple slices from a volume are tiled within the viewer. The 3D viewers enable visualization of volume data, such as triangulated surface models, fiber tracks, glyphs and volume renderings. Augmented reality applications can utilize stereoscopic capabilities of the 3D viewers. Two- and three-dimensional elements can be combined in the 3D viewers to provide an integrated visualization of the various data to the end user, as shown in various figures throughout this manuscript. Coherent integration and visualization of multiple images and data types in 2D and 3D viewers is achieved via a common, scanner-independent, patient-centered physical space coordinate frame reference system. Spatial alignment of individual volumes can be achieved by introducing hierarchies of rigid and deformable spatial transformations. These transformations can be defined manually by the operator, or using the automated registration tools. Finally, chart viewers, a relatively new feature under development, are available for displaying plots.

A variety of image markup and annotations are supported. Following the convention used by Rubin et al., we use the term image markup to refer to the graphical elements overlay, and image annotation for the text-based information, both of which describe a certain finding in a given image. The markup elements provided by the 3D Slicer (as of writing this) are fiducials (points), uni-dimensional measurements (rulers), 3D box ROIs and 3D image raster ROIs (“label maps”). It is important to note that all of the markup elements, with the exception of label maps, are defined in the 3D coordinate system of Slicer as opposed to the voxel coordinates of the image slice. Label maps store image segmentations that define how individual voxels of the image map to certain classes (specific anatomies or pathologies). As such, label maps are defined in the image space. Currently, each voxel can belong to only one segmentation class, although an arbitrary number of label maps can be created for a given image volume. Annotations can be associated with each markup element as free text.

Layouts allow customization of the number, type and configuration of the viewers to suit a specific use case. The user can choose from the set of pre-configured layouts. Layout configuration and content can also be manipulated by the Slicer modules. This capability is similar to DICOM hanging protocols, although layouts tend to be selected and populated with content manually. Since layouts are stored in the Slicer scene-graph, they can be serialized and restored, complete with their content, from session to session. Of specific interest to the QIN community, are the Slicer layouts referred to as “Compare” and “Quantitative”. The Compare layouts allow exploration of longitudinal or multi-modality image sequences by placing each volume in a separate viewer and coordinating the display such that corresponding anatomy is displayed across all the viewers. Quantitative layouts include chart viewers side by side with the 2D and/or 3D viewers.

Modules

Slicer follows a modular paradigm in delivering task-specific functionality to the user. Each module is a feature-complete functional unit designed to serve a specific task. A variety of modules designed for different research applications are included in the distribution of the software. The modules are grouped according to the functionality they provide. The active module can be selected by the operator using the Slicer main GUI, which will expose the controls of the selected module in the Module GUI panel (e.g., see Fig. 2). A formatted web-based wiki page that describes its functionality, use-cases, GUI controls and includes references to academic publications accompanies each module. We note that virtually all of the processing done by the individual modules in Slicer is in the context of 3D volumetric data. As a side-effect of this, generic Slicer tools may not be well suited for processing non-volumetric data such as endoscopic video, free hand ultrasound, or conventional radiographs, although customized Slicer-based tools for some of these tasks have been developed.

Core modules of Slicer are those that support functionality applicable to a breadth of applications, such as DICOM IO support (“DICOM” module), volume rendering (“Volume Rendering” module) and the manipulation of spatial transformations for manual registration (“Transforms” module). The other categories of modules include the following:

• Filtering: tools for pre-processing and auxiliary operations on images. Functionality includes arithmetic operations, Gaussian and anisotropic denoising filters and intensity inhomogeneity bias field correction, among other tools.

• Registration: rigid and non-rigid spatial alignment of the images. These modules support point-, surface- and intensity-based registration. Individual intensity-based registration modules implement algorithms that vary by the similarity metric used (e.g., mutual information or cross-correlation) and flexibility of the transformation parameterization (e.g., rigid, affine, B-spline and dense deformation fields are supported).

• Segmentation: tools that separate individual sub-regions in the dataset based on certain features. Most of the tools in this category operate on single- or multi-channel images, although a module for segmentation of triangular surfaces based on curvature is also available. Image-based segmentation tools include both interactive and automated methods. Techniques implemented include region-based statistical methods, level sets, active learning and Expectation-Maximization multi-channel segmentation. The Editor module contains a collection of tools for manual and semi-automatic segmentation.

• Surface models: tools for creating and manipulating triangulated surface models. Such models can be constructed either from grayscale image volumes, or, more typically, from the segmented label maps.

• Diffusion: modules designed specifically for processing Diffusion Tensor Imaging (DTI) MRI. This category includes tools for diffusion I/O as well as techniques for denoising, tractography, and clustering of fiber tracts.

• Image Guided Therapy (IGT): modules that support applications in image-guided therapy. The key functionality provided by the tools in this category is the OpenIGTLink interface that enables exchange of data between Slicer and external systems, such as robotic devices, MR scanners, and commercial image-guided surgery platforms.

The collection of modules is continuously expanding as new functionality is contributed by the community, and the modules are migrated from the previous releases of the software.

Data Formats and Organization

Support of the widely accepted data exchange standards and interfaces are critical for any image computing tool to be useful in a clinical research environment. 3D Slicer supports import, query, retrieve, and storage of clinical images using DICOM protocols and data structures. These features allow data exchange with clinical systems such as scanners, workstations, and PACS servers. Example use cases for DICOM networking include: (1) setting up a scanner to route newly acquired images directly to a DICOM listener in Slicer to support image guided therapy; (2) using Slicer to query and retrieve DICOM studies in a departmental PACS to perform retrospective image analysis; and (3) sending derived (post-processed) images to a PACS system to become part of the patient record. In all cases, coordination with responsible clinical support staff is required to ensure that research use of Slicer is authorized and has been tested to confirm that it will not interfere with ongoing clinical care. Implementation of the import and export of DICOM RT structures user in radiotherapy is currently under way.

As images are imported into Slicer, they are added to the Slicer scene that is used to organize the individual data elements. While the user performs operations on the data or reconfigures the visualization elements of the interface, the scene is used to keep track of the application configuration. Scene views cache the complete state of the Slicer application, including the configuration and content of the viewers, together with a screen capture of the visualization elements and a textual description. Slicer scenes can contain multiple scene views that emphasize or communicate different aspects of data or different stages of its processing. Scenes can be stored on disk using the MRML format for sharing of the analysis results and to facilitate reproducibility of the observation. As an example, a scene view can correspond to a visualization that was used to prepare a certain figure in a report or manuscript. Accompanied by the Slicer scene, version of the software used and input dataset used to prepare it, such an article would provide a detailed provenance record, together with the methods, parameters and visualization context.

In summary, 3D Slicer is a comprehensive application that can be used for various tasks related to both the qualitative and quantitative exploration of the multimodal medical imaging data received directly from the imaging equipment or clinical PACS. The supported tasks include image overlay and fusion; annotation and quantitative measurement of lesion dimensions and volumes; image filtering and preprocessing; automated registration of images and segmentation of the individual structures. The MRML serialization format facilitates reproducibility of the obtained results and their exchange across research groups. However, research applications often have unmet needs that require development of new image analysis tools. In the next section, we explain the basic concepts required for implementing new functionality using Slicer platform.

Slicer Core Architecture

The core of Slicer follows object-oriented programming paradigm and is coded using C++ programming language. The APIs of the core classes are also exposed via Python wrapping mechanisms. In the recent years, the Python programming language has become a popular computing tool in the scientific community, in particular due to its broad applicability, relative simplicity and the availability of powerful open source scientific tools and libraries such as SciPy¹³. Python wrapping of the Slicer functionality makes it possible to develop fully functional scripted modules, thereby allowing quick prototyping and simplifying the development process. Such modules can leverage the existing functionality of both the Slicer application and various Python-based scientific libraries.

The classes that implement the core of 3D Slicer are organized into three main groups based on the functionality they provide, following the Model View Controller (MVC) design pattern and rely on event communication and API calls for coordination. The main components of the application core are the following, as shown in Fig. 3:

1. The Model is responsible for data organization and serialization, and is supported by the Medical Reality Markup Language (MRML). MRML defines the hierarchies of the data elements, and the APIs for accessing and serializing the individual nodes. MRML support in the Slicer core is provided by the MRML library, which is a key component of the Slicer architecture, but does not have any dependencies on the other core components. This library is used by the Slicer core and plugins to instantiate the MRML nodes and organize them into a coherent internal data structure called the MRML scene. The MRML scene maintains the links between the individual data items, their visualization and any other persistent state of the application and modules. As an example, a MRML node can store the processing parameters used by the algorithms implemented in the individual modules, or the window/level settings used to visualize a specific image volume.

2. The View maintains the state of the visual elements of the application. The View functionality is provided by the GUI and displayable manager classes of the Slicer core. These classes maintain consistency between the internal MRML state (Model), and the visual appearance of the Qt GUI data viewers of the application (e.g., multiple slice reconstructions can exist, while pointing to the same underlying image data structure). The updates to the GUI and visualization components of Slicer trigger events that propagate via the corresponding GUI classes to the “stateful” MRML nodes. Displayable managers maintain consistent visualization of certain data elements in multiple views/viewers. For example, intersections of the modeled diffusion tracts can be displayed in the 2D slice viewers in an anatomical image overlay and as streamlines in the 3D viewers, both handled by the same displayable manager.

3. The Controller, or Logic component encapsulates the processing/analysis functionality of the application core. The logic does not depend on the existence of GUI, but is fully aware of the MRML data structures. Communication between the view and controller components happens indirectly through changes to the MRML data structures. The logic classes use the MRML nodes for storing the computation results. The view classes can register to receive event updates from the MRML scene and the individual nodes, which in turn initiate updates of the visualization elements.

Modules

The event-driven architecture of the Slicer core is complex in part due to the fact that the application incorporates several libraries (Qt, VTK and MRML) that have their distinctive event handling mechanisms. Recognizing that deep understanding of the application internals has a steep learning curve, Slicer provides two approaches for introducing new functionality as Slicer Execution Model (SEM) plugins or Slicer loadable modules. These approaches differ primarily by the level of their integration with the application core and — as a consequence — by the level of expertise in Slicer internals required from the developer.

The Slicer Execution Model (SEM) implements the simplest approach, as it does not require any knowledge of the 3D Slicer architecture, and does not have dependencies on the Slicer libraries or source code. SEM modules implement the task-specific Controller component of the MVC design, while the View and Model elements are maintained by the main application via the specialized SEM Module Manager (SEM-MM) core module, see Fig. 3. SEM-MM also serves as a communication intermediary between the application core and the SEM modules. The interface for this communication, defining the input/output data (e.g., images, transformations and points) and processing parameters that need to be specified by the application user, is described using XML, based on the Slicer SEM XML schema. This XML description is also used by SEM-MM to populate the GUI elements of the module panel with widgets that control inputs, outputs and the processing parameters.

The SEM XML compliant communication interface is the only requirement imposed on the SEM modules by the Slicer application. SEM modules can be implemented as independent executable files, shared libraries or scripts (such as Python or MATLAB scripts) that via SEM can leverage Slicer visualization and DICOM capabilities. Internally, they can use any of the processing libraries, and do not need to have any dependencies on the components distributed with 3D Slicer. SEM modules can also be distributed in the binary form, which satisfies the needs of developers and communities that cannot share the source code of the module, but are willing to make the tool available to the users. SEM modules are most suited for implementing new functionality that does not require interaction, dynamic visualization and reconfiguration of the Slicer interface. Examples of such modules included in Slicer are image resamplers, filtering and automatic registration tools. Slicer SEM has also been adopted as a mechanism for developing and integrating interoperable tools by several projects independent from Slicer, such as GIMIAS¹⁴, BRAINS and NiPype. By supporting the SEM, the aforementioned packages are able to directly incorporate Slicer SEM modules into their framework.

Compared to SEM plugins, Slicer loadable modules have complete access to the Slicer core logic, GUI and MRML elements. Loadable modules are typically developed for interactive tools, or for those applications that require new MRML data types, event handling or customization of the main Slicer GUI. Loadable modules follow the same MVC design pattern as the application core by introducing module-specific Logic, as well as GUI and MRML classes. Logic classes are typically the most important component for the developers of the new image analysis tools, as they include the core computation and the implementation of the analysis algorithms. Such an implementation would usually (although this is not a requirement) rely on the Insight Toolkit and VTK for constructing pipelines and implementing lower level processing steps. The View elements allow the module to interact with the operator to initialize the inputs and processing parameters, and any interactive initialization of the algorithm (e.g., collect the initialization seed points placed in the 2D slice viewer for a lesion segmentation tool). Examples of the interactive loadable modules available in 3D Slicer are “EMSegmenter” that implements expectation maximization multichannel segmentation algorithm and “Tractography fiducial seeding” that allows visualization of reconstructed DTI tracts at a location defined interactively by the user. We emphasize that both SEM plugins and loadable modules can be written in C++ or they can be scripted using the Python language. In our experience, Python scripting can greatly simplify and expedite implementation of the new functionality.

Investigators planning to develop new 3D Slicer functionality should also be aware of its various research interfaces used for data communication. Although support of DICOM is critical for the communication with the clinical systems and equipment, this format is not always suitable for the needs of medical image analysis community since the data fields it stores can contain patient-sensitive information and are often irrelevant for the image processing tasks. Moreover, in several new or emerging applications there is no standard that regulates how certain aspects of data that are critical for its accurate interpretation are stored using DICOM. Or, when standards do exist, they are often not fully implemented or are ignored in their entirety by vendors. As an example, vendor-specific private tags are still commonly used to store acquisition information specific to Diffusion Weighted MRI, even though a DICOM standard format exists. To address these limitations, Slicer uses custom code (in particular, the IO mechanisms provided by ITK), to support several additional formats, such as NRRD¹⁵, that are commonly adopted by the image analysis community. These formats often provide a more concise and less ambiguous formatting of the image-specific information. ITK IO is also used to store spatial transformations. Support of 3D models IO, such as surfaces streamlines and polygonal data, is available via VTK and STL formats. Finally, Slicer supports OpenIGTLink network communication interface that has been widely used in the interventional applications to communicate with instrument trackers, imaging and robotic devices.

Having reviewed the functionality and implementation of Slicer, we continue with the specific use cases derived from the experience of the sites participating in QIN. Imaging needs, body organs and clinical problems studied at each these sites are different. Nevertheless, 3D Slicer was identified independently as a platform of choice to support the needs of clinical researchers and biomedical engineers of the respective projects.

BWH

The objective of the Brigham and Women’s Hospital QIN site (PI Fiona Fennessy) is to study MR analysis tools and algorithms for detection of prostate cancer and disease recurrence, and as a guide for targeted prostate therapy. There is increasing evidence that MRI can facilitate the detection and characterization of prostate cancer (PCa) through the use of a combination of multi-parametric MRI (mpMRI) techniques (such as DWI and dynamic contrast-enhanced (DCE) MRI) in addition to the T2-weighted (T2w) MRI, used routinely in the clinic. This functional aspect of MR imaging could contribute greatly to the accuracy of tumor detection and localization, and potentially serve as a guide for focal ablative therapy, or could non-invasively assess functional aspects of prostate tissue microcirculation in response to neoadjuvant treatment. While mpMRI (DWI and DCE MRI in particular) could potentially become imaging biomarkers of PCa, thorough evaluation of the imaging and analysis methodologies are required for their mainstream adoption.

The focus of the BWH QIN effort is on optimization of the methods and software for pharmacokinetic (PK) analysis of prostate DCE MRI, and on clinical validation of the developed tools in the context of clinical trials for PCa treatment. This task requires software tools that could enable clinical researchers to perform fusion and coherent visualization of the individual MR parameters, including DCE MRI time series, calculation of the derived metrics at the different stages of treatment and correlation of the various imaging-based features with the histopathological properties of the tissue. Validation of the imaging-based research tools necessitates preparation of organized reference imaging collections, with lesions annotated by the expert radiologists and pathologists.

Development and evaluation of the proposed imaging based tools is distributed between the BWH team (PI Dr. Fiona Fennessy) and a GE Global Research team, led by Dr. Sandeep Gupta. The imaging and clinical expertise of the BWH site is utilized initially to prepare the annotated MRI datasets that enable the GE collaborators to test and refine the DCE MRI PK analysis techniques, with the analysis results communicated to the BWH team using research image formats. 3D Slicer is used as the primary research platform for this project. Its fusion capabilities are used for visualization of individual parameters from the prostate mpMRI datasets, as shown in Fig. 4. Post-processing, registration and plotting functionality of the application can support exploration of the quantitative parameters, arterial input functions, PK model fits and their correlation with the imaging data. The Editor module is used to provide expert radiologists with a convenient interface to contour the suspected lesion site, based on the clinical information and the visual impression, for the subsequent quantitative correlation with the imaging parameters. These tasks are important for the investigation of the various imaging and processing aspects that can influence the PK analysis. The existing image registration capabilities of 3D Slicer and its integration with the Insight Toolkit provide a foundation for the development of the registration tools customized for prostate mpMRI data. The SEM plugin mechanism is often used in implementing such tools, since it supports batch execution for automated analysis of large numbers of datasets. Via its support of open formats for data exchange, 3D Slicer enables coordinated development of both closed-source commercial components by the GE collaborators, and integration of the results derived using those tools within an open research platform.

Of interest for the broader community, as part of the BWH QIN effort, the capabilities of the Slicer software to handle time-resolved DCE MRI data are being expanded. Specialized Slicer modules customized for the analysis of prostate mpMRI and their correlation with pathology findings are under development. Finally, Slicer markup and annotation infrastructure is being improved in a customized reporting module that will support serialization of the annotations into interoperable formats, such as AIM and DICOM SR. These novel tools will be publicly available as Slicer modules and extensions.

Iowa

Response assessment to cancer therapy based on molecular imaging with PET/CT lacks an accepted robust and accurate quantitative metric. The literature is rife with new and different ways to analyze PET/CT image data, including variants of standardized uptake values (SUV), various lesion-to-background approaches, volume measurement, and metabolic tumor volume, but it is still unclear which of these approaches is best suited for response assessment.

A major goal of the QIN project at the University of Iowa is to establish a publicly accessible and large database of PET/CT images and associated analyses to serve as a test bed for quantitative image analysis in the context of therapy response assessment in head and neck (H&N) cancer. This will allow comparison of different approaches objectively by correlating different metrics with outcomes, and ultimately, lead to optimized quantitative image analysis methods, which will be utilized together with image quality assurance measures to support clinical decision making in several clinical trials.

Slicer was selected as a platform for the integration and development of semi-automatic medical image analysis tools, because it allows focusing on algorithm development while utilizing Slicer included image import/export mechanisms, GUI (viewer), and other general-purpose functions. Equally important, the newly developed image analysis methods and approaches can be easily and directly shared with other researchers within and beyond the QIN network.

Slicer with its developed specialized software extensions (loadable modules) was integrated in a workflow management system, which handles data flow between a research PACS implemented with XNAT¹⁶, the Slicer environment itself, and the Iowa QIN database, serving multiple users and different quantitative image analysis tasks. Along the stated paradigm, a Slicer module has been developed to assist in the task of measuring PET imaging based quantitative indices in the tumor region. Although the standard package of 3D Slicer includes a module for PET standardized uptake value (SUV) quantification, the region of interest for quantitative analysis must be specified manually. In contrast, the module developed by the Iowa QIN team allows segmenting tumors or lymph nodes in a highly automated fashion with low user interaction effort. Following the segmentation, a diverse set of 2D and 3D indices of tumor uptake are calculated. For reproducibility purposes, the module allows collecting and storing information (e.g., tumor location, segmentation parameters, visualization settings) utilized by the operator in the process of generating the quantitative indices.

Future work will focus on the development of 4D quantitative analysis approaches as well as method validation on the H&N database. The existing functionality implemented using previous generation of 3D Slicer (version 3) will be transitioned into the most recent release. The implementation of the PET SUV quantification and segmentation approaches will be shared with the QIN community for cross-validation and further improvement of the methodology.

MGH

The goal of the MGH QIN project is to develop quantitative imaging tools to facilitate clinical decision making, particularly in the setting of therapeutic response in glioblastoma multiforme (GBM). The overall research goals are to use mechanistic imaging to understand therapeutic response in GBM and thereby improve care and ultimately survival. Anti-angiogenic agents such as bevacizumab have been approved by the FDA for the treatment of recurrent GBM, and anti-VEGF therapies are used routinely in the clinical care of GBM patients. However, these therapies come with considerable toxicity, and many patients do not respond: the FDA cited a 26% objective response rate. This highlights the critical need for biomarkers of response to therapy in brain tumors. Preliminary data indicate that parametric analysis of multimodal imaging in these tumors provides clinically useful quantitative information to evaluate the response of these therapies. Specifically, DCE MRI, dynamic susceptibility contrast MRI (DSC MRI) and diffusion-weighted imaging provide clinically useful quantitative response information for GBM in the anti-VEGF treatment setting. The different automated and semi-automated segmentation tools within 3D Slicer assist in delineating the different regions of interest (ROIs) based on T1, T2 and FLAIR imaging. These can include enhancing tumor, necrosis and edema as seen in Fig. 6. Patients are imaged at a number of time-points and volumetric analysis based on these regions can be used to assess tumor response (e.g., stable vs progression).

3D Slicer provides a number of state-of-the-art algorithms for rigid, affine and deformable registration (in addition to manual registration). These algorithms can be selected and optimized depending on the anatomical site (e.g., brain vs prostate), purpose (multimodal vs longitudinal vs registering to an atlas), performance (speed vs accuracy vs robustness), and level of interaction (e.g., use of fiducials or markers). The registration tools within Slicer are utilized in a number of ways. Regions of interest delineated on T1w, T2w or FLAIR MRI are registered to the other imaging modalities and associated parametric maps (e.g., K^trans maps from DCE, rCBV maps from DSC and ADC maps from DTI) as seen in Fig. 6. This capability helps better understand the distribution of these parameters in the different regions of the tumor and in different patients. These tools can also be used to register the radiation therapy plans (CT-based) to the MR functional imaging, allowing exploration of the site of recurrence with respect to dose field and study the phenomenon of radiation necrosis. Registration algorithms and the change detection tools can be used to identify regions of change in the tumor from longitudinal imaging.

There are a number of enhancements planned for 3D Slicer, both by the Slicer team as well those being developed at the MGH site, that would have tremendous utility for the GBM imaging research. The planned improvements of the 4D support tools and the ability to conduct PK analysis in Slicer will help achieve better-integrated analysis workflows. Currently, external resources are used to create the parametric maps and subsequently import them into Slicer for registration with the anatomical volumes. The recently introduced charting capabilities of Slicer can be used to extend the existing label statistics tools to include histograms and graphs. The MGH investigators are also in the process of developing an EM-based segmentation algorithm to allow automatic delineation of the different regions within the tumor based on the multimodal imaging. The ability to create and store annotations in AIM format will provide an easy, standardized mechanism to exchange our results across the various members of the QIN, and to grade tumors or assess response (e.g., using the McDonald or RANO criteria ).

Ultimately, the vision of the MGH QIN project is to have a fully integrated analytical pipeline whereby each of the use-specific modules are customized for the GBM processing workflow. Specifically, this could lead to a system that (1) queries and retrieves original DICOM images (raw data) from a PACS server, (2) provides automated inter-anatomical registration (e.g., T1-weighted, T2-weighted and FLAIR images) as well as 4D dynamic and functional image registration (e.g., DCE, DSC, DTI, BOLD), (3) automatically segments regions of interest encompassing the abnormalities on anatomical images, (4) launches 4D analysis tools capable of creating parametric maps, and finally (5) extracts metrics and displays relevant characteristics from joint analysis. Importantly, data provenance can be systematically indexed through each process. Such an integrated pipeline will take raw information from clinical imaging to biomarker measurement in an efficient and controlled manner, ultimately facilitating accurate incorporation into a database. Moreover, given Slicer’s tractability, new analytical methods can be readily incorporated into the pipeline, thereby continuously improving our approaches to biomarker development and discovery.