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}