Slicer/Features/Modules - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T17:04:21Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Marianna: Protected "Slicer/Features/Modules" [edit=sysop:move=sysop]

2008-05-22T16:05:08Z

Protected "Slicer/Features/Modules" [edit=sysop:move=sysop]

Marianna: Unprotected "Slicer/Features/Modules"

2008-05-19T16:21:30Z

Unprotected "Slicer/Features/Modules"

Marianna: Replacing page with ''''Note:''' We are migrating this content to the slicer.org domain - The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer/Features/Mod...'

2008-05-19T16:21:23Z

Replacing page with '<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer/Features/Mod...'

Csoma at 20:42, 13 December 2007

2007-12-13T20:42:39Z

Csoma at 19:18, 13 December 2007

2007-12-13T19:18:09Z

Csoma: /* December 13, 2007 */

2007-12-13T18:51:55Z

December 13, 2007

Csoma at 18:06, 13 December 2007

2007-12-13T18:06:39Z

Csoma at 18:03, 13 December 2007

2007-12-13T18:03:11Z

Csoma at 18:01, 13 December 2007

2007-12-13T18:01:55Z

← Older revision		Revision as of 17:04, 10 July 2017
Line 1:		Line 1:
−	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [~~http~~://www.slicer.org/~~slicerWiki/index.php~~/Slicer/Features/Modules here]</font></big>	+	<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>

← Older revision		Revision as of 16:21, 19 May 2008
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 [http://www.slicer.org/slicerWiki/index.php/Slicer/Features/Modules here]</font></big>
−
−	~~=Title=~~
−	~~Slicer modules: base and plugins~~
−
−	~~=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]]

← Older revision		Revision as of 20:42, 13 December 2007
Line 2:		Line 2:

	=Title=		=Title=
		+	Slicer modules: base and plugins

	=Names=		=Names=

← Older revision		Revision as of 19:18, 13 December 2007
Line 1:		Line 1:
		+	<< [[Slicer/Features]]
		+
	=Title=		=Title=

@@ Line 16: / Line 16: @@
 * 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.
+* 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?
@@ Line 25: / Line 25: @@
 * 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?
+* 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

← Older revision	Revision as of 16:05, 22 May 2008
(No difference)

@@ Line 113: / Line 113: @@
 Base:
-* Tracker
+* Tracker support
 * Image I/O
-* Logging and replay (with accelerated replay for recovery after a crash) - Scene Scripting can be used
+* 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.
 Module/function dependency

@@ Line 116: / Line 116: @@
 * Image I/O
 * Logging and replay - accelerated replay for recovery after a crash
 == Decision: Base or Module ==