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

Base:
* Tracker
* Image I/O
* Logging and replay (with accelerated replay for recovery after a crash) - Scene Scripting can be used

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=
* [[2007_December_Slicer_IGT_Programming#Plug-in_mechanism]]