# Along the track analysis: tckedit and tckre/sample issues **URL:** \ **Category:** Uncategorized\ **Created:** [July 31, 2018, 5:30pm UTC](https://community.mrtrix.org/t/along-the-track-analysis-tckedit-and-tckre-sample-issues/1802 "2018-07-31T17:30:55Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![ahilderley](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/a/4af34b/32.png) [@ahilderley](https://community.mrtrix.org/u/ahilderley)\ **Post date:** [July 31, 2018, 5:30pm UTC](https://community.mrtrix.org/t/along-the-track-analysis-tckedit-and-tckre-sample-issues/1802/1 "2018-07-31T17:30:55Z")
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. * * * ```auto 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 ``` ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [August 15, 2018, 5:20am UTC](https://community.mrtrix.org/t/along-the-track-analysis-tckedit-and-tckre-sample-issues/1802/2 "2018-08-15T05:20:44Z")
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