Opening FA color map created by MRtrix in other software

Hi everyone,

We have calculated the FA (colored) map with dwi2tensor and tensor2metric. However, when opening it with other viewers for .nii files, such as MRIcro, it is a greyscale image. It looks like the vector information is saved in layers and only MRview can visualize it as a color map (there it looks normal). Also, Trackvis is unable to open the file (unknown error). How can we solve this?

Many thanks in advance!



Hi Klara,

Directionally-encoded colour (DEC) data are stored as 4D images with three volumes; the non-negative values in each of these volumes correspond to the red, green and blue components of the colour / intensity of each voxel. This should be evident in the output of mrinfo.

Assuming the data have been generated correctly, which should be the case if mrview shows it correctly, I can think of two things that may conceivably lead to issues:

  • Other softwares may require that the values stored within a DEC image lie within the range [0, 1], and fail to display as such / produce an error if this is not the case. FA values may exceed 1 in the presence of negative eigenvalues. You could try running mrstats on the image, and check the minimum / maximum values.

  • I was going to suggest that other softwares may have been expecting a NIfTI Intent Code to display a DEC image; but there doesn’t actually appear to be an intent code for such…

In MRIcro, is it a greyscale FA image that is shown, or the first volume of the image (i.e. the left-right component of the first eigenvector, scaled by FA)? You can visualise the latter in mrview by changing the colour map from RGB to greyscale.


I know it’s been a while, but I just happened to be looking through the NIfTI specification for some other reason, and came across their suggestion as to how these kinds of data should be stored. It looks like they expect a 5D image with dimensions X×Y×Z×1×3, with the NIfTI intent code set to NIFTI_INTENT_VECTOR. MRtrix3 won’t set the intent code, but I’m guessing (hoping?) most other software packages will probably ignore them like we do…

So in your case, it might be sufficient to insert an extra singleton dimension along the 4th axis – assuming that’s what other packages expect. In this case, this should do the trick:

mrconvert dec.mif -axes 0,1,2,-1,3 dec.nii

but unfortunately this won’t work until this pull request is reviewed and merged, and you update your installation to match – there’s a bug in the handling of this specific scenario… :blush:

If you’re impatient, you can always make the relevant one-line change to your own installation directly, invoke ./build to re-compile, and you should be good to go.

1 Like

I suppose that would’ve been using tensor2metric -vector.

This is not 100% correct then: there will be negative values in there for sure. mrview automatically deals with this by ignoring the sign (i.e. taking the absolute value) when using the RGB colour map. The RGB colour map itself is automatically selected when opening a 3-volume 4D image.

So apart from getting it recognised correctly as an RGB image by other software, you might also want to perform an mrcalc -abs on it beforehand.

That must be something different altogether though. I don’t have experience with Trackvis, but maybe it simply doesn’t open 4D images in general? Apart from the intended RGB interpretation of the image, it’s “simply” a regular 4D image after all, so it should at least open in viewers that allow for 4D images. The only possible incompatibility I can think of there (again, based on zero experience, just guessing how other software might be picky about something particular), might be the “voxel size” for the 4th axis? Since it’s not a physical axis, some software might expect a special value there, or some software might not be able to deal with seeing a 4th number for the voxel size at all… Or finally, maybe an expected order of strides, maybe in particular for the 4th axis. Again, all just random guesses. But beyond all that, it’s simply a 4D image, with no other special properties beyond that.

Hi all,

I realize I am very late with this reply, my apologies. I got caught up in longitudinal data collection for my project followed by analyses of the collected behavioral data, and this post slipped my mind. Anyway, better late than never, and maybe it could still help others :blush:.

I figured out how to open the FA color images created by MRtrix (tensor2metric -vector) in:

  • ITK-snap: tools > layer inspector > general > display mode > RGB display
  • fsleyes: change 3D/4D volume (top left) to 3-direction vector image (RGB)
  • Freeview: file > load DTI volume > load fa.nii (from tensor2metric -fa) as FA data file and dec.nii (from tensor2metric -vec) as DTI vector file
  • mricron/mricroGL: open FA image as main image and then iteratively add the 3 different volumes of the dec.nii as an overlay image (overlay > add), adjust the color scale of the first overlay to red, the second one to green and the third one to blue.

The image intensities in dec.nii can indeed be negative or above 1 in my case. Although the “raw” dec.nii image still opens in the programs listed above as is, it looks indeed more familiar to me after taking the absolute values of the image values using mrcalc -abs (as discussed in this post) and suggested by Thijs.

However, I still cannot open the image in Trackvis (which is the software I actually want to use :sweat_smile:), also not with the trick of inserting the extra singleton dimension along the 4th axis. I have previously used Trackvis with FAC images created by ExploreDTI. It turns out ExploreDTI creates a 3D RGB24 image instead of a 4D image with three volumes. So Thijs was correct in that it probably doesn’t open 4D images… Do you think I can obtain such 3D RGB24 images somehow in MRtrix, or should I go through the pipeline in ExploreDTI?

Thank you, and, if you happen to reply in 2 years like I did, I totally understand :nerd_face:


It turns out ExploreDTI creates a 3D RGB24 image instead of a 4D image with three volumes.


Technically you could produce the raw image data by:

  1. Applying appropriate absolute value transform & scaling so that values lie between 0 and 255;
  2. Generate 4D image with 3 volumes, unity positive stride across volumes, and convert to uint8;
  3. Save as .mih, such that binary data are written to corresponding .dat file.

The trick would then be “splicing” this binary image data into a file with the appropriate NIfTI header. So if you don’t mind getting your hands dirty with a hex editor, it could be done. But I’m not personally familiar with any existing software to do this conversion.


Thanks a lot, Rob. I’m not so familiar with all these technicalities, but I’ll look into it! :grin:

Best, Klara

Indeed, it would be very useful to implement something like this for future releases. :crossed_fingers:

Thank you for the explanations @KlaraSchevenels and @rsmith!