How to convert DTI tensor nhdr file from NRRD0004 to NRRD0005

Dear all,

I wonder if there is any way to convert DTI tensor file in .nhdr format from NRRD0004 to NRRD0005?
As in the header file .nhdr for tensor,
NRRD0004 has a line with six components, e.g. sizes: 6 181 216 179, while
NRRD0005 has a line with nine components, e.g. sizes: 9 181 216 179

Strangely, earlier when I saved DTI tensor into .nhdr, it wrote a .nhdr file with 6 components (NRRD0004 ), but now always writes into with 9 components (NRRD0005), though I seemed to do exactly the same steps. Any way to convert between both using Slicer? Thanks a lot for your attention.

Best regards, Xiaogai

Probably your version 4 file uses 3D-symmetric-matrix while the version 5 uses 3D-matrix. See the definitions here. Either should be fine for DTI.

If you really need to convert, the unu command should be easy to use.

1 Like

Thanks a lot! Exactly as you said, both are fine for DTI, and only differ 3D-symmetric-matrix and 3D-matrix.

I just checked unu command, seems unu save or unu convert may work, but none seem to have option to specify the conversion. Will be really appreciated if you have insights on what command to use. Thank you very much.

Or if there is any way to specify in Slicer 3D to save DTI files into 3D-symmetric-matrix (version 4) format?

I should have mentioned that the problem occurs when I have used module Resample DTI Volume in Slicer, then when saving to .nhdr always ended in version 5. Thanks!

Hmm, good question - I don’t know if there’s anyway to do that without writing a C or C++ program. All the utilities in the teem suite are pretty powerful but I don’t recall anything that handles that particular operation. Good luck!

Is there any reason that Slicer changed from the 6 component 3D-symmetric-matrix to the 3D-matrix? The 9 volume stores
XX XY XZ XY YY YZ XZ YZ ZZ
while the 6 component format removes the redundant volumes (here upper triangle):
XX XY XZ YY YZ ZZ
So the resulting file size and memory demands, cache penalties, etc. are all limitations of the 9 component storage. Furthermore, the compact representation would ease interoperability with other tools.

I don’t recall if it was a deliberate choice. Maybe @ljod knows? I agree that taking advantage of the symmetry is a good thing in general.