Execution Model Reference Systems - Revision history

Lantiga: /* The issue */

2007-01-13T11:18:08Z

The issue

Lantiga: /* The issue */

2007-01-13T11:04:37Z

The issue

Lantiga: /* The issue */

2007-01-13T09:17:37Z

The issue

Lantiga: /* The issue */

2007-01-13T09:14:47Z

The issue

Lantiga: /* The issue */

2007-01-13T09:14:25Z

The issue

Lantiga: /* The issue */

2007-01-13T09:11:23Z

The issue

Lantiga at 08:56, 13 January 2007

2007-01-13T08:56:08Z

New page

=== The issue ===

In Slicer3, every geometric entity is associated with a transform (via the MRML tree hierarchy): every image, model or fiducial (vtkImageData, vtkPolyData, ...) is associated with a vtkMatrix4x4 defining its orientation in space.
Therefore, the actual point coordinates stored in vtkPolyData may be expressed in arbitrary coordinate systems, but they will be properly located in the MRML scene, in the RAS coordinate system. Also, vtkImageData objects, which are defined in VTK as structured grids oriented with the x,y,z axes, can have arbitrary orientations in space.

While this is a powerful mechanism, maintaining consistency within the Execution Model is challenging.

When calling a CLI plugin, Slicer writes temporary data files that are fed to the CLI:
* the vtkPolyData point coordinates are first transformed in RAS (i.e. its points are transformed with the proper vtkMatrix4x4) and the file is written in VTK format. When the CLI program reads the VTK file, it implicitly has the data and the transform (which has become the identity matrix after the transformation has been applied berfore the call to the CLI program).
* fiducials are passed along as a comma-separated list of float arguments, and are expressed in RAS (for now, although the extension to LPS and IJK has been planned - by the way, if one specifies LPS, he should also specify LPS of what image, otherwise one fiducial in LPS corresponds to many fiducials in RAS)
* vtkImageData is stored in a nrrd file, with the information about the vtkMatrix4x4 stored in the header as space origin and space directions (which also include spacing); when the Archetype reader in the CLI reads the file in, the two objects are recreated: in the current implementation the vtkImageData has origin and spacing information, while vtkMatrix4x4 expresses the RAS to IJK transform.

At this stage, if a CLI program has to locate a point on the input surface on the input image, it first has to set the image origin and spacing to 0,0,0 and 1,1,1 respectively (whilch could eventually be done in the reader), apply the transform to the point, locate the transformed point. Conversely, if a pixel has to be turned into a geometric entity, it has to be transformed with the inverse of the vtkMatrix4x4. This way, all operations would be performed in IJK coordinates. There are two main disadvantages to this IJK approach: i) filters may not behave properly if images do not have anisotropic spacing; ii) while constantly dealing with transform is not a problem for small CLI programs written with Slicer in mind, it might mean a major code revision for VTK-based projects that have to be integrated with Slicer. This last point could be overcome by pre-transforming all input geometry and fiducials in IJK, but this is in general a bad idea, since surface curvature, etc will change in case of anisotropic voxels.

An alternative solution could be to extend the Archetype reader to output the RAS to LPS matrix as well (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials can be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.

Optionally, this last solution could be implemented in Slicer itself. The XML description would indicate which image entity provides the RAS to LPS transform, and all geometry and fiducials woudl be transformed in this coordinate system before the call to the CLI. After the CLI spits out data in the reference image LPS, Slicer would take care of applying the RAS to LPS inverse to whatever it loads up.
The benefit of this approach is nullified if two images with different orientations are passed to the CLI, but i) the RAS to LPS could be optional, ii) it wouldn't hurt a orientation-aware CLI anyway. The disadvantage is that potentially large vtkPolyData obejcts have to be duplicated (but this is common to all solutions except the first).

@@ Line 8: / Line 8: @@
 When calling a CLI plugin, Slicer writes temporary data files that are fed to the CLI:
 * the vtkPolyData point coordinates are first transformed in RAS (i.e. its points are transformed with the proper vtkMatrix4x4) and the file is written in VTK format. When the CLI program reads the VTK file, it implicitly has the data and the transform (which has become the identity matrix after the transformation has been applied berfore the call to the CLI program).
-* fiducials are passed along as a comma-separated list of float arguments, and are expressed in RAS (for now, although the extension to LSP and IJK has been planned - by the way, if one specifies LSP, he should also specify LPS of what image, otherwise one fiducial in LPS corresponds to many fiducials in RAS)
+* fiducials are passed along as a comma-separated list of float arguments, and are expressed in RAS (for now, although the extension to LSP and IJK has been planned - by the way, if one specifies IJK, he should also specify the image he refers to, otherwise one fiducial in IJK corresponds to many fiducials in RAS)
 * vtkImageData is stored in a nrrd file, with the information about the vtkMatrix4x4 stored in the header as space origin and space directions (which also include spacing); when the Archetype reader in the CLI reads the file in, the two objects are recreated: in the current implementation the vtkImageData has origin and spacing information, while vtkMatrix4x4 expresses the RAS to IJK transform.
-The problem is that vtkImageData as a stand-alone obejct lives in LSP, while fiducials and geometry live in RAS. Therefore, if a CLI program has to locate one point of a surface on top of an image, the plugin coder has to transform the point and then probe the image. This adds an additional layer to what VTK usually requires, and potentially means a major code revision for VTK-based projects that have to be integrated with Slicer. Also, if the CLI writes out the image in a format different from nrrd, the matrix is lost (unless it is stored in the header or in field data).
+The problem is that vtkImageData as a stand-alone obejct lives in IJK+origin+spacing, while fiducials and geometry live in RAS. Therefore, if a CLI program has to locate one point of a surface on top of an image, the plugin coder has to transform the point and then probe the image. This adds an additional layer to what VTK usually requires, and potentially means a major code revision for VTK-based projects that have to be integrated with Slicer. Also, if the CLI writes out the image in a format different from nrrd, the matrix is lost (unless it is stored in the header or in field data).
 A potential solution for this problem would be the following:
-extend the Archetype reader to output the RAS to LSP matrix (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials can be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.
+extend the Archetype reader to output the RAS to the Local image coordinates (IJK*spacing+origin) matrix (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials passed to the CLI woudl be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.
 <small>Note: this is similar to what happens in the ModelMaker CLI module, except that in ModelMaker origin and spacing are set to 0,0,0 and 1,1,1 respectively and geometry is generated in IJK coordinates. This is not viable as a general solution because i) most image processing algorithms are voxel spacing-aware ii) surface curvature, etc change in case of anisotropic spacing.</small>
-Optionally, the RAS to LSP solution could be implemented in Slicer itself. The XML description would indicate which image entity provides the RAS to LSP transform, and all geometry and fiducials woudl be transformed in this coordinate system before the call to the CLI. After the CLI spits out data in the reference image LSP, Slicer would take care of applying the RAS to LSP inverse to whatever it loads up.
+Optionally, the RAS to Local solution could be implemented in Slicer itself. The XML description would indicate which image entity provides the RAS to Local transform, and all geometry and fiducials would be transformed in this coordinate system before the call to the CLI. After the CLI spits out data in the reference image Local, Slicer would take care of applying the RAS to Local inverse to whatever it loads up.
-The benefit of this approach is nullified if two images with different orientations are passed to the CLI, but i) the RAS to LSP could be optional, ii) it wouldn't hurt a orientation-aware CLI anyway. The disadvantage is that potentially large vtkPolyData obejcts have to be duplicated (but this is common to all solutions except the first).
+The benefit of this approach is nullified if two images with different orientations are passed to the CLI, but i) IJK fiducials have even the same problem ii) the RAS to Local mechanism could be optional. The disadvantage is that potentially large vtkPolyData obejcts have to be duplicated (but this is common to all solutions except transforming points in the plugin code).

@@ Line 8: / Line 8: @@
 When calling a CLI plugin, Slicer writes temporary data files that are fed to the CLI:
 * the vtkPolyData point coordinates are first transformed in RAS (i.e. its points are transformed with the proper vtkMatrix4x4) and the file is written in VTK format. When the CLI program reads the VTK file, it implicitly has the data and the transform (which has become the identity matrix after the transformation has been applied berfore the call to the CLI program).
-* fiducials are passed along as a comma-separated list of float arguments, and are expressed in RAS (for now, although the extension to LPS and IJK has been planned - by the way, if one specifies LPS, he should also specify LPS of what image, otherwise one fiducial in LPS corresponds to many fiducials in RAS)
+* fiducials are passed along as a comma-separated list of float arguments, and are expressed in RAS (for now, although the extension to LSP and IJK has been planned - by the way, if one specifies LSP, he should also specify LPS of what image, otherwise one fiducial in LPS corresponds to many fiducials in RAS)
 * vtkImageData is stored in a nrrd file, with the information about the vtkMatrix4x4 stored in the header as space origin and space directions (which also include spacing); when the Archetype reader in the CLI reads the file in, the two objects are recreated: in the current implementation the vtkImageData has origin and spacing information, while vtkMatrix4x4 expresses the RAS to IJK transform.
-The problem is that vtkImageData as a stand-alone obejct lives in LPS, while fiducials and geometry live in RAS. Therefore, if a CLI program has to locate one point of a surface on top of an image, the plugin coder has to transform the point and then probe the image. This adds an additional layer to what VTK usually requires, and potentially means a major code revision for VTK-based projects that have to be integrated with Slicer. Also, if the CLI writes out the image in a format different from nrrd, the matrix is lost (unless it is stored in the header or in field data).
+The problem is that vtkImageData as a stand-alone obejct lives in LSP, while fiducials and geometry live in RAS. Therefore, if a CLI program has to locate one point of a surface on top of an image, the plugin coder has to transform the point and then probe the image. This adds an additional layer to what VTK usually requires, and potentially means a major code revision for VTK-based projects that have to be integrated with Slicer. Also, if the CLI writes out the image in a format different from nrrd, the matrix is lost (unless it is stored in the header or in field data).
 A potential solution for this problem would be the following:
-extend the Archetype reader to output the RAS to LPS matrix (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials can be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.
+extend the Archetype reader to output the RAS to LSP matrix (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials can be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.
 <small>Note: this is similar to what happens in the ModelMaker CLI module, except that in ModelMaker origin and spacing are set to 0,0,0 and 1,1,1 respectively and geometry is generated in IJK coordinates. This is not viable as a general solution because i) most image processing algorithms are voxel spacing-aware ii) surface curvature, etc change in case of anisotropic spacing.</small>
-Optionally, the RAS to LPS solution could be implemented in Slicer itself. The XML description would indicate which image entity provides the RAS to LPS transform, and all geometry and fiducials woudl be transformed in this coordinate system before the call to the CLI. After the CLI spits out data in the reference image LPS, Slicer would take care of applying the RAS to LPS inverse to whatever it loads up.
+Optionally, the RAS to LSP solution could be implemented in Slicer itself. The XML description would indicate which image entity provides the RAS to LSP transform, and all geometry and fiducials woudl be transformed in this coordinate system before the call to the CLI. After the CLI spits out data in the reference image LSP, Slicer would take care of applying the RAS to LSP inverse to whatever it loads up.
-The benefit of this approach is nullified if two images with different orientations are passed to the CLI, but i) the RAS to LPS could be optional, ii) it wouldn't hurt a orientation-aware CLI anyway. The disadvantage is that potentially large vtkPolyData obejcts have to be duplicated (but this is common to all solutions except the first).
+The benefit of this approach is nullified if two images with different orientations are passed to the CLI, but i) the RAS to LSP could be optional, ii) it wouldn't hurt a orientation-aware CLI anyway. The disadvantage is that potentially large vtkPolyData obejcts have to be duplicated (but this is common to all solutions except the first).

@@ Line 11: / Line 11: @@
 * vtkImageData is stored in a nrrd file, with the information about the vtkMatrix4x4 stored in the header as space origin and space directions (which also include spacing); when the Archetype reader in the CLI reads the file in, the two objects are recreated: in the current implementation the vtkImageData has origin and spacing information, while vtkMatrix4x4 expresses the RAS to IJK transform.
-The problem is that vtkImageData as a stand-alone obejct lives in LPS, while fiducials and geometry live in RAS. Therefore, if a CLI program has to locate one point of a surface on top of an image, the plugin coder has to transform the point and then probe the image. This adds an additional layer to what VTK usually requires, and potentially means a major code revision for VTK-based projects that have to be integrated with Slicer.
+The problem is that vtkImageData as a stand-alone obejct lives in LPS, while fiducials and geometry live in RAS. Therefore, if a CLI program has to locate one point of a surface on top of an image, the plugin coder has to transform the point and then probe the image. This adds an additional layer to what VTK usually requires, and potentially means a major code revision for VTK-based projects that have to be integrated with Slicer. Also, if the CLI writes out the image in a format different from nrrd, the matrix is lost (unless it is stored in the header or in field data).
 A potential solution for this problem would be the following:

← Older revision		Revision as of 09:14, 13 January 2007
Line 16:		Line 16:

	extend the Archetype reader to output the RAS to LPS matrix (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials can be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.		extend the Archetype reader to output the RAS to LPS matrix (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials can be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.
		+
	<small>Note: this is similar to what happens in the ModelMaker CLI module, except that in ModelMaker origin and spacing are set to 0,0,0 and 1,1,1 respectively and geometry is generated in IJK coordinates. This is not viable as a general solution because i) most image processing algorithms are voxel spacing-aware ii) surface curvature, etc change in case of anisotropic spacing.</small>		<small>Note: this is similar to what happens in the ModelMaker CLI module, except that in ModelMaker origin and spacing are set to 0,0,0 and 1,1,1 respectively and geometry is generated in IJK coordinates. This is not viable as a general solution because i) most image processing algorithms are voxel spacing-aware ii) surface curvature, etc change in case of anisotropic spacing.</small>

@@ Line 16: / Line 16: @@
 extend the Archetype reader to output the RAS to LPS matrix (i.e. origin and spacing would be factored out from the vtkMatrix4x4). This way, assuming all images in the CLI have the same orientation matrix (which is reasonable since it's a constraint imposed by VTK), all vtkPolyData and fiducials can be transformed before the actual processing without losing their shape, and point location or extraction could be left unmodified in the CLI algorithm code. The plugin coder would have to worry about transforms only at the beginning and at the end of the CLI program, which would ease the effort of interfacing existing projects with Slicer.
-<ref>This is similar to what happens in the ModelMaker CLI module, except that in ModelMaker origin and spacing are set to 0,0,0 and 1,1,1 respectively and geometry is generated in IJK coordinates. This is not viable as a general solution because i) most image processing algorithms are voxel spacing-aware ii) surface curvature, etc change in case of anisotropic spacing.</ref>
+<small>Note: this is similar to what happens in the ModelMaker CLI module, except that in ModelMaker origin and spacing are set to 0,0,0 and 1,1,1 respectively and geometry is generated in IJK coordinates. This is not viable as a general solution because i) most image processing algorithms are voxel spacing-aware ii) surface curvature, etc change in case of anisotropic spacing.</small>
 Optionally, the RAS to LPS solution could be implemented in Slicer itself. The XML description would indicate which image entity provides the RAS to LPS transform, and all geometry and fiducials woudl be transformed in this coordinate system before the call to the CLI. After the CLI spits out data in the reference image LPS, Slicer would take care of applying the RAS to LPS inverse to whatever it loads up.
 The benefit of this approach is nullified if two images with different orientations are passed to the CLI, but i) the RAS to LPS could be optional, ii) it wouldn't hurt a orientation-aware CLI anyway. The disadvantage is that potentially large vtkPolyData obejcts have to be duplicated (but this is common to all solutions except the first).