Difference between revisions of "2008 Winter Project Week:MRMLTransformHardening"
(New page: {| |thumb|320px|Return to [[2008_Winter_Project_Week ]] |valign="top"|thumb|320px|Todo |} __NOTOC__ ===Key Investigators...) |
|||
| Line 1: | Line 1: | ||
{| | {| | ||
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2008_Winter_Project_Week]] ]] | |[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2008_Winter_Project_Week]] ]] | ||
| − | |valign="top"|[[Image: | + | |valign="top"|[[Image:TransformHardening.png|thumb|500px|Hardening process: a) model under transform; b) selection of hardening option on the MRML tree context menu; c) model is hardened (rerooted to the MRMLScene, but its position in RAS space is unchanged)]] |
|} | |} | ||
| Line 14: | Line 14: | ||
<h1>Objective</h1> | <h1>Objective</h1> | ||
| − | + | Transform hardening consists in changing the location of a node in the MRML tree without changing its position in RAS space. | |
| + | |||
| + | For instance, if a model is a child of one or more transform nodes in the MRML scene, hardening the transforms onto the model will make the model be relocated to the root of the MRML scene | ||
| + | |||
| + | In other words, the global transform of the node to the root is applied to the vtkPolyData coordinates, and concurrently the node is rerooted to the MRML root. | ||
| + | |||
| + | As a note, this operation must be reversible, i.e. no information must be lost in the process. This means that volumes (images) are not resampled, just the ITKToRAS matrix will be changed in the hardening process. | ||
| + | |||
| + | While an important component in general, hardening is particularly useful for command line modules, since most of them are assuming that the MRML nodes are direct descendants of the MRML root (this is true for all modules except the ones that are MRML-aware). If one applies a non-MRML-aware command line module to a volume node that is placed under a transform node in the MRML tree, the output volume will result to be misplaced in RAS space. | ||
| + | |||
| + | In general, hardening can be also performed with the transform of the current node to any other node in the tree. The functionality for computing transforms to root and transforms to a node is already in MRML. What's lacking is the actual application of the transform to the data. | ||
</div> | </div> | ||
| Line 21: | Line 31: | ||
<h1>Approach, Plan </h1> | <h1>Approach, Plan </h1> | ||
| − | + | ||
| + | Recently, right before the code freeze, hardening functionality has been introduced at the MRML tree widget level (in the context menu, see figure), limited to hardening to root, for the following data types | ||
| + | * models (point coordinates are changed) | ||
| + | * volumes (the IJKToRAS matrix is changed) | ||
| + | * transforms (the parent transforms are incorporated into the transform matrix) | ||
| + | |||
| + | The data transformation code is now all in the widget callback, but it clearly belongs to the single MRML nodes (all transformable nodes, that is all displayable nodes, fiducial lists and transform nodes). Basically, the vtkMRMLTransformableNode class should have a pure virtual method TransformData or ApplyTransformToData taking a vtkMRMLMatrix4x4 in input; the callback should limit itself to calling the pure virtual and managing the reparenting of the MRML tree node. This is the plan of the project. | ||
| + | |||
| + | A direct byproduct of the project will be the ability of easily running command line modules in MRML scenes with a different reference system than RAS. This will allow command line modules that operate on volumes to work directly in the volume's XYZ space, thus enabling existing projects that don't support oriented images to work seamlessly as Slicer's command line modules without modifications. | ||
| + | |||
</div> | </div> | ||
| Line 28: | Line 47: | ||
<h1>Progress</h1> | <h1>Progress</h1> | ||
| − | + | Transform hardening is now implemented for a limited case (harden to root) on a subset of MRML nodes (volumes, models and transforms). | |
| − | |||
| − | |||
| − | |||
| − | |||
</div> | </div> | ||
Revision as of 11:11, 13 December 2007
Home < 2008 Winter Project Week:MRMLTransformHardening Return to 2008_Winter_Project_Week |
Key Investigators
- Mario Negri Institute: Luca Antiga
- Isomics: Steve Piper
Objective
Transform hardening consists in changing the location of a node in the MRML tree without changing its position in RAS space.
For instance, if a model is a child of one or more transform nodes in the MRML scene, hardening the transforms onto the model will make the model be relocated to the root of the MRML scene
In other words, the global transform of the node to the root is applied to the vtkPolyData coordinates, and concurrently the node is rerooted to the MRML root.
As a note, this operation must be reversible, i.e. no information must be lost in the process. This means that volumes (images) are not resampled, just the ITKToRAS matrix will be changed in the hardening process.
While an important component in general, hardening is particularly useful for command line modules, since most of them are assuming that the MRML nodes are direct descendants of the MRML root (this is true for all modules except the ones that are MRML-aware). If one applies a non-MRML-aware command line module to a volume node that is placed under a transform node in the MRML tree, the output volume will result to be misplaced in RAS space.
In general, hardening can be also performed with the transform of the current node to any other node in the tree. The functionality for computing transforms to root and transforms to a node is already in MRML. What's lacking is the actual application of the transform to the data.
Approach, Plan
Recently, right before the code freeze, hardening functionality has been introduced at the MRML tree widget level (in the context menu, see figure), limited to hardening to root, for the following data types
- models (point coordinates are changed)
- volumes (the IJKToRAS matrix is changed)
- transforms (the parent transforms are incorporated into the transform matrix)
The data transformation code is now all in the widget callback, but it clearly belongs to the single MRML nodes (all transformable nodes, that is all displayable nodes, fiducial lists and transform nodes). Basically, the vtkMRMLTransformableNode class should have a pure virtual method TransformData or ApplyTransformToData taking a vtkMRMLMatrix4x4 in input; the callback should limit itself to calling the pure virtual and managing the reparenting of the MRML tree node. This is the plan of the project.
A direct byproduct of the project will be the ability of easily running command line modules in MRML scenes with a different reference system than RAS. This will allow command line modules that operate on volumes to work directly in the volume's XYZ space, thus enabling existing projects that don't support oriented images to work seamlessly as Slicer's command line modules without modifications.
Progress
Transform hardening is now implemented for a limited case (harden to root) on a subset of MRML nodes (volumes, models and transforms).
