NAMIC Wiki - User contributions [en]

2014 Winter Project Week:NonlinearTransforms

2014-01-09T15:55:27Z

Alexy: /* Project Description */

__NOTOC__
<gallery>
Image:PW-SLC2014.png|[[2014_Winter_Project_Week#Projects|Projects List]]
</gallery>

==Key Investigators==
* Isomics: Alex Yarmarkovich
* Queen's University: Andras Lasso

==Project Description==

<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Objective</h3>
* Identify use scenarios for nonlinear transform.
* Need to copy-harden Volumes/Models.
* Need to harden to a specified parent.
* How to insure that all modules use transformed volumes/models.
</div>
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Approach, Plan</h3>
* Review initial implementation by Alex: https://github.com/jcfr/Slicer/tree/add-nonlinear-transform-support
* Documentation: [[https://www.slicer.org/slicerWiki/index.php/Documentation/Labs/NonlinearTransforms | here ]]
* Identify what is missing or not working.
* Propose integration into slicer plan.
</div>
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Progress</h3>
* Functionality was reviewed and approved for integration in Slicer.
* The following bugs/enhancements have been suggested:
** hardening and reslice should set bg pixel to min value of the volume.
** fiducials/markup do not transform the same way under linear and non-linear transforms, investigate.
** need non-linear transform widget that selects a reference volume
* Suggestions for the future work:
** investigate volume rendering with non-linear transforms
** add copy volumes/models/markup in the Data module to cache the hardening volumes
** API for transformable GetTaransformedData() that cashes transformed data to World (Andras will write a proposal)
** integrate grid visualization extension in Transforms module
</div>

==Discussion==
* It should work correctly for all basic Slicer data types: volumes (all kinds, check labelmap and make sure nearest neighbor interpolation is used), models, markups, ROI (the box shape has to be preserved, so the bounding box of the transformed corner points could be used as new corner points), annotations, ruler (transform the endpoints only, no need to warp the line)
* Add some information about non-linear transforms to the Transforms module GUI. Even something as simple as showing the non-linear transforms in the module selector would help and then if the user selects it, it would just show the transform's type and maybe also some basic parameters (extent, number of points, etc.). In the long term, the transform visualizer module could be used to show the transform in 2D and 3D views.
* It is necessary to be able to specify output volume origin, spacing, direction, and extent. In some cases some reasonable default value can be computed or the creator of the transform (e.g., a registration algorithm) can set this information in the transform. In the future it will have to be accessible to the user (set the values similarly as in the Volume node and also allow them to copy the info from a chosen volume)
* For some cases (e.g., interactive image warping in a slice viewer) it is preferable to let modules access the original volume and the transform (as it is done currently for linear transforms), but for other cases (such as volume rendering, CLI execution, labelmap statistics, etc.) the full volume in world coordinate system is needed. As computing a full transformed volume can take a long time (1 minute or even longer), it is not convenient to recompute it each time a module needs the deformed volume. Proposed solution:
** Add a coordinate system parameter (CoordinateSystem enum: COORD_OBJECT, COORD_WORLD) to all spatial data accessor methods in the MRML node
*** vtkImageData* vtkMRMLVolumeNodeGetImageData() => vtkImageData* vtkMRMLVolumeNodeGetImageData(CoordinateSystem coord=COORD_OBJECT)
*** vtkPolyData* GetPolyData() => vtkPolyData* GetPolyData(CoordinateSystem coord=COORD_OBJECT)
*** ...
** If COORD_OBJECT is passed (default) then the original, non-warped data is returned. If COORD_WORLD is passed as a parameter, then the warped data is returned. Other frequently used coordinate systems can be defined as well.
** The version of the data returned on COORD_OBJECT is the original one, which is also stored on disk, and it is not changed when the ParentTransformNode is changed.
** The version that is returned on COORD_WORLD is not stored on disk, but kept in memory (stored in the MRML node) and returned whenever it is needed. If some other objects keep a reference to the data object that was returned on COORD_WORLD (reference count>1) then when the ParentTransformNode is changed then the warped data is updated as well.

2014 Winter Project Week:NonlinearTransforms

2014-01-09T15:52:46Z

Alexy: /* Project Description */

__NOTOC__
<gallery>
Image:PW-SLC2014.png|[[2014_Winter_Project_Week#Projects|Projects List]]
</gallery>

==Key Investigators==
* Isomics: Alex Yarmarkovich
* Queen's University: Andras Lasso

==Project Description==

<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Objective</h3>
* Identify use scenarios for nonlinear transform.
* Need to copy-harden Volumes/Models.
* Need to harden to a specified parent.
* How to insure that all modules use transformed volumes/models.
</div>
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Approach, Plan</h3>
* Review initial implementation by Alex: https://github.com/jcfr/Slicer/tree/add-nonlinear-transform-support
* Documentation: https://www.slicer.org/slicerWiki/index.php/Documentation/Labs/NonlinearTransforms
* Identify what is missing or not working.
* Propose integration into slicer plan.
</div>
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Progress</h3>
* Functionality was reviewed and approved for integration in Slicer.
* The following bugs/enhancements have been suggested:
** hardening and reslice should set bg pixel to min value of the volume.
** fiducials/markup do not transform the same way under linear and non-linear transforms, investigate.
** need non-linear transform widget that selects a reference volume
* Suggestions for the future work:
** investigate volume rendering with non-linear transforms
** add copy volumes/models/markup in the Data module to cache the hardening volumes
** API for transformable GetTaransformedData() that cashes transformed data to World (Andras will write a proposal)
** integrate grid visualization extension in Transforms module
</div>

==Discussion==
* It should work correctly for all basic Slicer data types: volumes (all kinds, check labelmap and make sure nearest neighbor interpolation is used), models, markups, ROI (the box shape has to be preserved, so the bounding box of the transformed corner points could be used as new corner points), annotations, ruler (transform the endpoints only, no need to warp the line)
* Add some information about non-linear transforms to the Transforms module GUI. Even something as simple as showing the non-linear transforms in the module selector would help and then if the user selects it, it would just show the transform's type and maybe also some basic parameters (extent, number of points, etc.). In the long term, the transform visualizer module could be used to show the transform in 2D and 3D views.
* It is necessary to be able to specify output volume origin, spacing, direction, and extent. In some cases some reasonable default value can be computed or the creator of the transform (e.g., a registration algorithm) can set this information in the transform. In the future it will have to be accessible to the user (set the values similarly as in the Volume node and also allow them to copy the info from a chosen volume)
* For some cases (e.g., interactive image warping in a slice viewer) it is preferable to let modules access the original volume and the transform (as it is done currently for linear transforms), but for other cases (such as volume rendering, CLI execution, labelmap statistics, etc.) the full volume in world coordinate system is needed. As computing a full transformed volume can take a long time (1 minute or even longer), it is not convenient to recompute it each time a module needs the deformed volume. Proposed solution:
** Add a coordinate system parameter (CoordinateSystem enum: COORD_OBJECT, COORD_WORLD) to all spatial data accessor methods in the MRML node
*** vtkImageData* vtkMRMLVolumeNodeGetImageData() => vtkImageData* vtkMRMLVolumeNodeGetImageData(CoordinateSystem coord=COORD_OBJECT)
*** vtkPolyData* GetPolyData() => vtkPolyData* GetPolyData(CoordinateSystem coord=COORD_OBJECT)
*** ...
** If COORD_OBJECT is passed (default) then the original, non-warped data is returned. If COORD_WORLD is passed as a parameter, then the warped data is returned. Other frequently used coordinate systems can be defined as well.
** The version of the data returned on COORD_OBJECT is the original one, which is also stored on disk, and it is not changed when the ParentTransformNode is changed.
** The version that is returned on COORD_WORLD is not stored on disk, but kept in memory (stored in the MRML node) and returned whenever it is needed. If some other objects keep a reference to the data object that was returned on COORD_WORLD (reference count>1) then when the ParentTransformNode is changed then the warped data is updated as well.

2014 Winter Project Week:NonlinearTransforms

2014-01-09T15:49:26Z

Alexy: /* Project Description */

__NOTOC__
<gallery>
Image:PW-SLC2014.png|[[2014_Winter_Project_Week#Projects|Projects List]]
</gallery>

==Key Investigators==
* Isomics: Alex Yarmarkovich
* Queen's University: Andras Lasso

==Project Description==

<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Objective</h3>
* Identify use scenarios for nonlinear transform.
* Need to copy-harden Volumes/Models.
* Need to harden to a specified parent.
* How to insure that all modules use transformed volumes/models.
</div>
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Approach, Plan</h3>
* Review initial implementation by Alex: https://github.com/jcfr/Slicer/tree/add-nonlinear-transform-support
* Documentation: https://www.slicer.org/slicerWiki/index.php/Documentation/Labs/NonlinearTransforms
* Identify what is missing or not working.
* Propose integration into slicer plan.
</div>
<div style="width: 27%; float: left; padding-right: 3%;">
<h3>Progress</h3>
* Functionality was reviewed and approved for integration in Slicer.
* The following bugs/enhancements have been suggested:
** hardening and reslice should set bg pixel to min value of the volume.
** fiducials/markup do not transform correctly, investigate.
** need non-linear transform widget that edits reference volume
* Suggestions for the future work:
** investigate volume rendering with non-linear transforms
** add copy volumes/models/markup in the Data module
** API for transformable GetTaransformedData() that cashes transformed data to World (Andros to write a proposal)
** integrate grid visualization extension in Transforms module
</div>

==Discussion==
* It should work correctly for all basic Slicer data types: volumes (all kinds, check labelmap and make sure nearest neighbor interpolation is used), models, markups, ROI (the box shape has to be preserved, so the bounding box of the transformed corner points could be used as new corner points), annotations, ruler (transform the endpoints only, no need to warp the line)
* Add some information about non-linear transforms to the Transforms module GUI. Even something as simple as showing the non-linear transforms in the module selector would help and then if the user selects it, it would just show the transform's type and maybe also some basic parameters (extent, number of points, etc.). In the long term, the transform visualizer module could be used to show the transform in 2D and 3D views.
* It is necessary to be able to specify output volume origin, spacing, direction, and extent. In some cases some reasonable default value can be computed or the creator of the transform (e.g., a registration algorithm) can set this information in the transform. In the future it will have to be accessible to the user (set the values similarly as in the Volume node and also allow them to copy the info from a chosen volume)
* For some cases (e.g., interactive image warping in a slice viewer) it is preferable to let modules access the original volume and the transform (as it is done currently for linear transforms), but for other cases (such as volume rendering, CLI execution, labelmap statistics, etc.) the full volume in world coordinate system is needed. As computing a full transformed volume can take a long time (1 minute or even longer), it is not convenient to recompute it each time a module needs the deformed volume. Proposed solution:
** Add a coordinate system parameter (CoordinateSystem enum: COORD_OBJECT, COORD_WORLD) to all spatial data accessor methods in the MRML node
*** vtkImageData* vtkMRMLVolumeNodeGetImageData() => vtkImageData* vtkMRMLVolumeNodeGetImageData(CoordinateSystem coord=COORD_OBJECT)
*** vtkPolyData* GetPolyData() => vtkPolyData* GetPolyData(CoordinateSystem coord=COORD_OBJECT)
*** ...
** If COORD_OBJECT is passed (default) then the original, non-warped data is returned. If COORD_WORLD is passed as a parameter, then the warped data is returned. Other frequently used coordinate systems can be defined as well.
** The version of the data returned on COORD_OBJECT is the original one, which is also stored on disk, and it is not changed when the ParentTransformNode is changed.
** The version that is returned on COORD_WORLD is not stored on disk, but kept in memory (stored in the MRML node) and returned whenever it is needed. If some other objects keep a reference to the data object that was returned on COORD_WORLD (reference count>1) then when the ParentTransformNode is changed then the warped data is updated as well.

2014 Winter Project Week:NonlinearTransforms

2014-01-05T15:45:13Z

Alexy: /* Project Description */

2014 Winter Project Week:NonlinearTransforms

2014-01-05T14:52:01Z

Alexy: /* Project Description */

2014 Winter Project Week:NonlinearTransforms

2014-01-05T14:50:25Z

Alexy: /* Project Description */

2014 Winter Project Week:NonlinearTransforms

2013-12-10T20:30:01Z

Alexy: Created page with '__NOTOC__ <gallery> Image:PW-SLC2014.png|Projects List </gallery> ==Key Investigators== * Isomics: Alex Yarmarkovich * Queen's University: …'

2014 Winter Project Week

2013-12-10T20:20:08Z

Alexy: /* Infrastructure */

Back to [[Project Events]], [[AHM_2014]], [[Events]]

__NOTOC__
[[image:PW-SLC2014.png|300px]]

Project Week is a hands on activity -- programming using the open source [[NA-MIC-Kit|NA-MIC Kit]], algorithm design, and clinical application -- that has become one of the major events in the NA-MIC, NCIGT, and NAC calendars. It is held in the summer at MIT, typically the last week of June, and a shorter version is held in Salt Lake City in the winter, typically the second week of January.

Active preparation begins 6-8 weeks prior to the meeting, when a kick-off teleconference is hosted by the NA-MIC Engineering, Dissemination, and Leadership teams, the primary hosts of this event. Invitations to this call are sent to all na-mic members, past attendees of the event, as well as any parties who have expressed an interest in working with NA-MIC. The main goal of the kick-off call is to get an idea of which groups/projects will be active at the upcoming event, and to ensure that there is sufficient NA-MIC coverage for all. Subsequent teleconferences allow the hosts to finalize the project teams, consolidate any common components, and identify topics that should be discussed in breakout sessions. In the final days leading upto the meeting, all project teams are asked to fill in a template page on this wiki that describes the objectives and plan of their projects.

The event itself starts off with a short presentation by each project team, driven using their previously created description, and allows all participants to be acquainted with others who are doing similar work. In the rest of the week, about half the time is spent in breakout discussions on topics of common interest of subsets of the attendees, and the other half is spent in project teams, doing hands-on programming, algorithm design, or clinical application of NA-MIC kit tools. The hands-on activities are done in 10-20 small teams of size 3-5, each with a mix of experts in NA-MIC kit software, algorithms, and clinical. To facilitate this work, a large room is setup with several tables, with internet and power access, and each team gathers on a table with their individual laptops, connects to the internet to download their software and data, and is able to work on their projects. On the last day of the event, a closing presentation session is held in which each project team presents a summary of what they accomplished during the week.

A summary of all past NA-MIC Project Events is available [[Project_Events#Past|here]].
= Dates.Venue.Registration =

Please [[AHM_2014#Dates_Venue_Registration|click here for Dates, Venue, and Registration]] for this event.

= [[AHM_2014#Agenda|'''AGENDA''']] and Project List=

Please:
* [[AHM_2014#Agenda|'''Click here for the agenda for AHM 2014 and Project Week''']].
* [[#Projects|'''Click here to jump to Project list''']]

=Background and Preparation=

A summary of all past NA-MIC Project Events is available [[Project_Events#Past|here]].

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]

=Projects=
* [[2014_Project_Week_Template | Template for project pages]]

==TBI==
*[[2014_Project_Week:TBIatrophy|Multimodal neuroimaging for the quantification of brain atrophy at six months following severe traumatic brain injury]] (Andrei Irimia, SY Matthew Goh, Carinna M. Torgerson, John D. Van Horn)
*[[2014_Project_Week:TBIdemyelination|Systematic evaluation of axonal demyelination subsequent to traumatic brain injury using structural T1- and T2-weighted magnetic resonance imaging]] (Andrei Irimia, SY Matthew Goh, Carinna M. Torgerson, John D. Van Horn)
*[[2014_Project_Week:BrainAging|Mapping the effect of traumatic brain injury upon white matter connections in the human brain using 3D Slicer]] (Andrei Irimia, John D. Van Horn)

==Atrial Fibrillation==
*[[2014_Project_Week:GraphCutsLASegmentation|LA Segmentation via Graph Cuts]] (Josh, Salma, Gopal)
*[[2014_Project_Week:MRAFusionRegistration|DEMRI LA Segmentation via Image Fusion (MRA)]] (Josh, Salma, Alan)
*[[2014_Project_Week:LAFibrosisVisualizationModule|LA Fibrosis / Scar Visualization]] (Josh, Salma, Alan)
*[[2014_Project_Week:CARMADocumentation|CARMA Extension Documentation Project]] (Josh, Salma)

==Huntington's Disease==
*[[2014_Project_Week:DWIDispersion|DWI Dispersion]] (Hans, CF)
*[[2014_Project_Week:DTIAnalysis|DTI Compressed Sensing?]] (Hans, CF)
*[[2014_Project_Week:Modules scripting|Slicer module scripting?]] (Dave)
*[[2014_Project_Week:DWIConverter|DWIConverter?]] (Hans, Kent)
*Slicer Based Surface Template Estimation (Saurabh JHU, Steve Pieper, Hans?)

==Head and Neck Cancer==
*[[2014_Project_Week:DIR_validation|DIR Validation]] (Nadya and Greg)
*[[2014_Project_Week:Hybrid_bspline|Hybrid B Spline]] (Nadya, Greg, Steve)
*[[2014_Project_Week:KSlice|Interactive Segmentation]] (Ivan, Nadya, Greg, Allen)

==Stroke==

==Image-Guided Interventions==

==Radiation Therapy==
*[[2014_Project_Week:DICOM_RT|DICOM RT Export]] (Greg, Kevin Wang, others)
*[[2014_Project_Week:DICOM_SRO|DICOM Spatial Registration Export]] (Greg, Kevin Wang, others)
*[[2014_Project_Week:Registration_Evaluation|Interactive Registration and Evaluation]] (Kevin Wang, Greg, others)

==Medical Robotics==
==[http://qiicr.org QIICR]==

==TMJ-OA==

==Infrastructure==
*[[2014_Project_Week:SlicerSpeedUp|Slicer speed up]] (Jc, Andras Lasso, Steve Pieper)
*[[2014_Project_Week:MRMLSceneSpeedUp|MRML Scene speed up]] (Jc, Andras Lasso)
*[[2014_Project_Week:SlicerIPythonIntegration|Integration of IPython]] (Jc, Steve Pieper)
*[[2014_Project_Week:MultidimensionalDataSupport|Multidimensional data support]] (Andras Lasso, Andriy Fedorov, Steve Pieper, JC, Kevin Wang)
*CLI - Resources? Conditionals? Autonaming? Provenance? CTK unification? (Jim Miller)
*[[2014_Project_Week:MarkupsModule|Markups Module]] (Nicole Aucoin)
* [[2014_Winter_Project_Week:Steered Registration|Steered Registration]] (Steve, Greg, Kevin, Vinicius, Marcel)
* [[2014_Winter_Project_Week:MRB Extension Dependencies|MRB Extension Dependencies]] (Steve, Jc, Jim, Nicole, Alex)
* [[2014_Winter_Project_Week:SubjectHierarchy|Subject Hierarchy]] (Csaba Pinter, Andras Lasso, Steve Pieper, Jc)
* [[2014_Winter_Project_Week:IntegrationOfContourObject|Integration of Contour object]] (Csaba Pinter, Andras Lasso, Steve Pieper, ???)
* [[2014_Winter_Project_Week:NonLinearTransforms|Integration non-linear transforms]] (Alex Yarmarkovich, Csaba Pinter, Andras Lasso, Steve Pieper, ???)

2014 Project Week:NonLinearTransforms

2013-12-10T20:18:11Z

Alexy: Created page with '__NOTOC__ <gallery> Image:PW-SLC2014.png|Projects List </gallery> ==Key Investigators== * Isomics: Alex Yarmarkovich * Queen's University:…'

2013 Project Week:SimplifyMRMLReference

2013-01-08T21:55:54Z

Alexy: /* Key Investigators */

__NOTOC__
<gallery>
Image:PW-SLC2013.png|[[2013_Winter_Project_Week#Projects|Projects List]]


</gallery>

==Key Investigators==
* Isomics: Alex Yarmarkovich, Steve Pieper
* Andras Lasso
* Kitware: Julien Finet, Jean-Christophe Fillion-Robin

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

<h3>Objective</h3>
Slicer4 MRML node referencing mechanism needs some design improvement, as for each referenced node in each node type about 10 methods shall be added/updated manually. This is very difficult to do, often done incorrectly.
The goal is to discuss the details and design robust, simple, centralized implementation of all node reference updates for save/load, undo/redo, scene import features
</div>

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

<h3>Approach, Plan</h3>
A potential solution would be to introduce a "ReferencedNodes" list, which would store pointer, ID string, node type name, and observers for each referenced node instead of adding separate member variables for these manually. This list could be fully maintained by the Copy, UpdateScene, UpdateReferenceID, UpdateReferences, ReadXMLAttributes, WriteXML, etc. methods implementation in vtkMRMLNode base class. Developers would just need to add an item to the ReferencedNodes list and all the rest would be handled by the MRML framework.
</div>

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

<h3>Progress</h3>
* Design meeting held on 01/08/2013 with the particpants: Alex Yarmarkovich, Steve Pieper, Andras Lasso, Julien Finet, Jean-Christophe Fillion-Robin.
* A more general MRML node reference architecture was proposed and discussed.
* Reference node API should be developed in the base vtkMRMLNode class including:
** creating and managing references for a particular reference category, for example "displayNode" or "transformNode".
** managing references together with observers and events
* A developer should be able to associate reference category with the node. All the management of references will be done automatically after that.
* Alex created a github topic branch with the prototype API:
https://github.com/ayarmarkovich/Slicer/tree/mrml_ref_branch
* Success criteris: implementation of vtkMRMLDisplayableNode should utilize new reference API and the tests associated with it should still pass.
* Next steps could include extending the reference API for MRML Logic and Displayable Manager calsses.

</div>
</div>

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as changes in the Slicer4 core and in the SlicerRT extension

==References==
* [https://www.assembla.com/spaces/slicerrt/wiki SlicerRT]
* [https://www.assembla.com/spaces/slicerrt/tickets/125#/activity/ticket: http://www.na-mic.org/Bug/view.php?id=2727]

2013 Project Week:SimplifyMRMLReference

2013-01-08T21:52:12Z

Alexy: /* Key Investigators */

__NOTOC__
<gallery>
Image:PW-SLC2013.png|[[2013_Winter_Project_Week#Projects|Projects List]]


</gallery>

==Key Investigators==
* Isomics: Alex Yarmarkovich, Steve Pieper
* Andras Lasso
* Kitware: Julien Finet, Jean-Christophe Fillion-Robin

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

<h3>Objective</h3>
Slicer4 MRML node referencing mechanism needs some design improvement, as for each referenced node in each node type about 10 methods shall be added/updated manually. This is very difficult to do, often done incorrectly.
The goal is to discuss the details and design robust, simple, centralized implementation of all node reference updates for save/load, undo/redo, scene import features
</div>

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

<h3>Approach, Plan</h3>
A potential solution would be to introduce a "ReferencedNodes" list, which would store pointer, ID string, node type name, and observers for each referenced node instead of adding separate member variables for these manually. This list could be fully maintained by the Copy, UpdateScene, UpdateReferenceID, UpdateReferences, ReadXMLAttributes, WriteXML, etc. methods implementation in vtkMRMLNode base class. Developers would just need to add an item to the ReferencedNodes list and all the rest would be handled by the MRML framework.
</div>

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

<h3>Progress</h3>
* Design meeting held on 01/08/2013 with the particpants: Alex Yarmarkovich, Steve Pieper, Andras Lasso, Julien Finet, Jean-Christophe Fillion-Robin.
* A more general MRML node reference architecture were proposed and discussed.
* Reference node API should be developed in the base vtkMRMLNode including:
** creating and managing references for a particular category, for example "displayNode" or "transformNode".
** managing references together with observers and events
* Alex created a github topic branch with the prototype API:
https://github.com/ayarmarkovich/Slicer/tree/mrml_ref_branch
* Success criteris: implementation of vtkMRMLDisplayableNode should utilize new reference API and the tests associated with it should still pass.
* Next steps could include extending the reference API for MRML Logic and Displayable Manager calsses.

</div>
</div>

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as changes in the Slicer4 core and in the SlicerRT extension

==References==
* [https://www.assembla.com/spaces/slicerrt/wiki SlicerRT]
* [https://www.assembla.com/spaces/slicerrt/tickets/125#/activity/ticket: http://www.na-mic.org/Bug/view.php?id=2727]

2013 Project Week:SimplifyMRMLReference

2013-01-08T21:50:31Z

Alexy: /* Key Investigators */

__NOTOC__
<gallery>
Image:PW-SLC2013.png|[[2013_Winter_Project_Week#Projects|Projects List]]


</gallery>

==Key Investigators==
* Isomics: Alex Yarmarkovich, Steve Pieper
* Andras Lasso
* Kitware: Julien Finet, Jean-Christophe Fillion-Robin

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

<h3>Objective</h3>
Slicer4 MRML node referencing mechanism needs some design improvement, as for each referenced node in each node type about 10 methods shall be added/updated manually. This is very difficult to do, often done incorrectly.
The goal is to discuss the details and design robust, simple, centralized implementation of all node reference updates for save/load, undo/redo, scene import features
</div>

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

<h3>Approach, Plan</h3>
A potential solution would be to introduce a "ReferencedNodes" list, which would store pointer, ID string, node type name, and observers for each referenced node instead of adding separate member variables for these manually. This list could be fully maintained by the Copy, UpdateScene, UpdateReferenceID, UpdateReferences, ReadXMLAttributes, WriteXML, etc. methods implementation in vtkMRMLNode base class. Developers would just need to add an item to the ReferencedNodes list and all the rest would be handled by the MRML framework.
</div>

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

<h3>Progress</h3>
* Design meeting held on 01/08/2013: Yarmarkovich, Steve Pieper, Andras Lasso, Julien Finet, Jean-Christophe Fillion-Robin
* A more general MRML node reference architecture were proposed and discussed.
* Reference node API should be developed in the base vtkMRMLNode including:
** creating and managing references for a particular category, for example "displayNode" or "transformNode".
** managing references together with observers and events
* Alex created a github topic branch with the prototype API:
https://github.com/ayarmarkovich/Slicer/tree/mrml_ref_branch
* Success criteris: implementation of vtkMRMLDisplayableNode should utilize new reference API and the tests associated with it should still pass.

</div>
</div>

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as changes in the Slicer4 core and in the SlicerRT extension

==References==
* [https://www.assembla.com/spaces/slicerrt/wiki SlicerRT]
* [https://www.assembla.com/spaces/slicerrt/tickets/125#/activity/ticket: http://www.na-mic.org/Bug/view.php?id=2727]

2013 Project Week:SimplifyMRMLReference

2013-01-08T21:48:10Z

Alexy: /* Key Investigators */

__NOTOC__
<gallery>
Image:PW-SLC2013.png|[[2013_Winter_Project_Week#Projects|Projects List]]


</gallery>

==Key Investigators==
* Isomics: Alex Yarmarkovich, Steve Pieper
* Andras Lasso
* Kitware: Julien Finet, Jean-Christophe Fillion-Robin

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

<h3>Objective</h3>
Slicer4 MRML node referencing mechanism needs some design improvement, as for each referenced node in each node type about 10 methods shall be added/updated manually. This is very difficult to do, often done incorrectly.
The goal is to discuss the details and design robust, simple, centralized implementation of all node reference updates for save/load, undo/redo, scene import features
</div>

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

<h3>Approach, Plan</h3>
A potential solution would be to introduce a "ReferencedNodes" list, which would store pointer, ID string, node type name, and observers for each referenced node instead of adding separate member variables for these manually. This list could be fully maintained by the Copy, UpdateScene, UpdateReferenceID, UpdateReferences, ReadXMLAttributes, WriteXML, etc. methods implementation in vtkMRMLNode base class. Developers would just need to add an item to the ReferencedNodes list and all the rest would be handled by the MRML framework.
</div>

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

<h3>Progress</h3>
* Design meeting held on 01/08/2013: Yarmarkovich, Steve Pieper, Andras Lasso, Julien Finet, Jean-Christophe Fillion-Robin
* A more general MRML node reference architecture were proposed and discussed.
* Reference node API should be developed in the base vtkMRMLNode including:
** creating reference and managing references for a particular category, for example "displayNode" or "transformNode".
** managing references together with observers and events
* Alex created a github topic branch with the prototype API:
https://github.com/ayarmarkovich/Slicer/tree/mrml_ref_branch

</div>
</div>

==Delivery Mechanism==

This work will be delivered to the NA-MIC Kit as changes in the Slicer4 core and in the SlicerRT extension

==References==
* [https://www.assembla.com/spaces/slicerrt/wiki SlicerRT]
* [https://www.assembla.com/spaces/slicerrt/tickets/125#/activity/ticket: http://www.na-mic.org/Bug/view.php?id=2727]

2013 Project Week:SimplifyMRMLReference

2013-01-04T15:37:35Z

Alexy:

2013 Project Week:SimplifyMRMLReference

2013-01-04T15:36:36Z

Alexy:

2009-01-08T05:42:13Z

Alexy:

{|
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2009_Winter_Project_Week|Project Week Main Page]] ]]

|}

__NOTOC__

===Key Investigators===
* Isomics:Alex, Steve
* KnowledgeVis: Curt Lisle
* NCI: Yanling Liu

__NOTOC__
<div style="margin: 20px;">
<div style="width: 27%; float: left; padding-right: 3%;">
<h1>Objective</h1>
Revise the current Volume Rendering module through the inclusion of new
rendering methods. Simplify the code implementation while trying to preserve
the good interaction ideas which were implemented already.
</div>

<div style="width: 27%; float: left; padding-right: 3%;">
<h1>Approach, Plan</h1>

* Separate code into GUI-MRML-Logic components architecture.
* Create reusable components for clipping with ROI.
* Provide persistence/reuse of transfer functions and their MRML representation.
* Enable easy integration of other volume rendering techniques.

</div>

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

<h1>Progress</h1>

* Yanling and Curt integrated GPL based volume rendering algorithm into Slicer3
* Yanling, Curt and Alex discussed a plan for re-design:
** MRML nodes for ROI, transfer functions, lut's, parameters (Alex)
** GUI separation, widgets for separate components (Alex)
** Volume rendering pipeline and logic (Yanling, Curt, Alex)

</div>

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

2008-01-09T15:58:37Z

Alexy: /* Tractography Fiducial Seeding Module */

= Goals =

* Development of the core infrastructure for DT-MRI processing and visualization.
* Development of the core infrastructure for fiber tracks processing and visualization.
* Integration of new and existing methods and algorithms for DT-MRI processing using the provided infrastructure.
* Porting of the current DT-MRI capabilities existing in Slicer 2.x

= Core infrastructure for DT-MRI processing and visualization, fiber processing and visualization =
== Data Model ==
MRML nodes for different data representations involved in DTI analysis:
* Diffusion Weighted Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionWeightedVolumeNode.h?view=log vtkMRMLDiffusionWeightedVolumeNode].
* Diffusion Tensor Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionTensorVolumeNode.h?view=log vtkMRMLDiffusionTensorVolumeNode].
* Fiber Bundles: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleNode.h?view=log vtkMRMLFiberBundleNode].

== Visualization/Display ==
MRML nodes for definition for DTI data visualization:
* Diffusion Weighted Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionWeightedVolumeDisplayNode.h?view=log vtkMRMLDiffusionWeightedVolumeDisplayNode].
* Diffusion Tensor Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionTensorVolumeDisplayNode.h?view=log vtkMRMLDiffusionTensorVolumeDisplayNode], and [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionTensorDisplayPropertiesNode.h?view=log vtkMRMLDiffusionTensorDisplayPropertiesNode].
* Fiber Bundles: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleDisplayNode.h?view=log vtkMRMLFiberBundleDisplayNode], [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleLineDisplayNode.h?view=log vtkMRMLFiberBundleLineDisplayNode], [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleTubeDisplayNode.h?view=log vtkMRMLFiberBundleTubeDisplayNode], and [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleGlyphDisplayNode.h?view=log vtkMRMLFiberBundleGlyphDisplayNode].

==Storage and I/O ==
* DWI and DTI I/O: NRRD is the format supported by Slicer 3 for storing DWI and DTI images.
** NNRD reader/writer: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkNRRDReader.h?view=log vtkNRRDReader] and [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkNRRDWriter.h?view=log vtkNRRDWriter].
** Storage node: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLNRRDStorageNode.h?view=log vtkMRMLNRRDStorageNode].
* Fiber I/O: vtkPolyData has been the format adopted for the description of fibers.
** Storage node: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleStorageNode.h?view=log vtkMRMLFiberBundleStorageNode]
* Slicer3 Volume module is capable of loading and saving DWI and DTI images.
* Slicer3 Models and Tractography LoadSave modules are capable of loading and saving fiber tracts.

== Displaying Logic ==
* Visualization pipelines for DTI, DWI volumes, and fiber bundles are incorporated into the corresponding display nodes.
* DWI volumes are displayed as separate components.

{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* DTI volumes are displayed as computed scalar properties (such as FA, Linear Measure, Color Orientation, etc.)
| style="background: #ebeced"|[[Image:Dti-color.jpg|center|300px|Colore DTI]]
| style="background: #ebeced"|DTI volume slices colored by orientaion.
|}
<br>

{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* Fiber bundles are displayed as lines, tubes, and glyphs with their own properties and colors.
| style="background: #ebeced"|[[Image:Line-glyph-tracts.jpg|center|300px|fiber bundles]]
| style="background: #ebeced"|Fiber bundles displayed as lines and glyph ellipsoids.
|}
<br>

* Slicer3 Volume Module is capable of displaying DWI and DTI images.
* Slicer3 Models and Tractography LoadSave modules are capable of displaying fiber tracts.

== Diffusion Processing Toolbox ==
[http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem vtkTeem-library] provides tools for:
* Tensor estimation
* Computation of scalar measurements from tensor fields
*Fast rendering of tensor fields using glyphs: line, box, ellipsoid.
*Fiber Tracking using integration techniques
* Multiple ROI seeding and logic interconnections between ROIs

= DT-MRI processing and visualization Modules =

== Tensor Estimation from DWI ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionTensorEstimation.xml?view=log DiffusionTensorEstimation].
Teem currently provides a clean interface to do this estimation in a voxel by voxel fashion. Collaboration with Gordon Kindlmann for a vtk filter implementation that encapsulates the estimation process ([http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkTeemEstimateDiffusionTensor.h?view=log vtkTeemEstimateDiffusionTensor]).

== Diffusion Tensor Scalar Measurements ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionTensorMathematics.xml?view=log DiffusionTensorMathematics].
* Implemented in vtkTeem library [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkDiffusionTensorMathematics.h?view=log vtkDiffusionTensorMathematics].

== Rician LMMSE Filter ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/dwiNoiseFilter/dwiNoiseFilter.xml?view=log dwiNoiseFilter].

*Filters a set of diffusion weighted images in the mean squared error sense using a Rician noise model. The noise parameter is automatically estimated.
*Contributed by Santiago Aja Fernandez and Marc Niethammer
*Additional [[Slicer3:Module:Rician_Noise_Removal | Rician filtering module]] provided by Sylvain Gouttard et al

== Tractography Display/Load/Save Module==
* Loads and saves fiber tracks as vtkPolyData files (.vtp)
* Displays fiber tracks as lines, tubes, glyphs. Allows to control line/tube/glyph display properties and colors
* Built-in Slicer3 module.

== Tractography ROI Seeding Module ==
{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* Creates fibers passing through a specified ROI
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Modules/Tractography/Seeding/Seeding.xml?view=log ROI Seeding].
| style="background: #ebeced"|[[Image:roi_tract.jpg|center|300px|Roi seeding]]
| style="background: #ebeced"|Seeding from ROI example.
|}
<br>

== Tractography Fiducial Seeding Module ==
{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* Creates fibers passing through the specified fiducial points interactively
* Built-in Slicer3 module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Modules/Tractography/FiducialSeeding/vtkSlicerTractographyFiducialSeedingGUI.cxx?view=log vtkSlicerTractographyFiducialSeedingGUI.cxx]
| style="background: #ebeced"|[[Image:Fiducial-seeding.jpg|center|300px|fiducial seeding]]
| style="background: #ebeced"|Seeding from fiducials example.
|}
<br>

== Tractography ROI Select Module ==
* Select tracts passing or not passing through ROIs
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Modules/Tractography/Editor/ROISelect.xml?view=log ROI Select].

== Stochastic Tractography Filter ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/StochasticTractographyFilter/StochasticTractographyFilter.xml?view=log StochasticTractographyFilter].
* Generates a map of connectivity probabilities from a DWI volume.).
* Contributed by Tri Ngo (tringo@gmail.com)

== ROI Tract Filter ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/StochasticTractographyFilter/ROITractFilter.xml?view=log ROITractFilter].
* Creates a new tract container containing only tracts which pass through the selected ROI's.
* Contributed by Tri Ngo (tringo@gmail.com)

== Generate Connectivity Map ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/StochasticTractographyFilter/GenerateConnectivityMap.xml?view=log GenerateConnectivityMap].
* Generates a volume where the value of each voxel is the number of fibers which pass through that voxel divided by the total number of sampled fibers. This value can been interpreted as the probability that a particular voxel is connected to the seed ROI by a fiber tract.
* Contributed by Tri Ngo (tringo@gmail.com)

:

= Future development plans =
* Fiber editing: enviroment for manually editing individual fibers/bundles, reassigning of fibers to bundles.
* Fiber Bundle Clustering (Core 1).
* Render glyphs in the 2D slice windows.
* Statistics along fiber tracts (Core 1).
* Quantitative measurement
** Tract-based
** Region of interest-based
* fMRI seeding
* Surgical planning
* DT-MRI segmentation/atlas creation: enviroment for segmentation of DT-MRI fields
* DT-MRI registration: enviroment for registration of DT-MRI fields (possibly via DWI registration -- work done at GE and presented in MICCAI '06).
* Tensor estimation using different methods, namely:
** Least Squares
** Weighted Least Squares
** Non-linear methods
** Maximum Likelihood approach

= Development Screenshots =

[[Image:DtiDevel1.jpg]]

[[Image:DtiDevel2.jpg]]

= Notes on general diffusion framework (ODF/2 tensor) support =
http://wiki.na-mic.org/Wiki/index.php/Slicer3:DTMRI:GeneralDiffusionFramework

Slicer3:DTMRI

2008-01-09T04:04:09Z

Alexy: /* Future development plans */

= Goals =

* Development of the core infrastructure for DT-MRI processing and visualization.
* Development of the core infrastructure for fiber tracks processing and visualization.
* Integration of new and existing methods and algorithms for DT-MRI processing using the provided infrastructure.
* Porting of the current DT-MRI capabilities existing in Slicer 2.x

= Core infrastructure for DT-MRI processing and visualization, fiber processing and visualization =
== Data Model ==
MRML nodes for different data representations involved in DTI analysis:
* Diffusion Weighted Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionWeightedVolumeNode.h?view=log vtkMRMLDiffusionWeightedVolumeNode].
* Diffusion Tensor Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionTensorVolumeNode.h?view=log vtkMRMLDiffusionTensorVolumeNode].
* Fiber Bundles: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleNode.h?view=log vtkMRMLFiberBundleNode].

== Visualization/Display ==
MRML nodes for definition for DTI data visualization:
* Diffusion Weighted Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionWeightedVolumeDisplayNode.h?view=log vtkMRMLDiffusionWeightedVolumeDisplayNode].
* Diffusion Tensor Images: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionTensorVolumeDisplayNode.h?view=log vtkMRMLDiffusionTensorVolumeDisplayNode], and [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLDiffusionTensorDisplayPropertiesNode.h?view=log vtkMRMLDiffusionTensorDisplayPropertiesNode].
* Fiber Bundles: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleDisplayNode.h?view=log vtkMRMLFiberBundleDisplayNode], [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleLineDisplayNode.h?view=log vtkMRMLFiberBundleLineDisplayNode], [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleTubeDisplayNode.h?view=log vtkMRMLFiberBundleTubeDisplayNode], and [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleGlyphDisplayNode.h?view=log vtkMRMLFiberBundleGlyphDisplayNode].

==Storage and I/O ==
* DWI and DTI I/O: NRRD is the format supported by Slicer 3 for storing DWI and DTI images.
** NNRD reader/writer: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkNRRDReader.h?view=log vtkNRRDReader] and [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkNRRDWriter.h?view=log vtkNRRDWriter].
** Storage node: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLNRRDStorageNode.h?view=log vtkMRMLNRRDStorageNode].
* Fiber I/O: vtkPolyData has been the format adopted for the description of fibers.
** Storage node: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/MRML/vtkMRMLFiberBundleStorageNode.h?view=log vtkMRMLFiberBundleStorageNode]
* Slicer3 Volume module is capable of loading and saving DWI and DTI images.
* Slicer3 Models and Tractography LoadSave modules are capable of loading and saving fiber tracts.

== Displaying Logic ==
* Visualization pipelines for DTI, DWI volumes, and fiber bundles are incorporated into the corresponding display nodes.
* DWI volumes are displayed as separate components.

{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* DTI volumes are displayed as computed scalar properties (such as FA, Linear Measure, Color Orientation, etc.)
| style="background: #ebeced"|[[Image:Dti-color.jpg|center|300px|Colore DTI]]
| style="background: #ebeced"|DTI volume slices colored by orientaion.
|}
<br>

{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* Fiber bundles are displayed as lines, tubes, and glyphs with their own properties and colors.
| style="background: #ebeced"|[[Image:Line-glyph-tracts.jpg|center|300px|fiber bundles]]
| style="background: #ebeced"|Fiber bundles displayed as lines and glyph ellipsoids.
|}
<br>

* Slicer3 Volume Module is capable of displaying DWI and DTI images.
* Slicer3 Models and Tractography LoadSave modules are capable of displaying fiber tracts.

== Diffusion Processing Toolbox ==
[http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem vtkTeem-library] provides tools for:
* Tensor estimation
* Computation of scalar measurements from tensor fields
*Fast rendering of tensor fields using glyphs: line, box, ellipsoid.
*Fiber Tracking using integration techniques
* Multiple ROI seeding and logic interconnections between ROIs

= DT-MRI processing and visualization Modules =

== Tensor Estimation from DWI ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionTensorEstimation.xml?view=log DiffusionTensorEstimation].
Teem currently provides a clean interface to do this estimation in a voxel by voxel fashion. Collaboration with Gordon Kindlmann for a vtk filter implementation that encapsulates the estimation process ([http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkTeemEstimateDiffusionTensor.h?view=log vtkTeemEstimateDiffusionTensor]).

== Diffusion Tensor Scalar Measurements ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionTensorMathematics.xml?view=log DiffusionTensorMathematics].
* Implemented in vtkTeem library [http://www.na-mic.org/ViewVC/index.cgi/trunk/Libs/vtkTeem/vtkDiffusionTensorMathematics.h?view=log vtkDiffusionTensorMathematics].

== Rician LMMSE Filter ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/dwiNoiseFilter/dwiNoiseFilter.xml?view=log dwiNoiseFilter].

*Filters a set of diffusion weighted images in the mean squared error sense using a Rician noise model. The noise parameter is automatically estimated.
*Contributed by Santiago Aja Fernandez and Marc Niethammer
*Additional [[Slicer3:Module:Rician_Noise_Removal | Rician filtering module]] provided by Sylvain Gouttard et al

== Tractography Display/Load/Save Module==
* Loads and saves fiber tracks as vtkPolyData files (.vtp)
* Displays fiber tracks as lines, tubes, glyphs. Allows to control line/tube/glyph display properties and colors
* Built-in Slicer3 module.

== Tractography ROI Seeding Module ==
{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* Creates fibers passing through a specified ROI
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Modules/Tractography/Seeding/Seeding.xml?view=log ROI Seeding].
| style="background: #ebeced"|[[Image:roi_tract.jpg|center|300px|Roi seeding]]
| style="background: #ebeced"|Seeding from ROI example.
|}
<br>

== Tractography Fiducial Seeding Module ==
{| border="00" cellpadding="8" cellspacing="0"
|-
| rowspan="2"|

* Creates fibers passing through the specified fiducial points interactively
* Built-in Slicer3 module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Modules/Tractography/FiducilaSeeding/vtkSlicerTractographyFiducialSeedingGUI.cxx?view=log vtkSlicerTractographyFiducialSeedingGUI.cxx]
| style="background: #ebeced"|[[Image:Fiducial-seeding.jpg|center|300px|fiducial seeding]]
| style="background: #ebeced"|Seeding from fiducials example.
|}
<br>

== Tractography ROI Select Module ==
* Select tracts passing or not passing through ROIs
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Modules/Tractography/Editor/ROISelect.xml?view=log ROI Select].

== Stochastic Tractography Filter ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/StochasticTractographyFilter/StochasticTractographyFilter.xml?view=log StochasticTractographyFilter].
* Generates a map of connectivity probabilities from a DWI volume.).
* Contributed by Tri Ngo (tringo@gmail.com)

== ROI Tract Filter ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/StochasticTractographyFilter/ROITractFilter.xml?view=log ROITractFilter].
* Creates a new tract container containing only tracts which pass through the selected ROI's.
* Contributed by Tri Ngo (tringo@gmail.com)

== Generate Connectivity Map ==
* CLI Module: [http://www.na-mic.org/ViewVC/index.cgi/trunk/Applications/CLI/DiffusionApplications/StochasticTractographyFilter/GenerateConnectivityMap.xml?view=log GenerateConnectivityMap].
* Generates a volume where the value of each voxel is the number of fibers which pass through that voxel divided by the total number of sampled fibers. This value can been interpreted as the probability that a particular voxel is connected to the seed ROI by a fiber tract.
* Contributed by Tri Ngo (tringo@gmail.com)

:

= Future development plans =
* Fiber editing: enviroment for manually editing individual fibers/bundles, reassigning of fibers to bundles.
* Fiber Bundle Clustering (Core 1).
* Render glyphs in the 2D slice windows.
* Statistics along fiber tracts (Core 1).
* Quantitative measurement
** Tract-based
** Region of interest-based
* fMRI seeding
* Surgical planning
* DT-MRI segmentation/atlas creation: enviroment for segmentation of DT-MRI fields
* DT-MRI registration: enviroment for registration of DT-MRI fields (possibly via DWI registration -- work done at GE and presented in MICCAI '06).
* Tensor estimation using different methods, namely:
** Least Squares
** Weighted Least Squares
** Non-linear methods
** Maximum Likelihood approach

= Development Screenshots =

[[Image:DtiDevel1.jpg]]

[[Image:DtiDevel2.jpg]]

= Notes on general diffusion framework (ODF/2 tensor) support =
http://wiki.na-mic.org/Wiki/index.php/Slicer3:DTMRI:GeneralDiffusionFramework