Tckresample and tcksample for along the tract statistics

hcarlson · December 11, 2017, 9:28pm

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

rsmith · December 19, 2017, 1:34am

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

hcarlson · January 16, 2018, 10:21pm

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

ThijsDhollander · February 8, 2018, 2:44am

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

hcarlson · February 9, 2018, 5:59pm

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?
Thank-you very much
Helen

rsmith · February 10, 2018, 11:58pm

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

Rob

hcarlson · February 14, 2018, 10:49pm

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

hcarlson · March 2, 2018, 8:54pm

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

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

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

rsmith · March 21, 2018, 4:08am

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.

hcarlson · March 22, 2018, 5:02pm

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

rsmith · March 23, 2018, 12:53am

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!

Salah · February 10, 2021, 9:11am

Hi @ThijsDhollander and @rsmith

I have the same issue where the value.txt showing empty rows (sometimes one row while other times more than row. the uploaded example shows that several rows are empty) in between and the cells are shifted to the right when I did the
tckresample input.tck -line (1,2,3) (4,5,6) after_resamp.tck
tcksample after_resamp.tck fa.mif values.txt

It says that the issue was with the tckresample. Is it still exist?

Here is the version of my mrtrix:
== tckresample 3Tissue_v5.2.9 ==

64 bit release version, built Feb 2 2021, using Eigen 3.3.7

Author(s): Robert E. Smith (robert.smith@florey.edu.au) and J-Donald Tournier (jdtournier@gmail.com)

This Source Code Form is subject to the terms of the Mozilla Public

License, v. 2.0. If a copy of the MPL was not distributed with this

file, You can obtain one at http://mozilla.org/MPL/2.0/.

Covered Software is provided under this License on an “as is”

basis, without warranty of any kind, either expressed, implied, or

statutory, including, without limitation, warranties that the

Covered Software is free of defects, merchantable, fit for a

particular purpose or non-infringing.

See the Mozilla Public License v. 2.0 for more details.

For more details, see http://www.mrtrix.org/.

Regards,
Salah

Salah · February 10, 2021, 9:16am

Hi all,

Update: Sorry I did not mention that I run the command with -debug
and here is the result:

tckresample: [WARNING] existing output files will be overwritten

tckresample: [DEBUG] No config file found at “/etc/mrtrix.conf”

tckresample: [DEBUG] No config file found at “/Users/salah/.mrtrix.conf”

tckresample: [DEBUG] reading key/value file “Tractography/IFOF/R_IFOF_R01.tck”…

tckresample: [DEBUG] creating empty file “Tractography/IFOF/fa_R_IFOF_R01.tck”

tckresample: [INFO] file “Tractography/IFOF/fa_R_IFOF_R01.tck” already exists - removing

tckresample: [DEBUG] initialising threads…

tckresample: [DEBUG] launching thread “source”…

tckresample: [DEBUG] launching 24 threads “pipe”…

tckresample: [DEBUG] launching thread “sink”…

tckresample: [DEBUG] waiting for completion of thread “source”…

tckresample: [DEBUG] no writers left on queue “source->pipe”

tckresample: [DEBUG] thread “source” completed OK

tckresample: [DEBUG] waiting for completion of threads “pipe”…

tckresample: [DEBUG] no writers left on queue “pipe->sink”

tckresample: [DEBUG] no readers left on queue “pipe->sink”

tckresample: [DEBUG] no readers left on queue “source->pipe”

tckresample: [DEBUG] threads “pipe” completed OK

tckresample: [DEBUG] waiting for completion of thread “sink”…

tckresample: [DEBUG] thread “sink” completed OK

tckresample: [done] resampling streamlines (count: 2227, skipped: 0)

Regards,
Salah

rsmith · February 10, 2021, 11:28am

Hi Salah,

Given that you are using unsupported software, I cannot comment on whether or not the issue you are encountering is or is not consistent with the prior discussion on this thread. If you can reproduce the fault on the latest version of MRtrix3, please additionally post exemplar contents of the text file itself, as there is a chance of an issue between the actual data generated by MRtrix3 and the way that it is interpreted by your spreadsheet software.

Regards
Rob

Salah · February 10, 2021, 11:58am

Hi Rob,

Thank you for your reply.

Is it because not up to date version? or there is another reason?

I can not upload this type of files and it shows this error:
Sorry, the file you are trying to upload is not authorized (authorized extensions: jpg, jpeg, png, gif, woff, js, pdf). but I have saved it as a PDF.

FA_R_IFOF_R01.pdf (63.3 KB)

Regards,
Salah

jdtournier · February 10, 2021, 12:35pm

You’re using this version:

Here is the version of my mrtrix:
== tckresample 3Tissue_v5.2.9 ==

which is not an official MRtrix3 release. What Rob is saying is if you try using the latest release version (3.0.2 currently), there’s a chance the issue might already be fixed. If not, we’ll see if we can replicate the issue and fix the problem.

But looking at what you’re saying, this seems to be a totally unrelated issue. You have empty rows in the output file, which to mean suggests you have streamlines that simply don’t intersect the cut planes, which I expect might lead to an empty line (I’d need to look through the code to double-check). Are you sure all the streamlines in your input tracks file are suitable for resampling like this?

Salah · February 10, 2021, 1:12pm

Thank you @jdtournier and @rsmith for being patient and supportive!!

Sounds good. How can I update mine?

tckresample DIR/R_IFOF.tck -line 25 22.44,33.66,12.11 30.17,-33.57,4.107 DIR/fa_R_IFOF.tck -debug -force
tcksample DIR/fa_R_IFOF.tck DTI/fa.mif DIR/FA_R_IFOF.txt

I am not!!!
But when I call (tckconvert) to generate 2227 voxel_coordinate.txt files from the original.tck, there is nothing missing, I reckon!!

I think I need to call tckconvert to generate voxel_coordinate.txt files from the After_tckresample.tck. to find out the coordinate values of the resampled points (in my case 25 points). What do you think?

Regards,
Salah

jdtournier · February 10, 2021, 4:57pm

Just download and install the normal way should do it.

I’m not sure that would tell you whether any of the streamlines are empty. Try this command:

tckstats streamlines.tck -histogram hist.txt

and then look at the beginning of the hist.txt file this produces using head, e.g.:

head hist.txt 
# tckstats 'streamlines.tck' -histogram hist.txt  (version=3.0.2-61-ge2274ef9)
Length,Count
0,0
1,0
2,0
3,0
4,0
5,0
6,0
7,0

In this example, the first line 0,0 tells me I have no zero-length streamlines.

I’m not sure what your voxel_coordinate.txt file contains, or how it was generated. I don’t see how tckconvert could generate such an output…

rsmith · February 11, 2021, 1:49am

That’s actually not quite accurate: a “streamline whose length is zero” is actually a streamline that contains one vertex; whereas I’m pretty sure that if tckresample can’t produce an output streamline for a given input streamline (e.g. because it fails to span the space between the specified endpoints), it will write a “streamline” with zero vertices (i.e. consecutive delimiters). tckstats however reports the presence of either / both of these with a warning.

Salah · February 11, 2021, 2:33am

Hi all,

I already generated Whole_Brain Tractography and I segregated many tracts/subject.
In this case, is there an issue to update the MRtrix version and keep working? Or I need to run the whole process from the beginning.
I just want to clarify this before I update the version.
Thanks for all the efforts explaining things to the MRtrix users.

Cheers,
Salah