Leadership:SlicerIGT 2007 - Revision history

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

2017-07-10T16:59:50Z

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

Melonakos at 18:44, 6 November 2008

2008-11-06T18:44:57Z

Dgobbi: /* Gabor */

2007-10-18T17:28:54Z

Gabor

Dgobbi: /* David */

2007-10-18T17:28:07Z

David

Dgobbi: /* October 18 */

2007-10-18T17:27:49Z

October 18

Dgobbi: /* October 18 */

2007-10-18T17:14:35Z

October 18

Dgobbi: /* October 18 */

2007-10-18T17:13:49Z

October 18

Dgobbi: /* October 18 - Switch order bottom-to-top */

2007-10-18T17:12:57Z

October 18 - Switch order bottom-to-top

Csoma: /* October 18 */

2007-10-18T15:14:25Z

October 18

Csoma: /* October 18 */

2007-10-18T15:12:52Z

October 18

@@ Line 9: / Line 9: @@
 I want to get back to the architectural issue of the modules, however. For reference, this link describes the way that non-CLI modules are currently implemented in Slicer3:
-[http://www.slicer.org/slicerWiki/index.php/Slicer3:How_to_implement_an_Interactive_Module_GUI#Build_Support Slicer3:How_to_implement_an_Interactive_Module_GUI]
+[https://www.slicer.org/wiki/Slicer3:How_to_implement_an_Interactive_Module_GUI#Build_Support Slicer3:How_to_implement_an_Interactive_Module_GUI]
 The included instructions for module developers say to add the module initialization code to Slicer3.cxx.  From an architectural standpoint, this has to change, and I'm sure that it was always intended that these modules would be initialized in a cleaner fashion.

@@ Line 9: / Line 9: @@
 I want to get back to the architectural issue of the modules, however. For reference, this link describes the way that non-CLI modules are currently implemented in Slicer3:
-[[Slicer3:How_to_implement_an_Interactive_Module_GUI]]
+[http://www.slicer.org/slicerWiki/index.php/Slicer3:How_to_implement_an_Interactive_Module_GUI#Build_Support Slicer3:How_to_implement_an_Interactive_Module_GUI]
 The included instructions for module developers say to add the module initialization code to Slicer3.cxx.  From an architectural standpoint, this has to change, and I'm sure that it was always intended that these modules would be initialized in a cleaner fashion.

@@ Line 14: / Line 14: @@
 ==Gabor==
 Right: Slicer must support both uses. I want both uses, but never at the
 same time. The Swiss knife should never appear in the OR in a clinical

@@ Line 9: / Line 9: @@
 I want to get back to the architectural issue of the modules, however. For reference, this link describes the way that non-CLI modules are currently implemented in Slicer3:
-[http://wiki.na-mic.org/Wiki/index.php/Slicer3:How_to_implement_an_Interactive_Module_GUI]
+[[Slicer3:How_to_implement_an_Interactive_Module_GUI]]
 The included instructions for module developers say to add the module initialization code to Slicer3.cxx.  From an architectural standpoint, this has to change, and I'm sure that it was always intended that these modules would be initialized in a cleaner fashion.

@@ Line 1: / Line 1: @@
 This is a discussion about the requirements for Slicer for IGT. The blog is in reverse chronological order, most recent on top.
 =October 18=
 ==Gabor==

← Older revision		Revision as of 17:13, 18 October 2007
Line 6:		Line 6:

	If you have dynamic modules, just like Photoshop plugins, you can load any module run time, including filters.		If you have dynamic modules, just like Photoshop plugins, you can load any module run time, including filters.
		+
		+	==Will==
		+	10:42AM
		+
		+	Noby brings up a good point. However, I think there are two somewhat conflicting uses: 1) as a research platform and 2) as a deployment vehicle. For research, flexibility is imperative. For focused delivery of a medical therapy (or in support of a therapy) the API and application should be finely tuned, simple and hardened. I think we want to create the framework in Slicer so that we can support both uses.
		+	Will

	==Noby==		==Noby==

@@ Line 1: / Line 1: @@
 This is a discussion about the requirements for Slicer for IGT. The blog is in reverse chronological order, most recent on top.
 =October 18=
-I agree with you. That is exactly the issue that we are talking about.
+==Csaba==
-If the gentleman from Synarch feels that he needs a trimmed down and locked down version for a clinical trial, there is nothing in our license that would prevent him from doing that. He will have to do whatever maintenance that is needed for his special version.
+The result was beautiful and surgeon could comprehend the thermal map better. We did a follow up analysis and found that filter only preserved the true thermal map while removing noises.
-However, for the NA-MIC funded work, I think that it is critical, that we have only one Slicer. I am not opposed to have an initial presentation that does not expose all of Slicer and the layout mechanism could be expanded to support this.
+My point is there is a benefit of Slicer being swiss army knife with both IGT  and medical image processing tools attached together. It actually functions as the bridging mechanism between IGT and medical image processing. Concealing "non-IGT" tool had downside of it and let us be blind to opportunity.
 ==Csaba==
@@ Line 22: / Line 30: @@
 If a module can't be made dynamic, we could have a CMake option to turn it on or off before compiling.
-==Noby==
+==Ron==
-:22AM
+:29AM
-Let me be a devil's advocate based on my real experience...
+I agree with you. That is exactly the issue that we are talking about.
-I was in MR/T operating Slicer for MR-guided ablation of brain tumor. We showed MR thermal map to the surgeons for them to assess the effect of ablation, but they complained it was the thermal map was noisy very difficult to comprehend.  During a short break (2-3 minute), I browsed what was available in Slicer for image smoothing and found anisotropic diffusion filter, I believe, originally developed for vessel segmentation.
+If the gentleman from Synarch feels that he needs a trimmed down and locked down version for a clinical trial, there is nothing in our license that would prevent him from doing that. He will have to do whatever maintenance that is needed for his special version.
-If you have dynamic modules, just like Photoshop plugins, you can load any module run time, including filters.
+However, for the NA-MIC funded work, I think that it is critical, that we have only one Slicer. I am not opposed to have an initial presentation that does not expose all of Slicer and the layout mechanism could be expanded to support this.
 =October 15=