Difference between revisions of "Slicer3:DTMRI:GeneralDiffusionFramework"

From NAMIC Wiki
Jump to: navigation, search
m (Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/")
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Demian Wasserman, Raul San Jose, Lauren O'Donnell
+
<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:DTMRI:GeneralDiffusionFramework  here]</font></big>a
 
 
The goal is the define the basic design and data structure specifications to support general diffusion models in the slicer like two tensor diffusion models and higher order spherical harmonics tensors.
 
 
 
[[Image:DiffusionTODOList.jpg|thumb|300px|left|Initial development draft. Authors: Lauren, Demian, Raul]]
 
 
 
 
 
= MRML Redesign =
 
The generalization to general diffusion data models comes through a superclass that generalizes the original behaviour of vtkDiffusionTensorVolumeNode as described in the original design ([http://wiki.na-mic.org/Wiki/index.php/Slicer3:DTMRI] and [http://wiki.na-mic.org/Wiki/index.php/AHM_2007:Slicer3_Developer_Feedback#DTI])
 
This new class, vtkDiffusionImageVolumeNode, is a child of vtkMRMLTensorVolumeNode and abstracts the behaviour related to diffusion imaging. The main members of vtkDiffusionImageVolumeNode are:
 
* ID to the Diffusion Weighted Volume Node
 
* ID to the Baseline Image Volume Node
 
* ID to the Mask Image Volume Node.
 
 
 
As part of this redesign, the handling of IDs to the display node and storage node have been revamped to keep consistency. vtkMRMLVolumeNode is the class that keeps the DisplayNodeID and the subclassess take care of downcasting the node corresponding to that ID to make sure that the DisplayNode is the right one corresponding to the specific VolumeNode
 
 
 
The VolumeDisplayNode hierarchy has been refactored to better support display nodes that rely on glyphs as a display option. A new abstract class, vtkMRMLGlyphedDisplayNode, handles the different glyph properties. This class serves as parent class for vtkMRMLDiffusionTensorVolumeDisplayNode and vtkMRMLVectorVolumeDisplayNode.
 
 
 
[[Image:DiffusionImagingMRML.png|thumb|300px|left|MRML class diagram for diffusion imaging. Authors: Lauren, Demian, Raul]]
 
 
 
 
 
= Specifications to encapsulate General Diffusion Data into vtkImageData =
 
Slicer 3 intrinsic image data representation is a vtkImageData class. This implies important limitations, namely
 
* The dimensionality is strictly 3D: the data is supposed to be arranged in a 3D grid and there is not possibilities for further extensions
 
* A specific set of point data attributes are allowed: Scalars, Normals, Vectors and Tensors.
 
 
 
There is not much we can do about dimensionality. However we can define a convention to be able to store point data attributes beyond the previously commented using new vtkDataArrays in the vtkFieldData.
 
Then, our work now is to define a clear convention that allow us to make an unequivocal connection between the vtkDataArray an the representation associated to it.
 
 
 
Each vtkDataArray will be a new array with a predefined name in the vtkFieldData associated to the PointData (or CellData for that sake) of the vtkImageData. The DataArray will be a multicomponent DataArray. The components will have a predefined semantic meaning to encompass different data complexities.
 
{|class="wikitable" style="text-align:center" style="width:75%; height:200px" border="1"
 
|+ DataArray name convention
 
|-
 
|'Array Name' ||  ' Number of Component' || 'Multicomponent Semantic'
 
|-
 
| Scalar
 
| 1
 
| A standard scalar image
 
|-
 
| RGB
 
| 3
 
| Color Image. First component is R channel, Second component is the G channel and Thrid component is the B channel
 
|-
 
| Symmetric-Tensor
 
| 6
 
| A symmetric tensor. The data is arranged as follows: [dxx dxy dxz dyy dyz dzz]
 
|}
 

Latest revision as of 18:07, 10 July 2017

Home < Slicer3:DTMRI:GeneralDiffusionFramework

Note: We are migrating this content to the slicer.org domain - The newer page is herea