Streamline lengths before and after SIFT

1

Dear MRtrix community,

I have some questions about the streamline length values, both before and after applying the SIFT algorithm.

I generated the whole-brain tractographies of some HCP subjects following the guidelines of the ISMRM tutorial (http://mrtrix.readthedocs.io/en/latest/quantitative_structural_connectivity/ismrm_hcp_tutorial.html), except from the total initial number of streamlines that I fixed to 5M. I used 3 different algorithms: CSD muti-shell, CSD single-shell (b=1000) and DTI single-shell (b=1000).

I have two issues:

  1. I haven’t set a value for the minimum length of the streamlines, thus accepting the default value that when using ACT is equal to 2 times the voxel size (i.e. 2 x 1.25 = 2.5 mm).
    However, when I calculate the minimum length of the streamlines using tckstats, I get a value close to 2.1 mm for each subject when using CSD, and close to 1.4 when using DTI. How is it possible?

  2. After CSD, I then applied the SIFT algorithm to have 1M streamlines. I calculated the histograms of the lengths of the streamlines before and after applying SIFT. Here what I obtained for one subject (for the other subjects the results are similar).

image
image.png1576×600 40.3 KB

image
image.png1381×600 39 KB

Is it plausible that I got such a large amount of short streamlines? It seems to me that the average lengths are pretty low, especially after having applied SIFT.

Any suggestion would be highly appreciated.

Thanks a lot,
best,
Giulia

2

Hi Giulia,

  1. There’s a little bit of wiggle room in here, for a couple of reasons. The minimum length is implemented in tckgen based on a minimum number of points. However the precision of the mapping from number of points to streamline length may not be perfectly preserved. Cases I can think of:

    • The -crop_at_gmwmi option, which will shorten the distance between the first and second points (and the last and second-last points), but the number of points remains the same.

    • Streamline downsampling (which defaults to 3 in the case of the iFOD2 algorithm), since the streamline endpoints are always preserved regardless of the downsampling factor. Though tckedit should handle this appropriately (if my code is correct).

    • A little bit of integer rounding error; maybe this and this should be std::ceil… @jdtournier?

    tckstats is aware of these possibilities, and so explicitly calculates the length of the first and last “steps” on the streamline, rather than assuming that the distance between each pair of successive streamline points is exactly the tracking step size.

    So I suppose the two questions to come out of that would be:

    • Does tckgen need to retrospectively reject streamlines if cropping at the GM-WM interface reduces the streamline length to below the minimum?

    • Does this fully explain your observation of 1.4mm streamlines with a 2.5mm minimum length criterion? I’d need to see your complete tckgen call to try to reproduce it.

  2. This effect is reported and discussed in this article. SIFT was carefully designed to not have a preference for retaining / removing short / long streamlines; combine that with the prevalence of short connections both from biological observation and from generative models of brain wiring that take wiring cost into account, and I tend to believe that that’s how the brain actually is.

Rob

3

Hi Robert,

thank you very much for your fast and clear answer and also for the useful forum.

  1. I was wondering if something went wrong during the generation of the tractography, but your explanation has cleared up my doubts. I didn’t know that the -crop_at_gmwi would have an effect on the streamline lengths. Anyway, the commands that I’ve run (for csd and dti single shell b=1000) were:

  • tckgen WM_FOD_b1k.mif 5M.tck -act 5TT.mif -backtrack -crop_at_gmwmi -seed_dynamic WM_FOD_b1k.mif -maxlength 250 -select 5M -cutoff 0.06

  • tckgen dwi_b1k.mif 5M.tck -algorithm Tensor_Prob -act 5TT.mif -crop_at_gmwmi -seed_gmwmi gmwmi.mif -maxlength 250 -select 5M -cutoff 0.06 -step 0.625

  1. The paper you suggested fully answered my question.

Thank you again!

Best,
Giulia

4

I didn’t know that the -crop_at_gmwi would have an effect on the streamline lengths.

The issue is that the cropping mechanism is reducing the physical length of the streamlines, but not the reported length of the streamlines when tckgen applies its thresholds. Note though if you were to later apply tckedit with the same minimum length as that used in tckgen, it would (I think) remove those streamlines as being too short. So tckgen should probably be updated to be more stringent with its streamline length checking.