search

bids-apps / MRtrix3_connectome

Generate subject connectomes from raw BIDS data & perform inter-subject connection density normalisation, using the MRtrix3 software package.
http://www.mrtrix.org/
Apache License 2.0
48 stars 26 forks source link

question: number of streamlines in tckgen #111

Open LucSam opened 2 years ago

LucSam commented 2 years ago

Hi, thanks very much for providing this bids-app.

1)Is there a rationale regarding the rather specific definition of n streamlines: num_streamlines = 500 * num_nodes * (num_nodes-1) (cf. line 2618 in mrtrix3_connectome.py)?

2)I remember the nice poster "Investigating the streamline count required for reproducible structural connectome construction across a range of brain parcellation resolutions" from Chun-Hung, demonstrating a minimum of ca. 20M streamlines for e.g. a 85 nodes parcellation to achieve reproducible structural connectomes and reduce variation. That number doesn't seem to be related here or did I miscalculate?

Best, Lucius

Lestropie commented 2 years ago

Is there a rationale regarding the rather specific definition of n streamlines:

Not massively. It results in the mean number of streamlines per connectome edge being 1000. There's some limited logic in the quadratic scaling of number of streamlines as a function of number of edges, but the magnitude is somewhat arbitrary.

Chun-Hung, demonstrating a minimum of ca. 20M streamlines for e.g. a 85 nodes parcellation

So there's two outstanding limitations here. Firstly, that work was interested specifically in the numbers required to achieve stability in individual edge weights, which is a specific experimental outcome for which the precision is assessed; if one is interested in alternative experimental outcomes (eg. graph metrics), the required numbers will likely vary. Secondly, there is a somewhat arbitrary thresholding necessary to place on the precision in order to draw a line at a fixed number of streamlines for a given parcellation; one can change that threshold and get a different number, and there's no obvious standout candidate.

Personally I prefer bigger numbers, but there's an additional concern in that if the default is too large (which is exacerbated by other parameters here resulting in the computational time per streamline being longer than usual) people may hit Ctrl-C and go use something else. You can of course always just override with the --streamlines option.

Cheers Rob