From Slicer Wiki
Jump to: navigation, search
Home < Slicer4

Back to Slicer 4 Developers


Slicer4 (officially 3D Slicer version 4) is 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).


  • Work on a patch release called Slicer 3.6.3 has resulted in a release in March of 2011. While 3.6 is i the final stages of being debugged, potentially disruptive code changes (like changes to MRML to support Qt widgets) should be added to the Slicer4 svn branch
  • Bulk of the core developer effort has switched to Slicer4 by early 2011
  • 3D Slicer version 4.0 release date: Jan 2012
  • ITKv4 Migration plan

Considerations for Developers

  • Getting Started With Slicer4 Development
  • Build Instructions using SuperBuild, the evolution of getbuildtest.tcl and genlib.tcl (but with a cooler name!)
  • Debug Instructions
  • 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
  • Instruction explaining how to setup a dashboard are available here

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.


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?

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).