Slicer/Features/Modules

<< Slicer/Features

Title

Slicer modules: base and plugins

Names

• session leader

• participants

Discussion

December 13, 2007

• David Gobbi: Option to turn off modules for OR
• Steve Pieper: Needs refactoring so it will be as flexible as Slicer 2 (runtime). Slicer 3 is cMake based (pre-compilation). I would prefer run-time dynamic. This would allow distributing modules independent of the base.
• Louis Ibanez: The benefit would be a standard Slicer for everybody. How about testing?
• Peter Kazanzides: It's the user's responsibility to make it sure it was tested before going to OR
• David: and turn off the loading of modules at startup.
• Louis: Versioning?
• Stephen Aylward: It's useful to have this versioning, for ex. VTK/ITK.
• Steve P.: The nightly build should build the modules also, and test them together.
• Csaba Csoma: So we all agree that dynamic modules is a good thing. Question: what is module, what is basic functionality?
• Steve P: Base Features vs. Modules. Csaba's right, we should make for ex. Diffusion Imaging modular, because it's pretty specific.
• Noby Hata: There are classes that can go only to base, like tracker?
• Steve P: Theoretically we can make it generic enough. Should the concept of tracker be a base, or just the transform?
• Steve A: Can a module bring in any library?
• Steve P: Yes. The base can't depend on Matlab, but a module can.
• Steve P: Static modules are restrictive, because you can't extend for ex. for full VTK/ITK library if you have a limited one compiled in.
• Sebastien Barre: Start up time?
• Steve P: Might not be affected.
• Liver RF 2D point of view (see next section): the functionality is in VTK, needs work to be exposed by Slicer
• Steve P / Noby H.: Tracked view point (each slice or for the 3slice view)
• Steve A: Record pre-selected views and bring it up easily when needed
• Noby: make sure the base does not rely on any module
• (Non trivial case: Dynamic MRML node, dynamic based on representation in the space - geometry changes as you move it through the space)
• Peter: we use different size of cutters
• Steve P: that can be on module level
• David: how easy can a module use other modules
• Steve P: dependency can be handled. The library dependency build process should be sequenced.
• Csaba: make sure we talk about libraries, GUI is just a type of library/module
• Steve P: Load Data is generic enough to be a module?
• David: Not necessarily. A module can do it, so you don't necessarily had to have a generic one.
• Noby: How about invisible Modules or even Base elements?
• All: Yes, it's an important thing to do
• Steve P: recording / playback / logging of procedure sounds like base function
• Steve P: required by IGT: login - can go to the base

Liver RF

• Slicing class (orthogonal)
• Base: RT imaging class / image source
• Load data / save result / recording
• Base: Visualization: 2D view of oblique slices - arbitrary point of view
• Dependent on transform modules / different trackers can be used - separate from RF ablation module

Post processing:

• Volume Rendering
• Access to more modules

Which part is already in Slicer

• There's a plan to implement a flexible/dynamic module system, no real work done yet

Who among us will take leading role?

Function list

Proposed:

Features	Base	Module
Visualization	MRML, Arbitary ViewPoint (Pre-defined)	Liver RF
Filtering	None	Command Line Module
IGT	Intra-op Image I/O	Liver RF
Registration	Transform Display, Edit and Save/Resotre	Calculae Transforms, Resample Data
Segmentation	Label Maps, Parcellated Surface	Segmentation Algorighms
Quantification	Label, Image, Volume Statistics; Numpy access to MRML	Applications in Python or MATLAB
Real-time Integration	VTK Rendering, KWWidgets framework, Tracker Support (as Transforms)	Direct Manipulation of the MRL Scene; 2D/3D Widgets; Device Interface
Diffusion Imaging	DWI, DTI, Fiber Bundles	Tractography, Clustering, Atlases
Application	Bundles of Modules in Distribution: Registration Editor, some Filters	Customized Extensions, Domain specific code, optimized Interface

Base:

• Tracker support
• Image I/O
• Logging and replay (with accelerated replay for recovery after a crash) - Scene Scripting can be used, which is based on undo/redo mechanism (delta over time). Extension: checkpoint slides.
• Support for Stereo modules

Module/function dependency

• Tracker I/O (BWH Hata)
  • Tracker On/Off
• Real-Image I/O (BWH Hata)
  • Video capturing
  • Simple loading image
  • Imager control for each modality
    • MRI (NCIGT Tokuda)
• Image re-slicing based on tracker (BWH Hata Liu)
• GUI configuration control (XXX)
• Human interface control
  • Foot pedal (BWH Liu)
• Stereo
• Output to outside display
• Logging replay and saving
  • IGSTK has fast version
  • MRML scene recorder (Georgetown)

Links

• 2007_December_Slicer_IGT_Programming#Plug-in_mechanism