Difference between revisions of "AHM 2007:Slicer3 Developer Feedback"

From NAMIC Wiki
Jump to: navigation, search
Line 42: Line 42:
  
 
===Architecture===
 
===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.
  
 
===Feedback===
 
===Feedback===

Revision as of 03:45, 7 January 2007

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.

Feedback

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 interface
      • 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