Hi,
I thought higher angle threshold is more liberal, and more tracts will be kept, but when I compare the different between two angle thresholds, I found that it’s not what I thought.
angle threshold at 60
angle threshold at 90
The algorithm is iFOD2, all the other parameters are the same.
Appreciate if you could shed a light on that. Many thanks
Mengxing
This is indeed not what I would have expected. But it’s hard to assess this from a single run: these are probabilistic results, and there’s a couple of stray streamlines at the bottom right of your 60° results that probably have a strong visual influence on how we might interpret these results. But if that holds up, I’ll need to look into it…
Thanks Jacques-Donald,
I have been testing it on other tracts, but the same happened. See below example of Optical Radiation, I tested angle at 60 and 90, all the four subjects showed less tracts thresholded at 90 than it at 60:
I think there’s a number of experimental details that need to be taken into account when interpreting these data. I.e. What details are relevant in the determination of how many streamlines are present in the output file?
Firstly, if using tckgen with default settings, and having all of your inclusion / exclusion regions included in the tckgen call, then you will get an identical number of streamlines in every run. This is because the default termination criterion in tckgen is based on a fixed number of streamlines in the output file. So the fact that this is not the case for your data means that there must be some additional relevant information. For instance: Are you generating a fixed number of streamlines from a seed region, and then post hoc selecting those streamlines that follow the entire trajectory of interest? Or are you instructing tckgen to generate a fixed number of streamline seeds, and then counting the number of output streamlines?
In many of these cases, what ends up actually being quantified is “the fraction of streamlines that satisfy my criteria”; i.e. you generate some fixed number of streamlines in your seed region, and only some fraction of them reach your target region, and the number of streamlines in your output file reflect that fraction.
It entirely follows from this that increasing the streamline angle threshold could lead to a reduced number of streamlines in the output file. Your pathways of interest are reasonably straight, and a small angle threshold will prevent streamlines from deviating from the intended path. By increasing the angle threshold, streamlines are now free to latch on to crossing or adjacent fibre bundles, following unintended trajectories, and reducing the fraction of streamlines that satisfy your selection criteria.
So I would generally advise thinking carefully about exactly what parameter is being quantified, and what influences that parameter due to your experimental design. Even within the scope of the adage that “streamline count is not quantitative”, there are actually multiple branches in terms of different ways in which streamline count can be not quantitative. 
Cheers
Rob
I can confirm these results when extracting the OR from a whole brain connectome.
command used for streamlines: tckgen -act 5tt_coreg.mif -backtrack -seed_gmwmi gmwmSeed_coreg.mif -nthreads 8 -angle 90 (or 45 or 180 instead) -maxlength 250 -cutoff 0.06 -select 10000000 wmfod_norm.mif tracks_10M_90.tck (version=3.0.2)
Streamline count -angle 45: 84
Streamline count -angle 90: 41
Streamline count -angle 180: 50
Might this be due to the act option?
Welcome Philip!
I’m dubious of any results generated with -angle 180, since that’s permitting streamlines to double back on themselves within a single half-voxel step. Indeed we’d probably need to check the iFOD2 code to see if the generated arcs even make sense…
The streamline counts are also quite small, so you don’t necessarily know for sure if you’re just looking at two random samples from what’s vaguely a Poisson counting process.
What would be interesting here is not so much that the streamline count of one specific edge is decreasing with increasing angular threshold, but rather where they go instead.
Cheers
Rob
Thanks for the explanation! Did not really improve the final results anyways, but good to know what might have been the reason 
