Difference between revisions of "NA-MIC/Projects/NA-MIC Kit/Coordinate Systems"
m (Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/") |
|||
| 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. | ''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. | ''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 [ | + | ''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 = | = Key Investigators = | ||
| Line 23: | Line 23: | ||
* [http://www.itk.org/Wiki/Proposals:Orientation Image Orientation in ITK] | * [http://www.itk.org/Wiki/Proposals:Orientation Image Orientation in ITK] | ||
* [[NAMIC Wiki:DTI:Nrrd format | NRRD DTI Format]] | * [[NAMIC Wiki:DTI:Nrrd format | NRRD DTI Format]] | ||
| − | * [ | + | * [https://www.slicer.org/wiki/Slicer3:Execution_Model Slicer3 Execution Model] |
| − | * [ | + | * [https://www.slicer.org/wiki/Slicer3:Execution_Model_Documentation Slicer3 Execution Model Documentation] |
* [[Execution Model Reference Systems]] | * [[Execution Model Reference Systems]] | ||
Latest revision as of 18:07, 10 July 2017
Home < NA-MIC < Projects < NA-MIC Kit < Coordinate SystemsBack to NA-MIC_Collaborations
Name of Template project goes right here
Our objective is to provide the infrastructure necessary to represent, manage, and transform between the variety of coordinate frames used in medical imaging.
Description
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. 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 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
