AHM 2007:Slicer3 Developer Feedback

Back to AHM_2007#Wednesday.2C_Jan_10_2007:Project_Activities

Topics for this session:

• Information to the developer community about how these projects have approached developing their code for slicer3 (what's the architecture of their modules)
• Feedback to the base developers about what was easy or hard in the code writing
• What would they like to see in the slicer3 base and/or in VTK, ITK, KKWidgets, etc to make the module development more effective

DTI

Tractography Module: Lauren O'Donnell

Module Architecture

• Tractography is represented as a vtkMRMLFiberBundleNode. Display parameters are stored in a vtkMRMLFiberBundleDisplayNode, and storage (load/save) handled by vtkMRMLFiberBundleStorageNode. Basic operations of adding new fiber bundles, etc. are in vtkMRMLFiberBundleLogic.
• vtkMRMLFiberBundleDisplayLogic is needed to create "hidden" slicer models that will be rendered in the MRML scene. Otherwise base classes would have to be heavily edited to handle tractography display using the display node.
• There will be several slicer module units to handle tractography. The division will be by Load/Save/Display, Editing (to manually add, select, delete, or to use ROI selection), Seeding, etc.
• Initial work is on the Load/Save/Display and the entire MRML infrastructure.

Feedback on Slicer3

• When adding a new module and a new datatype, it is difficult to find the places in Base code that must be edited.
• It is also difficult to understand how the MRML callback happens, and how to set a new one up. It would be great to have a simple overview on the observers somewhere (or even the SVN web for easier code navigation).
• If a vtkMRMLNode inherits from another one used in slicer (for example mine inherits from the modelNode currently) then the subclass will show up on all of the superclass menus. This is because the vtk "IsA" function is used rather than a direct match. I believe this is feature that is not desired.

What I would like in Slicer3 base...

• More documentation, comments, etc.

EM

Primary Developers

Yumin Yuan, Sebastien Barre, Brad Davis

Module Description

The following description is from the project wiki page:

The goal of this project is the creation of a module in Slicer 3 integrating the EMSegment algorithm (Pohl et al.), an automatic segmentation algorithm for medical images that previously existed in Slicer 2. As in Slicer 2, the user is able to adjust the algorithm to a variety of imaging protocols as well as anatomical structures and run the segmenter on large data set. However, the configuration of the algorithm is greatly simplified in Slicer 3 as the user is guided by a work flow. The target audience for this module is someone familiar with brain atlases and tissue labels, not a computer scientist.

As of January 1, 2007, the EMSegment module is substantially complete and has been checked into the Slicer3 SVN repository. It was previewed at the December 2006 NAMIC meeting in Clifton Park and will be a demonstration at the NAMIC All-Hands meeting in Salt Lake City on Wednesday 10 January 2007. Future work includes adding advanced and experimental algorithm parameters, improving visualization of parameter settings, and incorporating tissue labels from a controlled vocabulary.

Architecture

The module is implemented as a programmatic Slicer3 module because it requires a large degree of interaction with the user, the data stored in the MRML tree, and the Slicer3 GUI itself. Because the MRML node structure is rather complicated (for example the anatomical tissue hierarchy and a large number of interdependent nodes) the Logic class is solely responsible for maintaining and accessing these nodes. The Logic class provides an API that the GUI code uses to access and modify data. The Logic class also wraps the algorithm code itself.

• the parameters for the algorithm are stored in a number of MRML nodes:
  • EMSGlobalParametersNode (global algorithm parameters)
  • EMSTreeNode (tree structure for hierarchy of anatomical structures)
  • EMSTreeParametersNode (algorithm parameters assigned to each tree node)
  • EMSAtlasNode (image data and parameters for atlas)
  • EMSTargetNode (image data for target images (to be segmented))
  • EMSVolumeCollectionNode (essentially a hash map of image volumes, used for atlas and target nodes)
  • EMSTemplateNode (collects global parameters and tree structure)
  • EMSSegmenterNode (collectes template and output data)
  • EMSNode (highest level node, reference to EMSegmenterNode and storage location for module specific data)
• the logic is responsible for
  • maintaining and traversing the data in the mrml scene
  • providing an interface for the GUI to access the data
  • providing an interface for the segmentation algorithm

GUI

The EM GUI includes eight steps implemented with KWWidgets and vtkKWWizardWorkflow framework. Each step is written as a single class, derived from a super class vtkEMSegmentStep. All steps are initialized with parameters from the vtkKWEMSegmentLogic class, and once a user interacts with the UI, the new parameters (if there are) will be passed to the logic class immediately.

There is also a brief description of these steps in the project wiki page:

• 1/8 vtkEMSegmentParametersSetStep: Select parameter set or create new parameters

This can be used as a convenient method to reload all the parameters of a previous EM procedure.

• 2/8 vtkEMSegmentAnatomicalStructureStep: Define a hierarchy of anatomical structures

The anatomical structures are represented with a a tree structure using vtkKWTree, which can be directly manipulated to assign attributes to each anatomical structure, such as name, color, etc.

• 3/8 vtkEMSegmentSpatialPriorsStep: Assign atlases for anatomical structures

Again, the same tree structure is used here to assign atlas to each anatomical structure.

• 4/8 vtkEMSegmentIntensityImagesStep: Choose the set of images that will be segmented

The widget used here, vtkKWListBoxToListBoxSelectionEditor, allows selection of images in different orders, which is actually important in following steps.

• 5/8 vtkEMSegmentIntensityDistributionsStep: Define intensity distribution for each anatomical structure

Same tree structure is used for anatomical structures. This step is where EM module is interacting directly with Slicer3 main application, namely the mouse events from vtkSlicerSliceGUI are processed to get sampling intensities and coordinates.

• 6/8 vtkEMSegmentNodeParametersStep: Specify node-based segmentation parameters

There are many KWWidgets used here (vtkKWTree, vtkKWNotebook, vtkKWMultiColumnList, vtkKWEntryWithScale etc), and given the limited UI space we have , it does take some creativity to arrange everything nicely.

• 7/8 vtkEMSegmentRegistrationParametersStep: Specify atlas-to-target registration parameters

A simple step to assign registration parameters.

• 8/8 vtkEMSegmentRunSegmentationStep: Save work and apply EM Algorithm to segment target images

Again, this step has many gui components.

Feedback

• the community was extreemly helpful!
• over all our experience was very positive, but more examples and documentation would be helpful
• used wiki page describing how to build a module---this documentation was helpful
• used GradientAnisotropic module as a template---more examples (and more complicated examples) would be helpful
• we had to write new MRML classes because the slicer2 classes used nested tags and Slicer3 uses references
• could our mrml tree class be generalized for others to use?
• it seems like the creation of most MRML classes could be automated
• it will be very helpful to have a wiki page describing how to observe and process events from main application, such as MRML nodes events, mouse events, progress events etc.

IGT

Blockdiagram of the IGT module

Noby Hata, Haiying Liu, Simon DiMaio and Raimundo Sierra

Hisotory of our involvement

• Summer 2006: Haiying Liu joined the core development team and translated MRAblation module from the Slicer 2.6. There he
  • Learned the architecture of Slicer 3
  • Got familiar with KWWidgets

• Fall 2006: Haiying Liu implemented IGT Demo module. There he
  • Contributed vtkIGTDemoLogic and vtkIGTDemoGUI classes in the Base
  • Added an option for CMake to link the external library OpenTracker

• December 2006: Two additional members joined IGT-Slier3 task force
  • Simon DiMaio representing prostate robot project [PI Tempany1R01CA111288]
  • Raimundo Sierra representing Neuroendoscope project [PI Jolesz 5U41RR019703]

• January 4th, 2007 at 1249 Boylston Office: Implementation strategy for IGT-Slicer has been discussed and preliminary design proposed by Hata and Liu (see the figure at the left)
  • Slicer3/Base/GUI/vtkSlicerIGTGUI: cxx class
    • Creates GUI components for IGT application modules
    • Handles interface update
  • Slicer3/Base/Logic/vtkSlicerIGTLogic: cxx class
    • Processes shared logics for IGT applications, such as handling communication with tracking server
    • Wraps tracker-specific logics
  • Slicer3/Libs/IGT: IGT lib (Place holder classes committed to SVN (NH)
    • Patient to image registration
    • Tool calibration
    • Specific tracker logics
    • Online image I/O
    • Special image processing
    • More...
  • Slicer3/Modules: IGT applications
    • MRAbration
    • Neurosurgery
    • ProstateBiosy
    • More...

Our timeline

• IGT tutorial demo on alpha (done)
• IGT tutorial demo on beta (during AHM week by Liu)
• Neurosurgical navigation with GE Nav (spring to summer)
• Building with IGSTK (during AHM week, by Hata)
• Neurosurgical navigationi with JHU robot (by March)
• Integration to MR/T (fall)

Feedback

• genutiltest.tcl is great!
• Guideline for creating library and modules would be helpful for those joining Slicer community. Template (blank) code may be helpful.
• Don't understand what "NA-MIC sandbox" means...
• It is a bit confusing to request "NA-MIC sandbox" account when you want to create account for "Slicer 3."
• It is nice to have separate account policy for main SVN tree and branches. We want to make our branch relatively open to the IGT community, while the main SVN tree may want to ensure stable release.
• Application-specific customization and streamlining of the GUI will be important for IGT applications. To what extent is this possible?
• Performance bounds are important to understand for IGT applications. Can we talk about determinism and performance as Slicer scales?
• Can we make "lean" Slicer w/o many modules and libraries.
• How to specify module dependency
• README.txt to add a module
• What we can do and cannot do with a command line module