Slicer4

Back to Slicer 4 Developers

Overview

Slicer4 (officially 3D Slicer version 4) will be the next big development in the history of the 3D Slicer project. It's also an opportunity to adopt some new programming styles and break with a few past traditions. Overall though it should maintain the same spirit as earlier versions of slicer in a more modern wrapper.

Main Features

(Note that things will evolve as the project progresses).

• The biggest and most visible change is the outgrowth of the port of Slicer's GUI from KWWidgets to Qt. This is the outgrowth of a much consideration and research.
• Increased focus on python as the main scripting interface
• Use of CMake external project feature (a.k.a. SuperBuild) as default build method
• Move from subversion repository to git
  • During the spring/summer of 2010 both repositories will exist in parallel. During summer of 2010 code from the subversion repository will be migrated into git (retaining all revision history). See the Slicer4 git transition page for details as they are defined.
  • Currently github is hosting the git repository, but it may move to another host in the future within the slicer.org domain
• Much of the infrastructure for the GUI, DICOM support, and other fundamental library support will be developed jointly with the Common Toolkit (CTK) group.
• Increased emphasis on code coverage, testing, and documentation.

Plan

• During April and May 2010 a majority of slicer developers will be working on the Slicer 3.6 release. While 3.6 is being debugged, potentially disruptive code changes (like changes to MRML to support Qt widgets) should be added to the Slicer4 svn branch
• Tutorials and breakout sessions will be held at the Summer Project Week in June.
• Bulk of developer effort will switch to Slicer4 during the last half of 2010
• 3D Slicer version 4.0 release date: TBD

Considerations for Developers

• Build Instructions: SuperBuild is the evolution of getbuildtest.tcl and genlib.tcl (but with a cooler name!)
• Slicer 3.6 will be the last KWWidgets based release so all interfaces will need to be ported to Qt. Training and support will be provided to make this as painless as possible.
• Command Line Modules do not need to change
• Code in Libs and Base/Logic do not link to KWWidgets and do not need to change
• Tcl code is expected to run alongside Python code in Slicer4 in a similar manner to the way Python and Tcl coexist in Slicer3

Sponsorship and Participation

Major support for this effort comes from developers funded by the US National Institutes of Health through the National Alliance for Medical Image Computing, the Neuroimage Analysis Center, the National Center for Image Guided Therapy, and related collaborating efforts. Additional involvement from the research and commercial communities is also welcome and appreciated.

FAQ

What do I gain from the switch to Qt?

• Performance, performance, performance.
  • Qt is more optimized than KW widgets
• Community, Community, Community!
  • There's an emerging trend in the research community to adopt Qt as the de facto standard interface. This means a lot of momentum and code sharing, so slicer developers can spend more time and effort performing actual medical image computing research.
• Better support for integration on the different platforms (e.g. no need for X11 on Mac)
• Webkit will allow better integration of webcontent

Didn't we just make a big change from Slicer2 to Slicer3 just a few years ago? Why should we change again?

• Constant re-invention is the nature of research. Slicer3 has served us very well, and we expect the 3.6 release to be stable and in-use for several years. Where the transition from 2->3 was about an 80% rewrite, the transition from 3->4 is expected to be concentrated primarily on the GUI.

Oh no, not another source code repository. What's wrong with svn and why should we use git?

• Similar to Qt, git has become a widely adopted standard. It is used for CMake and now for VTK.
• Here's a good rationale for git and a set of links to git resources to help you get comfortable.
• For people who really like subversion tools, you can now access a git repository as if it were an svn repository

I like Tcl - why emphasize python?

• This is another de facto standard, just like Qt and git - there's a lot of activity that we'd like to leverage like NiPy. In a lot of ways, our experience with slicer3 has been that tcl and python are really very similar. The way python is integrated in slicer3 proves that the two languages can co-exist and both can fill the need for runtime programmability.

Additional Goals for Slicer4

• Repository
  • Development history from svn will be migrated to git
  • Remove large binary datasets from repository and instead host them on midas or other web site for download during testing.
  • Adopt 'best practices' for keeping repository organized (use 'topic forks' for developing new code and selectively merge this to the main line of development).

• Modularity
  • Promote some 'Libs' code to have better utility outside of slicer. Examples such as vtkITK, MRML, and the execution model may be useful in many other programs. Consider migrating to CTK or hosting independent respository.
  • Remove some older modules from default build (make them optional or convert to extensions).