NA-MIC/Projects/NA-MIC Kit/Coordinate Systems - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T18:07:27Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Melonakos at 21:31, 5 November 2008

2008-11-05T21:31:56Z

Melonakos at 21:26, 5 November 2008

2008-11-05T21:26:51Z

Melonakos at 18:39, 28 November 2007

2007-11-28T18:39:35Z

Mhalle at 20:17, 24 April 2007

2007-04-24T20:17:52Z

Millerjv at 20:21, 20 April 2007

2007-04-20T20:21:07Z

Millerjv at 20:19, 20 April 2007

2007-04-20T20:19:52Z

Millerjv at 20:19, 20 April 2007

2007-04-20T20:19:12Z

Millerjv at 20:18, 20 April 2007

2007-04-20T20:18:41Z

Millerjv at 20:18, 20 April 2007

2007-04-20T20:18:10Z

@@ Line 12: / Line 12: @@
 ''Slicer3/MRML'' Slicer3 employs an RAS coordinate frame and manages coordinate frame relationships between various data using transform nodes in the MRML scene. [[NA-MIC/Projects/NA-MIC Kit/IO Unification|Slicer3 leverages the ITK IO factory mechanism]] to provide a variety of image file formats. Because ITK uses an LPS coordinate frame (matching DICOM conventions), Slicer3 explictly manages conversions from RAS <-> LPS during IO.
 ''Non-linear/non-euclidean coordinate systems'' Applications such as astronomy and ultrasound use non-linear or non-euclidean coordinate systems to represent the physical/angular position of data voxels.  Use cases for these transforms include readout of voxel positions located under a mouse or cursor, and drawing of coordinate systems overlays representing the equivalent of latitude and longitude.  Because these coordinate systems can be domain-specific and computationally complex, a direction cosine represention is inadequate: the ideal solution is the creation of an opaque transform that can wrap native coordinate system libraries and be passed down an itk pipeline to Slicer.  Currently, there is no supported solution to this coordinate system issue in vtk, itk, or Slicer.  The NA-MIC team has proposed a possible solution based on loading a transform into the metadata dictionary.  An prototype astronomy data reader as been developed to test this idea, but the itk pipeline support has not been implemented.
-''Command line module'' The [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model execution model] infrastructure in Slicer3 communicates all data between the Slicer3 MRML scene and the Slicer3 plugin (also referred to as a command line module).  The execution model supports two types of plugins.  The first is a command line executable.  The second is a shared object module or DLL.  In the former, some data is written to disk to be passed to the module while other data is passed directly on the command line.  In the latter, scalar image data (to be expanded to include vector and tensor image data) is passed via memory to the module while other types of data are passed via files or directly on the command line.  In all cases and permutations, Slicer3 and the module must agree on the coordinate conventions, either defined in the requirements or specified with the data. This is an area needing further specification and development. Currently some data types are converted from RAS <-> LPS when transferred to a plugin module while other data is assumed to be in a RAS coordinate frame.
+''Command line module'' The [https://www.slicer.org/wiki/Slicer3:Execution_Model execution model] infrastructure in Slicer3 communicates all data between the Slicer3 MRML scene and the Slicer3 plugin (also referred to as a command line module).  The execution model supports two types of plugins.  The first is a command line executable.  The second is a shared object module or DLL.  In the former, some data is written to disk to be passed to the module while other data is passed directly on the command line.  In the latter, scalar image data (to be expanded to include vector and tensor image data) is passed via memory to the module while other types of data are passed via files or directly on the command line.  In all cases and permutations, Slicer3 and the module must agree on the coordinate conventions, either defined in the requirements or specified with the data. This is an area needing further specification and development. Currently some data types are converted from RAS <-> LPS when transferred to a plugin module while other data is assumed to be in a RAS coordinate frame.
 = Key Investigators =
@@ Line 23: / Line 23: @@
 * [http://www.itk.org/Wiki/Proposals:Orientation Image Orientation in ITK]
 * [[NAMIC Wiki:DTI:Nrrd format | NRRD DTI Format]]
-* [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model Slicer3 Execution Model]
+* [https://www.slicer.org/wiki/Slicer3:Execution_Model Slicer3 Execution Model]
-* [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer3 Execution Model Documentation]
+* [https://www.slicer.org/wiki/Slicer3:Execution_Model_Documentation Slicer3 Execution Model Documentation]
 * [[Execution Model Reference Systems]]

@@ Line 12: / Line 12: @@
 ''Slicer3/MRML'' Slicer3 employs an RAS coordinate frame and manages coordinate frame relationships between various data using transform nodes in the MRML scene. [[NA-MIC/Projects/NA-MIC Kit/IO Unification|Slicer3 leverages the ITK IO factory mechanism]] to provide a variety of image file formats. Because ITK uses an LPS coordinate frame (matching DICOM conventions), Slicer3 explictly manages conversions from RAS <-> LPS during IO.
 ''Non-linear/non-euclidean coordinate systems'' Applications such as astronomy and ultrasound use non-linear or non-euclidean coordinate systems to represent the physical/angular position of data voxels.  Use cases for these transforms include readout of voxel positions located under a mouse or cursor, and drawing of coordinate systems overlays representing the equivalent of latitude and longitude.  Because these coordinate systems can be domain-specific and computationally complex, a direction cosine represention is inadequate: the ideal solution is the creation of an opaque transform that can wrap native coordinate system libraries and be passed down an itk pipeline to Slicer.  Currently, there is no supported solution to this coordinate system issue in vtk, itk, or Slicer.  The NA-MIC team has proposed a possible solution based on loading a transform into the metadata dictionary.  An prototype astronomy data reader as been developed to test this idea, but the itk pipeline support has not been implemented.
-''Command line module'' The [[Slicer3:Execution Model|execution model]] infrastructure in Slicer3 communicates all data between the Slicer3 MRML scene and the Slicer3 plugin (also referred to as a command line module).  The execution model supports two types of plugins.  The first is a command line executable.  The second is a shared object module or DLL.  In the former, some data is written to disk to be passed to the module while other data is passed directly on the command line.  In the latter, scalar image data (to be expanded to include vector and tensor image data) is passed via memory to the module while other types of data are passed via files or directly on the command line.  In all cases and permutations, Slicer3 and the module must agree on the coordinate conventions, either defined in the requirements or specified with the data. This is an area needing further specification and development. Currently some data types are converted from RAS <-> LPS when transferred to a plugin module while other data is assumed to be in a RAS coordinate frame.
+''Command line module'' The [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model execution model] infrastructure in Slicer3 communicates all data between the Slicer3 MRML scene and the Slicer3 plugin (also referred to as a command line module).  The execution model supports two types of plugins.  The first is a command line executable.  The second is a shared object module or DLL.  In the former, some data is written to disk to be passed to the module while other data is passed directly on the command line.  In the latter, scalar image data (to be expanded to include vector and tensor image data) is passed via memory to the module while other types of data are passed via files or directly on the command line.  In all cases and permutations, Slicer3 and the module must agree on the coordinate conventions, either defined in the requirements or specified with the data. This is an area needing further specification and development. Currently some data types are converted from RAS <-> LPS when transferred to a plugin module while other data is assumed to be in a RAS coordinate frame.
 = Key Investigators =
@@ Line 23: / Line 23: @@
 * [http://www.itk.org/Wiki/Proposals:Orientation Image Orientation in ITK]
 * [[NAMIC Wiki:DTI:Nrrd format | NRRD DTI Format]]
-* [[Slicer3:Execution Model | Slicer3 Execution Model]]
+* [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model Slicer3 Execution Model]
 * [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer3 Execution Model Documentation]
 * [[Execution Model Reference Systems]]

@@ Line 24: / Line 24: @@
 * [[NAMIC Wiki:DTI:Nrrd format | NRRD DTI Format]]
 * [[Slicer3:Execution Model | Slicer3 Execution Model]]
-* [[Slicer3:Execution Model Documentation|Slicer3 Execution Model Documentation]]
+* [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer3 Execution Model Documentation]
 * [[Execution Model Reference Systems]]

@@ Line 1: / Line 1: @@
   Back to [[NA-MIC_Collaborations|NA-MIC_Collaborations]]
-'''Objective:''' To provide the infrastructure necessary to represent, manage, and transform between the variety of coordinate frames used in medical imaging.
+= Name of Template project goes right here =
-<br />'''Progress:''' Coordinate frame support is required at 3 distinct levels: low level library support via ITK and NRRD, application level support in Slicer3 via MRML, and execution model support via the command line modules.
+Our objective is to provide the infrastructure necessary to represent, manage, and transform between the variety of coordinate frames used in medical imaging.
-:'''ITK/NRRD.''' A new image class, itk::OrientedImage, has been developed and added to ITK. This image class caches the image direction cosines. ITK's IO mechanisms have been updated to read and write orientation information. Filters which implictly manipulate orientation (flip, resample, etc.) have been modified to explictly modify the cached image orientation. NRRD support has been expanded to include specification of the patient coordinate frame as well as the gradient coil [http://teem.sourceforge.net/nrrd/format.html#measurementframe measurement frame].
+= Description =
-'''Key Investigators:'''
+Coordinate frame support is required at 3 distinct levels: low level library support via ITK and NRRD, application level support in Slicer3 via MRML, and execution model support via the command line modules.
 * GE Research: Bill Lorensen, Jim Miller
 * Isomics: Steve Pieper
-'''Links:'''
+= Links =
 * [http://www.itk.org/Wiki/Proposals:Orientation Image Orientation in ITK]

@@ Line 7: / Line 7: @@
 :'''ITK/NRRD.''' A new image class, itk::OrientedImage, has been developed and added to ITK. This image class caches the image direction cosines. ITK's IO mechanisms have been updated to read and write orientation information. Filters which implictly manipulate orientation (flip, resample, etc.) have been modified to explictly modify the cached image orientation. NRRD support has been expanded to include specification of the patient coordinate frame as well as the gradient coil [http://teem.sourceforge.net/nrrd/format.html#measurementframe measurement frame].
 :'''Slicer3/MRML.''' Slicer3 employs an RAS coordinate frame and manages coordinate frame relationships between various data using transform nodes in the MRML scene. [[NA-MIC/Projects/NA-MIC Kit/IO Unification|Slicer3 leverages the ITK IO factory mechanism]] to provide a variety of image file formats. Because ITK uses an LPS coordinate frame (matching DICOM conventions), Slicer3 explictly manages conversions from RAS <-> LPS during IO.
 :'''Command line module.''' The [[Slicer3:Execution Model|execution model]] infrastructure in Slicer3 communicates all data between the Slicer3 MRML scene and the Slicer3 plugin (also referred to as a command line module).  The execution model supports two types of plugins.  The first is a command line executable.  The second is a shared object module or DLL.  In the former, some data is written to disk to be passed to the module while other data is passed directly on the command line.  In the latter, scalar image data (to be expanded to include vector and tensor image data) is passed via memory to the module while other types of data are passed via files or directly on the command line.  In all cases and permutations, Slicer3 and the module must agree on the coordinate conventions, either defined in the requirements or specified with the data. This is an area needing further specification and development. Currently some data types are converted from RAS <-> LPS when transferred to a plugin module while other data is assumed to be in a RAS coordinate frame.

@@ Line 6: / Line 6: @@
 :'''ITK/NRRD.''' A new image class, itk::OrientedImage, has been developed and added to ITK. This image class caches the image direction cosines. ITK's IO mechanisms have been updated to read and write orientation information. Filters which implictly manipulate orientation (flip, resample, etc.) have been modified to explictly modify the cached image orientation. NRRD support has been expanded to include specification of the patient coordinate frame as well as the gradient coil [http://teem.sourceforge.net/nrrd/format.html#measurementframe measurement frame].
-:'''Slicer3/MRML.''' Slicer3 employs an RAS coordinate frame and manages coordinate frame relationships between various data using transform nodes in the MRML scene. [[NA-MIC/Projects/NA-MIC Kit/IO Unification|Slicer3 leverages the ITK IO factory mechanism]] to provide a variety of image file formats. Since ITK uses an LPS coordinate frame (matching DICOM conventions), Slicer3 manages conversions from RAS <-> LPS during IO.
+:'''Slicer3/MRML.''' Slicer3 employs an RAS coordinate frame and manages coordinate frame relationships between various data using transform nodes in the MRML scene. [[NA-MIC/Projects/NA-MIC Kit/IO Unification|Slicer3 leverages the ITK IO factory mechanism]] to provide a variety of image file formats. Because ITK uses an LPS coordinate frame (matching DICOM conventions), Slicer3 explictly manages conversions from RAS <-> LPS during IO.
 :'''Command line module.''' The execution model infrastructure in Slicer3 communicates all data between the Slicer3 MRML scene and the Slicer3 plugin (also referred to as a command line module).  The execution model supports two types of plugins.  The first is a command line executable.  The second is a shared object module or DLL.  In the former, some data is written to disk to be passed to the module while other data is passed directly on the command line.  In the latter, scalar image data (to be expanded to include vector and tensor image data) is passed via memory to the module while other types of data are passed via files or directly on the command line.  In all cases and permutations, Slicer3 and the module must agree on the coordinate conventions, either defined in the requirements or specified with the data. This is an area needing further specification and development. Currently some data types are converted from RAS <-> LPS when transferred to a plugin module while other data is assumed to be in a RAS coordinate frame.