-angle parameter in the iFOD2 algorithm

I have been trying to determine how to utilize the -angle parameter to apply stricter criteria to streamline curvature output from the iFOD2 algorithm. The default value results in a large number of biologically implausible (tight curvature or complete “loops”) streamlines. This has lead to a few questions.

For starters,

  1. As I understand it, the equation for the angle parameter in iFOD1 is θ = 2 sin-1 (S/2R) (per the 2012 paper). But the iFOD2 reference (ISMRM poster) doesn’t provide an equivalent equation. I tried taking a look at the source code (ifod2.h), and it seems a bit different than iFOD1. Can you provide an equation for how theta is calculated for iFOD2?

  2. Can I expect the same behavior from the iFOD2 algorithm if a) I leave it to use the default angle or b) input “-angle 45”?

  3. Is there a way to limit torsion?

Thanks!

Some quick answers:

  1. the radius of curvature parameter was used in the previous version of MRtrix 0.2.X, which is no longer under development. Both iFOD1 & iFOD2 now use just the angle as-is to determine the allowable directions for the next steps. The default value of that angle is 45° for iFOD2, or using the equation stated on the tckgen help page for the -angle option. If you run tckgen using the -info flag, you should in fact see the corresponding radius of curvature as computed using the above formula for iFOD1, or the appropriate formula for iFOD2.

    And yes, the way iFOD1 & iFOD2 work is a bit different. Since iFOD2 projects path segments that are inherently modelled as arcs of a circle, the angle corresponds to the angle between the current direction and the tangent direction at the end of the path segment (i.e. what is destined to become the current direction of tracking).

  2. If you don’t modify the step size, then yes. By default, the step size in iFOD2 is ½ the voxel size, and the angle is 90° × step size / voxel size = 45°.

  3. No, I’m afraid there is no control on torsion…

All the best,
Donald.

Thanks for the quick and clarifying response, Donald! Glad to hear that I’m on the right track.

Using a more conservative angle threshold (35°) definitely cleaned things up in my data. Though the remaining biologically improbable pathways now just have more gradual curvature than at 45°+. Hopefully those can be cleaned up with post-processing quality control based on length, exemplars, or such thing.

Is torsion control something you plan on implementing in the future?

Good to hear.

Not as far as I know… What specific use case do you have in mind that would require this?

I’d like to use it as another way to characterize the physical / spatial properties of the streamlines for the purposes of regularization and quality control.

It may or may not turn out to be useful, but seems worth a look.

Understood. I’m not sure we can commit resources to it without a really concrete advantage, but I’d encourage you to look into it, and maybe modify the code to achieve what you need. If it works well and offers a clear benefit, let us know!