I have spherical ROIs (along with radius as the 4th dimension) saved as separate csv/txt files that I’d like to use in tckedit. From what I see, these spherical ROIs need to be manually entered as part of the -include flag.
I had tried this strategy to use the txt files:
tckconvert test.txt test.tck
tckmap test.tck test.nii.gz -template subject1.nii.gz
tckedit tracks.tck test_2mm.tck -include test.nii.gz
But the number of streamlines yielded is about 10x less compared to the manual entry of the coordinates. I’m guessing this because the radius dimension probably was not captured in the ROI generation for the above strategy (?).
Is there a way to utlize txt/csv files for tckedit as part of the -include flag? It would help automate processing on my end.
Thanks for your help,
tckconvert test.txt test.tck
This will interpret the XYZ centre of each sphere as a streamline vertex location, and ignore the radius. Admittedly yielding an error based on the fact that there is more than three columns would probably be preferable…
I’m guessing this because the radius dimension probably was not captured in the ROI generation for the above strategy (?).
Correct. For this to work, not only would the
.tck format need to be able to store a radius per vertex (which is a completely non-standard application), but
tckmap would need to seamlessly detect the presence of such data and utilise a completely different algorithm to map such data to a voxel grid.
Is there a way to utlize txt/csv files for
tckedit as part of the
One would normally achieve this kind of thing using Unix commands & your shell interpreter. You’re trying to take the contents of a text file, extract a specific line, and then insert that text into another command call; that can all be done before any MRtrix3 command ever sees those data.
The only other thing to consider is the effect of multiple inclusion regions. In
tckedit, if multiple inclusion regions are specified, then a streamline must intersect all such regions in order to be accepted. Whereas with your attempted strategy here, by mapping all such regions to a single inclusion mask, a streamline only has to intersect any part of your inclusion criteria in order to be included. If it is the latter of these that you are trying to achieve, then I would instead suggest using
mredit -sphere to map your spheres to a voxel grid, taking the intersection of those masks (
mrmath max), and then providing that image to
Thanks for your reply and guidance Rob. Yes, I have been trying to figure out a way with Bash scripting the past few days so that each line can be parsed out and fed into the MRtrix3 command line. I still have not found a solution so if you have any ideas, it would be most welcome.
Each of the ROIs have a separate connectome (I’ve done this by manual entry of the coordinates) so they are not mapped together into a single inclusion mask.
Personally I’d start by using Python rather than Bash
Thanks Rob for looking into this! I’ll revisit this in Python.