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!

Cheers,

Thijs

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’);

[idx,dd]=knnsearch(M’,N’);

where idx is a vector to have the indices of tracts included in roi.nii.

Regards,

Justin

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.

Cheers,

Thijs

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.