Extracting streamlines connecting basal ganglia and fMRI dervied cortical ROI

Dear MRtrix team,

I would like to assess the connectivity between subcortical structures and a cortical region defined using fMRI. I have generated a whole brain tractogram, applied SIFT2 and would now like to extract the streamline count between the two ROIs (one of which is derived from fMRI data and the other from freesurfer segmentation). I would like to derive tracts that exclusively connect the two regions but I’m struggling to work out how to do this using tckedit. I’d be very grateful for any help.

Thanks,

Akshay

Hi Akshay,

So there’s potentially two different ways of doing this. The main concern is that if ACT has been used, many of the streamlines may not actually intersect the FreeSurfer segmentation. This occurs because streamlines are terminated relatively precisely at the GM-WM interface, but the FreeSurfer segmentations are fairly conservative and really only label those voxels with >50% GM. So quite often, the streamline termination point doesn’t quite make it into the target ROI. This is precisely why the default assignment mechanism in tck2connectome does a little 2mm radial search from each streamline termination. However tckedit does not do this, so runs the risk of missing some streamlines.

So here’s your two options:

  • tckedit:
    tckedit tracks.tck -include fMRI_ROI.mif -include FS_seg.mif -tck_weights_in weights.csv pathway.tck -tck_weights_out pathway.csv
    (Note that the two ROIs are provided as separate input -include images: this enforces that a streamline must traverse both regions in order to be written to the output)

  • tck2connectome:
    The details here vary depending on precisely how your ROIs are being defined. Let’s say, for example, that you’re interested in tracks that are connected to a particular FreeSurfer segment in the connectome, but that traverse a particular fMRI ‘blob’ (that is, the ‘blob’ doesn’t actually form a node in the connectome). You could get this using:

    • tck2connectome tractogram.tck connectome.csv -tck_weights_in weights.csv -out_assignments assignments.csv
    • mkdir output; connectome2tck tractogram.tck assignments.csv output/ -nodes # -files per_node -tck_weights_in weights.csv -prefix_tck_weights_out output/
      (Replace ‘#’ with the index of your node of interest)
      (Note that because connectome2tck can generate more than one output file, both track and streamline weight output files get postfixed with the index / indices of the relevant node(s))
    • tckedit output/#.tck -tck_weights_in output/#.csv -include fMRI.mif final.tck -tck_weights_out final.csv
      (Note that this will select any streamline that traverses the blob; if you explicitly want only those streamlines that terminate within the blob, use the -test_ends_only option in tckedit)

Remember that with SIFT2, it’s the sum of streamline weights that provides an estimate of the connection density, not the streamline count.

Wheeeee!
Rob

Dear Rob,

Thanks so much for your help and rapid response - for our purposes -test_ends_only option was exactly what I was looking for.

One quick follow up though - I’ve attached the image of tckedit using the -test_ends_only option and as you can see there are a few bizarre streamline wandering off posteriorly that don’t seem to be related to either ROI. Do you know where these are coming from and how I can tidy them up?

The command I used was:

tckedit tracks.tck -include lh_fmri_cortex.nii.gz -include cortical_resample/12.nii.gz -tck_weights_in sitf2_tracks -test_ends_only ROIpathway2.tck -tck_weights_out ROIpathwayweights2.csv

Again, thanks for your help,

Akshay

Hi @akshay_nair, are you sure that’s not a/some track(s) that are going posteriorly, taking a turn and going back to one of your regions? It might help to switch off “crop to slab” in the tractography tool of mrview, and rotate the results around a bit (ctrl + drag) to get a good look at that particular situation.

If so, you could simply exclude the culprits by adding an exclusion region in that neighbourhood.

Yes, it’s hard to tell from a single image but my instinct is the same as Thijs’ here. You can check that the streamline filtering is in fact doing what it’s supposed to by using tckmap -ends_only, and verifying that the streamline endpoint density is only where it should be; if there’s no terminations out where you feel the tracks shouldn’t be, they must be looping back on themselves to get back to the ROI.