I am running tckgen between two ROIs (Amygdala - PFC) and initially used -select 10000 as a test run that took 130min to complete but only selected 1 streamline. tckgen: [100%] 10000000 seeds, 5451563 streamlines, 1 selected
I updated to -select 10000000 and the program seems to run for 12 hours so far with only 1 selected from the log output.
The full code: time tckgen -seed_image ${mask1} -include ${mask2} -stop -act ${dir_out_sub}/${subject}_T1_5tt_coreg.mif -crop_at_gmwmi -nthreads 8 -maxlength 250 -select 10000000 -cutoff 0.06 -force ${dir_out_sub}/wmfod_norm_${subject}.mif ${dir_out_sub}/ROI_SeedTractography/tckgen/noends/noends_${tracklabel}_${hemi}_${subject}.tck
Im not sure why my selected streamlines are so low
Figuring out why streamlines are failing to make it from mask1 to mask2 requires gleaning some information about those streamlines that were actually generated but failed to make it from mask1 to mask2.
There’s a couple of things you can play with:
Omit the -include ${mask2} command-line option, and just look at the streamlines generated from the seed point and how they relate to your target region.
Run tckgen with the -info option, and additionally use something like -seeds 1000000 -select 0 so that the command runs to completion and terminates normally. This will give you statistics about the various mechanisms by which streamlines were terminated, and then accepted / rejected based on your specified criteria.
Given the mention of PFC as a ROI and the use of ACT, a potential culprit that comes to mind is if your ROI only includes voxels that are entirely within GM, whereas ACT terminates streamlines at the GM-WM interface, such that streamlines approaching the target ROI are not quite spatially intersecting it. For connectome construction we have a cheap & nasty hack for dealing with that particular issue, so you might consider using tck2connectome & connectome2tck to isolate streamlines between the two regions that are of interest, rather than performing targeted tracking. Alternatively you can just dilate the ROI a little, or use FreeSurfer commands to derive a new voxel mask that encases the GM-WM interface rather than only the ribbon itself. We will hopefully eventually have a couple of better technical solutions within the software.
Thank you, the connectome approach seems to work. In this case, if I choose 2 ROIs, should I use connectome2tck from ROI 1:2 and from ROI 2:1, then average the output of tckstats? Or is one direction enough?
If I am also interested in FA/MD values between these ROIs, is there a command to derive those values from streamlines?
if I choose 2 ROIs, should I use connectome2tck from ROI 1:2 and from ROI 2:1, then average the output of tckstats ? Or is one direction enough?
All commands in MRtrix3 intended to deal with structural connectome data are carefully and deliberately designed with the implicit symmetry of those data in mind. So connectome2tck does not consider the requests “-nodes 1,2” and “-nodes 2,1” to be any different to one another. Indeed tck2connectome outputs an upper diagonal matrix by default to reflect this; though I think that choice may have upset more people than not :-/
If I am also interested in FA/MD values between these ROIs, is there a command to derive those values from streamlines?
There’s multiple ways in which this can be done:
Construct the full connectome based on the desired contrast, and then just extract from that matrix the values for the particular edges that are of interest; see Wiki page
Take that set of streamlines, use tcksample to sample the values of the parametric map along each streamline (likely taking e.g. the mean along each streamline so that there’s a single scalar value per streamline), then take e.g. the mean of these values across all streamlines.
Use tckmap followed by mrthreshold to produce a binary mask for that set of streamlines, and then use mrstats -mask to compute the e.g. mean values of those quantities within that mask.