View source for Nrrd ITK IO, read and write nrrd tensor data with ITK (Gordon Kindlmann)

= Wrapping up loose ends with NrrdIO =

[[Image:Namic-nrrdIO.ppt|Image:Namic-nrrdIO.ppt]]

== Intro ==

The NRRD format has recently seen some incremental additions (such as the "measurement frame: ") field. ITK's NrrdIO Utility doesn't yet have these changes, and nor is the ITK wrapper around NrrdIO very sophisticated about mapping Nrrd info to ITK info. Also, since the initial release of the NAMIC NRRD DW-MRI data from Harvard, there were some improvements in how key/value pairs are used to represent the parameters of the DWI sequence. New headers should be generated to reflect these improvements.

== Status ==

* Updating ITK's NrrdIO to use the "measurement frame: " field should be done immediately.
* Generating improved headers for NAMIC datasets can hopefully be done prior to the programming week.
* Updating ITK's wrapper around NrrdIO is my main goal for the programming week. I will be leaning on others (perhaps even Bill Lorensen) for their knowledge of ITK's image properties to ensure the correctness of the Nrrd-to-ITK property mappings

== Success Determination ==

* For all fields in the NRRD format, there is either a mapping to the analogous ITK image property, or there is no such analog.
* Some other NAMIC software can read in and usefully process the DWI-specific key/value pairs in NRRD headers

== Contacts ==

Gordon Kindlmann @ Brigham & Women's

== Post-Programming Week ==

* Updated ITK's NrrdIO to read the "measurement frame: " field; it is now saved in the MetaData dictionary.
* Slicer can now use the measurement frame to set tensor orientation; but this is via Slicer's VTK-based nrrd reader (with calls to Insight/Utilities/NrrdIO), rather than via ITK's wrapper around NrrdIO (Code/IO/itkNrrdImageIO.cxx)
* Orientation information now mapped between NRRD and ITK, but only for scalar images

Things yet undone:

* Create an ITK image type which nicely handles DWI datasets. Karthik Krishnan (and hopefully others?) have said they can help with this. The main requirement is that

# DWI values for one pixel are closest, not furthest, in memory
# all DWI values are contiguous in memory
# number of DWI values per pixel is known only at run-time

* more complete mapping between NRRD and ITK for non-scalar pixel types.