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.
Potential interactions with other projects: "MRML Scenes for the Execution Model including Transforms"
Progress
Jan 2008 Project Week
Support for transforming data has been added at the vtkMRMLTransformableNode level. Three methods have been added
virtual bool CanApplyNonLinearTransforms() = 0; virtual void ApplyTransform(vtkAbstractTransform* transform) = 0; virtual void ApplyTransform(vtkMatrix4x4* transformMatrix);
Any class derived from vtkMRMLTransformableNode has to implement the first two methods at least (the first only returns a bool whether or not the node forcibly requires a linear transform). The third method has a default implementation that calls the second, but it can be overridden in case efficient ways of applying a transform in matrix form exist.
In addition, the transform hardening functionality in vtkSlicerMRMLTreeWidget has been adapted to reflect the changes. Hardening is now node-agnostic, and it behaves differently whether or not the transform to world is linear.
