Complex fiber regions

Hello community!

I am a new user of mrtrix and am still trying to become familiar with it. I have two questions:

  1. has anyone ran into issues working with IDL nifti outputs in mrtrix? I created some simulated data in IDL in nifti format, but mrtrix seems to have trouble with it. I was hoping to find a way to fix this! Thanks for any input!

  2. is there a code in mrtrix that will output the number of fiber populations present in each voxel, either 1, 2 or 3, similar to what was presented in this paper:

I’ve never encountered this issue, but assuming other packages have no trouble loading these data sets, I’m happy to take a look and see if we can fix this. Feel free to send me a dataset via Dropbox or whichever means you’re comfortable with.

The sh2peaks command, combined with the -threshold option, is a good starting point. Any peaks below the specified threshold will be filled with NaN, you can count the number of estimated peaks using something like:

$ sh2peaks csd.mif -threshold 0.3 - | mrcalc - -isnan 1 -neq - | mrmath - sum -axis 3 - | mrcalc - 3 -div num_peaks.mif
sh2peaks: [100%] estimating peak directions
mrcalc: [100%] computing: (isnan (/tmp/mrtrix-tmp-adgyWl.mif) != 1)
mrmath: [100%] computing sum along axis 3...
mrcalc: [100%] computing: (/tmp/mrtrix-tmp-adgyWl.mif / 3)

However, bear in mind that the results are very dependent on the threshold used, the details of the acquisition, and the parameters used for the CSD (the current defaults are different than what was used in the paper you mention). The results in that paper were obtained using 12 repeats of a 30 direction sequence - a total of 360 volumes. You’ll find that trying to replicate this with more standard ~60 direction data will probably show a lot of noise…

Thank you for the detailed response! Sure I can definitely send some data your way. One of these files is a very small dataset (approx 30 voxels by 30 voxels I believe if not less) and I can directly email that to you if that is convenient for you! a quick google search tells me that your email is jdtournier@gmail.com, should I email?

And yes I developed a different technique to look at number of fibers and just wanted to compare results to the CSD approach. I will play around with the details and look at results.

Yes, that’s my email, feel free to send your file that way.

Just had a quick look at your file. It’s definitely not NIfTI1 compliant. The first 4 bytes of the file should correspond to a 32 bit integer with value 348, as per the specification - i.e. this bit:

 int   sizeof_hdr;    /*!< MUST be 348           */  /* int sizeof_hdr;      */

Your file however starts with just zeros.

Otherwise, I can see from the header that this is a 4D image with dimensions 16×16×1×72, voxel size 1×1×1 mm³, stored as 32 bit floats. I could relax the compliance checks in our NIfTI import code to allow trying to read malformed inputs, but I’m a bit reluctant to do this. The fact that the NIfTI specs state in capitals that the first entry MUST be 348 also seems to back me up on this. So I’m not sure where your IDL code came from, but I would personally be more inclined to fix that up…

Ok I completely agree. Actually your insight can help me fix this bug on my end!

  1. is there a code in mrtrix that will output the number of fiber populations present in each voxel, either 1, 2 or 3, similar to what was presented in this paper:

That paper used the approach implemented in sh2peaks for locating FOD peaks and quantifying their peak amplitude, so that’s the way to go if you’re looking to duplicate. More recently, we have been making use of a different algorithm (see Appendix 2 of this paper) in various MRtrix3 commands that require a set of discrete fibre populations rather than a continuous FOD per voxel. You can access this most directly using the fod2fixel command, and manipulate the output as desired based on the new fixel directory format.

Interesting. Ok I will have a read and look into this. I’m a little bit behind, I’m still trying to understand some of the terminology but I will definitely look into this!