Difference between revisions of "Slicer/Features/Modules"

From NAMIC Wiki
Jump to: navigation, search
Line 116: Line 116:
 
* Image I/O
 
* Image I/O
 
* Logging and replay - accelerated replay for recovery after a crash
 
* Logging and replay - accelerated replay for recovery after a crash
 +
 +
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)
 +
  
 
== Decision: Base or Module ==
 
== Decision: Base or Module ==

Revision as of 18:01, 13 December 2007

Home < Slicer < Features < Modules

Title

Names

  • session leader
  • participants

Technology/Function description

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?
  • Steve 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.
  • S 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

Prostate IGT

Potential application in IGT

Which part is already in Slicer

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

What is not

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
  • Image I/O
  • Logging and replay - accelerated replay for recovery after a crash

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)


Decision: Base or Module

Implementation

Links