Coordinates for tckresample for along-tract analysis


Dear MRtrix3 experts,

I have a segmented tract in .tck format. My aim is conducting an along-tract analysis. I would like to resample my tract along its longitudinal axis to obtain the points I would get if I ideally cut it with a series of equidistant planes placed orthogonally to its longitudinal axis.

To do so, I used the command:

tckresample -line x a,b,c d,e,f input.tck output.tck

with x being the number resampling locations, and a,b,c , d,e,f the coordinates between which to resample (i.e. the endpoints of the resampling line).

My questions are: (i) which would be the most reasonable approach for choosing the coordinates between which to resample in your opinion?
It seems that if I indicate some coordinates which are more extreme (i.e. more anterior and more posterior for a tract oriented along the y axis as in my case) than the tract’s endpoints, the output is an empty image. From the tests I did, if I am not getting it wrong, it seems that for a streamline, to be successfully resampled it is necessary that its endpoints are as extreme or more extreme than the ones of the resampling line. However, if one desires to not lose any streamlines (in terms of number of streamlines), this - again, if I am not getting it wrong - would restrict the resampling only to the part of the tract in which all the streamlines are present.

So my second question is: (ii) is there a way to include all the tract in the resampling procedure? In other words, to keep both the number of streamlines and their length (not lose the extreme parts)?

Thank you very much for your attention and for any help.

Tckresample and tcksample for along the tract statistics

Hi Lisa,


… the output is an empty image.

Do you mean an empty track file?

Stepping through the code, it looks as though the operation is relatively strict: If a streamline is found that does not intersect the planes corresponding to the start and end points of your line path of interest, this not only prevents resampling of that individual streamline, but sends an error code that it seems will result in premature termination of the entire command. It may make more sense if the command were instead to exclude such streamlines from the output file, but continue processing through the entire input track file; this is a relatively easy fix to implement, and appears to be the way it behaved before I hijacked @jdtournier’s code…

Even with this change, yes I believe that the resampling will, by design / intent, be restricted to those streamlines that span the entire path defined by your -line option. There’s simply no meaningful way to retain streamlines that fail to do so, without either losing the criterion of a fixed number of points per streamline (which is typically one of the justifications for using the -line option), or retaining streamline points outside of your pathway of interest (and likely subsequently sampling from a position in space you didn’t intend to).

(ii) is there a way to include all the tract in the resampling procedure? In other words, to keep both the number of streamlines and their length (not lose the extreme parts)?

If you were to not perform any resampling whatsoever, this would keep both the number of streamlines and their length. So it really depends on what you’re trying to achieve with the tckresample command. If, for instance, your primary goal is to have an equal number of points per streamline, you could try the -num_points option. If this however results in having streamline points beyond your pathway of interest, and this is a problem for your experiment, you could try masking the streamlines first using tckedit -mask, or you can use tckresample -line or tckresample -arc. However in the latter cases, if a streamline doesn’t traverse that whole pathway from endpoint to endpoint, there’s simply no meaningful way in which to resample that streamline based on your pathway of interest, and still have the correct number of points & positioning of those points relative to the other streamlines.

If that’s not clear, it might help to draw what the situation is, and justify why you think the command should behave differently; sometimes that exercise alone can in fact be insightful.



Just to follow up on this: I’ve pushed a change to tckresample that will prevent the command from exiting prematurely when it is unable to perform resampling of an individual streamline; it will instead go through the input track file and resample as many streamlines as it can.