Handling deformable transforms in Slicer meeting minutes

• Should it be handled on what level?
  • MRML level (Transformable, VolumesLogic?)
  • Using modules (BRAINSResample, Resample Scalar/Vector/DWI Volume) - Subject Hierarchy would know what module can transform what objects using what transforms and use them
• Invertability / reversibility
  • Should it create clones of the 'hardened' objects? - in Subject Hierarchy
  • Should we maintain a history in the hardened nodes?
  • Harden option on drop (I can't display but can resample) - in Data and Transforms modules
• Plugin mechanism for registering non-linear transforms
  • Modules register themselves in the fashion "I can apply X type of transform to Y type objects"
    • The application could call these algorithms (instead of registering from outside)
  • GUI decision if hardened
• Where?
  • Data module
  • Transforms module (display tree, and add a 'Harden' button to the panels)
  • 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?
• Extend to contain bounding box
  • In case of non-linear transforms, go down the edges to specify the output bounding box
  • Options: resample in source lattice (still cloned), the one above, rsample in target volume

Ideas

• Look at the DICOM transform logic
  • Make frame of reference concept explicit in Slicer?