NAMIC Wiki - User contributions [en]

AHM2009:GUI Testing

2009-01-02T15:07:03Z

Yumin:

Back to [[AHM_2009]]

Breakout session Moderator: Sebastien Barre

Introduction: [http://wiki.na-mic.org/Wiki/index.php/2009_Winter_Project_Week_Automated_GUI_Testing Automatic KWWidgets and Slicer GUI Testing]

Agenda:
* How to create Squish test suites from Squish IDE.
* How to add validation points in Squish tests.
* How to add Squish tests using CMake macros, so that they can be run nightly from ctest.
* Wiki pages of Squish for KWWidgets and Slicer3.
** [http://www.vtk.org/Wiki/KWWidgets/GUI_Testing/Squish/SquishForKWWidgets Squish for KWWidgets].
** [http://www.vtk.org/Wiki/KWWidgets/GUI_Testing/Squish/SquishForSlicer3 Squish for Slicer3].

===References===
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets GUI testing].
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets GUI testing with Squish].

AHM2009:GUI Testing

2008-12-18T06:01:39Z

Yumin:

Back to [[AHM_2009]]

Breakout session Moderator: Sebastien Barre

Introduction: [http://wiki.na-mic.org/Wiki/index.php/2009_Winter_Project_Week_Automated_GUI_Testing Automatic KWWidgets and Slicer GUI Testing]

Agenda:
* How to create Squish test suites from Squish IDE.
* How to add validation points in Squish tests.
* How to add Squish tests using CMake macros, so that they can be run nightly from ctest.
* Squish current known issues with some KWWidgets.
** vtkKWComboBox, vtkKWMenuButton
** Recording a lot of MouseMove events with coordinates, which may not always be reliable.
** Asynchronous handling of mouse events, which is difficult to control of the procedure-flow, so in some cases, manual insert of "wait-some-time" is needed in the script
** RenderWindow mouse move events are recorded and played back TOO MUCH.

* Discussions: tests validation methods.

AHM2009:GUI Testing

2008-12-18T05:53:43Z

Yumin:

2009 Winter Project Week Automated GUI Testing

2008-12-18T05:36:00Z

Yumin: /* Key Investigators */

{|
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]
|[[Image:squish_slicer3.png|thumb|320px|Image showing the end result of a Squish test with the clipbox of a volume in Slicer3]]
|}

__NOTOC__

===Key Investigators===
* Kitware: Sebastien Barre, Yumin Yuan

<div style="margin: 20px;">

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Objective</h1>
An automated GUI testing framework in KWWidgets is definitely on high demand, and the reason is best described by Ron Kikinis:
"The automatic testing capability that kww will enable, appears to me to be more and more important, the more I think about it. As a matter of fact, automatic testing of entire sequences of mouse clicks and keyboard strokes will enable us to move to a different level robustness with slicer 3.0.".

</div>

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Approach, Plan</h1>
Suggestions, discussions and specifications related to this topic are documented in this [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets wiki page].
As described on the wiki, many solutions (freeware and commercial) have been investigated, and currently we think that Squish looks like to be a valid solution for simple tests (or, actually, our only solution). A detailed wiki page about [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets testing with Squish] has been created, and a work-plan is defined:

* Create a CMake module to find Squish on the system (paths to Squish server and Squish runner).
* Create CMake macros that will start/stop the server and run a test by invoking the runner and parsing its output.
* Invoke the Squish module when configuring/building KWWidgets.
* Create CMake macros that will add Squish tests for KWWidgets.
* Create new suites for KWWidgets examples.
* Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example).
* Create new suites for Slicer3.

</div>

<div style="width: 40%; float: left;">

<h1>Progress</h1>

* Create a CMake module to find Squish on the system (paths to Squish server and Squish runner). --- Done by Brad Davis
* Create CMake macros that will start/stop the server and run a test by invoking the runner and parsing its output. --- Done by Brad Davis
* Invoke the Squish module when configuring/building KWWidgets. --- Done
* Create CMake macros that will add Squish tests for KWWidgets. --- In Progress (Need to add validation methods for some tests)
* Create new suites for KWWidgets examples. --- In Progress (Some new Squish test suites are created for all the Cxx examples, but still need to add validation methods to these tests).
* Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example). --- In progress. (Some widgets are not working with Squish currently (Squish bugs), for example, vtkKWComboBox and vtkKWMenuButton. Trying to work with Squish support team to resolve these issues.)
* Create new suites for Slicer3. --- In progress. (A couple simple tests are created, but the test scripts need to be manually massaged quite a bit to make them work.)

</div>

<br style="clear: both;" />

</div>

===References===
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets GUI testing].
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets GUI testing with Squish].

2009 Winter Project Week

2008-12-18T05:35:23Z

Yumin: /* Other NA-MIC Projects */

Back to [[Project Events]], [[AHM_2009]], [[Events]]

==Introduction to NA-MIC Project Week==

Please read an introduction about these events [[Project_Events#Introduction|here]].

== Dates.Venue.Registration ==

Please [[AHM_2009#Dates._Venue._Registration| click here for Dates, Venue, and Registration]] for this event.

== Agenda==

Please [[AHM_2009#Agenda|click here for the agenda for AHM 2009 and Project Week]].

==Projects==
Please note:
*Please use the [[2009_Winter_Project_Week_Template|'''2009 Project Week Template''']] to create a page for your project(s)
*[[2008_Summer_Project_Week#Projects|Last Event's Projects as a reference]]
*For hosting projects, we are planning to make use of the NITRC resources. See [[NA-MIC_and_NITRC | Information about NITRC Collaboration]]
*Next Project Week is at MIT -- June 22-26, 2009
The following is a list of all projects that will be pursued at this meeting.

===NA-MIC DBP Roadmap Projects===
Please note that these projects correspond to four clinical Roadmap application projects that will be pursued in focused parallel tracks at the meeting, each corresponding to a DBP problem.

#[[DBP2:Harvard:Brain_Segmentation_Roadmap|Harvard Roadmap Project: Stochastic Tractography for VCFS]]
##[[2009_Winter_Project_Week:GT_TubularSurfaceSeg|Tubular Surface Segmentation for fiber bundle extraction]] (Vandana Mohan GATech, Allen Tannenbaum GATech, Marek Kubicki BWH, Stephen Aylward Kitware)
##[[2009_Winter_Project_Week_StochasticTractography |Stochastic Tractograhy Tool for Slicer]] (Marek Kubicki BWH, Julien de Siebenthal BWH, Steve Pieper Isomics)
##[[2009_Winter_Project_Week_Slicer3Functioning |Evaluation of basic Slicer 3.0 Functionality from a User Perspective]] (Doug Terry BWH, Marek Kubicki BWH, Sylvain Bouix BWH, Steve Pieper, Wendy Plesniak, Nicole Aucoin)
##[[2009_Winter_Project_Week:DTIGroupAnalysis |Group analysis of DTI fiber bundles]] (Casey Goodlett, Guido Gerig, Marek Kubicki, Sylvain Bouix)
#[[DBP2:UNC:Cortical_Thickness_Roadmap|UNC Roadmap Project: Cortical Thickness Measurement for Autism]]
##[[2009_Winter_Project_Week:LocalCorticalThicknessPipeline|Local Cortical Thickness Pipeline]] (Clement Vachet, Martin Styner, Heather Cody Hazlett, Marc Niethammer, Ipek Oguz)
##[[2009_Winter_Project_Week:RegionalCorticalThicknessPipeline|Regional Cortical Thickness Pipeline]] (Cedric Mathieu, Clement Vachet, Martin Styner, Heather Cody Hazlett)
#[[DBP2:MIND:Roadmap|MIND Roadmap Project: Brain Lesion Analysis in Lupus]]
##[[2009_Winter_Project_Week:HighLevelWizard|Slicer High Level Wizard Project]](Steve Pieper, Mark Scully, Jeremy Bockholt)
##[[2009_Winter_Project_Week:LesionAlgorithms|Review of Lesion Algorithms]](Ross Whitaker, Vincent Magnotta, Marcel Prastawa, Mark Scully, Jeremy Bockholt)
##[[2009_Winter_Project_Week:LongitudinalLesions|Determine Requirements of Longitudinal Lesion Analyses]](Jeremy Bockholt, Marcel Prastawa, Mark Scully, Andriy Fedorov)
#[[DBP2:JHU:Roadmap|JHU Roadmap Project: Segmentation and Registration for Robotic Prostate Intervention]]
##[[2009_Winter_Project_Week:SterotacticFrameModel|Generating a Model of a Stereotactic Frame for Neurosurgery]] (Rares Crisan, Queens, Gabor Fichtinger, Queens, Katie Hayes, BWH)

===Other NA-MIC Projects===
#[[2009_Winter_Project_Week_Hageman_FMTractography | Fluid mechanics tractography and visualization]] (Nathan Hageman UCLA)
#UCLA BrainLab/Slicer Neurosurgery Preoperative Tumor Planning - using Slicer and its link to BrainLab to investigate whether different tractography methods aid in preoperative planning of tumor resection.(Nathan Hageman UCLA)
#Development of FEM / FVM solver library in ITK/VTK (and/or Python?) (Nathan Hageman UCLA, Vince, Luca, Steve)
#[[2009_Winter_Project_Week_Transform_Management | Transform Management]](Jim Miller)
#Interactive 3D Widgets - Introduce new interactors into Slicer; extensions to current widgets to support Slicer (Karthik, Will Schroeder, Nicole Aucoin)
#[[2009_Winter_Project_Week_vtkITK_Pipeline | Using ITK in VTK Pipelines]] (Jim, Steve)
#[[2009_Winter_Project_Week_SlicerLayouts | User Interface Flexible Layouts]] (Wendy, Jim, Steve, Sebastien, Ron)
#[[2009_Winter_Project_Week_Python | Python interface completion and packaging - Fortran and openssl problems]] (Luca, Steve, Demian)
#[[Two-tensor tractography in Slicer using Python and Teem]] (Madeleine Seeland, C-F Westin, Xiaodong Tao)
#[[2009_Winter_Project_Week_Rotation_Tangents | Diffusion Tensor Invariant gradients and rotation tangents in Python and Teem]] (Peter Savadjiev, C-F Westin, Luis Ibanez)
#[[2009_Winter_Project_Week_Automated_GUI_Testing | KWWidgets and Slicer automated GUI testing ]](Sebastien, Yumin, Interested User: Vince)
#[[2009_Winter_Project_Week_ColorModule | Slicer Colors Module update ]](Nicole)
#[[Volume Rendering]] (Alex, Curt, Nicholas)
#[[2009_Winter_Project_Week_XND | XNAT Desktop BatchMake integration & Slicer interface]] (Dan Marcus, Stephen Aylward, Wendy Plesniak, Curt Lisle)
#[[2009_Winter_Project_Week_Cortical_Correspondence | Cortical correspondence using DTI]] (Ipek, Martin, Xiaodong)
#[[2009_Winter_Project_Week_Command_Line_Program_Testing |Command Line Program Testing]] (Lorensen, Ron)
#[[2009_Winter_Project_Week_Slicer_VMTK |Vessel Segmentation in Slicer using VMTK]] ([[User:haehn|Daniel Haehn]], [[User:lantiga| Luca Antiga]])
#[[2009_Winter_Project_Week_fMRI_Clustering |Exploring Functional Connectivity in fMRI via Clustering]] (Archana Venkataraman, Marek Kubicki, Polina Golland)
#[[2009_Winter_Project_Week_Compiler_Warnings:Slicer3_Graffiti |Compiler Warnings:Slicer3's Graffiti]] (Lorensen, NA-MIC)
#[[2009_Winter_Project_Week_ChangeTracker |Measuring dynamics of tumor growth in Slicer3 with ChangeTracker]] (Andriy Fedorov)
#[[2009_Winter_Project_Week_GWE_Catalogs |GWE integration with catalog files]] (Marco)
#[[2009_Winter_Project_Week_Gofigure_LevelSet |ITK level set solution for cell segmentation in microscopy datasets]] (part of Gofigure) (Kishore mosaliganti)
#[[2009_Winter_Project_Week_Surface_Processing |ITK surface processing filters: Smoothing, spherical parameterization]] (part of Gofigure) (Alex. Gouaillard)
#[[2009_Winter_Project_Week_Manual_Segmentation_Widgets |VTK widgets for manual segmentation and manual validation of segmentation]] (part of Gofigure) (Arnaud Gelas)
#[[2009_Winter_Project_Week_UtahPlugins | Integration of Utah registration and segmentation methods as Slicer plugins]] (Marcel Prastawa)
#[[2009_Winter_Project_Week_OMTRegistration | DWI to MRI Registration Using Optimat Mass Transport]] (Sylvain Bouix, Ivan Kolesov GATech)

===External Collaborations===
* [[Iowa Meshing Tutorial]]
*Wake Forest - Virginia Tech
** [[2009_Winter_Project_Week_WFU1 | Move to All Slicer3 Workflow]]
** [[2009_Winter_Project_Week_WFU2 | Development of deformation based morphometry module]]
*Georgetown U: [[2009_Winter_Project_Week_NAVRFA | Prototype RF Lesion Ablation Workflow prototyped in Slicer]]
*UNC:
**[[2009_UNC_HAMMER | MR-image registration algorithm to be extended and added to namic kit]]
**[[2009_UNC_White_Matter_Lesion | white matter lesion segmentation]]
* [[Stanford SIMBIOS: Whole Body Segmentation for Simulation]]
* [[2009_Winter_Project_Week_MRSI | MRSI Module for Slicer (Bjoern Menze)]]
*[[NCI Evaluating NA-MIC Tools for Image Analysis]]

=== Preparation ===

# Please make sure that you are on the [http://public.kitware.com/cgi-bin/mailman/listinfo/na-mic-project-week na-mic-project-week mailing list]
# Starting Thursday, October 16th, part of the weekly Thursday 3pm NA-MIC Engineering TCON will be used to prepare for this meeting. The schedule for these preparatory calls is as follows:
#*October 16: Engineering Infrastructure Projects
#*October 23: Funded External Collaboration Projects
#*November 6: DPB Projects
#*November 20: New Collaborations
#*December 4: Other Projects
#*December 18: Loose Ends
#By December 17, 2008: [[2009_Winter_Project_Week_Template|Complete a templated wiki page for your project]]. Please do not edit the template page itself, but create a new page for your project and cut-and-paste the text from this template page. If you have questions, please send an email to tkapur at bwh.harvard.edu.
# By December 17, 2008: Create a directory for each project on the [[Engineering:SandBox|NAMIC Sandbox]] (Zack)
##[https://www.kitware.com/Admin/SendPassword.cgi Ask Zack for a Sandbox account]
## Commit on each sandbox directory the code examples/snippets that represent our first guesses of appropriate methods. (Luis and Steve will help with this, as needed)
## Gather test images in any of the Data sharing resources we have (e.g. the BIRN). These ones don't have to be many. At least three different cases, so we can get an idea of the modality-specific characteristics of these images. Put the IDs of these data sets on the wiki page. (the participants must do this.)
## Setup nightly tests on a separate Dashboard, where we will run the methods that we are experimenting with. The test should post result images and computation time. (Zack)
# FINAL TCON: December 18th 3pm ET to tie loose ends
# Please note that by the time we get to the project event, we should be trying to close off a project milestone rather than starting to work on one...

== Previous Project Events ==

A history of all the programming/project events in NA-MIC is available by following [[Project Events|this link]].

2009 Winter Project Week Automated GUI Testing

2008-12-18T05:30:31Z

Yumin:

{|
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]
|[[Image:squish_slicer3.png|thumb|320px|Image showing the end result of a Squish test with the clipbox of a volume in Slicer3]]
|}

__NOTOC__

===Key Investigators===
* Kitware: Sebastien Barre, Yumin Yuan

<div style="margin: 20px;">

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Objective</h1>
An automated GUI Testing framework in KWWidgets is definitely on high demand, and the reason is best described by Ron Kikinis:
"The automatic testing capability that kww will enable, appears to me to be more and more important, the more I think about it. As a matter of fact, automatic testing of entire sequences of mouse clicks and keyboard strokes will enable us to move to a different level robustness with slicer 3.0.".

</div>

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Approach, Plan</h1>
Suggestions, discussions and specifications related to this topic are documented in this [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets wiki page].
As described on the wiki, many solutions (freeware and commercial) have been investigated, and currently we think that Squish looks like to be a valid solution for simple tests (or, actually, our only solution). A detailed wiki page about [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets testing with Squish] has been created, and a work-plan is defined:

* Create a CMake module to find Squish on the system (paths to Squish server and Squish runner).
* Create CMake macros that will start/stop the server and run a test by invoking the runner and parsing its output.
* Invoke the Squish module when configuring/building KWWidgets.
* Create CMake macros that will add Squish tests for KWWidgets.
* Create new suites for KWWidgets examples.
* Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example).
* Create new suites for Slicer3.

</div>

<div style="width: 40%; float: left;">

<h1>Progress</h1>

* Create a CMake module to find Squish on the system (paths to Squish server and Squish runner). --- Done by Brad Davis
* Create CMake macros that will start/stop the server and run a test by invoking the runner and parsing its output. --- Done by Brad Davis
* Invoke the Squish module when configuring/building KWWidgets. --- Done
* Create CMake macros that will add Squish tests for KWWidgets. --- In Progress (Need to add validation methods for some tests)
* Create new suites for KWWidgets examples. --- In Progress (Some new Squish test suites are created for all the Cxx examples, but still need to add validation methods to these tests).
* Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example). --- In progress. (Some widgets are not working with Squish currently (Squish bugs), for example, vtkKWComboBox and vtkKWMenuButton. Trying to work with Squish support team to resolve these issues.)
* Create new suites for Slicer3. --- In progress. (A couple simple tests are created, but the test scripts need to be manually massaged quite a bit to make them work.)

</div>

<br style="clear: both;" />

</div>

===References===
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets GUI testing].
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets GUI testing with Squish].

File:Squish slicer3.png

2008-12-18T05:21:03Z

Yumin:

2009 Winter Project Week Automated GUI Testing

2008-12-18T05:15:19Z

Yumin:

{|
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]
|[[Image:squish_kwwidgets.jpg|thumb|320px|Image showing the end result of a Squish test on the MedicalImageViewerExample of KWWidgets]]
|[[Image:squish_slicer3.png|thumb|320px|Image showing the end result of a Squish test with the clipbox of a volume in Slicer3]]
|}

__NOTOC__

===Key Investigators===
* Kitware: Sebastien Barre, Yumin Yuan

<div style="margin: 20px;">

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Objective</h1>
An automated GUI Testing framework in KWWidgets is definitely on high demand, and the reason is best described by Ron Kikinis:
"The automatic testing capability that kww will enable, appears to me to be more and more important, the more I think about it. As a matter of fact, automatic testing of entire sequences of mouse clicks and keyboard strokes will enable us to move to a different level robustness with slicer 3.0.".

</div>

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Approach, Plan</h1>
Suggestions, discussions and specifications related to this topic are documented in this [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets wiki page].
As described on the wiki, many solutions (freeware and commercial) have been investigated, and currently we think that Squish looks like to be a valid solution for simple tests (or, actually, our only solution). A detailed wiki page about [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets testing with Squish] has been created, and a work-plan is defined:

Create a CMake module to find Squish on the system (paths to Squish server and Squish runner).
Create CMake macros that will start/stop the server and run a test by invoking the runner and parsing its output.
Invoke the Squish module when configuring/building KWWidgets.
Create CMake macros that will add Squish tests for KWWidgets.
Create new suites for KWWidgets examples.
Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example)
Create new suites for Slicer3.

</div>

<div style="width: 40%; float: left;">

<h1>Progress</h1>

Create a CMake module to find Squish on the system (paths to Squish server and Squish runner). --- Done by Brad Davis
Create CMake macros that will start/stop the server and run a test by invoking the runner and parsing its output. --- Done by Brad Davis
Invoke the Squish module when configuring/building KWWidgets. --- Done
Create CMake macros that will add Squish tests for KWWidgets. --- In Progress (Need to add validation methods for some tests)
Create new suites for KWWidgets examples. --- In Progress (Some new Squish test suites are created for all the Cxx examples, but still need to add validation methods to these tests).
Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example). --- In progress. (Some widgets are not working with Squish currently (Squish bugs), for example, vtkKWComboBox and vtkKWMenuButton. Trying to work with Squish support team to resolve these issues.)
Create new suites for Slicer3. --- In progress. (A couple simple tests are created, but the test scripts need to be manually massaged quite a bit to make them work.)

</div>

<br style="clear: both;" />

</div>

===References===
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets GUI testing].
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets GUI testing with Squish].

2009 Winter Project Week Automated GUI Testing

2008-12-18T05:06:14Z

Yumin:

{|
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]
|[[Image:squish_kwwidgets.jpg|thumb|320px|Image showing the end result of a Squish test on the MedicalImageViewerExample of KWWidgets]]
|[[Image:squish_slicer3.jpg|thumb|320px|Image showing the end result of a Squish test with the clipbox of a volume in Slicer3]]
|}

__NOTOC__

===Key Investigators===
* Kitware: Sebastien Barre, Yumin Yuan

<div style="margin: 20px;">

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Objective</h1>
An automated GUI Testing framework in KWWidgets is definitely on high demand, and the reason is best described by Ron Kikinis:
* "The automatic testing capability that kww will enable, appears to me to be more and more important, the more I think about it. As a matter of fact, automatic testing of entire sequences of mouse clicks and keyboard strokes will enable us to move to a different level robustness with slicer 3.0.".

</div>

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Approach, Plan</h1>
Suggestions, discussions and specifications related to this topic are documented in this [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets wiki page].
As described on the wiki, many solutions (freeware and commercial) have been investigated, and currently we think that Squish looks like to be a valid solution for simple tests (or, actually, our only solution). A detailed wiki page about [http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets testing with Squish] has been created, and a work-plan is defined:

* Create a CMake module to find Squish on the system (paths to Squish server and Squish runner),
* Create CMake macros that will start/stop the server
* Create CMake macros that will run a test by invoking the runner and parsing its output,
* Invoke the Squish module when configuring/building KWWidgets,
* If Squish is found, add the above test to the KWCallbacks example, so that it is executed nightly.
* Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example).
* Create new suites for Slicer3.

</div>

<div style="width: 40%; float: left;">

<h1>Progress</h1>

* Create a CMake module to find Squish on the system (paths to Squish server and Squish runner). --- Done by Brad Davis
* Create CMake macros that will start/stop the server and run a test by invoking the runner and parsing its output. --- Done by Brad Davis
* Invoke the Squish module when configuring/building KWWidgets. --- Done
* Create CMake macros that will add Squish tests for KWWidgets. --- In Progress (Need to add validation methods for some tests)
* Create new suites for KWWidgets examples. --- In Progress (Some new Squish test suites are created for all the Cxx examples, but still need to add validation methods to these tests).
* Create new suites to test every single KWWidgets core widget (in the WidgetsTour for example). --- In progress. (Some widgets are not working with Squish currently (Squish bugs), for example, vtkKWComboBox and vtkKWMenuButton. Trying to work with Squish support team to resolve these issues.)
* Create new suites for Slicer3. --- In progress. (A couple simple tests are created, but the test scripts need to be manually massaged quite a bit to make them work.)

</div>

<br style="clear: both;" />

</div>

===References===
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing KWWidgets GUI testing].
*[http://www.kwwidgets.org/Wiki/KWWidgets/GUI_Testing/Squish KWWidgets GUI testing with Squish].

2009 Winter Project Week Automated GUI Testing

2008-12-18T03:46:25Z

Yumin: New page: {| |Project Week Main Page ]] |[[Image:scarmri_namic.jpg|thumb|320px|Image showing scar in the left atrium using MR...

{|
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]
|[[Image:scarmri_namic.jpg|thumb|320px|Image showing scar in the left atrium using MRI]]
|[[Image:scar_carto_namic.jpg|thumb|320px|Image of scar by MRI registered to MR Angiogram, and to the EP RF ablation site data.]]
|}

__NOTOC__

===Key Investigators===
* Beth Israel Deaconess: Dana C. Peters
* Beth Israel Deaconess: Jason Taclas
* Kitware: Luis Ibanez, NAMIC: Steve Pieper, GE: Jim Miller (providing advice)

<div style="margin: 20px;">

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Objective</h1>
We are developing methods for registering peri-procedural electrophysiological data showing sites of RF energy application (called Carto data) in the left atrium, with post-procedural MRI data, which shows regions of scarred left atrium (see figure above), using an interative closest point algorithm (Z. Malchano et al). The goal is to measure the distance between scar by MRI and ablation sites (Carto data) by EP.

</div>

<div style="width: 27%; float: left; padding-right: 3%;">

<h1>Approach, Plan</h1>

Our approach for comparing the locations of scar to sites of RF ablation is summarized in the ISMRM 2008 reference below. The main challenge to this approach is to measure the distance between each scarred pixel, and each RF ablation site, and then the distance from each RF ablation site, to the nearest scarred pixel. <foo>.

Our plan for the project week is to first try to measure the closest distances between MRI scar and Carto data <bar>,and then to measure distances between Carto data and closest scar. We also wish to colorize the Carto surface, based on voltage data. We also wish to streamline the MR angiography segmentation method.
</div>

<div style="width: 40%; float: left;">

<h1>Progress</h1>

Software for the registration between electrophysiology Carto data and the MR angiogram has been implemented, using the ITK/VTK platform (see ISMRM 2008 abstract, Taclas et al, and figure above). This week we wrote code to quantitatively determine the distances between each ablation location, and the closest region of scar, and to determine the distances between each pixel of scar, and the nearest ablation point. Therefore we accomplished our goal!

</div>

<br style="clear: both;" />

</div>

===References===
*Peters DC, Wylie JV, Hauser TH, Kissinger KV, Botnar RM, Essebag V, Josephson ME, Manning WJ. Detection of pulmonary vein and left atrial scar after catheter ablation with three-dimensional navigator-gated delayed enhancement MR imaging: initial experience. Radiology 2007; 243:690-695.
* Taclas JE, Wylie JV, Hauser TH, Manning WJ, Josephson ME, Peters, DC. Correlation and Visualization of Left Atrial Scar due to Pulmonary Vein Ablation with Recorded Ablation Sites. Proceedings of the 16th scientific meeting of the International Society for Magnetic Resonance in Medicine (2008), Toronto, CA, p. 1042.
*Malchano ZJ, Neuzil P, Cury RC, Holmvang G, Weichet J, Schmidt EJ, Ruskin JN, Reddy VY. Integration of cardiac CT/MR imaging with three-dimensional electroanatomical mapping to guide catheter manipulation in the left atrium: implications for catheter ablation of atrial fibrillation. J Cardiovasc Electrophysiol 2006; 17:1221-1229.

2009 Winter Project Week

2008-12-18T03:45:20Z

Yumin: /* Other NA-MIC Projects */

Back to [[Project Events]], [[AHM_2009]], [[Events]]

==Introduction to NA-MIC Project Week==

Please read an introduction about these events [[Project_Events#Introduction|here]].

== Dates.Venue.Registration ==

Please [[AHM_2009#Dates._Venue._Registration| click here for Dates, Venue, and Registration]] for this event.

== Agenda==

Please [[AHM_2009#Agenda|click here for the agenda for AHM 2009 and Project Week]].

==Projects==
Please note:
*Please use the [[2009_Winter_Project_Week_Template|'''2009 Project Week Template''']] to create a page for your project(s)
*[[2008_Summer_Project_Week#Projects|Last Event's Projects as a reference]]
*For hosting projects, we are planning to make use of the NITRC resources. See [[NA-MIC_and_NITRC | Information about NITRC Collaboration]]
*Next Project Week is at MIT -- June 22-26, 2009
The following is a list of all projects that will be pursued at this meeting.

===NA-MIC DBP Roadmap Projects===
Please note that these projects correspond to four clinical Roadmap application projects that will be pursued in focused parallel tracks at the meeting, each corresponding to a DBP problem.

#[[DBP2:Harvard:Brain_Segmentation_Roadmap|Harvard Roadmap Project: Stochastic Tractography for VCFS]]
##[[2009_Winter_Project_Week:GT_TubularSurfaceSeg|Tubular Surface Segmentation for fiber bundle extraction]] (Vandana Mohan GATech, Allen Tannenbaum GATech, Marek Kubicki BWH, Stephen Aylward Kitware)
##[[2009_Winter_Project_Week_StochasticTractography |Stochastic Tractograhy Tool for Slicer]] (Marek Kubicki BWH, Julien de Siebenthal BWH, Steve Pieper Isomics)
##[[2009_Winter_Project_Week_Slicer3Functioning |Evaluation of basic Slicer 3.0 Functionality from a User Perspective]] (Doug Terry BWH, Marek Kubicki BWH, Sylvain Bouix BWH, Steve Pieper, Wendy Plesniak, Nicole Aucoin)
##[[2009_Winter_Project_Week:DTIGroupAnalysis |Group analysis of DTI fiber bundles]] (Casey Goodlett, Guido Gerig, Marek Kubicki, Sylvain Bouix)
#[[DBP2:UNC:Cortical_Thickness_Roadmap|UNC Roadmap Project: Cortical Thickness Measurement for Autism]]
##[[2009_Winter_Project_Week:LocalCorticalThicknessPipeline|Local Cortical Thickness Pipeline]] (Clement Vachet, Martin Styner, Heather Cody Hazlett, Marc Niethammer, Ipek Oguz)
##[[2009_Winter_Project_Week:RegionalCorticalThicknessPipeline|Regional Cortical Thickness Pipeline]] (Cedric Mathieu, Clement Vachet, Martin Styner, Heather Cody Hazlett)
#[[DBP2:MIND:Roadmap|MIND Roadmap Project: Brain Lesion Analysis in Lupus]]
##[[2009_Winter_Project_Week:HighLevelWizard|Slicer High Level Wizard Project]](Steve Pieper, Mark Scully, Jeremy Bockholt)
##[[2009_Winter_Project_Week:LesionAlgorithms|Review of Lesion Algorithms]](Ross Whitaker, Vincent Magnotta, Marcel Prastawa, Mark Scully, Jeremy Bockholt)
##[[2009_Winter_Project_Week:LongitudinalLesions|Determine Requirements of Longitudinal Lesion Analyses]](Jeremy Bockholt, Marcel Prastawa, Mark Scully, Andriy Fedorov)
#[[DBP2:JHU:Roadmap|JHU Roadmap Project: Segmentation and Registration for Robotic Prostate Intervention]]
##[[2009_Winter_Project_Week:SterotacticFrameModel|Generating a Model of a Stereotactic Frame for Neurosurgery]] (Rares Crisan, Queens, Gabor Fichtinger, Queens, Katie Hayes, BWH)

===Other NA-MIC Projects===
#[[2009_Winter_Project_Week_Hageman_FMTractography | Fluid mechanics tractography and visualization]] (Nathan Hageman UCLA)
#UCLA BrainLab/Slicer Neurosurgery Preoperative Tumor Planning - using Slicer and its link to BrainLab to investigate whether different tractography methods aid in preoperative planning of tumor resection.(Nathan Hageman UCLA)
#Development of FEM / FVM solver library in ITK/VTK (and/or Python?) (Nathan Hageman UCLA, Vince, Luca, Steve)
#[[2009_Winter_Project_Week_Transform_Management | Transform Management]](Jim Miller)
#Interactive 3D Widgets - Introduce new interactors into Slicer; extensions to current widgets to support Slicer (Karthik, Will Schroeder, Nicole Aucoin)
#[[2009_Winter_Project_Week_vtkITK_Pipeline | Using ITK in VTK Pipelines]] (Jim, Steve)
#[[2009_Winter_Project_Week_SlicerLayouts | User Interface Flexible Layouts]] (Wendy, Jim, Steve, Sebastien, Ron)
#[[2009_Winter_Project_Week_Python | Python interface completion and packaging - Fortran and openssl problems]] (Luca, Steve, Demian)
#[[Two-tensor tractography in Slicer using Python and Teem]] (Madeleine Seeland, C-F Westin, Xiaodong Tao)
#[[2009_Winter_Project_Week_Rotation_Tangents | Diffusion Tensor Invariant gradients and rotation tangents in Python and Teem]] (Peter Savadjiev, C-F Westin, Luis Ibanez)
#[[2009_Winter_Project_Week_Automated_GUI_Testing | KWWidgets and Slicer automated GUI testing with Squish ]](Sebastien, Yumin, Interested User: Vince)
#[[2009_Winter_Project_Week_ColorModule | Slicer Colors Module update ]](Nicole)
#[[Volume Rendering]] (Alex, Curt, Nicholas)
#[[2009_Winter_Project_Week_XND | XNAT Desktop BatchMake integration & Slicer interface]] (Dan Marcus, Stephen Aylward, Wendy Plesniak, Curt Lisle)
#[[2009_Winter_Project_Week_Cortical_Correspondence | Cortical correspondence using DTI]] (Ipek, Martin, Xiaodong)
#[[2009_Winter_Project_Week_Command_Line_Program_Testing |Command Line Program Testing]] (Lorensen, Ron)
#[[2009_Winter_Project_Week_Slicer_VMTK |Vessel Segmentation in Slicer using VMTK]] ([[User:haehn|Daniel Haehn]], [[User:lantiga| Luca Antiga]])
#[[2009_Winter_Project_Week_fMRI_Clustering |Exploring Functional Connectivity in fMRI via Clustering]] (Archana Venkataraman, Marek Kubicki, Polina Golland)
#[[2009_Winter_Project_Week_Compiler_Warnings:Slicer3_Graffiti |Compiler Warnings:Slicer3's Graffiti]] (Lorensen, NA-MIC)
#[[2009_Winter_Project_Week_ChangeTracker |Measuring dynamics of tumor growth in Slicer3 with ChangeTracker]] (Andriy Fedorov)
#[[2009_Winter_Project_Week_GWE_Catalogs |GWE integration with catalog files]] (Marco)
#[[2009_Winter_Project_Week_Gofigure_LevelSet |ITK level set solution for cell segmentation in microscopy datasets]] (part of Gofigure) (Kishore mosaliganti)
#[[2009_Winter_Project_Week_Surface_Processing |ITK surface processing filters: Smoothing, spherical parameterization]] (part of Gofigure) (Alex. Gouaillard)
#[[2009_Winter_Project_Week_Manual_Segmentation_Widgets |VTK widgets for manual segmentation and manual validation of segmentation]] (part of Gofigure) (Arnaud Gelas)
#[[2009_Winter_Project_Week_UtahPlugins | Integration of Utah registration and segmentation methods as Slicer plugins]] (Marcel Prastawa)
#[[2009_Winter_Project_Week_OMTRegistration | DWI to MRI Registration Using Optimat Mass Transport]] (Sylvain Bouix, Ivan Kolesov GATech)

===External Collaborations===
* [[Iowa Meshing Tutorial]]
*Wake Forest - Virginia Tech
** [[2009_Winter_Project_Week_WFU1 | Move to All Slicer3 Workflow]]
** [[2009_Winter_Project_Week_WFU2 | Development of deformation based morphometry module]]
*Georgetown U: [[2009_Winter_Project_Week_NAVRFA | Prototype RF Lesion Ablation Workflow prototyped in Slicer]]
*UNC:
**[[2009_UNC_HAMMER | MR-image registration algorithm to be extended and added to namic kit]]
**[[2009_UNC_White_Matter_Lesion | white matter lesion segmentation]]
* [[Stanford SIMBIOS: Whole Body Segmentation for Simulation]]
* [[2009_Winter_Project_Week_MRSI | MRSI Module for Slicer (Bjoern Menze)]]
*[[NCI Evaluating NA-MIC Tools for Image Analysis]]

=== Preparation ===

# Please make sure that you are on the [http://public.kitware.com/cgi-bin/mailman/listinfo/na-mic-project-week na-mic-project-week mailing list]
# Starting Thursday, October 16th, part of the weekly Thursday 3pm NA-MIC Engineering TCON will be used to prepare for this meeting. The schedule for these preparatory calls is as follows:
#*October 16: Engineering Infrastructure Projects
#*October 23: Funded External Collaboration Projects
#*November 6: DPB Projects
#*November 20: New Collaborations
#*December 4: Other Projects
#*December 18: Loose Ends
#By December 17, 2008: [[2009_Winter_Project_Week_Template|Complete a templated wiki page for your project]]. Please do not edit the template page itself, but create a new page for your project and cut-and-paste the text from this template page. If you have questions, please send an email to tkapur at bwh.harvard.edu.
# By December 17, 2008: Create a directory for each project on the [[Engineering:SandBox|NAMIC Sandbox]] (Zack)
##[https://www.kitware.com/Admin/SendPassword.cgi Ask Zack for a Sandbox account]
## Commit on each sandbox directory the code examples/snippets that represent our first guesses of appropriate methods. (Luis and Steve will help with this, as needed)
## Gather test images in any of the Data sharing resources we have (e.g. the BIRN). These ones don't have to be many. At least three different cases, so we can get an idea of the modality-specific characteristics of these images. Put the IDs of these data sets on the wiki page. (the participants must do this.)
## Setup nightly tests on a separate Dashboard, where we will run the methods that we are experimenting with. The test should post result images and computation time. (Zack)
# FINAL TCON: December 18th 3pm ET to tie loose ends
# Please note that by the time we get to the project event, we should be trying to close off a project milestone rather than starting to work on one...

== Previous Project Events ==

A history of all the programming/project events in NA-MIC is available by following [[Project Events|this link]].

Special topic breakout: KWWidgets

2007-06-27T03:55:13Z

Yumin: /* From KWW-Users mailing list */

[[Image:ProjectWeek-2007.png|thumb|300px|left|Return to [[2007_Programming/Project_Week_MIT|Project Week Main Page]]]]

<br><br><br><br>

KWWidgets Breakout Session

June 26th, 1-2pm

Location: [[Meeting_Locations:MIT_Grier_A_%26B|Grier Rooms A & B: 34-401A & 34-401B]]

<br><br><br><br><br><br>

=== Attendees: ===
* Yumin Yuan
* Steve Pieper
* Alex Yarmarkovich
* Wendy Plesniak
* Nicole Aucoin
* Curt Lisle
* Csaba Csoma
* Brad Davis
* David Gobbi
* Kiran Shivanna
* Kevin Teich
* Jeff Hawley
* Xiujuan Geng
* James Harris
* Gary Christensen
* Paul Song
* Alex. Gouaillard
* Vincent Magnotta
* Kiran Shivanna
* Katie Hayes

__NOTOC__

=== Agenda ===

* Roadmap (to help KWWidgets developers prioritize their work)
* Widget feature requests / feedback
* Talk about best approaches to making some widget behavior appear consistent across platforms.
* Separate Tutorial Session for New Users (to happen possibly on Wednesday).<br>'''Hint:''' ''Seb: I just added a tentative Tutorial 1 that tackles creating a very simple composite widget. See [http://kwwidgets.org/cgi-bin/viewcvs.cgi/Examples/Cxx/Tutorial1/?root=KWWidgets Examples/Cxx/Tutorial1]. I need to write the corresponding documentation.''

=== Specific Issues ===

==== From Nicole Aucoin====
Directory selection dialog box on linux:

* Bug: it pops up with a default width such that the right scroll bar isn't visible (see this [http://www.na-mic.org/Wiki/index.php/Image:KWDirectoryBrowserLinuxTooShort.jpg screenshot]; to reproduce it, start up Slicer3, go to the Models module, click on "Load Directory").<br>'''Hint:''' ''Seb: the quickest workaround (Yumin?) at this point would be to make the default width a tad larger so that the right scrollbar button shows up.'' ''Yumin: Fixed.''

* Request: an entry box where I can type a path to reduce clicking through the tree (useful before setting up a favourite)<br>'''Hint:''' ''Seb: Very doable (Yumin?). Let's put all requests in the TODO list and prioritize.''

==== From Curtis Lisle====

* I have had trouble initializing widgets to specific values in advance of user input. For example, I've created interfaces with sliders and buttons but I have had trouble getting the widgets toinitialize in a state different then the default state. For example, setting a slider to value=26 in the middle of its range without dragging the mouse. The API looks like it is there, but I couldn't get it to work for me. I'm sure I tried setting the state before and after creation, if I remember, but no luck. It may be that I'm not updating the GUI successfully after changing values. Update: see [http://www.na-mic.org/Wiki/index.php/Image:KWMeshViewer030607.png screenshot]; by state, I mean the widget-specific state, such as a check button is checked, or a slider is set at a particular value within its range. For example, the "Outline Display" button could be checked ON via API control of the program, not the user clicking on it. Before this picture was taken, I dragged the "element size" slider to 93% via the mouse. I'd like to instantiate the GUI, then set the actual positions and state values of the widgets. I just need clarity on the order of events to invoke through the API or help figuring out what I'm doing wrong. I notice that for KWWidgets, State usually means enabled/disabled to process user events. Instead, I am thinking about setting widget values from the program. I guess for CheckButtons, this would be Get/SetSelectedState(). For a vtkKWScale, this would be SetValue(). I tried setting these but didn't see the effect on the GUI. Maybe I am just not invoking Modified() correctly afterwards.<br>'''Hint:''' ''Seb: Not sure on this one. Setting the values programmatically is something that is done in all our apps and it is a pretty important part of how the application works through callbacks. For most widgets, setting a value before calling Create() *should* work, but it never hurts do make sure it is done *after* Create(), to be on the safe side. There is no need to call Modified(), at least on the core widgets like checkbuttons or scales, the UI should be updated right away. You can even do it at runtime through the Tcl interpreter. So I guess we would need to see the code: it is possible that as soon you set a new value, an event is triggered (like ModifiedEvent) and some other part of your app that would listen to this event would set that widget back to its previous value. In term of Model/View/Controller pattern, the UI/view is supposed to reflect the state/values of a model; if you designed your app that way and it is possible that your controller is always resetting the UI to the current model's value.''

* discuss when UI elements need to have Modified() / Update()invoked to refresh their appearance. I used a histogram widget on a project and had to experiment a lot calling the panel and RenderWidowWidget, etc. before I finally got the histogram to update when the input changed.<br>'''Hint:''' ''Seb: it's mostly widget dependent, but for the core widgets, you should not have to call Modified(), or Update() (which is not part of the vtkKWWidget superclass anyway). For some composite widgets, they should be smart enough to be always 'up to date', but sometimes being up to date is so costly that a manual call to a method is needed (which might be called Update()). The histogram, to my knowledge, is indeed the trickiest one, sorry :) You do not want to have the histogram updated automatically each time somebody modifies one pixel in an image/vtkDataArray, for example. There is nothing in VTK that really says, asynchronously, "this image has been modified enough that it might be time to refresh your histogram". Granularity issues...''.

==== From Brad Davis ====

* Bug: Double-clicking does not work with slicer3 and linux.<br>'''Hint:''' ''Seb: The KWWidgets demo/examples handle double-clicks fine, so my guess is that Slicer3 is intercepting them. Yumin to investigate this issue.''
* Bug: File->Add Data does not use new file browser.<br>'''Hint:''' ''Seb: Sounds like a quick fix (Yumin?).'' ''Steve: this has been fixed.''
* Request: Tree with additional columns widget<br>'''Hint:''' ''Seb: The TkTreeCtrl library is in KWW and allows that, but one need to wrap it inside a C++ class, and this is a lot of work (Seb?). Let's put all requests in the TODO list and prioritize.'' ''Steve: there was discussion about exposing the TkTreeCtrl in the tcl interp so users can access it directly with Script() - is this an easy thing to do now?'' ''Seb: yes, that's very easy, but that means we are going to see tons of ugly Tcl code in the middle of C++ code :)'' ''Seb: OK, DONE, it's in. I compiled and tested on Win32. I compiled but could not test on Linux. TkTreeCtrl documentation can be found [http://tktreectrl.sourceforge.net/ here]. Download the TkTreeCtrl distribution, then from Slicer3/KWWidgets interactor, source demos/demo.tcl, then issue: wm deiconify .'' ''Steve: Thanks! I'll give it a try. My plan, actually, is to have some very pretty tcl code that uses this feature (no comment on the aesthetic qualities of C++ code!).'' ''Seb: I had to disable it until the VS7 build is fixed. To play with it though, edit Utilities\TkTreeCtrl\TkTreeCtrl.cmake and change the code to SET(${supported} 1). This is such a huge (50,000 lines) library that I would suggest you guys start playing with it at the Tcl level and that we use that feedback to create a C++ API that would not have to expose every thing features but the ones you use the most.''

====From Alex:====

* Request: I would like to address the performance of building GUI in slicer3 Modules. When selecting a module for the first time (Volumes or Models) it takes noticable time before the UI panel is displayed.<br>'''Hint:''' ''Seb: Well, you can't have your cake and eat it too :)) We delayed the creation of modules so that Slicer3 starts up faster. But one way or the other, the modules GUI has to be created. I just tried on my laptop on Win32, and I did not notice anything slow when I selected a few modules. Which ones are slow? Maybe one of the slow modules is actually doing more than just creating GUI when it is initialized.''

* Request: Customizable tree widget similar to slicer2 model hierarchy editor: allow to add push-buttons or check boxes for the individual tree leaves.<br>'''Hint:''' ''Seb: The TkTreeCtrl library is in KWW and allows that, but one need to wrap it inside a C++ class, and this is a lot of work (Seb?). Unless, as suggested by Steve, you want to expose the TkTreeCtrl library directly and do it from Tcl. Let's put all requests in the TODO list and prioritize.''

====From Wendy:====

Mostly pesky things:
* Request: Creating special versions of menubutton drop-down menus with scroll capability.<br>'''Hint:''' ''Seb: There is no such native widget, so we would have to create a composite widget mixing a button and a scroll list (Seb or Yumin?). A day or two worth probably. Let's put all requests in the TODO list and prioritize.''
* Request: checkbuttons and radiobuttons with consistent "on/off" visual representation across platforms. (either special Slicer widgets or KWWidgets).<br>'''Hint:''' ''Seb: Tcl/Tk does not provide an API to modify that visual representation (called the 'indicator'), since it is trying to use the native widgets when possible. However, you can emulate that behavior by setting an image for both unselected and selected state (SetImageToPredefinedIcon, SetSelectImageToPredefinedIcon), then make sure the image does not override the text (SetCompoundModeToLeft), remove the usual indicator (SetIndicatorVisibility), and remove the border of what is now a button (SetBorderWidth). All of those calls can be made into a theme. I've updated the KWThemeExample (check the green theme) to show how it is done. I would recommend against it, as a lot of Slicer3 GUI already uses SetImage and SetSelectImage to provide graphical checkbuttons instead of textual ones. I'm not confident this would play well, but let's try.''

It would be good to decide on a strategy for addressing these things.

* Request: Also, if a radiobutton's indicator visibility is off, the widget gets rendered with a 3D effect (even if we're using an icon to display the button's on/off state). Can we turn that 3D effect off?<br>'''Hint:''' ''Seb: Not to my knowledge, it might be a Tk "feature" but try SetBorderWidth 0''

==== From KWW-Users mailing list====

* http://public.kitware.com/pipermail/kwwidgets/2007-June/000456.html<br>'''Hint:''' ''Seb: To be investigrated by the File Browser Master aka Yumin.''
* http://public.kitware.com/pipermail/kwwidgets/2007-June/000461.html<br>'''Hint:''' ''Seb: Gonna need some source code/example to reproduce it (Seb?).'' ''Kevin: Source code is in that mail, and I can send you a .tar.gz with a CMake file in it if you'd like. Thanks.'' ''Yumin: Fixed''
* http://public.kitware.com/pipermail/kwwidgets/2007-May/000433.html<br>'''Hint:''' ''Seb: I've heard this has been done but usually no, the command has to be a Tcl command. We would need a Python guru on this one.''

==== From Steve:====

I'd like to have a discussion of [http://www.kwwidgets.org/Wiki/KWWidgets/Tracing GUI Tracing]. In slicer3 we've started to experiment with a MRML-based tracing structure using the scene snapshot infrastructure, but we should consider if this is preferable to a GUI-based solution or not. See, for example, [http://www.na-mic.org/ViewVC/index.cgi/trunk/Base/GUI/vtkSlicerRecordSnapshotWidget.cxx?annotate=3621 the vtkSlicerRecordSnapshotWidget].

Performance of the file browser could be improved (request for multi-threaded solution or a helper process that does the glob'ing so the main application does not block).

Look and feel issues:
* On windows, the menu bar and scroll bar do not get the appearance.<br>'''Hint:''' ''Seb: Nope, that was investigated in the past, menu bar and scroll bar are not themable on Windows, it's a Tk "feature".''
* On linux, font size is sometimes way too small.<br>'''Hint:''' ''Seb: Fonts are themable, did you try assigning a bigger one globally?.'' ''Steve: see Vince's notes below''

* Maybe just me, but I find the new file browser sometimes ignores doubleclicks -- perhaps it is more picky about any small mouse movement between clicks?<br>'''Hint:''' ''Seb: Would the be related to the whole double-click problem mentioned already, i.e. Slicer3 might be capturing double-clicks.''

* Configure event management is still a problem - dragging the split frame or hiding the left panel (with F5) causes a lot of extraneous ConfigureEvents.<br>'''Hint:''' ''Seb: pretty much all the widgets are inside those split frames, hence repacked/relayout by Tk, and that may trigger a ton of ConfigureEvents (not actual 'pack' calls but just Tk re-doing its whole layout, which triggers events). There are so many widgets and different packing parameters, some "rubber-band" effect may be going on where the layout is adjusted iteratively until it stabilizes.''

==== From Gary and James:====

* I'd like to have a discussion of how to make a widget that reads one image plane at a time from a volume to make a multi-data set display. We have an implementation in wxWidgets that reads data from multiple files as a slider that changes the slice number without having to read the entire volumes into memory.<br>'''Hint:''' ''Seb: I think that is demonstrated by the MedicalImageViewer example. The reading/caching/streaming strategy is not KWW related, but VTK related though.''

* When displaying multiple vtkKWRenderWindows at once, the KWwidgets base class generates an error. Being able to display multiple renderwindows at one time is an essential requirement for our project. <br>'''Hint:''' ''Seb: Displaying multiple render windows is done by pretty much all our medical apps at Kitware, so yes, this is doable and we can help. What error message are you referring to?''

* The order of linking the ITK, VTK, TCL, TK and KWwidget libraries so that they do not conflict.<br>'''Hint:''' ''Seb: I'm not aware of ordering conflicts. Have a look at the KWW examples and how they are linked: there is *no* explicit mention to VTK and Tcl/Tk, they are pulled automatically by CMake as part of the dependencies.''

* We want to access the KWwidgets' device client/handles for drawing on the controls.<br>'''Hint:''' ''Seb: if you draw directly, you would probably lose it the next time the UI is refreshed. However, you can use vtkKWCanvas, which is a canvas on top of which you can draw, insert images, etc., and they would be displayed properly. Or you can even embed a render window inside a UI to do 2D or 3D scenes using VTK actors, etc.''

==== From Vincent ====

* There are issues with Slicer3 and fonts under Ubuntu Linux (Fiesty Fawn). The fonts are unreadable under this system. On the same system, Paraview fonts appear just fine. After performing some testing and evaluation, it appears that this is related to the order that fonts are resolved under Linux. We have a little script that will work around this by removing the X11 fonts on this sytem and only using the other system fonts for Slicer3. This is an ugly hack, but was close as we managed to get to track down the issue after approximately 3-4 hours of investigation. <br>'''Hint:''' ''Seb: If we are talking ParaView 2 (the old ones), then they may be specifying their own fonts explicitly at startup, and that can be done by Slicer3 as well, fonts are themable. If ParaView3, then it's a different story since it is using Qt.''

#!/bin/bash

mv /usr/share/fonts/X11 /usr/share/fonts/X11-Slicer3
/opt/Slicer3/Slicer3
mv /usr/share/fonts/X11-Slicer3 /usr/share/fonts/X11

Special topic breakout: KWWidgets

2007-06-27T03:52:15Z

Yumin: /* From Nicole Aucoin */

[[Image:ProjectWeek-2007.png|thumb|300px|left|Return to [[2007_Programming/Project_Week_MIT|Project Week Main Page]]]]

<br><br><br><br>

KWWidgets Breakout Session

June 26th, 1-2pm

Location: [[Meeting_Locations:MIT_Grier_A_%26B|Grier Rooms A & B: 34-401A & 34-401B]]

<br><br><br><br><br><br>

=== Attendees: ===
* Yumin Yuan
* Steve Pieper
* Alex Yarmarkovich
* Wendy Plesniak
* Nicole Aucoin
* Curt Lisle
* Csaba Csoma
* Brad Davis
* David Gobbi
* Kiran Shivanna
* Kevin Teich
* Jeff Hawley
* Xiujuan Geng
* James Harris
* Gary Christensen
* Paul Song
* Alex. Gouaillard
* Vincent Magnotta
* Kiran Shivanna
* Katie Hayes

__NOTOC__

=== Agenda ===

* Roadmap (to help KWWidgets developers prioritize their work)
* Widget feature requests / feedback
* Talk about best approaches to making some widget behavior appear consistent across platforms.
* Separate Tutorial Session for New Users (to happen possibly on Wednesday).<br>'''Hint:''' ''Seb: I just added a tentative Tutorial 1 that tackles creating a very simple composite widget. See [http://kwwidgets.org/cgi-bin/viewcvs.cgi/Examples/Cxx/Tutorial1/?root=KWWidgets Examples/Cxx/Tutorial1]. I need to write the corresponding documentation.''

=== Specific Issues ===

==== From Nicole Aucoin====
Directory selection dialog box on linux:

* Bug: it pops up with a default width such that the right scroll bar isn't visible (see this [http://www.na-mic.org/Wiki/index.php/Image:KWDirectoryBrowserLinuxTooShort.jpg screenshot]; to reproduce it, start up Slicer3, go to the Models module, click on "Load Directory").<br>'''Hint:''' ''Seb: the quickest workaround (Yumin?) at this point would be to make the default width a tad larger so that the right scrollbar button shows up.'' ''Yumin: Fixed.''

* Request: an entry box where I can type a path to reduce clicking through the tree (useful before setting up a favourite)<br>'''Hint:''' ''Seb: Very doable (Yumin?). Let's put all requests in the TODO list and prioritize.''

==== From Curtis Lisle====

* I have had trouble initializing widgets to specific values in advance of user input. For example, I've created interfaces with sliders and buttons but I have had trouble getting the widgets toinitialize in a state different then the default state. For example, setting a slider to value=26 in the middle of its range without dragging the mouse. The API looks like it is there, but I couldn't get it to work for me. I'm sure I tried setting the state before and after creation, if I remember, but no luck. It may be that I'm not updating the GUI successfully after changing values. Update: see [http://www.na-mic.org/Wiki/index.php/Image:KWMeshViewer030607.png screenshot]; by state, I mean the widget-specific state, such as a check button is checked, or a slider is set at a particular value within its range. For example, the "Outline Display" button could be checked ON via API control of the program, not the user clicking on it. Before this picture was taken, I dragged the "element size" slider to 93% via the mouse. I'd like to instantiate the GUI, then set the actual positions and state values of the widgets. I just need clarity on the order of events to invoke through the API or help figuring out what I'm doing wrong. I notice that for KWWidgets, State usually means enabled/disabled to process user events. Instead, I am thinking about setting widget values from the program. I guess for CheckButtons, this would be Get/SetSelectedState(). For a vtkKWScale, this would be SetValue(). I tried setting these but didn't see the effect on the GUI. Maybe I am just not invoking Modified() correctly afterwards.<br>'''Hint:''' ''Seb: Not sure on this one. Setting the values programmatically is something that is done in all our apps and it is a pretty important part of how the application works through callbacks. For most widgets, setting a value before calling Create() *should* work, but it never hurts do make sure it is done *after* Create(), to be on the safe side. There is no need to call Modified(), at least on the core widgets like checkbuttons or scales, the UI should be updated right away. You can even do it at runtime through the Tcl interpreter. So I guess we would need to see the code: it is possible that as soon you set a new value, an event is triggered (like ModifiedEvent) and some other part of your app that would listen to this event would set that widget back to its previous value. In term of Model/View/Controller pattern, the UI/view is supposed to reflect the state/values of a model; if you designed your app that way and it is possible that your controller is always resetting the UI to the current model's value.''

* discuss when UI elements need to have Modified() / Update()invoked to refresh their appearance. I used a histogram widget on a project and had to experiment a lot calling the panel and RenderWidowWidget, etc. before I finally got the histogram to update when the input changed.<br>'''Hint:''' ''Seb: it's mostly widget dependent, but for the core widgets, you should not have to call Modified(), or Update() (which is not part of the vtkKWWidget superclass anyway). For some composite widgets, they should be smart enough to be always 'up to date', but sometimes being up to date is so costly that a manual call to a method is needed (which might be called Update()). The histogram, to my knowledge, is indeed the trickiest one, sorry :) You do not want to have the histogram updated automatically each time somebody modifies one pixel in an image/vtkDataArray, for example. There is nothing in VTK that really says, asynchronously, "this image has been modified enough that it might be time to refresh your histogram". Granularity issues...''.

==== From Brad Davis ====

* Bug: Double-clicking does not work with slicer3 and linux.<br>'''Hint:''' ''Seb: The KWWidgets demo/examples handle double-clicks fine, so my guess is that Slicer3 is intercepting them. Yumin to investigate this issue.''
* Bug: File->Add Data does not use new file browser.<br>'''Hint:''' ''Seb: Sounds like a quick fix (Yumin?).'' ''Steve: this has been fixed.''
* Request: Tree with additional columns widget<br>'''Hint:''' ''Seb: The TkTreeCtrl library is in KWW and allows that, but one need to wrap it inside a C++ class, and this is a lot of work (Seb?). Let's put all requests in the TODO list and prioritize.'' ''Steve: there was discussion about exposing the TkTreeCtrl in the tcl interp so users can access it directly with Script() - is this an easy thing to do now?'' ''Seb: yes, that's very easy, but that means we are going to see tons of ugly Tcl code in the middle of C++ code :)'' ''Seb: OK, DONE, it's in. I compiled and tested on Win32. I compiled but could not test on Linux. TkTreeCtrl documentation can be found [http://tktreectrl.sourceforge.net/ here]. Download the TkTreeCtrl distribution, then from Slicer3/KWWidgets interactor, source demos/demo.tcl, then issue: wm deiconify .'' ''Steve: Thanks! I'll give it a try. My plan, actually, is to have some very pretty tcl code that uses this feature (no comment on the aesthetic qualities of C++ code!).'' ''Seb: I had to disable it until the VS7 build is fixed. To play with it though, edit Utilities\TkTreeCtrl\TkTreeCtrl.cmake and change the code to SET(${supported} 1). This is such a huge (50,000 lines) library that I would suggest you guys start playing with it at the Tcl level and that we use that feedback to create a C++ API that would not have to expose every thing features but the ones you use the most.''

====From Alex:====

* Request: I would like to address the performance of building GUI in slicer3 Modules. When selecting a module for the first time (Volumes or Models) it takes noticable time before the UI panel is displayed.<br>'''Hint:''' ''Seb: Well, you can't have your cake and eat it too :)) We delayed the creation of modules so that Slicer3 starts up faster. But one way or the other, the modules GUI has to be created. I just tried on my laptop on Win32, and I did not notice anything slow when I selected a few modules. Which ones are slow? Maybe one of the slow modules is actually doing more than just creating GUI when it is initialized.''

* Request: Customizable tree widget similar to slicer2 model hierarchy editor: allow to add push-buttons or check boxes for the individual tree leaves.<br>'''Hint:''' ''Seb: The TkTreeCtrl library is in KWW and allows that, but one need to wrap it inside a C++ class, and this is a lot of work (Seb?). Unless, as suggested by Steve, you want to expose the TkTreeCtrl library directly and do it from Tcl. Let's put all requests in the TODO list and prioritize.''

====From Wendy:====

Mostly pesky things:
* Request: Creating special versions of menubutton drop-down menus with scroll capability.<br>'''Hint:''' ''Seb: There is no such native widget, so we would have to create a composite widget mixing a button and a scroll list (Seb or Yumin?). A day or two worth probably. Let's put all requests in the TODO list and prioritize.''
* Request: checkbuttons and radiobuttons with consistent "on/off" visual representation across platforms. (either special Slicer widgets or KWWidgets).<br>'''Hint:''' ''Seb: Tcl/Tk does not provide an API to modify that visual representation (called the 'indicator'), since it is trying to use the native widgets when possible. However, you can emulate that behavior by setting an image for both unselected and selected state (SetImageToPredefinedIcon, SetSelectImageToPredefinedIcon), then make sure the image does not override the text (SetCompoundModeToLeft), remove the usual indicator (SetIndicatorVisibility), and remove the border of what is now a button (SetBorderWidth). All of those calls can be made into a theme. I've updated the KWThemeExample (check the green theme) to show how it is done. I would recommend against it, as a lot of Slicer3 GUI already uses SetImage and SetSelectImage to provide graphical checkbuttons instead of textual ones. I'm not confident this would play well, but let's try.''

It would be good to decide on a strategy for addressing these things.

* Request: Also, if a radiobutton's indicator visibility is off, the widget gets rendered with a 3D effect (even if we're using an icon to display the button's on/off state). Can we turn that 3D effect off?<br>'''Hint:''' ''Seb: Not to my knowledge, it might be a Tk "feature" but try SetBorderWidth 0''

==== From KWW-Users mailing list====

* http://public.kitware.com/pipermail/kwwidgets/2007-June/000456.html<br>'''Hint:''' ''Seb: To be investigrated by the File Browser Master aka Yumin.''
* http://public.kitware.com/pipermail/kwwidgets/2007-June/000461.html<br>'''Hint:''' ''Seb: Gonna need some source code/example to reproduce it (Seb?).'' ''Kevin: Source code is in that mail, and I can send you a .tar.gz with a CMake file in it if you'd like. Thanks.''
* http://public.kitware.com/pipermail/kwwidgets/2007-May/000433.html<br>'''Hint:''' ''Seb: I've heard this has been done but usually no, the command has to be a Tcl command. We would need a Python guru on this one.''

==== From Steve:====

I'd like to have a discussion of [http://www.kwwidgets.org/Wiki/KWWidgets/Tracing GUI Tracing]. In slicer3 we've started to experiment with a MRML-based tracing structure using the scene snapshot infrastructure, but we should consider if this is preferable to a GUI-based solution or not. See, for example, [http://www.na-mic.org/ViewVC/index.cgi/trunk/Base/GUI/vtkSlicerRecordSnapshotWidget.cxx?annotate=3621 the vtkSlicerRecordSnapshotWidget].

Performance of the file browser could be improved (request for multi-threaded solution or a helper process that does the glob'ing so the main application does not block).

Look and feel issues:
* On windows, the menu bar and scroll bar do not get the appearance.<br>'''Hint:''' ''Seb: Nope, that was investigated in the past, menu bar and scroll bar are not themable on Windows, it's a Tk "feature".''
* On linux, font size is sometimes way too small.<br>'''Hint:''' ''Seb: Fonts are themable, did you try assigning a bigger one globally?.'' ''Steve: see Vince's notes below''

* Maybe just me, but I find the new file browser sometimes ignores doubleclicks -- perhaps it is more picky about any small mouse movement between clicks?<br>'''Hint:''' ''Seb: Would the be related to the whole double-click problem mentioned already, i.e. Slicer3 might be capturing double-clicks.''

* Configure event management is still a problem - dragging the split frame or hiding the left panel (with F5) causes a lot of extraneous ConfigureEvents.<br>'''Hint:''' ''Seb: pretty much all the widgets are inside those split frames, hence repacked/relayout by Tk, and that may trigger a ton of ConfigureEvents (not actual 'pack' calls but just Tk re-doing its whole layout, which triggers events). There are so many widgets and different packing parameters, some "rubber-band" effect may be going on where the layout is adjusted iteratively until it stabilizes.''

==== From Gary and James:====

* I'd like to have a discussion of how to make a widget that reads one image plane at a time from a volume to make a multi-data set display. We have an implementation in wxWidgets that reads data from multiple files as a slider that changes the slice number without having to read the entire volumes into memory.<br>'''Hint:''' ''Seb: I think that is demonstrated by the MedicalImageViewer example. The reading/caching/streaming strategy is not KWW related, but VTK related though.''

* When displaying multiple vtkKWRenderWindows at once, the KWwidgets base class generates an error. Being able to display multiple renderwindows at one time is an essential requirement for our project. <br>'''Hint:''' ''Seb: Displaying multiple render windows is done by pretty much all our medical apps at Kitware, so yes, this is doable and we can help. What error message are you referring to?''

* The order of linking the ITK, VTK, TCL, TK and KWwidget libraries so that they do not conflict.<br>'''Hint:''' ''Seb: I'm not aware of ordering conflicts. Have a look at the KWW examples and how they are linked: there is *no* explicit mention to VTK and Tcl/Tk, they are pulled automatically by CMake as part of the dependencies.''

* We want to access the KWwidgets' device client/handles for drawing on the controls.<br>'''Hint:''' ''Seb: if you draw directly, you would probably lose it the next time the UI is refreshed. However, you can use vtkKWCanvas, which is a canvas on top of which you can draw, insert images, etc., and they would be displayed properly. Or you can even embed a render window inside a UI to do 2D or 3D scenes using VTK actors, etc.''

==== From Vincent ====

* There are issues with Slicer3 and fonts under Ubuntu Linux (Fiesty Fawn). The fonts are unreadable under this system. On the same system, Paraview fonts appear just fine. After performing some testing and evaluation, it appears that this is related to the order that fonts are resolved under Linux. We have a little script that will work around this by removing the X11 fonts on this sytem and only using the other system fonts for Slicer3. This is an ugly hack, but was close as we managed to get to track down the issue after approximately 3-4 hours of investigation. <br>'''Hint:''' ''Seb: If we are talking ParaView 2 (the old ones), then they may be specifying their own fonts explicitly at startup, and that can be done by Slicer3 as well, fonts are themable. If ParaView3, then it's a different story since it is using Qt.''

#!/bin/bash

mv /usr/share/fonts/X11 /usr/share/fonts/X11-Slicer3
/opt/Slicer3/Slicer3
mv /usr/share/fonts/X11-Slicer3 /usr/share/fonts/X11

Special topic breakout: KWWidgets

2007-06-19T02:11:48Z

Yumin: /* Agenda */

AHM 2007:Slicer3 Developer Feedback

2007-01-08T16:14:31Z

Yumin: /* EM */

Back to [[AHM_2007#Wednesday.2C_Jan_10_2007:Project_Activities]]

=Topics for this session:=

* Information to the developer community about how these projects have approached developing their code for slicer3 (what's the architecture of their modules)
* Feedback to the base developers about what was easy or hard in the code writing
* What would they like to see in the slicer3 base and/or in VTK, ITK, KKWidgets, etc to make the module development more effective

=DTI=
==DTI Module: Raul San Jose==

==Tractography Module: [http://www.na-mic.org/Wiki/index.php/User:Lauren Lauren O'Donnell]==

===Module Architecture ===
* Tractography is represented as a vtkMRMLFiberBundleNode. Display parameters are stored in a vtkMRMLFiberBundleDisplayNode, and storage (load/save) handled by vtkMRMLFiberBundleStorageNode. Basic operations of adding new fiber bundles, etc. are in vtkMRMLFiberBundleLogic.
* vtkMRMLFiberBundleDisplayLogic is needed to create "hidden" slicer models that will be rendered in the MRML scene. Otherwise base classes would have to be heavily edited to handle tractography display using the display node.
* There will be several slicer module units to handle tractography. The division will be by Load/Save/Display, Editing (to manually add, select, delete, or to use ROI selection), Seeding, etc.
* Initial work is on the Load/Save/Display and the entire MRML infrastructure.

===Feedback on Slicer3 ===
* When adding a new module and a new datatype, it is difficult to find the places in Base code that must be edited.
* It is also difficult to understand how the MRML callback happens, and how to set a new one up. It would be great to have a simple overview on the observers somewhere (or even the SVN web for easier code navigation).
* If a vtkMRMLNode inherits from another one used in slicer (for example mine inherits from the modelNode currently) then the subclass will show up on all of the superclass menus. This is because the vtk "IsA" function is used rather than a direct match. I believe this is feature that is not desired.

===What I would like in Slicer3 base...===
* More documentation, comments, etc.

=EM=

===Primary Developers===

Yumin Yuan, Sebastien Barre, Brad Davis

===Module Description===

The following description is from the [[Slicer3:EM |project wiki page]]:

The goal of this project is the creation of a module in Slicer 3 integrating the EMSegment algorithm (Pohl et al.), an automatic segmentation algorithm for medical images that previously existed in Slicer 2. As in Slicer 2, the user is able to adjust the algorithm to a variety of imaging protocols as well as anatomical structures and run the segmenter on large data set. However, the configuration of the algorithm is greatly simplified in Slicer 3 as the user is guided by a work flow. The target audience for this module is someone familiar with brain atlases and tissue labels, not a computer scientist.

As of January 1, 2007, the EMSegment module is substantially complete and has been checked into the Slicer3 SVN repository. It was previewed at the December 2006 NAMIC meeting in Clifton Park and will be a demonstration at the NAMIC All-Hands meeting in Salt Lake City on Wednesday 10 January 2007. Future work includes adding advanced and experimental algorithm parameters, improving visualization of parameter settings, and incorporating tissue labels from a controlled vocabulary.

===Architecture===

The module is implemented as a programmatic Slicer3 module because it
requires a large degree of interaction with the user, the data stored
in the MRML tree, and the Slicer3 GUI itself. Because the MRML node
structure is rather complicated (for example the anatomical tissue
hierarchy and a large number of interdependent nodes) the Logic class
is solely responsible for maintaining and accessing these nodes. The
Logic class provides an API that the GUI code uses to access and
modify data. The Logic class also wraps the algorithm code itself.

*the parameters for the algorithm are stored in a number of MRML nodes:
**EMSGlobalParametersNode (global algorithm parameters)
**EMSTreeNode (tree structure for hierarchy of anatomical structures)
**EMSTreeParametersNode (algorithm parameters assigned to each tree node)
**EMSAtlasNode (image data and parameters for atlas)
**EMSTargetNode (image data for target images (to be segmented))
**EMSVolumeCollectionNode (essentially a hash map of image volumes, used for atlas and target nodes)
**EMSTemplateNode (collects global parameters and tree structure)
**EMSSegmenterNode (collectes template and output data)
**EMSNode (highest level node, reference to EMSegmenterNode and storage location for module specific data)
*the logic is responsible for
**maintaining and traversing the data in the mrml scene
**providing an interface for the GUI to access the data
**providing an interface for the segmentation algorithm

===GUI===

The EM GUI includes eight steps implemented with KWWidgets and vtkKWWizardWorkflow framework. Each step is written as a single class, derived from a super class vtkEMSegmentStep. All steps are initialized with parameters from the vtkKWEMSegmentLogic class, and once a user interacts with the UI, the new parameters (if there are) will be passed to the logic class immediately.

There is also a brief description of these steps in the [[Slicer3:EM |project wiki page]]:

*1/8 vtkEMSegmentParametersSetStep: Select parameter set or create new parameters
This can be used as a convenient method to reload all the parameters of a previous EM procedure.
*2/8 vtkEMSegmentAnatomicalStructureStep: Define a hierarchy of anatomical structures
The anatomical structures are represented with a a tree structure using vtkKWTree, which can be directly manipulated to assign attributes to each anatomical structure, such as name, color, etc.
*3/8 vtkEMSegmentSpatialPriorsStep: Assign atlases for anatomical structures
Again, the same tree structure is used here to assign atlas to each anatomical structure.
*4/8 vtkEMSegmentIntensityImagesStep: Choose the set of images that will be segmented
The widget used here, vtkKWListBoxToListBoxSelectionEditor, allows selection of images in different orders, which is actually important in following steps.
*5/8 vtkEMSegmentIntensityDistributionsStep: Define intensity distribution for each anatomical structure
Same tree structure is used for anatomical structures. This step is where EM module is interacting
directly with Slicer3 main application, namely the mouse events from vtkSlicerSliceGUI are processed
to get sampling intensities and coordinates.
*6/8 vtkEMSegmentNodeParametersStep: Specify node-based segmentation parameters
There are many KWWidgets used here (vtkKWTree, vtkKWNotebook, vtkKWMultiColumnList, vtkKWEntryWithScale etc), and given the limited UI space we have , it does take some creativity to arrange everything nicely.
*7/8 vtkEMSegmentRegistrationParametersStep: Specify atlas-to-target registration parameters
A simple step to assign registration parameters.
*8/8 vtkEMSegmentRunSegmentationStep: Save work and apply EM Algorithm to segment target images
Again, this step has many gui components.

===Feedback===

*the community was extreemly helpful!
*over all our experience was very positive, but more examples and documentation would be helpful
*used wiki page describing how to build a module---this documentation was helpful
*used GradientAnisotropic module as a template---more examples (and more complicated examples) would be helpful
*we had to write new MRML classes because the slicer2 classes used nested tags and Slicer3 uses references
*could our mrml tree class be generalized for others to use?
*it seems like the creation of most MRML classes could be automated
*it will be very helpful to have a wiki page describing how to observe and process events from main application, such as MRML nodes events, mouse events, progress events etc.

=IGT=
[[Image:Slicer3-IGT-Architecture.png|300px|thumb| Blockdiagram of the IGT module]]

Noby Hata, Haiying Liu, Simon DiMaio and Raimundo Sierra
==Hisotory of our involvement==
*Summer 2006: Haiying Liu joined the core development team and translated '''MRAblation''' module from the Slicer 2.6. There he
**Learned the architecture of Slicer 3
**Got familiar with KWWidgets

*Fall 2006: Haiying Liu implemented '''IGT Demo''' module. There he
**Contributed vtkIGTDemoLogic and vtkIGTDemoGUI classes in the Base
**Added an option for CMake to link the external library [http://studierstube.icg.tu-graz.ac.at/opentracker/ '''OpenTracker''']

*December 2006: Two additional members joined IGT-Slier3 task force
**Simon DiMaio representing prostate robot project [[http://crisp.cit.nih.gov/crisp/CRISP_LIB.getdoc?textkey=7070178&p_grant_num=1R01CA111288-01A1&p_query=&ticket=29242393&p_audit_session_id=195929678&p_keywords=| PI Tempany1R01CA111288]]
**Raimundo Sierra representing Neuroendoscope project [[http://crisp.cit.nih.gov/crisp/CRISP_LIB.getdoc?textkey=7126732&p_grant_num=5U41RR019703-02&p_query=&ticket=29242406&p_audit_session_id=195929678&p_keywords=| PI Jolesz 5U41RR019703]]

*January 4th, 2007 at 1249 Boylston Office: Implementation strategy for IGT-Slicer has been discussed and preliminary design proposed by Hata and Liu (see the figure at the left)
**Slicer3/Base/GUI/vtkSlicerIGTGUI: cxx class
***Creates GUI components for IGT application modules
***Handles interface update
**Slicer3/Base/Logic/vtkSlicerIGTLogic: cxx class
***Processes shared logics for IGT applications, such as handling communication with tracking server
***Wraps tracker-specific logics
**Slicer3/Libs/IGT: IGT lib ('''Place holder classes committed to SVN (NH)'''
***Patient to image registration
***Tool calibration
***Specific tracker logics
***Online image I/O
***Special image processing
***More...
**Slicer3/Modules: IGT applications
***MRAbration
***Neurosurgery
***ProstateBiosy
***More...

==Our timeline==
*IGT tutorial demo on alpha (done)
*IGT tutorial demo on beta (during AHM week by Liu)
*Neurosurgical navigation with GE Nav (spring to summer)
*Building with IGSTK (during AHM week, by Hata)
*Neurosurgical navigationi with JHU robot (by March)
*Integration to MR/T (fall)

==Feedback==
*genutiltest.tcl is great!
*Guideline for creating library and modules would be helpful for those joining Slicer community. Template (blank) code may be helpful.
*Don't understand what "NA-MIC sandbox" means...
*Application-specific customization and streamlining of the GUI will be important for IGT applications. To what extent is this possible?
*Performance bounds are important to understand for IGT applications. Can we talk about determinism and performance as Slicer scales?
*How to specify module dependency
*README.txt to add a module
*What we can do and cannot do with a command line module

AHM 2007:Slicer3 Developer Feedback

2007-01-08T15:40:32Z

Yumin: /* EM */

Back to [[AHM_2007#Wednesday.2C_Jan_10_2007:Project_Activities]]

=Topics for this session:=

* Information to the developer community about how these projects have approached developing their code for slicer3 (what's the architecture of their modules)
* Feedback to the base developers about what was easy or hard in the code writing
* What would they like to see in the slicer3 base and/or in VTK, ITK, KKWidgets, etc to make the module development more effective

=DTI=
==DTI Module: Raul San Jose==

==Tractography Module: [http://www.na-mic.org/Wiki/index.php/User:Lauren Lauren O'Donnell]==

===Module Architecture ===
* Tractography is represented as a vtkMRMLFiberBundleNode. Display parameters are stored in a vtkMRMLFiberBundleDisplayNode, and storage (load/save) handled by vtkMRMLFiberBundleStorageNode. Basic operations of adding new fiber bundles, etc. are in vtkMRMLFiberBundleLogic.
* vtkMRMLFiberBundleDisplayLogic is needed to create "hidden" slicer models that will be rendered in the MRML scene. Otherwise base classes would have to be heavily edited to handle tractography display using the display node.
* There will be several slicer module units to handle tractography. The division will be by Load/Save/Display, Editing (to manually add, select, delete, or to use ROI selection), Seeding, etc.
* Initial work is on the Load/Save/Display and the entire MRML infrastructure.

===Feedback on Slicer3 ===
* When adding a new module and a new datatype, it is difficult to find the places in Base code that must be edited.
* It is also difficult to understand how the MRML callback happens, and how to set a new one up. It would be great to have a simple overview on the observers somewhere (or even the SVN web for easier code navigation).
* If a vtkMRMLNode inherits from another one used in slicer (for example mine inherits from the modelNode currently) then the subclass will show up on all of the superclass menus. This is because the vtk "IsA" function is used rather than a direct match. I believe this is feature that is not desired.

===What I would like in Slicer3 base...===
* More documentation, comments, etc.

=EM=

===Primary Developers===

Yumin Yuan, Sebastien Barre, Brad Davis

===Module Description===

The following description is from the [[Slicer3:EM |project wiki page]]:

The goal of this project is the creation of a module in Slicer 3 integrating the EMSegment algorithm (Pohl et al.), an automatic segmentation algorithm for medical images that previously existed in Slicer 2. As in Slicer 2, the user is able to adjust the algorithm to a variety of imaging protocols as well as anatomical structures and run the segmenter on large data set. However, the configuration of the algorithm is greatly simplified in Slicer 3 as the user is guided by a work flow. The target audience for this module is someone familiar with brain atlases and tissue labels, not a computer scientist.

As of January 1, 2007, the EMSegment module is substantially complete and has been checked into the Slicer3 SVN repository. It was previewed at the December 2006 NAMIC meeting in Clifton Park and will be a demonstration at the NAMIC All-Hands meeting in Salt Lake City on Wednesday 10 January 2007. Future work includes adding advanced and experimental algorithm parameters, improving visualization of parameter settings, and incorporating tissue labels from a controlled vocabulary.

===Architecture===

The module is implemented as a programmatic Slicer3 module because it
requires a large degree of interaction with the user, the data stored
in the MRML tree, and the Slicer3 GUI itself. Because the MRML node
structure is rather complicated (for example the anatomical tissue
hierarchy and a large number of interdependent nodes) the Logic class
is solely responsible for maintaining and accessing these nodes. The
Logic class provides an API that the GUI code uses to access and
modify data. The Logic class also wraps the algorithm code itself.

*the parameters for the algorithm are stored in a number of MRML nodes:
**EMSGlobalParametersNode (global algorithm parameters)
**EMSTreeNode (tree structure for hierarchy of anatomical structures)
**EMSTreeParametersNode (algorithm parameters assigned to each tree node)
**EMSAtlasNode (image data and parameters for atlas)
**EMSTargetNode (image data for target images (to be segmented))
**EMSVolumeCollectionNode (essentially a hash map of image volumes, used for atlas and target nodes)
**EMSTemplateNode (collects global parameters and tree structure)
**EMSSegmenterNode (collectes template and output data)
**EMSNode (highest level node, reference to EMSegmenterNode and storage location for module specific data)
*the logic is responsible for
**maintaining and traversing the data in the mrml scene
**providing an interface for the GUI to access the data
**providing an interface for the segmentation algorithm

===GUI===

The EM GUI includes eight steps implemented with KWWWidgets and workflow framework (see Sebastein's description). Each step is written as a single class, derived from a super class vtkEMSegmentStep. All steps are initialized with parameters from the vtkKWEMSegmentLogic class, and once a user interacts with the UI, the new parameters (if there are) will be passed to the logic class immediately.

There is also a brief description of these steps in the [[Slicer3:EM |project wiki page]]:

*1/8 vtkEMSegmentParametersSetStep: Select parameter set or create new parameters
This can be used as a convenient method to reload all the parameters of a previous EM procedure.
*2/8 vtkEMSegmentAnatomicalStructureStep: Define a hierarchy of anatomical structures
The anatomical structures are represented with a a tree structure using vtkKWTree, which can be directly manipulated to assign attributes to each anatomical structure, such as name, color, etc.
*3/8 vtkEMSegmentSpatialPriorsStep: Assign atlases for anatomical structures
Again, the same tree structure is used here to assign atlas to each anatomical structure.
*4/8 vtkEMSegmentIntensityImagesStep: Choose the set of images that will be segmented
The widget used here, vtkKWListBoxToListBoxSelectionEditor, allows selection of images in different orders, which is actually important in following steps.
*5/8 vtkEMSegmentIntensityDistributionsStep: Define intensity distribution for each anatomical structure
Same tree structure is used for anatomical structures. This step is where EM module is interacting
directly with Slicer3 main application, namely the mouse events from vtkSlicerSliceGUI are processed
to get sampling intensities and coordinates.
*6/8 vtkEMSegmentNodeParametersStep: Specify node-based segmentation parameters
There are many KWWidgets used here (vtkKWTree, vtkKWNotebook, vtkKWMultiColumnList, vtkKWEntryWithScale etc), and given the limited UI space we have , it does take some creativity to arrange everything nicely.
*7/8 vtkEMSegmentRegistrationParametersStep: Specify atlas-to-target registration parameters
A simple step to assign registration parameters.
*8/8 vtkEMSegmentRunSegmentationStep: Save work and apply EM Algorithm to segment target images
Again, this step has many gui components.

===Feedback===

*the community was extreemly helpful!
*over all our experience was very positive, but more examples and documentation would be helpful
*used wiki page describing how to build a module---this documentation was helpful
*used GradientAnisotropic module as a template---more examples (and more complicated examples) would be helpful
*we had to write new MRML classes because the slicer2 classes used nested tags and Slicer3 uses references
*could our mrml tree class be generalized for others to use?
*it seems like the creation of most MRML classes could be automated
*it will be very helpful to have a wiki page describing how to observe and process events from main application, such as MRML nodes events, mouse events, progress events etc.

=IGT=
[[Image:Slicer3-IGT-Architecture.png|300px|thumb| Blockdiagram of the IGT module]]

Noby Hata, Haiying Liu, Simon DiMaio and Raimundo Sierra
==Hisotory of our involvement==
*Summer 2006: Haiying Liu joined the core development team and translated '''MRAblation''' module from the Slicer 2.6. There he
**Learned the architecture of Slicer 3
**Got familiar with KWWidgets

*Fall 2006: Haiying Liu implemented '''IGT Demo''' module. There he
**Contributed vtkIGTDemoLogic and vtkIGTDemoGUI classes in the Base
**Added an option for CMake to link the external library [http://studierstube.icg.tu-graz.ac.at/opentracker/ '''OpenTracker''']

*December 2006: Two additional members joined IGT-Slier3 task force
**Simon DiMaio representing prostate robot project [[http://crisp.cit.nih.gov/crisp/CRISP_LIB.getdoc?textkey=7070178&p_grant_num=1R01CA111288-01A1&p_query=&ticket=29242393&p_audit_session_id=195929678&p_keywords=| PI Tempany1R01CA111288]]
**Raimundo Sierra representing Neuroendoscope project [[http://crisp.cit.nih.gov/crisp/CRISP_LIB.getdoc?textkey=7126732&p_grant_num=5U41RR019703-02&p_query=&ticket=29242406&p_audit_session_id=195929678&p_keywords=| PI Jolesz 5U41RR019703]]

*January 4th, 2007 at 1249 Boylston Office: Implementation strategy for IGT-Slicer has been discussed and preliminary design proposed by Hata and Liu (see the figure at the left)
**Slicer3/Base/GUI/vtkSlicerIGTGUI: cxx class
***Creates GUI components for IGT application modules
***Handles interface update
**Slicer3/Base/Logic/vtkSlicerIGTLogic: cxx class
***Processes shared logics for IGT applications, such as handling communication with tracking server
***Wraps tracker-specific logics
**Slicer3/Libs/IGT: IGT lib ('''Place holder classes committed to SVN (NH)'''
***Patient to image registration
***Tool calibration
***Specific tracker logics
***Online image I/O
***Special image processing
***More...
**Slicer3/Modules: IGT applications
***MRAbration
***Neurosurgery
***ProstateBiosy
***More...

==Our timeline==
*IGT tutorial demo on alpha (done)
*IGT tutorial demo on beta (during AHM week by Liu)
*Neurosurgical navigation with GE Nav (spring to summer)
*Building with IGSTK (during AHM week, by Hata)
*Neurosurgical navigationi with JHU robot (by March)
*Integration to MR/T (fall)

==Feedback==
*genutiltest.tcl is great!
*Guideline for creating library and modules would be helpful for those joining Slicer community. Template (blank) code may be helpful.
*Don't understand what "NA-MIC sandbox" means...
*Application-specific customization and streamlining of the GUI will be important for IGT applications. To what extent is this possible?
*Performance bounds are important to understand for IGT applications. Can we talk about determinism and performance as Slicer scales?
*How to specify module dependency
*README.txt to add a module
*What we can do and cannot do with a command line module