Individual streamline index included in tck file

Hi, I have a whole brain tractogram, “whole_bran.tck” consisting of 1M streamlines, fj=1,2,…,1000000. And I want to know the indices of streamlines (e.g., j) included in my ROI when I use tckedit. Is there any way or other commends which I can use to have those indices in MRtrix? Many thanks for help. Justin.

Hi @Jeongwon_Jeong,

There’s no “official” way to do so, but quickly looking at tckedit's options, I spotted something which you may be able to exploit. If you’re not using streamline weights in your application, you can exploit these to carry the indices you’re after through as a piece of information. You could create a streamline weights file beforehand (just a text scalar file) that has the indices as each streamline’s piece of information, and feed this file to tckedit via the -tck_weights_in option, while also supplying the -tck_weights_out option to write your selected/retained weights to a new text file. I haven’t used these options for such a purpose yet myself… so definitely let us know whether this trick works for you!


Hi, Thijs
Thanks for your reply. Yes, it works with a Matlab function, knnsearch to match indices between tck_weights_in and tck_weights_out. Below is what I tried.
tckedit -nthreads 0 -force -include roi.nii whole_brain.tck -tck_weights_in whole_brain_weights.csv -tck_weights_out roi.csv;
M = load(‘whole_brain_weights.csv’); N = load(‘roi.csv’);
where idx is a vector to have the indices of tracts included in roi.nii.


1 Like

Thanks for reporting back and confirming, @Jeongwon_Jeong! Even though a slightly hacked solution, it does work; I’m sure this will come in handy for users in similar scenarios that require tracking of streamline indices through various tckedit stages. :+1:


The -tck_weights_in / -tck_weights_out options can indeed be “hijacked” for this purpose.

The streamline weights in particular require their own explicit command-line options, since those weights are interpreted in a very specific way in certain areas of the code. I have however considered in the past how it might be possible to handle other use cases: Described here was keeping track of the streamline indices, but alternatively (or maybe the ultimate purpose of such?) there may be some arbitrary quantitative parameter per streamline that one wishes to retain correspondence with the associated streamlines, even though some subset of streamlines are being extracted.

There’s a number of different ways that this could be achieved in the software, each with their pros and cons. Bumping this thread in case anybody out there has current or potential use cases where such capabilities would be useful that may prove informative, or opinions on how such data could be most intuitively managed from a software interface perspective.