Difference between revisions of "Slicer:VTK ITK Coordinates"
m (Update from Wiki) |
(→Slicer) |
||
Line 21: | Line 21: | ||
== Slicer == | == Slicer == | ||
− | In | + | === Slicer2.x === |
+ | In slicer2, images are stored in VTK convention with: | ||
* RasToIjk telling the mapping from patient space to the way data was originally on disk | * RasToIjk telling the mapping from patient space to the way data was originally on disk | ||
Line 27: | Line 28: | ||
Slicer composites all volume data in RAS space (axes pointing along Right-Anterior-Superior, which origin at the center of the volume by default). The rendering from RAS to View coordinates can select to view the data axial, coronal etc. | Slicer composites all volume data in RAS space (axes pointing along Right-Anterior-Superior, which origin at the center of the volume by default). The rendering from RAS to View coordinates can select to view the data axial, coronal etc. | ||
+ | |||
+ | === Slicer3 === | ||
+ | |||
+ | Slicer3 stores images in vtkImageData, but '''does not include the Y flip'''. This means that the image data in memory is laid out consistent with many medical image file formats (nrrd, analyze, meta, nifti...). | ||
+ | |||
+ | Slicer3 has a single matrix to map from image space to physical space: | ||
+ | |||
+ | * RASToIJK gives the IJK coordinate for any point in world space (invert this matrix to go the other way). | ||
== ITK == | == ITK == |
Revision as of 15:57, 15 January 2007
Home < Slicer:VTK ITK CoordinatesContents
Background
Both VTK and ITK have their image origin in the lower left corner of the image. The BIG difference is in the way they read in the data.
VTK view of Image Data
From the vtkDICOMImageReader: http://public.kitware.com/cgi-bin/viewcvs.cgi/IO/vtkDICOMImageReader.cxx?annotate=1.32
// DICOM stores the upper left pixel as the first pixel in an // image. VTK stores the lower left pixel as the first pixel in // an image. Need to flip the data.
Note that every vtk image reader does the mapping from the way data is stored on disk into the way it is stored in memory. For Slicer's Nrrd reader and Generic readers (based on ITK infrastructure), this is done using the vtkImageFlip filter to flip data along the y axis of the data after it is read as a block.
ITK view of Image Data
ITK internally does not do the same flipping of the data during read that VTK does. As result, if image data is passed from ITK to VTK for rendering, the pictures will appear upside down unless flipped.
Using VTK and ITK in Situations with Orientation Directions
Slicer
Slicer2.x
In slicer2, images are stored in VTK convention with:
- RasToIjk telling the mapping from patient space to the way data was originally on disk
- RasToVtk tell the mapping to the way VTK stores it in memory (flipped in Y)
Slicer composites all volume data in RAS space (axes pointing along Right-Anterior-Superior, which origin at the center of the volume by default). The rendering from RAS to View coordinates can select to view the data axial, coronal etc.
Slicer3
Slicer3 stores images in vtkImageData, but does not include the Y flip. This means that the image data in memory is laid out consistent with many medical image file formats (nrrd, analyze, meta, nifti...).
Slicer3 has a single matrix to map from image space to physical space:
- RASToIJK gives the IJK coordinate for any point in world space (invert this matrix to go the other way).
ITK
In ITK, the Spacing and Directions members of an itk::ImageBase holds the same information as slicer's RasToIjk (except stored differently).
Registration Framework
In order for the ITK Registration framework to generate RAS-to-RAS transforms, the slicer code resamples the image data including the flips.
Notes:
Although it is possible to represent the differences (the flip) in the Directions in ITK and/or the RasToIjk matrix in slicer, the drawback is that there isn't a 'standard' slice orientation which describes this difference (choices are IS, SI, AP, PA, RL, LR each of which corresponds to a radiology standard acquisition layout).