Spurious streamlines - difference between tckgen versions


#1

Dear all,

I’ve encountered a problem with the output tckgen, somewhat related to the one reported here:

I ran tckgen with ACT using a command like that:

tckgen -algorithm iFOD2 -act 5ttf.mif -seed_gmwmi 5ttf_gmWm.mif -backtrack -crop_at_gmwmi -select 500000 csd.mif tck500000.tck’

In the result, I noticed some spurious streamlines going in the anterior-posterior direction within the splenium of the corpus callosum (and other regions), as well as possibly spurious streamline within the cingulum bundle, going in the medial-lateral direction and in the ventral-dorsal:

I am using an up to date version of MRtrix. When typing “tckgen --help” the version I get is:
MRtrix 3.0_RC3-51-g52a2540d tckgen Jun 14 2018

Importantly, most of these spurious streamlines are absent when using a different machine with the following version:
MRtrix 3.0_RC2-90-g21f3d913-dirty tckgen May 22 2018

as can be seen here:

Is this behavior the result of a recent update to tckgen? Should I downgrade to an older version, or perhaps this is the side effect of a second, wanted behavior?

Any help would be greatly appreciated.
Many thanks!

Roey


#2

Hi everyone,

Indeed, this seems to be the result of lowering the default FOD -cutoff threshold used by tckgen, from 0.1 to 0.05. See also a discussion about changing this default parameter here. When changing the cutoff from 0.05 to 0.1, the results look at before (no anterior-posterioe streamlines within the corpus callosum).

  1. I’d be very happy to know if any of you thinks I should be using the default 0.05 for any reason (I should note I’m using SSST CSD, and as far as I can tell, streamlines reach the GM/WM interface.

  2. Specifically in the corpus callosum, is it a common behavior for the boundary between CC and the ventricles to be classified as GM, leading to the GM/WM interface image to include these regions?

Many thanks,
Enjoy ISMRM and OHBM,
Roey


#3

Hi Roey,

Sorry about the radio silence – we’ve all been a bit overwhelmed with ISMRM and preparations for the MRtrix workshop last week.

As you’ve already figured out, the difference will be related to the change in default for tckgen -cutoff option, along with a minor contribution from a bug fix in our handling of the spherical harmonics (this is unlikely to be related to the issue you linked to though). We tried to alert users to this change, since it was definitely going to introduce differences… Choosing an appropriate default threshold is not as trivial as it sounds, as you’ll see from the lengthy discussion we had over this on GitHub. It boils down to the inherent differences between the old CSD and the newer MSMT-CSD version, in particular with regards to how the non-negativity constraint is implemented (soft vs. hard respectively). Since tckgen doesn’t inherently have knowledge of how your FOD image was generated, a one-size-fits-all default cutoff isn’t always appropriate. However, since our recommendations are now veering heavily towards the use of multi-tissue CSD (even for single-shell data), we have decided to use adopt a default threshold more appropriate for that algorithm…

I hope this clarifies a few things…?
All the best,
Donald.


Good b-value sensitivity parameter for 2shell
#4

To answer your specific follow-on questions:

If you’re using single-shell CSD, then I reckon you could/should increase the cutoff to match what used to be the default. However, I reckon a better option would be to switch to 2-tissue CSD:

  • estimate responses for GM, WM, CSF using dwi2response dhollander
  • use dwi2fod msmt_csd using the WM & CSF responses only.

This gives you CSF suppression and introduces the hard constraint for the non-negativity, which means your FODs will be a better match to the default cutoff in tckgen

This will depend entirely on the accuracy of the segmentation, which relies on commands external to MRtrix3. But yes, it’s not uncommon to find voxels containing a mix of CSF & WM (as you’d find lining the ventricles) to be classed as GM…


Good b-value sensitivity parameter for 2shell
#5

Hi Donald,

Yes, it’s all musch clearer now. Thank you so much for you detailed response and suggestions. I will incorporate the changes you suggested.

Best wishes,
Roey