|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | << [[Slicer/Features]] | + | <big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer/Features/Modules here]</font></big> |
| − | | |
| − | =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?
| |
| − | * 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
| |
| − | | |
| − | == 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 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)
| |
| − | | |
| − | | |
| − | == Decision: Base or Module ==
| |
| − | | |
| − | == Implementation ==
| |
| − | | |
| − | | |
| − | =Links=
| |
| − | * [[2007_December_Slicer_IGT_Programming#Plug-in_mechanism]]
| |
