Understanding values in tck2connectome

Hi all,

I will start by apologizing if my question is trivial. I am doing my first tractography and I am really not sure of what means my results.

So, for my tractography, I have a seed area and a target template. I mean I want to find (8000) fibers leaving from one areas (in my case a small part of the cerebellum) and finishing in one of the areas of my template (simple template with large areas…visual left and right; temporal left and right…).
So here is my tckgen function
tckgen -algorithm iFOD2 -mask WM.mif -seed_image SeedImage -include TargetTemplate -seeds 0 -select 8000 SphericalDeconv.mif output.tck

After combining my targetTemplate and my seed_area(CombineSeedTemplate.nii), I want to extract a connectome matrix.
So function:
tck2connectome output.tck CombineSeedTemplate.nii outputConnectome.cvs

Here is my pb: I am happy my matrix have just one column with number (the column of the seed) the est of the matrix is 0… but what I dont understand is why the sum of this column is not 8000! I am usually between 2000 and 3000 (sometimes less) depending of my subject or/and seeds (different part of the cerebellum).

Am I doing something wrong? or did I misunderstand the function tck2connectome?

Thanks a lot for your helps!
Cheers
Cecile

Hi Cecile,

I guess the mismatch of the total number of fibers is caused by that the command did not recognize the fibers reached the target ROI.
In the connectome generation, the radial search is utilized ( see -assignment_radial_search radius option)
If the search radius is too small, the fibers tend not to be counted properly.

If you could attach your data here, the MRtrix users can investigate the cause more deeply.

Cheers,

Takafumi.

1 Like

Hi Takafumi;

Thanks a lot for your help and explanation.
I tried to increase the assignement_radial_search to 4 and 8mm (2mm is the default). It actually improve the number of links in my connectivity matrix (but never reach the sum of 8000). On the top of that, it seems that for some of my track files a value of 8mm induce spurous results. Indeed, I am getting links between the areas of my template (when it should not be the case).
Here is a link to 2 tracks files and the 2 associated Templates.
https://drive.google.com/drive/folders/1Q3KQskeW2ML3ny15x4uQwOMt147sf0AR?usp=sharing
Thanks a lot for your help!
Cheers
Cc

Hi @cbordier,

You might be really interested in reading this paper: https://www.sciencedirect.com/science/article/abs/pii/S105381191930388X .

Well, see that paper, explaining the risks associated with that.

You’ll at least need a form of anatomically constrained tractography; but as the paper explains, there’s still important limitations to the technique, resulting in mismatches between anatomical constraints (e.g. WM-GM boundary) and the parcellation at hand. Radial search may get more streamlines assigned (maybe eventually reaching your 8000), however, the further the radial search required, the more false (biologically inaccurate) assignments may be made.

The ultimate solution to this will be Mesh-based anatomically-constrained tractography, where no mechanisms that might introduce imprecision (such as radial search) are present any more; and both anatomical constraints as well as parcellation will be unified, and up to their original (mesh) precision.

Cheers,
Thijs

Hi ThijsDhollander,

Thanks a lot for the link!
I was not really planning to use the connectivity matrix straight away. It was more a " checking if my results are coherent" thing. Like I specify in my message, it is my first tractography and so I am trying to understand what is happening and I try to check each step. I read paper saying that using number of streamline as connectivity matrix was not the best way to do analysis.
I will have a look at thisMesh based anatomically constrained tractography. But I just would like to know if the fact that the sum of my connectivity matrix is not equal to 8000 is a mistake from my part or something that can be explain (more or less :slight_smile: )
Thanks for your answer.
Cheers
Cc

No worries; good to hear! :slightly_smiling_face: :+1:

So essentially: there’s very logical explanations for what you were seeing. You at least want to use some form of anatomically constrained tractography (see the related options in tckgen to do exactly that at the tckgen stage). Currently, even doing that, you’ll see some unassigned streamlines, so you’ll still not hit that 8000: that’s the bit that that first paper I linked to shows (and explains, so it’s sensible). In the future mesh-based anatomically constrained tractography should overcome that mostly, if not fully. @chunhungyeh is the expert on the latter (mesh-based anatomically constrained tractography), and also the first author on that first paper I linked to.

Cheers,
Thijs

I am happy my matrix have just one column with number (the column of the seed) the est of the matrix is 0

It sounds like for your particular experiment you may want to use the -vector option in tck2connectome: that assumes that all streamlines have been seeded from a particular area of interest, and you are only interested in where the endpoints of the streamlines reach. The command will therefore explicitly give you a 1D vector of connectivity data rather than a 2D matrix.

why the sum of this column is not 8000! I am usually between 2000 and 3000 (sometimes less) depending of my subject or/and seeds (different part of the cerebellum).

If you use the -keep_unassigned option in tck2connectome, the number of streamlines not successfully assigned to a node will additionally be reported in the first row / column; so in that case, the sum should indeed be the number of streamlines provided as input.

On the top of that, it seems that for some of my track files a value of 8mm induce spurous results. Indeed, I am getting links between the areas of my template (when it should not be the case).

The radial search mechanism really is quite “dumb”, and was never intended to be a final solution to the issue of streamline-to-node assignment. Those spurious connections at higher radial distances are why an upper distance limit is imposed at all; though in retrospect the default of 2mm was probably a little too low.