2008 Summer Project Week:Nonlinear transforms - Revision history

Millerjv: /* Design options */

2008-10-24T13:44:27Z

Design options

Millerjv: /* Design options */

2008-10-22T20:15:26Z

Design options

Millerjv: /* Design options */

2008-10-22T20:14:27Z

Design options

Millerjv: /* Design options */

2008-10-22T20:12:04Z

Design options

Millerjv: /* Design options */

2008-10-22T20:11:29Z

Design options

Millerjv: /* Design options */

2008-10-22T20:11:01Z

Design options

Millerjv: /* Design options */

2008-10-22T20:09:54Z

Design options

Millerjv at 20:06, 22 October 2008

2008-10-22T20:06:51Z

Millerjv: /* Key Investigators */

2008-06-27T13:46:29Z

Key Investigators

Millerjv: /* Key Investigators */

2008-06-27T13:45:32Z

Key Investigators

← Older revision		Revision as of 13:44, 24 October 2008
Line 109:		Line 109:
	</transform>		</transform>
	</pre>		</pre>
		+
		+	=== Coordinate Frames ===
		+
		+	Mike Halle has a prototype coordinate frame manager written in python. This class allows one to name coordinate frames and then register transformations that map from one coordinate frame to another coordinate frame. The coordinate frame manager uses a graph search technique to construct transformations to map between any two named coordinate frames.
		+
		+	We could implement this manager in Slicer as is or distribute the information across several Slicer objects. For instance,
		+
		+	# New MRML node type vtkMRMLCoordinateFrameNode would have an ivar to name the coordinate frame.
		+	# Add an ivar to vtkMRMLTransformableNode to keep the ID of the data's coordinate frame
		+	# Add two ivars to vtkMRMLTransformNode to keep track of the IDs of the "from" coordinate frame and the "to" coordinate frame
		+
		+	Each MRMLTransformableNode would initially define a unique coordinate frame. Slicer could treat coordinate frames with no mappings as being trivially aligned with the world coordinate frame. Or Slicer could force the user to define coordinate frame mappings between two data sets before those data sets are allowed to be shown in the same visualization or processed by certain algorithms.

@@ Line 101: / Line 101: @@
        <description>Moving image</description>
      </image>
-     <transform fileExtensions=".txt" '''reference="movingImageFileName"'''>
+     <transform fileExtensions=".txt" reference="movingImageFileName">
        <name>OutputTransform</name>
        <longflag>outputtransform</longflag>

← Older revision		Revision as of 20:14, 22 October 2008
Line 91:		Line 91:
	#* Modify all uses of transforms to take advantage of the sense of transform (skip unnecessary transform inversions)		#* Modify all uses of transforms to take advantage of the sense of transform (skip unnecessary transform inversions)
	#* BSplines and GridTransforms may be handled cleanly		#* BSplines and GridTransforms may be handled cleanly
		+
		+	* Should we add a mechanism in the CLI to indicate how a transform should be added to the scene?
		+	<pre>
		+	<image>
		+	<name>MovingImageFileName</name>
		+	<label>Moving Image</label>
		+	<channel>input</channel>
		+	<index>1</index>
		+	<description>Moving image</description>
		+	</image>
		+	<transform fileExtensions=".txt" '''reference="movingImageFileName"'''>
		+	<name>OutputTransform</name>
		+	<longflag>outputtransform</longflag>
		+	<description>Transform calculated that aligns the fixed and moving image. Maps positions in the fixed coordinate frame to the moving coordinate frame. Optional (specify an output transform or an output volume or both).</description>
		+	<label>Output transform</label>
		+	<channel>output</channel>
		+	</transform>
		+	</pre>

@@ Line 82: / Line 82: @@
 #* Nothing changes within the CLI module
 #* Modify the vtkCommandLineModuleLogic (writing of transforms) and vtkSlicerApplicationLogic (reading of transforms).
-#* Only affects transform sent to/from CLI. Doesn't affect transform loaded with "Add Transform...".
+#* Only affects transforms sent to/from CLI. Doesn't affect transforms loaded with "Add Transform...".
 #** So transform files generated via batch running of CLI will have to be manually inverted within Slicer (or an invert option will need to be added to the "Add Transform..." dialog).
 #* Ugly for BSpline and GridTransforms (speed and accuracy concerns).

@@ Line 79: / Line 79: @@
 #* Prototype implemented.
 # (Short term) Assume all transforms to/from CLI need "to be" or "are" resampling transforms.
-#* All changed are at the CLI interface layer
+#* All changes are at the CLI interface layer
 #* Nothing changes within the CLI module
 #* Modify the vtkCommandLineModuleLogic (writing of transforms) and vtkSlicerApplicationLogic (reading of transforms).

@@ Line 76: / Line 76: @@
 #* Modify vtkMRMLTransformStorageNode to add an inversion to the sequence of converting Slicer <-> ITK (already doing an RAS to LPS conversion).
 #* Affects all transforms loaded/saved to file (such as through the menu option to "Add Transform...")
-#* Ugly for BSpline and GridTransforms
+#* Ugly for BSpline and GridTransforms (speed and accuracy concerns).
 #* Prototype implemented.
 # (Short term) Assume all transform to CLI need "to be" or "are" resampling transforms.
@@ Line 84: / Line 84: @@
 #* Only affects transform sent to/from CLI. Doesn't affect transform loaded with "Add Transform...".
 #** So transform files generated via batch running of CLI will have to be manually inverted within Slicer (or an invert option will need to be added to the "Add Transform..." dialog).
-#* Ugly for BSpline and GridTransforms
+#* Ugly for BSpline and GridTransforms (speed and accuracy concerns).
-# Add attribute to transforms to indicate transform sense (ToParent verses FromParent)
+# (Long term) Add attribute to transforms to indicate transform sense (ToParent verses FromParent)
 #* Modification needed at the CLI interface layer to manage what sense CLI are expecting and producing
-#* Modify vtkMRMLTransformStorageNode to properly manage sense
+#* Modify vtkMRMLTransformStorageNode to properly manage sense, provide the right sense to a CLI, etc.
 #* Modify all uses of transforms to take advantage of the sense of transform (skip unnecessary transform inversions)

← Older revision		Revision as of 20:06, 22 October 2008
Line 68:		Line 68:

	===References===		===References===
		+
		+	=== Design options ===
		+
		+	# (Short term) Assume all transforms in ITK transform files are resampling transforms and hence need to be inverted on read/write from Slicer.
		+	#* Nothing changes at the CLI interface layer
		+	#* Nothing changes within the CLI module
		+	#* Modify vtkMRMLTransformStorageNode to add an inversion to the sequence of converting Slicer <-> ITK (already doing an RAS to LPS conversion).
		+	#* Affects all transforms loaded/saved to file (such as through the menu option to "Add Transform...")
		+	#* Ugly for BSpline and GridTransforms
		+	#* Prototype implemented.
		+	# (Short term) Assume all transform to CLI need "to be" or "are" resampling transforms.
		+	#* All changed are at the CLI interface layer
		+	#* Nothing changes within the CLI module
		+	#* Modify the vtkCommandLineModuleLogic (writing of transforms) and vtkSlicerApplicationLogic (reading of transforms).
		+	#* Only affects transform sent to/from CLI. Doesn't affect transform loaded with "Add Transform...".
		+	#** So transform files generated via batch running of CLI will have to be manually inverted within Slicer (or an invert option will need to be added to the "Add Transform..." dialog).
		+	#* Ugly for BSpline and GridTransforms
		+	# Add attribute to transforms to indicate transform sense (ToParent verses FromParent)
		+	#* Modification needed at the CLI interface layer to manage what sense CLI are expecting and producing
		+	#* Modify vtkMRMLTransformStorageNode to properly manage sense
		+	#* Modify all uses of transforms to take advantage of the sense of transform (skip unnecessary transform inversions)

@@ Line 46: / Line 46: @@
 <h3>Discussions</h3>
-* Eulerian/Langrangian viewpoint discussions
+* Eulerian/Langrangian viewpoint discussions (Gary, Steve)
 * Transform file format "should" indicate the coordinate frames and direction a transform maps* "Add Transform..." menu added
-* Coordinate frame manager to map between any two data sets verses mapping to parent/world.
+* Coordinate frame manager to map between any two data sets verses mapping to parent/world. (Mike)
 ** Named coordinate frames, coordinate frame for new data is labeled as the name of the dataset
 ** If transformation between coordinate frames is "unknown", Slicer will initially assume they are the same coordinate frame (identity)

@@ Line 46: / Line 46: @@
 <h3>Discussions</h3>
-** Eulerian/Langrangian viewpoint discussions
+* Eulerian/Langrangian viewpoint discussions
-** Transform file format "should" indicate the coordinate frames and direction a transform maps* "Add Transform..." menu added
+* Transform file format "should" indicate the coordinate frames and direction a transform maps* "Add Transform..." menu added
 <h3>Todo</h3>
 * itkDisplacementFieldTransform
 * Transform attribute of coordinate frame
-** Coordinate frame manager from Mike Halle
+* Coordinate frame manager from Mike Halle
 * Visualization support?
 ** TransformDisplayNode?