NAMIC Wiki:DTI:Fiber format

IO specs for DTI Fiber data, suggestion by UNC

Implentation suggestions:

• Support directly within ITK and VTK
• Processing using ITK and display using VTK
• ITK datastructure based on Spatial Objects
  • Each fiber is defined by a set of points along the fiber with each point possessing a set of attributes
  • ITK inheritance: [itk::SpatialObject] -> [itk::TubeSpatialObject] -> [itk::DTITubeSpatialObject]
  • MetaIO in ITK for loading and saving DTITubeSpatialObject, should support multiple version (compability to older versions)
  • Existing Meta IO in ITK using [itk::MetaDTITubeConverter] for reading and writing
• Btw Stephen Aylward's group is developing an itk::VesselTubeSpatialObject on top of the TubeSpatialObject for their vessel extraction, vessel model to image registration etc. Stephen's group is currently also developing a set of RenderMethods that link SpatialObjects to vtkActors. Basically, for each SpatialObject the Render Method creates a VTK actor. The framework uses the object factory concept to find a "default" rendering object. Users can also switch between render methods (like CenterLine representation of the tube, surface coloring, surface without color, Ellipsoid at each point etc...)

Necessary attributes per fiber:

• Point set
• Radius of fiber (either per point or per fiber)
• Tensor interpolation method (could store the method the tensor was optionally interpolated with)?

Necessary attributes per point (all of these attributes are already implemented in [itk::DTITubeSpatialObjectPoint]):

• Position vector x, y, z
• Frenet frame described by tangent vector and the 2 normal vectors
• Radius of fibers, useful for display. There could be a single radius for each fiber, or per point. Currently itk::TubeSpatialObjectPoint supports a single radius per point. I would though suggest to have only a single radius per fiber.
• Color, useful for display
• FA value
• ADC value
• GA value
• Lambda 1 largest eigenvalue
• Lambda 2 middle eigenvalue
• Lambda 3 smallest eigenvalue
• Ev1 largest eigenvector
• Ev2 middle eigenvector
• Ev3 smallest eigenvector
• Lamba1-3 + Ev1-3 fully describe the tensor
• Tensor info (additional): 6 float tensor matrix (upper triangle)
• MRattribute1 - MRattribute5: 5 custom fields for storing related MRI grayscale information
• Tensor interpolation method (currently stored as a single integer-id per point, but probably should be stored per fiber)

Suggestions by BWH

Attributes per fiber point implemented in itk::DTITubeSpatialObjectPoint are totally reasonable. Some of these attributes could be extracted from the stored tensor, namely, eigenvalues and eigenvectors, FA...

Fileformat: vtkPolyData [[1]]:

• Each fiber stored as two POLY_LINE cells: each cell links points for the forward and backward integration direction respectively.
• Attribute stored as DataSet Attributes. There is support for Scalars, Normals and Tensors. The different measures described above can be stored in one of this fields. Each field can be identified from a given Tag to be preestablished.

Advantage of this fileformat:

• Take advantage of the existing readers and writers.
• Total integration with VTK
• Possibility of ASCII and Binary.
• New attributes can be added to the format.

Additional comments by UNC

Attributes

• The redundant information (i.e. FA or ADC are computed from the tensor) allows efficient access of the attributes
• Should we store redundant information in the file or compute them when reading/writing? In order to reduce computation time when reading/writing, I would prefer to store the redundant information.
• There could an integrity check procedure for the itk::DTITubeSpatialObjectPoint that checks the integrity of the redundant information and recomputes the derived information such as FA,ADC,Eigenvalues in case of an error (assuming the tensor is correct). This routine could be called by the user if needed.

Fileformat

• The VTK fileformat sounds very interesting. vtkPolyDataReader should be able to read the data and anybody using VTK can display the tubes (without using the DTI attributes though)
• There is no VTK reader/writer yet that specifically interpretes the DTI attributes
• ITK already has a reader/writer using MetaIO for directly reading/writing itk::DTITubeSpatialIObject objects
• The ITK MetaIO is easily expandable and is built on a nice class hierarchy. Currently, it cannot write the data in binary format and thus the fiber files can grow quite large.
• Both options (ITK MetaIO and VTK Polydata IO) are valuable options, and the main question is thus whether the file handling should be integrated within ITK (the processing library) or VTK (the display library).
• There is no translation to itk::DTITubeSpatialIObject from vtkPolyData, such a translation would be necessary when using vtkPolyDataReader
• As ITK would be the choice for processing the fibers, a translation from itk::DTITubeSpatialIObject to vtk will be necessary in any case.

Additional comments from GE Research

Fileformat

• DTI attributes can be stored as field data in the VTK file formats. Any array can be stored as field data. Each field data array has a string "key" or "name". So the FA attribute could be stored in a field called "FA". The ADC attribute could be stored in a field called "ADC". The eigenvalues could be stored in separate fields, as could the eigenvectors. When the file is read, all this field information will be attached to the DataSet, the PointData, or CellData as appropriate. Various fields can be selected as the "active set" and visualized.

Additional comments from MIT/BWH (O'Donnell)

• The issue with the field data as I understand it is that only per-point scalars, etc. can be stored. There are attributes that are per-tract which are also needed, and have not been mentioned on this page.

• These include labels (division into clusters or anatomy) and anatomical names.

• Do the GE folks have a comment about if this is possible to store in vtkPolyData? It would require arrays of a shorter length than the per-point arrays. We believe it is not possible.

• I plan to implement saving such information in the slicer MRML file format. I think that it will work better for our purposes to keep the higher-level information about cluster/anatomy membership separate from the raw data of the tract paths.

BWH File format (vtkPolyData)

• Coordinate system: RAS
  • Note that this loses connection to tensor data
  • MRML can store RAS->tensor IJK
  • MRML needs way to reference original tensor data
• Polylines
  • Points field containing points on the lines
  • Cells describing line connectivity
• Per-point data (optional)
  • Tensors
  • Scalars (possible but not needed if store tensors)
• Per-cell data (per line)
  • Initial point (index of this point)
  • Tract properties (optional)

• Sample test file containing polylines (not other optional properties)