Difference between revisions of "Handling deformable transforms in Slicer meeting minutes"

From NAMIC Wiki
Jump to: navigation, search
(Page created)
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
−
* Should it be handled on what level?
+
=== Operations ===
−
** MRML level (Transformable, VolumesLogic?)
+
* Harden transform
−
** '''Using modules (BRAINSResample, Resample Scalar/Vector/DWI Volume)''' - Subject Hierarchy would know what module can transform what objects using what transforms and use them
+
*: Harden transform* is an existing capability that collapses linear transforms in a transform hierarchty.  Hardening is available as a context menu on a (data) node in the Data module. When hardened, the data object is moved in the Data module to be outside all transformations with the effect of the transform hierarchy applied. *Harden transform* is only available for transform hierarchies involving linear transforms.
−
* Invertability / reversibility
+
* Clone and harden
−
** '''Should it create clones of the 'hardened' objects?''' - in Subject Hierarchy
+
*: Clone and harden* differs from the current *Harden transform* capability in two ways:
−
** Should we maintain a history in the hardened nodes?
+
*# Instead of the data being moved outside of all transforms, a "copy" of the data will be moved outside of all transforms.
−
** '''Harden option on drop (I can't display but can resample)''' - in Data and Transforms modules
+
*# All transform types, linear and deformable, will be part of the hardening.
−
* Plugin mechanism for registering non-linear transforms
+
 
−
** Modules register themselves in the fashion "I can apply X type of transform to Y type objects"
+
=== Proposed data type support ===
−
*** The application could call these algorithms (instead of registering from outside)
+
* Scalar volumes
−
** GUI decision if hardened
+
* Vector volumes
 +
** RGB
 +
** Vector
 +
** Displacement field
 +
* Tensor volumes
 +
* Models
 +
* Fiducials and annotations
 +
* Multivolume
 +
 
 +
=== Questions ===
 +
* Should we maintain a link between the original and hardened data?
 +
* Should only the hardened version be available for visualization?
 +
** Probably yes, but display a warning on hardening
 +
* Can you clone and harden part of the transform hierarchy?
 +
*: Harden just the non-linear portions
 +
* Which tools do we use for each type of data to harden/warp the data?
 +
* When hardening applied, the user would be presented with a list of modules that can harden each type of data?
 +
* What happens to
 +
** pixel lattice - stays the "same"
 +
*** create an axis-aligned bounding box in the world space, the number of pixels along each dimension will change
 +
** spacing - affected by the transform
 +
** orientation - affected by the transform
 +
 
 +
=== Design ===
 +
* Level of performing the hardening
 +
** Application level: module can register itself as the capable of hardening certain types of data.
 +
*** For now the modules containing the algorithms (BRAINSResample, Resample Scalar/Vector/DWI Volume) will be known by the class performing the hardening
 +
** Logic level
 +
* Need to know the inverse of each transform
 +
** to transform the models and fiducials
 +
** to figure out how to define an appropriate lattice
 +
*** need to back transform all the edge/face voxels to find the bounding box in the world space
 +
* Three options presented to the user
 +
** Resample in source lattice (still cloned)
 +
** Resample into lattice that bounds the warping of the edge/face voxels
 +
** Resample into a target volume
 
* Where?
 
* Where?
−
** Data module
+
** Tie into the drag and drop of the Data module and prompt the user to harden the transform.
−
** Transforms module (display tree, and add a 'Harden' button to the panels)
+
** Transforms module: display tree, and add a 'Harden' button to the panels
 
** Subject Hierarchy right-click -> apply transform to branch
 
** Subject Hierarchy right-click -> apply transform to branch
−
* Harden all the way up or until all the parents are linear or just one level a time?
+
* Look at the logic of handling transforms in DICOM
−
* Extend to contain bounding box
+
 
−
** In case of non-linear transforms, go down the edges to specify the output bounding box
+
=== Subject hierarchy ===
−
** Options: resample in source lattice (still cloned), the one above, rsample in target volume
 
  
−
Ideas
+
* Transforms resulting from registration point back to the fixed and moving images.  This information is stored in the *attributes* of the hierarchy node.
−
* Look at the DICOM transform logic
+
* Should we use the DICOM frame of reference concepts (frame of reference UID).
−
** Make frame of reference concept explicit in Slicer?
+
* Transform map between two frames of references.
 +
* Currently, Slicer combines two concepts:
 +
** Frame of reference
 +
*** Everything "under" a transform is in the same frame of reference
 +
** Transform that maps between two frames of references
 +
*** The two frames of reference are implicitly defined by the transform hierarchy

Latest revision as of 15:31, 18 June 2013

Home < Handling deformable transforms in Slicer meeting minutes

Operations

  • Harden transform
    Harden transform* is an existing capability that collapses linear transforms in a transform hierarchty. Hardening is available as a context menu on a (data) node in the Data module. When hardened, the data object is moved in the Data module to be outside all transformations with the effect of the transform hierarchy applied. *Harden transform* is only available for transform hierarchies involving linear transforms.
  • Clone and harden
    Clone and harden* differs from the current *Harden transform* capability in two ways:
    1. Instead of the data being moved outside of all transforms, a "copy" of the data will be moved outside of all transforms.
    2. All transform types, linear and deformable, will be part of the hardening.

Proposed data type support

  • Scalar volumes
  • Vector volumes
    • RGB
    • Vector
    • Displacement field
  • Tensor volumes
  • Models
  • Fiducials and annotations
  • Multivolume

Questions

  • Should we maintain a link between the original and hardened data?
  • Should only the hardened version be available for visualization?
    • Probably yes, but display a warning on hardening
  • Can you clone and harden part of the transform hierarchy?
    Harden just the non-linear portions
  • Which tools do we use for each type of data to harden/warp the data?
  • When hardening applied, the user would be presented with a list of modules that can harden each type of data?
  • What happens to
    • pixel lattice - stays the "same"
      • create an axis-aligned bounding box in the world space, the number of pixels along each dimension will change
    • spacing - affected by the transform
    • orientation - affected by the transform

Design

  • Level of performing the hardening
    • Application level: module can register itself as the capable of hardening certain types of data.
      • For now the modules containing the algorithms (BRAINSResample, Resample Scalar/Vector/DWI Volume) will be known by the class performing the hardening
    • Logic level
  • Need to know the inverse of each transform
    • to transform the models and fiducials
    • to figure out how to define an appropriate lattice
      • need to back transform all the edge/face voxels to find the bounding box in the world space
  • Three options presented to the user
    • Resample in source lattice (still cloned)
    • Resample into lattice that bounds the warping of the edge/face voxels
    • Resample into a target volume
  • Where?
    • Tie into the drag and drop of the Data module and prompt the user to harden the transform.
    • Transforms module: display tree, and add a 'Harden' button to the panels
    • Subject Hierarchy right-click -> apply transform to branch
  • Look at the logic of handling transforms in DICOM

Subject hierarchy

  • Transforms resulting from registration point back to the fixed and moving images. This information is stored in the *attributes* of the hierarchy node.
  • Should we use the DICOM frame of reference concepts (frame of reference UID).
  • Transform map between two frames of references.
  • Currently, Slicer combines two concepts:
    • Frame of reference
      • Everything "under" a transform is in the same frame of reference
    • Transform that maps between two frames of references
      • The two frames of reference are implicitly defined by the transform hierarchy
Retrieved from "https://www.na-mic.org/w/index.php?title=Handling_deformable_transforms_in_Slicer_meeting_minutes&oldid=82082"