Along the track analysis: tckedit and tckre/sample issues


#1

Hi there,
I am trying to do an along the track analysis, and have come across issues.

I have a CST track (full_CST.tck below) with max 7500 streamlines. Originally generated using include ROIs at the cerebral peduncle (CP) and posterior limb of the internal capsule (PLIC).

I am analyzing stroke brains with varying CST lengths, so decided to create a generic start point and create cuts along the tract at the same distance (2mm).

Using tckedit, I have cut the track shorter (cut_CST.tck).
I used a whole brain mask cut at the level of the CPs (to generate the shorter track), with an include ROI at the PLIC (PLIC.mif).
Next, I ran tckresample to cut at every 2mm, then ran tcksample to extract FA values from each segment.
Code below.

A couple of issues:

  1. The cut track is visually shorter (mask worked), but has more segments than the original (8627).
  2. minlength was set to 40. Yet the cut_CST.tck minimum from tckstats is 0.117562. This distance also wouldn’t reach the -include ROI of PLIC.mif.
  3. The txt file outputted from tcksample included data for 61 cuts, yet tckstats indicated the longest streamline was 112.861 (/2=56 cuts maximum).

Any insights into why this is happening and how I can fix it would be ++ appreciated.
Thank you.


tckstats full_CST.tck 
tckstats: [100%] Reading track file
         mean       median    std. dev.          min          max       count
      107.391      108.511      7.86463      58.7816      117.563         7500

tckedit -mask CPmask.mif -include PLIC.mif full_CST.tck cut_CST.tck -nthreads 0 -number 7500 -minlength 40
tckedit: [done]     7500 read,     7500 written,     8627 segments

tckstats cut_CST.tck
         mean       median    std. dev.          min          max       count
      76.4346      86.7616       28.065     0.117562      112.861         8627

tckresample -step_size 2 cut_CST.tck cut_CST_2mmseg.tck
tcksample cut_CST_2mmseg.tck famap.mif cut_CST_2mmseg_fa.txt

#2

Hi @ahilderley,

Just to be clear, when you say:

Using tckedit, I have cut the track shorter (cut_CST.tck).
I used a whole brain mask cut at the level of the CPs (to generate the shorter track), with an include ROI at the PLIC (PLIC.mif).

, you mean that you took a whole-brain mask, removed all voxels below the CPs, and then ran tckedit with the -mask option? I tend to refer to this as a “crop”: “cut” could imply that both the streamline segments above and below the level of the CPs are retained (like cutting a string).

I need this clarification because you then say:

Next, I ran tckresample to cut at every 2mm, then ran tcksample to extract FA values from each segment.

Here “cut” is used again, but seems to refer to resampling each streamline onto vertices spaced 2mm apart, which is a fundamentally different operation to the first.


  1. When using the -mask option, one can have more streamlines at output than at input because for any particular streamline there may be a set of contiguous vertices that lie outside the mask, yet beyond that set on either side there are vertices that lie within the mask. In this scenario, by masking out vertices in the middle of the streamline, the streamline is effectively bisected into two streamline “segments”. In your case this could be due to e.g. streamlines turning 180 degrees in the pons and traversing the length of the CST twice.

  2. This is an operation ordering issue. The minimum length criterion is applied to the input streamlines, rather than output streamlines that may have undergone one or more bisection operations. It would make sense I think to ensure that all streamline segments following the application of a mask ROI also exceed any specified minimum length, but this will require changes to the code.

  3. There’s definitely scope for some slight mismatch here:

  • tcksample outputs one value per vertex, and there is always one more vertex than there are streamline segments of the specified step size.

  • It is possible for both the first and last streamline segment to be shorter than the specified step size, both from tckgen and tckresample. I’ve endeavoured to ensure that the streamline endpoint locations are always preserved exactly, for all resampling strategies; but for the fixed step size case it’s impossible to both guarantee this and have precisely that step size along the entire streamline.

  • Since streamline length is quantified as the sum of distances between vertices, which is always shorter than the length of a smooth spline representing the streamline, by down-sampling a streamline to a longer step size the quantified length will in fact reduce slightly.

Hope that provides some insight
Rob