2014 Winter Project Week:NonlinearTransforms

• 

  Projects List

Key Investigators

• Isomics: Alex Yarmarkovich
• Queen's University: Andras Lasso

Project Description

Objective

• 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.

Approach, Plan

• 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.

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.

Progress