View source for Engineering:ISCPaper

 <nowiki>
 
 % 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}
 
 </nowiki>