Difference between revisions of "NA-MIC/Projects/NA-MIC Kit/Coordinate Systems"

From NAMIC Wiki
Jump to: navigation, search
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].  
 
:'''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.
 
:'''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.
  

Revision as of 20:19, 20 April 2007

Home < NA-MIC < Projects < NA-MIC Kit < Coordinate Systems
Back to NA-MIC_Collaborations

Objective: To provide the infrastructure necessary to represent, manage, and transform between the variety of coordinate frames used in medical imaging.


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.

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 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. 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.

Key Investigators:

  • GE Research: Bill Lorensen, Jim Miller
  • Isomics: Steve Pieper

Links: