Engineering:ISCPaper
From NAMIC Wiki
Home < Engineering:ISCPaper
% This is sample.tex the demonstration file of
% MICCAI 2005 for Latex2e
% adapted from LLNCS.DEM from
% the LaTeX macro package from Springer-Verlag
% for Lecture Notes in Computer Science,
% version 2.2 for LaTeX2e
%
\documentclass{llncs}
%
\usepackage{makeidx} % allows for indexgeneration
\usepackage{url}
%
\usepackage{graphicx}
\graphicspath{{pics/}{figs/}}
% list here all the paths to your figure folders
\begin{document}
%
\frontmatter % for the preliminaries
%
%\pagestyle{headings} % switches on printing of running heads
\pagestyle{empty} % switches on printing of running heads
%
\mainmatter % start of your contributions
%
\title{Application Software for Medical Image Computing: Slicer3 Architecture Design Review}
%
\titlerunning{Short Title} % abbreviated title (for running head)
%
\author{
Kathryn Hayes\inst{1,2}
\and Michael Halle\inst{1,2}
\and Nicole Aucoin\inst{1,2}
\and Sebastien Barre\inst{2,4}
\and Dan Blezek\inst{2,5}
\and Andy Cedilnik\inst{2,4}
\and Luis Ibanez\inst{2,4}
\and Tina Kapur\inst{2}
\and Bill Lorensen\inst{2,5}
\and Jim Miller\inst{2,5}
\and Lauren O'Donnell\inst{1,2,7,8}
\and Jagadeeswaran Rajendiran\inst{2,6}
\and Will Schroeder\inst{2,4}
\and Alex Yarmarkovich\inst{2,3}
\and Steve Pieper\inst{2,3}
\and Ron Kikinis\inst{1,2}
}
%
\authorrunning{me} % abbreviated author list (for running head)
%
%%%% modified list of authors for the TOC (add the affiliations)
\tocauthor{Kathryn Hayes (Brigham and Women's Hospital),
author2 (Isomics, Inc.),
author3 (National Alliance of Medical Image Computing),
author4 (Kitware),
author5 (GE)
}
%
\institute{Department of Radiology, Brigham and Women's Hospital, Harvard Medical School, 75 Francis Street, Boston, MA 02115, USA, \email{hayes@bwh.harvard.edu},
\and
National Alliance of Medical Image Computing, USA
\and
Isomics, Inc, Cambridge, Massachusetts, USA
\and
Kitware, Inc, 28 Corporate Drive, Suite 204, Clifton Park, New York 12065, USA
\and
GE Corporate R\&D, 1 Research Circle, Niskayuna, NY 12309, USA
\and
Laboratory of Neuro Imaging, Department of Neurology, UCLA School of Medicine, 710 Westwood Plaza, Rm 4-238 , Los Angeles, CA 90095, USA
\and Division of Health Sciences and Technology (HST), Massachusetts Institute of Technology, 77 Massachusetts Ave, E25-519, Cambridge, MA 02139, USA
\and Computer Science and Artificial Intelligence Laboratory (CSAIL), Massachusetts Institute of Technology, 32 Vassar Street, Cambridge, MA 02139, USA
\thanks{This work is part of the National Alliance for Medical Image Computing
(NAMIC), funded by the National Institutes of Health through the NIH
Roadmap for Medical Research, Grant U54 EB005149. Information on the
National Centers for Biomedical Computing can be obtained from
http://nihroadmap.nih.gov/bioinformatics.
}
}
\maketitle % typeset the title of the contribution
\begin{abstract}
The authors are part of a consortium effort (NA-MIC) to support
computing for biomedical imaging research, and are particularly
interested in the development of end-user application software as part
of that effort. The purpose of the Slicer3 architecture review is to
investigate use cases, requirements, and components for an updated
cross-platform, modular, testable, end-user application framework for
future NA-MIC and related use. This paper presents a snapshot of the
architecture development process including both topics on which
consensus has been achieved (e.g. the use of ITK as the algorithm
development framework) and areas where further research is ongoing.
To be successful, the architecture must meet a diverse set of user and
developer requirements; as a report to the wider community, this paper
is an attempt to solicit input and participation.
\end{abstract}
\section{Introduction}
\subsection{Context}
\subsubsection{Slicer}
Why we decided to do it the way we did (path of development):
Social Goals:
- open platform
- be able to extend the code base for research purposes
- use it freely in a clinical research env.
- share software with collaborators, inc. visitors to the lab
- Dave Gering @MIT - worked @ GE before he got to MIT - take best
ideas of what's currently available in industry with our goals
Technical Goals:
- provide a modular research platform that is an end user interface to
algorithms implementing segmentation, reg., data viz., guiding image
acquisition,
- major motivator: Open magnet system that needed to provide real-time
data to the system with the help of the surgical team.
- open (MRT) and conventional surgery provided an interface for
IRB-approved experiments
- how often it has been used
- as we continued to support Slicer as part of our research efforts,
the ITK effort built up seg. and reg. algorithms as a common
platform
- those were specifically designed to not have a UI that an end user
would use
NA-MIC:
ITK, VTK, etc. - elements without UI
NA-MIC can bring software tech., lessons of soft. eng. that were
learned, other soft. efforts, DBPs
Slicer provides a UI that both the DBP people and the developers can
use the UI in a way that is intuitive.
Slicer was a natural fit because it was built on top of VTK and ITK,
but it wasn't designed for that.
-> take lessons of existing software, adapt to a specific larger need.
- filled a gap that fitted an immediate need, we want to fit a need
with a specific product, and w/ the lessons of previous
development...
What is the current status of the software:
(Slicer2 as a reference: current state of Slicer)
- mechanisms that allow distributed development to be successful -
elements of comm. for dist. devel. and users
- interact w/ Slicer both programatically (w/ tkcon) and through the UI
- MRML designed to be a scene/data description for exchange
- programming infrastructure was not layered to allow modularity,
prog. language does not allow encapsulation
- no easy access of math. expr.
- doesn't allow extensive reuse of UI components
- harder to isolate functionality (ind. modules or objects) - can't
encapsulate functionality
- current structure makes testing of UI difficult
- elements of Slicer can't be reused by other programs (essentially
monolithic)
- interesting functionality can't be incorporated into other programs
- what have we learned in the process?
- what applications can we envision that we would like to support with
Slicer that we hadn't thought about before? e.g. ITK
- desired new functionality/applications
- what does an app. person, an end user, and a programmer want?
- go to NA-MIC, what do people want? UI for grid comp., remote
execution
- standardized interface to tracking systems and medical image devices
- other end user apps.
- behave like a professional quality UI app
- services offered: exchange data with other programs and software
systems, make it easy for people to bring their software into Slicer
w/out a great investment in understanding Slicer arch. and provide
building blocks for building interactive applications that go beyond
particular algos. (e.g. how to get to remote data, talk to other
progs., other trackers, etc.)
Licensing reqs.
- want to maximize sharing of data - realize that good stuff comes
from clinical, reserach, academic, commercial env. The more people
that can share data, the greater likelihood that we can ... in ways
that we can't predict or control.
- What are the ramifications? People thing, not a lawyer thing
- trying to balance needs of sharing with the real issues of liability
in the medical community, continues to be an ongoing discussion
- objective is not to evangenlise anything -> want to share, allow
people to decide for themselves
- licensing affects decisions - how are we choosing the technologies
and making this choice? - an element of design
The 3D Slicer is freely available, open-source software for
visualization, registration, segmentation, and quantification of
medical data.
%\cite{slicer.org}.
Slicer uniquely integrates several facets of image-guided medicine
into a single environment. It provides capabilities for automatic
registration (aligning data sets), semi-automatic segmentation
(extracting structures such as vessels and tumors from the data),
generation of 3D surface models (for viewing the segmented
structures), 3D visualization, and quantitative analysis (measuring
distances, angles, surface areas, and volumes) of various medical
scans.
%\cite{slicer.org}.
We integrated Slicer with an open MR scanner to augment
intra-operative imaging with a full array of pre-operative data. The
same analysis previously reserved for pre-operative data can now be
applied to exploring the anatomical changes as the surgery
progresses. Surgical instruments are tracked and used to drive the
location of reformatted slices. Real-time scans are visualized as
slices in the same 3D view along with the pre-operative slices and
surface models. The system has been applied in over 20 neurosurgical
cases at Brigham and Women's Hospital, and continues to be routinely
used for 1-2 cases per week.
%\cite{slicer.org}.
\subsubsection{NA-MIC}
The National Alliance for Medical Imaging Computing (NA-MIC) is a
multi-institutional, interdisciplinary team of computer scientists,
software engineers, and medical investigators who develop
computational tools for the analysis and visualization of medical
image data. NA-MIC is supported by the National Institutes of Health,
Roadmap Initiative for Bioinformatics and Computational Biology. The
purpose of the center is to provide the infrastructure and environment
for the development of algorithms and open software technologies, and
then oversee the training and dissemination of these tools to the
medical research community.
The engineering core of NA-MIC serves as the link between the
algorithm developers and the end-user medical practitioners of the
driving biological projects (initially NA-MIC is developing software
for neuroimage analysis in support of schizophrenia research, a focus
that will broaden to include other image computing types as the
project evolves). A robust, well-architected application environment,
with a logical user interface and a set of complementary image
analysis and data manipulation tools provides a critical component for
the success of the overall effort. In addition, the end-user
application environment must be flexible enough to support a variety
of interaction styles, including interactive and batch processing
modes. The application must also support different operating systems
and machine architectures.
\subsection{Slicer2 as a Reference}
To meet their overall goals, the NA-MIC investigators have to adopt
and build on the existing 3D Slicer application environment (or simply
``Slicer'') as a reference platform for the development of new
functionality because it already has many of the features that were
known to be important for this purpose. Slicer is already a complete
end-user application, purpose-built to provide a platform for image
analysis research and algorithm development while adhering to the user
interface conventions that have become standard in end-user software.
%\cite{JMRjournalpaper}.
Slicer is available for download both in source code format and in
pre-compiled binaries for the Linux, Windows, and Sun Solaris
platforms, and thus can be used by developers who wish to add new
functionality to the existing feature base and by users familiar with
a point-and-click menu environment. While the Surgical Planning
Laboratory (SPL) at Brigham and Women's Hospital is the primary home
of the Slicer, a number of groups have been involved in the initiation
and ongoing development of the software.
Slicer core functionality and architecture are implemented using the
Visualization Toolkit (VTK) library developed by GE Research and
Kitware. Slicer has also been adopted as one of the core software
components of the Biomedical Informatics Research Network (BIRN)
project, one of NA-MIC's sister projects, through which our
collaborators at UCSD, Georgia Tech, and the Laboratory of Neuro
Imaging at UCLA have integrated Slicer with their research.
Additionally, several algorithms in the Insight Toolkit (ITK) have
already been integrated into Slicer as plug-in modules, and new
software from Slicer developers is being contributed back into the
Insight Consortium.
In summary, Slicer2 has been a highly effective vehicle for putting
medical segmentation, registration, visualization, and data
manipulation tools driven by the needs of research projects into the
hands of end users. Slicer2 is an important part of NA-MIC: it is
NA-MIC's current application platform. Now and for the near future,
Slicer2 offers NA-MIC researchers an effective way to make their
algorithms and software available to others.
\subsection{Motivation for New Development}
Slicer3 will be developed as a collaboration between the Algorithms,
Engineering, and Driving Biological Projects cores of NA-MIC.
Slicer2's current stability offers us an opportunity to review
limitations of its current design and architecture based on the new
roles it is being called on to fill. Years of experience as users,
developers, and code base maintainers have given us insight on the
strengths and limitations of Slicer2, which we hope to build on in
Slicer3. We can begin developing elements of a new Slicer
infrastructure (Slicer3) as a platform for the future while continuing
to use Slicer2 as a technology deployment tool for current projects.
We believe this moment in the NA-MIC development schedule is the best
time to evaluate the requirements, benefits, costs, and possible
composition of a Slicer3 architecture. The goal is to understand the
needs and opinions of all parties as well as the current state of the
art in application development when deciding on the direction of
Slicer3.
Overhauling the current Slicer architecture allows us to shed
limitations of the current Slicer2 architecture and adjusting
structure to the NA-MIC approach. We are able to add new ideas,
including NA-MIC inspired ideas, and create a long-lived, maintainable
system. By improving the architecture, we are hoping that Slicer3
will evolve into a platform with a broad developer community as well
as an attractive end-user application for NA-MIC user groups and
biomedical imaging researchers in general.
\section{Method}
\label{sec:method}
The Slicer3 architecture design review has been facilitated by Slicer
developer meetings, and the recent NA-MIC programming retreat in
Cambridge, MA from Monday, June 27 - Friday, July 1st, 2005 at MIT.
In attendance were Slicer users, Slicer developers, and developers of
Slicer's underlying technologies. The Slicer architecture review at
the programming retreat consisted of individual presentations followed
by group discussions.
In addition to the programming week, ongoing weekly NA-MIC engineering
teleconferences and updates of the NA-MIC wiki provide communication
about the current state of the Slicer architecture design process.
Slicer developer meetings are held every two weeks at BWH to
facilitate further architecture design between local developers, with
minutes posted to the NA-MIC wiki. A second programmer's week is
scheduled for January in Salt Lake City, Utah, to report on Slicer
architecture progress and continue discussion among the Slicer
development community.
These organizational efforts will be supported by the technologies and
practices of the NA-MIC software engineering methodology, carried
forward from the ITK and VTK communities. This process include a cvs
source code repository, nightly testing with Dart, users and
developers mailing lists, and an "extreme" programming approach.
\section{Requirements and Specifications}
\subsection{Current Slicer Evaluation}
The re-engineering of elements of Slicer is based on several years of
experience with Slicer2, the underlying VTK and ITK toolkits, as well
as elements of other applications, frameworks, and technologies. This
effort is designed to address several shortcomings of the current
Slicer2, while preserving its strengths.
\subsubsection{Strengths}
Slicer2 as it exists today has a number of strengths that we wish to
incorporate into the new Slicer3 design. Slicer2 is currently a
stable, mature application which incorporates a large amount of
functionality at both the developer and user level. It is actively
maintained, with bug fixes made and new functionality added in minor
releases multiple times a year. There are many resources for users
and developers including extensive documentation, mailing lists, a bug
tracker, and a Dart dashboard which provides a visual interface to
nightly builds and regression testing.
Slicer and its key technologies are open, and permit development by
multiple geographically distributed developers in a cross-platform,
unencumbered fashion. The use of the Tcl/Tk scripting language allows
rapid development of new modules and functionality and user interfaces
to be constructed with relatively few lines of code. Tcl supports
dynamic loading of scripts and code, and Slicer's runtime tkcon (Tk
console) allows for interactive access to the Tcl interpreter.
MRML, Slicer's scene description and data exchange file format, is
based on XML and supports hierarchies of models and volumes.
\subsubsection{Weaknesses}
Slicer2 also has a number of weaknesses we would like to address in
the architecture review process.
Tcl, while it is strong in introspection, flexibility, and stability,
also has weaknesses which Slicer developers have found limiting.
Slicer currently uses Tcl (without any object-oriented extensions) for
both UI scripting and program control. As a language, Tcl has
limitations including a lack of general objects, arrays that are not
first-class objects, mathematical expressions that are not part of the
core language syntax, and lists which require a verbose indexing
syntax.
Debugging Tcl code can be difficult because command, variable, and
array index names are often formed by string concatenation which
increases the complexity of code tracing. VTK's current Tcl bindings
place all objects in a single, global namespace; object names are
chosen by the user; conflicts are easy to generate and must be avoided
manually by naming convention. This can be especially problematic
because many of Slicer's developers work almost completely
independently of each other.
Because no object oriented language features are used at the Tcl
level, Slicer2's current modules combine code collections, UI panels,
and quasi-object instances into a single construct. As a result, it
is not possible to create multiple instances of user interface
components. While Slicer's VTK implementation classes are potentially
available from other applications, Slicer's application logic
(implemented in Tcl) is in general much harder to interface to
arbitrary external software. Code interdependencies make it difficult
or impossible to extract specific subsets of this functionality for
use in other software.
There is no objective specification of how Slicer2's components are
meant to behave. In fact, Slicer2's behavior is in some cases defined
by bugs and bug workarounds required by compatibility over its
development life. Because Slicer2 does not have a testing framework
that developers are required to populate, it isn't possble to track
when software is or isn't behaving correctly.
MRML, Slicer2's data description and exchange mechanism, has several
limitations. There is not a clean separation between data
description, scene description (the relationship of the objects that
the data represents), rendering state (instancing) and rendering style
(color, material, visibility). There is currently no support for
semantic links and limited support for program state. There is no XML
namespace support, no remote resources supported, and no effective
mechanism for approved extensions, or guidance about how to design
them. Slicer's MRML parser is a Tcl-based ``ad-hoc''" parser.
\subsection{UI Tools}
One of the major design decisions that will be made for Slicer3 will
be the choice of user interface tools. Although it is difficult to
quantify improvements in the user interface, we do have specifications
that we want our UI tools to meet. We want to ensure that the chosen
UI tool enforces the distinction between the user interface and
functionality, in contrast to the current Slicer2 UI which is deeply
integrated with the underlying code base. For consideration in
Slicer3, UI tools need to be well-designed developer tools, have an
active developer community, and have testing, debugging, and support
options available. In addition, we want to know the current UI trends
in the medical image community to decide which tools are best for our
developer group.
Another consideration is the native look and feel options that are
available in a particular UI tool. In addition to a clean,
professional interface, we would like to be able to change
accessibility options (e.g. font sizes and typefaces), and allow
future internationalization of the interface, if necessary.
A particularly useful set of features include the ability to implement
multi-level 'undo' functionality, the ability to log and replay user
sessions, and create user macros. These would be invaluable to both
users for ease of use, customization, and training scenarios, and to
developers to help debug user sessions.
Another key consideration is in which programming language the UI will
be written. The language needs to facilitate building compound
widgets in a clean, convenient, and reusable fashion. One strong
advantage of an interpreted language over a compiled language is that
UI changes can be made, reloaded, and viewed at runtime, instead of
needing to recompile and restart the program.
The language also needs to allow clean coupling between the 2D user
interface and the 3D user interface. It would be optimal to be able
to leverage ongoing efforts to simplify the amount of code rewriting
that will need to take place in this domain. In addition, there needs
to be clean, efficient event management between the 2D and 3D UIs.
\subsection{Services Offered}
Slicer needs to offer a variety of services. Our data model and API
for scene description is the MRML (Medical Reality Modeling Language)
format. In addition to MRML, there is also non-scene program state,
which includes program options, window and UI preferences and state,
etc.
Slicer also offers asynchronous event handling, which allows for
external program execution, multi-user interaction, and tracking of
external devices, such as probes.
Slicer also has data interfaces, including virtual file systems, local
caches, and interfaces to databases and other external programs.
\subsection{Licensing Requirements}
Currently, Slicer2 and many of its associated technologies are
distributed under different licenses. A key goal for Slicer3 is to
determine which licenses are compatible with furthering the goals of
NA-MIC and the NIH.
The NIH, in soliciting proposals for the program that funds NA-MIC,
stated their general goals for software licenses:
``...NIH does have goals for software dissemination...''
``...software should be freely available...''
``...permit the commercialization of enhanced or customized
versions...''
``...include the ability of researchers outside the center and its
collaborating projects to modify the source code and to share
modifications...''
%\cite{NIHlink}
There has been much discussion about which software licenses are
licenses are compatible with the goals of the NIH as intepreted by
NA-MIC investigators. After this review, the policy of NA-MIC is that
BSD or MIT-style licenses are preferred for NA-MIC software because
they place the fewest restrictions on users and are compatibile with
commercialization in the predominant style of the medical imaging
community. Also acceptable but not preferred are licenses of the type
used by FLTK and wxWidgets which are LGPL but with an explicit
exception to allow distribution of statically linked executables in
binary-only form.
Importantly, NA-MIC will not accept code licensed under the GPL or
LGPL licenses. This policy is motivated by the desire to encourage
widespread adoption of the NA-MIC software infrastructure by both
academic and commercial entities. Unlike many IT applications,
medical software must have regulatory approval by the FDA (or their
international counterparts) in order to become a clinical standard of
care. At present, closed source business models dominate the clinical
computing field, and therefore ``viral'' licenses like GPL and LGPL
have been determined to be incompatible with the goal of encouraging
widespread adoption. ``Viral'' is a term that is used to describe
licenses that have terms such that all derived works must in turn be
distributed under a license that is defined by the authors of the
original software (i.e., all derived works of code licensed under the
GPL must also be licensed under the GPL). Note that this restriction
applies only to software that NA-MIC will be distributing itself;
end-users and application developers are free to use NA-MIC code as
components in applications that are distriuted under viral licenses.
\subsubsection{Licensing Status of Existing Software}
Slicer versions starting with 2.0 are copyright BWH (previous versions
were copyright MIT, but the institutions executed a transfer of
copyright ownership to reflect the fact that BWH had increasingly
become the ``home'' of Slicer development). As part of the new
license, BWH legal staff required a ``non-clinical'' clause to
minimize liability for code released to the community. Discussions are
ongoing between NA-MIC investigators and BWH officials to find the
best way to meet NIH goals for open development while protecting BWH
from liability.
ITK was developed under contract to the National Library of Medicine
at NIH. The contract explicitly stated that data and software were to
be publically available. Early in the project it was decided to
assign copyright to the non-profit Insight Software Consortium (ISC),
an educational corporation organized to promote the use and
dissemination of open source software. ISC may also hold IP (e.g.,
copyright, trademarks). Finally, ISC grants licenses under BSD. The
ISC is also designed as a legal shield for contributors of open source
software.
VTK was created as part of a textbook. The copyright was (and still
is) held by the three principal authors of the textbook (Schroeder,
Martin, Lorensen). These authors were employees of GE, but obtained
permission to create the book and VTK software. GE realized the
benefits of open source software and decided to contribute code
developed at GE R\&D to the VTK community. As a result, formal
documents were drawn up and a process was established to assign
copyright from GE to the VTK copyright holders. Thus far several dozen
classes have been contributed by GE to VTK.
\section{Specific Proposals}
\subsection{Data-centric Architecture Design}
As noted above, Slicer2 suffers from a lack of modularity and
insufficient abstraction between the base code and the modules, and
between the base code and the user interface. Part of the redesign of
Slicer3 will focus on increasing modularity, reusability, and
abstraction. In the context of NA-MIC, we also are increasing
modularity between the Cores. Figure~\ref{fig:sample} shows the
relationship of the NA-MIC Cores to the technical components of
Slicer3. The NA-MIC Algorithms Core will develop algorithms for the
analysis and visualization of medical image data. The Engineering
Core will establish software architectures and software processes that
will empower the Algorithms Core developers to create robust,
well-designed software and interfaces. Algorithms will be implemented
using ITK so they can be used both in Slicer and in other software.
ITKu is currently being developed as a command line interface to ITK
so that algorithms implemented using ITK can be used in a batch
processing fashion and take advantage of the computational resources
of the LONI pipeline.
VTK will be used to provide the visualization of the results generated
by the ITK code and to support interactive steering of algorithms.
The visualization code will be used by both Slicer3 as well as any
other non-Slicer VTK applications which want to use ITK algorithms.
Slicer3 provides a desktop application for end users, who use
computational tools for the quantitative analysis and visualization of
MRI, Diffusion Tensor Imaging (DTI) and fMRI, to further understanding
of brain abnormalities in schizophrenia and other brain diseases.
Slicer3 will be able to run with just the base code, with a subset of
all available Slicer modules, or with all Slicer modules, as the
researchers see fit. Developing modules so that they can be run
independently of the Slicer base code also allows batch processing of
module functionality.
\begin{figure}[tb]
\begin{center}
\begin{tabular}{ccc}
\includegraphics[height=10cm,width=13cm] {fig1}
\end{tabular}
\caption{
Relationships of Slicer3 technical components.
}
\label{fig:sample}
\end{center}
\end{figure}
%\begin{figure}[tb]
% \begin{center}
% % \begin{tabular}{ccc}
% \includegraphics[height=10cm,width=10cm] {slide}
% % \end{tabular}
% \caption{
% ppt slide
% }
% \label{fig:sample}
% \end{center}
%\end{figure}
\subsubsection{Code Structure Goal}
In Slicer3, we intend to redefine the definition of a Slicer module so
that each module can run as a stand alone library, a discrete testable
unit, an executable external to Slicer (i.e. through a script or at
the command line), and has the ability to reuse object-oriented module
functionality outside of Slicer. Each module in Slicer should be able
to run independently of other Slicer modules; with the Slicer Base
alone, or with a subset of available modules.
\subsubsection{MRML}
Currently, a Tcl script (Parse.tcl) handles MRML tree parsing. In
Slicer3, MRML will be a stand alone library for parsing, reading, and
writing MRML trees. The vtkMRMLTree class will read (parse) as well
as write MRML trees. A MRML node is an XML description of data on
disk or other scene information. A node handling mechanism will be
implemented so that each node will know about their children and
parents, and each node will receive a MRML version number from the
parser. Each node can construct itself based on a string from the
parser.
The MRML node code will be made available in a module directory.
There will be a separate CMake method to compile a single external
library for MRML use outside of slicer. Other possible MRML
extensions include more general hierarchies of attributes (like
transforms) to handle colors, etc. and a vtkMRMLTree manager objects
to crawl the MRML tree.
\subsubsection{MRML Data access}
The MRML tree is an in-memory representation of the XML file. In
Slicer3, all modules will edit the scene through MRML calls, and will
create and manage their own MRML nodes. Modules will be able to
access data from other modules only by going through the MRML tree.
MRML nodes will have a GetData function that returns a pointer to a
node-specific object type that can read and write the data. This will
replace the current use of Tcl lists of object IDs. Modules will take
a MRML tree as input. In the future, a module may take multiple trees
as input. Treating the module as an object will enable us to work
around our current limitation of only having one instance of a module
run at once.
\subsubsection{UI/Visualization}
Currently, the UI and visualization aspects of Slicer2 are closely
integrated with the data and scene description. In Slicer3, we hope
to separate the data/MRML layer from the UI and visualization layer.
To accomplish this, anything that will be persistent in MRML scene
description needs to be modified through methods in the MRML nodes.
For example, during image segmentation, any labelmap changes must
notify the corresponding MRML node that the object is unsaved through
a data dirty flag. When the MRML file is written, it can also write a
data file if needed.
By developing reusable widgets that interact with the MRML tree, we
hope to lessen the burden on the developer when writing new Slicer
modules.
\subsection{Possible UI Candidate Technologies}
\subsubsection{KWWidgets}
Kitware has developed KWWidgets for a number of years and used it as
part of their commercial VolView
%\cite{VolView}
product and their large open source ParaView
%\cite{ParaView}
project. KWWidgets runs on a wide variety of platforms, and has a
compatible open source license.
KWWidgets has a programming interface similar to that of VTK, which is
already familiar to many Slicer developers. The class structures are
clean, object-oriented, and usable directly from C++ programs. In
addition, the code is wrappable for use in Python, Tcl, or Java
programs.
Internally, KWWidgets uses Tk event management so it can co-exist with
the existing Slicer UI during transition from Slicer2 to Slicer 3.0.
ParaView currently has a KWWidgets-based ``trace'' mode to store GUI
interactions which facilitate batch testing and demos. We would like
to implement similar functionality in Slicer, and this code might be
partially reusable for this purpose.
Before and during the programming retreat in Boston, preparatory work
was completed to extract KWWidgets from Paraview/VTK dependencies, to
create a library build system, an application framework for testing,
and experimental compilation against the current cvs versions of VTK
and Slicer.
Work still to be done with KWWidgets includes gaining more practical
experience with KWWidgets usage and prototype development, as well as
collecting Slicer3 design requirements for NA-MIC custom widgets and
class hierarchy. In addition, we intend to develop a straw man
application framework based on KWWidgets and identify steps for
migrating current Slicer modules and functionality into the new
framework.
\subsubsection{Qt}
Qt is a user interface package which deserves consideration due to its
widespread international acceptance, and significant developer
familiarity. Qt is also currently available, so key features of the
GUI toolkit wouldn't need to be implemented before GUI development can
begin. However, without a per-developer license purchase, code
developed using Qt is GPL, which is problematic for reasons described
in section 3.4. While the purchase of per-developer Qt licenses would
provide a supported GUI toolkit with many of the benefits of
KWWidgets, we do not want to limit our base of potential developers to
only those who have the resources to maintain active developer license
to Qt.
\subsubsection{Other UI Options}
Other UI options that continue to be explored include Python
MegaWidgets, FLTK, and wxWidgets.
\subsection{Additional Technology Options}
\subsubsection{VTK 3D Widgets}
Another option considered for the Slicer3 UI is VTK 3D Widgets. The
community is actively implementing 3D widgets that allow interactive
data/object manipulation in the 3D environment (some of this work is
sponsored by Dr. Terry Yoo, NLM under A2D2 RFP). The community is
encouraging feedback for new widgets.
\subsubsection{Possible Large Data / Client Server Technologies}
An extension of the Slicer3 architecture could include large data and
client server technologies. One technology we would like to integrate
with Slicer is the LONI Pipeline, which would provide users with a
batch interface to large computational resources.
\subsubsection{ParaView Server Manager}
We would also like to interface ParaView technology with Slicer to
take advantage of its extremely large data handling capabilities in
distributed, parallel computing environments (demonstrated on petabyte
size data on 2048 processors at Los Alamos). Both the GUI and access
to VTK can be described (at run time) via XML. Implementing similar
functionality in Slicer would allow end users to work with much larger
and more complex data sets than they are currently able.
\subsubsection{Spatial Object Hierarchies and Visualizers}
We are experimenting with the idea of ITK spatial objects, and spatial
object visualizers.
%Previous work~\cite{Test2005} showed.
%Figure~\ref{fig:sample} demonstrates our new results.
%\begin{figure}[tb]
% \begin{center}
% \begin{tabular}{ccc}
% \includegraphics[height=1.2in,width=1cm] {fig1} &
% \includegraphics[height=1.2in,width=10mm] {fig2} &
% \includegraphics[height=1.2in,width=1in] {fig3}
% \end{tabular}
% \caption{
% Illustration of xxx.
% }
% \label{fig:sample}
% \end{center}
%\end{figure}
\section{Discussion}
\label{sec:discussion}
\subsection{Future Steps}
Design discussions about the Slicer3 architecture are ongoing. Slicer
developer's meetings, weekly teleconferences, the NA-MIC Wiki, Slicer
and NA-MIC mailing lists, and the January NA-MIC programming week are
all important venues for developers and users to keep up to date on
the process and give input.
As Slicer3 is developed, we intend to continue to release bug fixes
and minor feature enhancements to the Slicer2 user community, while
developing new functionality to be compatible with Slicer3.
Continuing NA-MIC workshops and dissemination events provide us with a
constant flow of feedback on Slicer2, as well as feature requests for
Slicer3.
\subsubsection{UI Bake-Off}
The next major design decision we intend to make is to decide on an
appropriate user interface tool for Slicer3. This will be decided in
a programmer's ``Bake-Off'', in which Slicer developers will each take
a UI technology such as python MegaWidgets and KWWidgets and design a
small mock up. The code and finished product will be presented to and
discussed by the rest of the Slicer developers, with attention paid to
ease of use, cleanliness, and reusability in order to choose the right
UI tool for Slicer3.
\section{Conclusion}
We are currently evaluating a diverse set of user and developer
requirements to facilitate development of an updated, more modular
version of the 3D Slicer software. Slicer3 is being developed by
building on the current strengths of Slicer2, while looking to the
future to anticipate user's needs. In association with NA-MIC, we
hope to gain a wider developer and user base, and provide a robust
open-source application to the medical and computer science
communities.
%\cite{Gering2001}\cite{NA-MIC.org}\cite{ProgWeekSlicer3.0}\cite{Core2Doc}\cite{KikinisIntro}\cite{ProgWeek}\cite{WikiMain}\cite{Licensing}\cite{LicensingInst}
\bibliographystyle{splncs}
%\bibliography{slicer3}
\end{document}
