Difference between revisions of "Slicer/Features/Modules"
From NAMIC Wiki
Line 115: | Line 115: | ||
* Tracker | * Tracker | ||
* Image I/O | * Image I/O | ||
+ | * Logging and replay - accelerated replay for recovery after a crash | ||
== Decision: Base or Module == | == Decision: Base or Module == |
Revision as of 17:59, 13 December 2007
Home < Slicer < Features < ModulesContents
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