… and 30 reconstructed bundles from Dipy Recobundles …
If my interpretation is correct, the primary outputs from this process are a set of track files? This is important as the nature of those data dictate what operations are necessary to interact with them.
I seeded in GMWM since I figured this may cut out some redundant streamlines that don’t reach GM.
I’m interpreting from this that you are using ACT, since you stated that your streamlines were cropped at the GM-WM interface. Sometimes people don’t use ACT but just seed based on a GM mask; but that wouldn’t enable cropping at the interface (unless you did that explicitly afterwards using
tckedit). If my interpretation is correct then some of my suggestions below may not be accurate.
If ACT is used, then you don’t have “redundant streamlines that don’t reach GM”. Streamlines are forbidden from terminating inside the WM. So seeding at the GM-WM interface does not influence the prevalence of such streamlines.
Intersect these functional ROI streamline files with Recobundles tracts. This would answer a question such as “What portion of the left arcuate is associated with this reading-activated functional area”?
What is the reasoning behind not simply looking at the intersection between the Recobundles tracks and the functional ROIs? It’s not immediately clear to me why a whole-brain tractogram needs to be used as an intermediary between those two data.
Do you have any recommendations for overlapping two streamline files?
There isn’t really such a thing as an “intersection” between two streamlines (or two sets of streamlines), since each streamline is infinitessimally thin. The first possibility I would be trying is generating a TDI for each, and then performing some quantification based on comparing those maps.
I know that for
tck2connectome , a radial search is executed to assign streamlines to nodes. Could this be applied to find all streamlines corresponding to a single node, as opposed to between two connectome nodes?
I think you’re trying to manipulate the process to get the data you want, whereas you can get the data you want from the existing process.
Once you have a connectome matrix (and the associate streamline-node assignments) via
tck2connectome, you can use
connectome2tck to extract specific connections of interest. This command is quite flexible; by default it outputs one track file per edge, but that’s not the only possibility. If you specify
-files per_node, what you’ll get is one track file per node, where each contains all streamlines that are assigned to an edge for which one of the streamline endpoints is assigned to that node. If you additionally specify
-nodes 1 (assuming your blob of interest contains index 1), only a track file for that one node will be produced.
There’s a trick to making this slightly more robust. Say, for instance, that all you have are two separate ROIs, and you’re not interested in sub-division of anything else in the brain. What you want to do is synthesize a parcellation image, where voxels in ROI 1 have the value 1, voxels in ROI 2 have the value 2, and all of the grey matter that is not within either of those two ROIs has the value 3. That way, streamlines that terminate near the functional ROI, but are better characterised as intersecting whatever is adjacent to that ROI, will get assigned to dummy parcel 3 instead of the ROI. This is just mitigation of the imperfections of that radial search mechanism (which I intended to supersede years ago…).
What data manipulations do or do not work here can also depend on the nature of your data; e.g. whether the functional ROIs are big spherical blobs or constrained to the cortical ribbon, and what the distribution of streamlines terminations looks like. The radial search was made the default as it’s a reasonable compromise across a wide range of usage scenarios (the developer doesn’t know a priori the attributes of any data a user may provide it with), but it’s far from perfect.
I ask because for something like
tckedit , the
-include mask seems to be more explicit, meaning no streamlines would likely get assigned to a GM mask because the streamlines are seeded and cropped at GMWM.
Maybe more “basic” rather than more “explicit”; they’re both explicit, it’s just that one is predicated on an overlap whereas the other is predicated on a maximal distance. Nevertheless, that’s precisely why the radial search was necessary for
tck2connectome. But ideally
tckedit would have a solution to the same problem.
That is, when I find the streamlines associated with an fROI and later its intersection with segmented tracts, I am oriented to a binary scale; that is, is this streamline passing through the ROI / intersecting with a segmented bundle or not?
Yes, in this framework the attribution of each individual streamline to the pathway of interest is binary; but the streamline weights represent independent information to such. You can still use that information to modulate how much each streamline contributes to whatever metric you are quantifying.
I also worry about compatibility with DIPY if I do have to use it for tract metrics. I could alternatively remake tractograms with 100M and SIFT to 10M, which would resolve that issue.
If resolving the biases that SIFT(2) address are important for your experiment, but you can’t utilise per-streamline weights properly, then yes, you could do that instead. Though you can also look at the comprehensive set of operations within the pipeline and ask whether or not such modulation is actually going to have any effect on your eventual output quantification.
Also, if you instead use dynamic seeding, it’s quite common for reducing streamline count by a factor of 10 to not even be possible for the algorithm, since the magnitude of the bias in the initial tractogram is reduced; so you could do say 50M → 10M instead.