Hello All, I had a quick question. I am currently doing a post-analysis on a tractography I created based on the pipeline shown here: OSF | BATMAN_tutorial_update2020.pdf. I am extracting a contralateral pathway via tckedit, the pathway consists of the the respective cerebellum and their contralateral connections to the opposite side thalamus and motor cortex. When extracting the subset of tracts, I was successful. But as a gut-check I decided to extract a tract subset that encompassed only ipsilateral connections (i.e. left cerebellum, left thalamus, left M1). And to my surprise, the number of tracts for both the contralateral pathway (which is known to be anatomically present) and the ipsilateral pathway are very similar, within a few thousand tracts. And even when comparing each respective subset of tracts of the contralateral pathways, the asymmetry is not as pronounced as expected. Is this normal? I was curious on how exactly tckgen propagated tracts? Or if there is something im missing here on effectively extracting these tracts. Thank you in advance to anyone who has any insight…
I guess the question is more of how to isolate tracts effectively using the tckedit -include and -exclude flags effectively. Is there a tckedit or mrtrix function to subtract tracts from .tck files?
Hi Ricardo,
The fact that the erroneous ipsilateral pathway has a similar density to that of the known contralateral pathway is not particularly surprising given the ill-posed nature of streamlines tractography. With a shallow crossing angle, and with the streamlines algorithm sampling the entire FOD shape rather than just the peak amplitudes, it’s exceptionally easy for a streamline initially traversing one orientation to take a turn and follow the other, and such a path is entirely plausible based on the tracking algorithm’s interpretation of the data. We may know that one is correct and one is erroneous based on other sources of information, but such information is not by default available to a tracking algorithm.
I was curious on how exactly tckgen propagated tracts?
The default is the iFOD2 algorithm, the reference for which (and al other implemented algorithms) is in the command help page. The iFODx algorithms in particular treat the FOD shape as a distribution from which to sample from directly, and so the broadness of the FOD lobes is reflected in the orientation dispersion of the generated streamlines. If two fibre orientations are sufficiently close such that there is not essentially a zero-amplitude crossing in between them (and indeed sometimes even when there is), then according to the combination of the image data & the logic upon which those algorithms are built, transitioning from one “orientation” to another (bearing in mind that iFODx aren’t actually aware of discrete fibre orientations, they just sample the FOD amplitudes) is an entirely reasonable thing to do. Attempting to overcome these ambiguities is a difficult field of research. Hence why it is quite often necessary to combine tractography with user intervention in order to isolate specific anatomical pathways of interest from the many false positives surrounding them.
I guess the question is more of how to isolate tracts effectively using the tckedit -include and -exclude flags effectively. Is there a tckedit or mrtrix function to subtract tracts from .tck files?
It’s not entirely clear what the question(s) is/are here. As far as what the -include and -exclude options of tckedit do, we’ve tried to be very precise in the relevant sections of the help page as to how they operate; admittedly we would benefit from having some documentation or educational material on targeted tracking / track editing, but it’s something that’s hard to get to the top of the priority list for the developers. If the question is moreso about strategy / philosophy, the only thing I can really contribute is that when filtering, it’s very easy to visually check for false positives, but false negatives (i.e. streamlines that are in your input tractogram, and should ideally be included in your output tractogra, but are being removed because your critera are too stringent) require greater discipline to spot.
As far as “subtracting tracks”, given that you’ve already spoken about tckedit, my best guess is that here you’re referring to taking an existing track file, and eliminating specific streamlines from that file but keeping the file there with the same name. This is directly opposed to the design philosophy of MRtrix3. This command will generate a new track file; if at some point you no longer have a need to retain the original track file, and want to instead replace it with the outcome of the filtering operation, then that’s something that you can do at the level of the file system, and by your own choice (so we’re not responsible for deleting your data, you are). Even using the same file system path for both the input and the output of a command will not work: as soon as the new output file is created the existing file must be destroyed, and so if the streamlines are read from the file one streamline at a time (which is the case for MRtrix3), you will erase your input data before it has all been read. If this were not the case, and all of the streamlines data were read into memory as soon as the file is opened, then not only would certain operations become far slower than they need to be, but it would also limit the size of tractograms that can be processed on any given system.
Rob