AHM 2007:Slicer3 Developer Feedback

From NAMIC Wiki
Revision as of 04:18, 7 January 2007 by Davisb (talk | contribs) (→‎Feedback)
Jump to: navigation, search
Home < 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

DTI Module: Raul San Jose

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

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

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
  • 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...
  • 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?
  • How to specify module dependency
  • README.txt to add a module
  • What we can do and cannot do with a command line module
Retrieved from "https://www.na-mic.org/w/index.php?title=AHM_2007:Slicer3_Developer_Feedback&oldid=5854"