|
|
| (17 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]]
| |
| − | | |
| − | | |
| − | = Redesign of MRLM =
| |
| − | 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 adequate associated to the specialize VolumeNode.
| |
| − | | |
| − | = 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.
| |
