Avoiding false-positive when counting streamlines

[bwlee89]

Dear MRtrix3 community,

I extracted connectomes of a few subjects (downloaded from HCP) by following the MRtrix3 guideline.

When I checked the output connectome.csv file where each index in the file represents number of streamline btw two regions, I can see a lot of numbers less than 10. I guess those small values are the false positive streamlines. Is there any conventional or widely used methods to avoid false positive streamlines? (simply thresholding? if it is the way, what would be the conventionally used thresholding value?)

And one more question, when I use ‘-scale_invlength -scale_invnodevol’ option on tck2connectome command, each index of the output connectome file represents (# of streamlines) / (length of streamline * volume of two areas) right?

Thanks.

Lee

[ThijsDhollander]

@bwlee89

Is there any conventional or widely used methods to avoid false positive streamlines? (simply thresholding?

This would probably be the only decent pragmatic solution to that problem. A “suitable” threshold will depend entirely on your total number of streamlines, but even then there’s no solid argument as to a specific threshold value.[quote=“bwlee89, post:1, topic:854”]
And one more question, when I use ‘-scale_invlength -scale_invnodevol’ option on tck2connectome command, each index of the output connectome file represents (# of streamlines) / (length of streamline * volume of two areas) right?
[/quote]

@rsmith probably knows the answer to this!

[rsmith]

I can see a lot of numbers less than 10. I guess those small values are the false positive streamlines.

“Connectome edges with a small number of streamlines” and “false positive connections” are unfortunately two very different statements

Is there any conventional or widely used methods to avoid false positive streamlines?

In my small amount of experience, there’s no clear value at which a thresholding operation is stable; i.e. Wherever you set the threshold, there will always be edges with values just above and just below that threshold, and therefore changing the threshold even slightly will alter which edges are removed / retained. There’s some research articles out there investigating the effects of thresholding, or proposing alternative techniques for dealing with the arbitrary nature of thresholding, but I tend to not read them since I don’t think it’s a good thing to be doing in the first place…

If you’re not making a binary connectome, i.e. you’re keeping the edge weights but are just zeroing the weakest connections, then I’d question why it is necessary to zero those connections at all. If your analysis takes weights into account, then those low-density connections should have only a minimal effect on your analysis, and hence whether or not they are zeroed shouldn’t really matter. Essentially all you’re doing by thresholding then is introducing an unnecessary free parameter. Alternatively, if your analysis is highly sensitive to whether or not low-density connections are zeroed, I’d be taking a closer look at the stability of your analysis, since that’s where the problem lies, not in the selection of the threshold itself.

</rant>

When I use -scale_invlength -scale_invnodevol option on tck2connectome command, each index of the output connectome file represents (# of streamlines) / (length of streamline * volume of two areas) right?

Almost. The trouble is that the streamline length is different for each streamline; there’s also a factor of 2.0 in there to account for summing two node volumes. So it’s better expressed as:

(2.0 / volume of two areas) * sum(1 / length_of_streamline)

Rob