110 likes | 305 Views
Slicer 3. Ron Kikinis, Steve Pieper. Slicer Goals. Stable, Usable, Cross Platform, End-User Software for Medical Image Analysis 3D Slicer Role in NA-MIC and NCIGT Translation Platform to Deliver Medical Computing Technology to DBP Researchers
E N D
Slicer 3 Ron Kikinis, Steve Pieper
Slicer Goals • Stable, Usable, Cross Platform, End-User Software for Medical Image Analysis • 3D Slicer Role in NA-MIC and NCIGT • Translation Platform to Deliver Medical Computing Technology to DBP Researchers • Provide Reference Implementation using NA-MIC Kit (End-to-End Open Source) • Outreach to New Applications
3D Slicer Nutshell • 3D Slicer Version 3 work began in 2005, first code 2006 • Multi-platform, Using Kitware software engineering methodology • Includes by now 11 packages and toolkits (ITK, VTK, Python, Tcl/Tk, KWWidgets, IGSTK, ….) • Layered modular architecture: trunk, loadable modules, plug-ins • Support for external plug-ins from a repository
Progress Since Jan 2009 • Numbers June 2009 • Subversion Commits: 9,732 (1,415) • Lines of Code*: 791,101 • Bugs & Features: • 605 Submitted • 323 Fixed • Active Developers†: 59 • 3D Slicer Version 3.4 • Released May 2009 *: find . -iname \*.h -o -iname \*.cxx -o -iname \*.tcl -o -iname \*.java -o -name \*.py | grep -v svn | xargs wc (does not include libraries or modules in external repositories) †: svn log | grep "^r" | cut -d " " -f 3 | sort | uniq | wc • Numbers Jan 2009 • Subversion Commits: 8,317 • Lines of Code*: 735,536 • Bugs & Features: • 239 Submitted • 129 Fixed • Active Developers†: 53 • 3D Slicer Version 3.2 • Released August 8, 2008
Focus of 3D Slicer Development • Analysis and display of medical image data from single subjects: • Complex visualization capabilities; Real Time data • Segmentation and registration, DTI, DCE, Changetracking, mesh generation • FOSS without restrictions (BSD-style) • Useability • Workflows • Open source PACS + Clinical Database (XNAT)
Roadmap • Next 12 months • Improved loading interface • Improvements to EM Segmentation • Improvements to Registration • Annotation and Markup capabilities • Workflow engine • Port to QT (now possible because of license change) • Full roundtrip capabilities with XNAT enterprise • Beyond 12 months • Will write a competitive renewal of NA-MIC • Widen focus to applications and solutions: neuro, cardiovascular, cancer, IGT, biology
Dreams • Long term vision • To build more and more robust solutions for biomedical research • Provide an easy to use plug-in interface to attract third party development
Open-source status and activities • Source code availability: SVN open for checkouts, write access controlled, currently 50+ developers • License model: BSD-style license • Public process: • feature planning: professional core engineering, open weekly tcons, twice a year weeklong project weeks, ad hoc in person meetings • bug tracking: mantis bugtracker, regular bug squashing efforts • testing: Kitware methodology: cmake, ctest, cpack • Contributions: • all comers accepted, emerging plugin infrastructure will remove needs for “policing” • Community • ...
Open-source status and activities • Community • Core funding by NIH center grants: NA-MIC, NAC, NCIGT, Catalyst • Algorithms, Engineering, Driving Biological Projects • Collaborations with funding component for core (currently about 8) • Other collaborations • Regular “Project Weeks” (twice a year since June 2005) • Last week at MIT: 125 participants, 71 projects • Segmentation, Registration, Diffusion, IGT, Informatics… • GE, Siemens, INRIA, Kitware, Harvard, MIT, UNC, UCLA, NCI…
What's most important for a common platform / toolkit? • Developers • Flat learning curve • Provide attractive infrastructure • Multi platform support • FOSS • Robust I/O • End Users • Flat learning curve • UIs for beginners and experts • Solve problems they care about • Large portfolio of solutions to be attractive to a large number of end users
How could a collaboration look like? Possible ways of collaboration (from loose to tight): • Regular workshops • Defined interfaces as in DICOM • Bridges between existing toolkits on different levels: • Data level: file-based exchange, inter-process communication, ... • Code level: adapter classes, common base classes, ... • “Common Toolkit”, composed from existing toolkits • “Common Toolkit”, implemented from scratch