Tckresample and tcksample for along the tract statistics

tractography

#1

Hi all
I am attempting to use tckresample and tcksample to resample FA values along my anterior forceps tract perpendicular to the tangent of an arc. I have followed instructions from a few other posts including this one: Along tract analysis. My commands are:

tckresample genu.tck -arc 20 -18,54,2 0,28,2 18,54,2 genu_samples.tck -nthreads 0
tcksample genu_samples.tck IITmean_FA.nii.gz genu_fa_values.txt

Where the coordinates roughly correspond to the red dots in this image:

The resulting resampled genu_samples.tck file looks like this:

I was expecting something that looks more like this that shows where the samples are located and their angles along the tangent of the tract (an illustration from Groeschel et al, 2014) so that I could verify that I have sufficiently sampled the tract evenly:

So my question is, how can I be sure that the sampling has come from the entire anterior forceps rather than just the central portion shown in the genu_samples.tck file? The output genu_fa_values.txt file appears to have the correct amount of data in it (20 columns and 4450 rows corresponding to the number of streamlines).

I get a similar result if I move the anterior points closer to the centre point essentially making a smaller arc with shorter streamlines.

Thank-you
Helen


Tcktransform and tckresample doubts
#2

Hi Helen,

It definitely looks like tckresample is somehow misbehaving. The only possible scapegoat I could think of here was if you were providing voxel positions rather than scanner-space positions; but that doesn’t appear to be the case. The fact that genu_fa_values.txt contains 20 values per streamline would suggest that tckresample is in fact producing 20 vertices per streamlines as requested, and tcksample is doing its own job just fine, but that those vertices are simply not being appropriately mapped to the path of the desired arc.

I’ll need to do a bit of poking and prodding to figure out exactly what’s going wrong here, and there’s a chance that it might take a little while to get an answer, but I’ll let you know how I progress.

Cheers for the report
Rob


#3

Hi Rob,
I wanted to add a few pieces of additional information here just in case they help with troubleshooting.

The misbehaviour of tckresample does not appear to be isolated to the -arc option. The -line option appears to have the same results as the images presented in the previous post.

Also, while the output file does contain the requested 20 samples, it does have some “ragged edges”. I initially attributed this to the fact that some of the streamlines may have not quite made it to the end of the sampling area. However, in this post (Coordinates for tckresample…) it clearly states that only streamlines that span the entire path will be sampled therefore there should be no “ragged edges” in the data file.

In this example below I asked for 10 samples along a line and the resulting data file has 9 or 10 values in any given row and some rows are shifted to the right. Could this possibly help to diagnose the misbehaviour of tckresample?

Thanks very much
Helen


#4

Hi @hcarlson,

Just so you’re aware, and as well for anyone else interested in this topic: these issues were indeed confirmed to be due to a bug, and a solution is in the making / has been found; see this pull request on GitHub (where we develop MRtrix3) for more details and to follow up on progress: https://github.com/MRtrix3/mrtrix3/pull/1248

Cheers,
Thijs


#5

Hi Thijs and Rob
This is great! Any idea as to when the fix will be available? I updated my MRtrix this morning (to MRtrix 3.0_RC2-117-gf098f097) and tckresample does not appear to be working just yet. Might I have an old version or not be updating MRtrix correctly (I used git pull and ./build)? Or perhaps I need to be a little more patient? :grinning:
Thank-you very much
Helen


#6

Hi Helen,

The changes were awaiting approval (we’re doing our best to prevent ourselves from introducing more problems than we fix, so changes that go to the public need to be independently checked by another developer). They have now been merged into the master branch; so a git pull; ./build should now update you to mrinfo 3.0_RC2-119-g84318c78, which contains the fixes.

Do however continue to be diligent in checking your data & processing :+1:

Rob


#7

Thank-you,
It all appears to be working now. We appreciate your hard work and your great program!
Cheers
Helen


#8

Hi all
I have a couple of more questions about this. I have resampled my genu using tckresample -arc and have overlaid the resampled file on the native space FA map.

tckresample genu.tck -arc 21 14,91,31 -4,68,29 -19,91,29 genu_samples.tck -nthreads 0

  1. This is what my resampled .tck file looks like along with small squares representing the coordinates used to define the arc. You can see that the resampled track does not quite make it to one of the lateral ROIs (on the right side of the image), nor is it symmetrical around the central ROI which is on the midline. This does not change if I increase or decrease the number of samples specified.

Interestingly if I reverse the order of the two lateral ROIs in the tckresample command, the gap is on the other side leading me to believe that it is not a problem with the ROIs. Does this behaviour appear to be correct?

tckresample genu.tck -arc 21 -19,91,29 -4,68,29 14,91,31 genu_samples.tck -nthreads 0

  1. How do I visualize where the samples were taken from? In the fix conversation on Github there was an image that looked like this and I can’t seem to recreate it for my patient in mrview:

Thanks very much
Helen


#9

Hi Helen,

I’ve just done some more tests, and I wasn’t able to re-create the effect you’ve demonstrated. Reversing the order of the start and end points of the arc for me has almost no effect (there can be a small number of streamlines where a sample point differs, but this is due to those streamlines crossing a sampling plane more than once, and hence the sampled point differs depending on along which direction the resampling is performed). The start and end planes were exactly where they should be. So unfortunately without being able to reproduce the issue I don’t quite know what to suggest…

One idea I came up with is that it might have been due to the track sub-sampling that can occur within mrview; but it shouldn’t produce an effect of that magnitude, and its behaviour should change when you alter the number of samples per streamline in tckresample. So that can’t be it.

Can you check the number of points in each streamline? Converting to ASCII using tckconvert is one way to do this. I’m curious to know whether the tracks actually contain the number of samples that they are supposed to. Alternatively, set the number of samples to be really small, e.g. 4-6, and then you’ll be able to see visually whether e.g. the final sampling plane is missing, or e.g. whether the sampling planes have been improperly placed along the desired arc.

How do I visualize where the samples were taken from?

This is a new mrview feature (adjustable display geometry for track files) that will be included in the pending tag update. You can access it via the dev branch if you think it would be useful for you here.


#10

Hi Rob
I checked the number of streamlines in each sub-sampled track file using tckconvert and it is correct. So when I ask for 21 sub-samples I get 21 lines in the resulting .txt file. It also is correct for very small numbers of points (4).

I also played around with the sub-sampled track visualization in mrview and it seems that if you reduce the line thickness to the very minimum value it displays correctly and the track is symmetrical. Larger values of line thickness causes the track to look asymmetrical (like the images previously posted).

So it seems that it was working perfectly, it was just a visualization problem I was having because of my mrview settings. Thank-you for your help.
Helen


#11

OK, that actually surprises me; though I’m now glad I threw the concept out there in case of! I’m not sure how I wasn’t able to duplicate the visualisation issue as I made sure to test against the master branch.

I know that @rtabbara has made some fixes to this particular feature, in order to both better calculate the appropriate downsampling ratio (which stops tracks from looking really weird when the line thickness becomes comparable to the step size), and better guarantee that the streamline endpoints are always drawn regardless of the downsampling ratio. So fingers crossed you won’t be able to reproduce this after the upcoming update!