New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Precise quantification of streamlines lengths #1507

Open
wants to merge 3 commits into
base: dev
from

Conversation

Projects
None yet
3 participants
@Lestropie
Copy link
Member

Lestropie commented Nov 28, 2018

As discussed in #1501.

The only time at which it is safe to perform a multiplication between number of vertices and step size in order to derive the streamline length is within the tractography propagation algorithm itself, when a fixed step size is guaranteed. As soon as there is the possibility of an inconsistent step size (input data from a file, various resampling strategies, truncation), this is no longer safe, and so the sum of inter-vertex distances must be calculated.

Couple of points to note:

  • Whenever tckgen -act -crop_at_gmwmi is specified, streamline lengths are always re-quantified, based on a fixed step size for all but the first and last segments (those are measured explicitly) and compared against the floating-point minimum length (previously the tckgen test for minimum length was purely based on number of vertices).

  • Downsampling that can occur in tckgen (and is on by default for iFOD2) affects length quantification. As such I've thrown in an additional test against the tracking minimum length after downsampling has occurred. I measured the performance penalty of this at about 1%.
    Conceptually this isn't required for iFOD2 under default usage, since in that algorithm it's actually the post-downsampling inter-vertex distance that is controlled, not the "internal" step size within each arc trajectory. But trying to catch this case in order to skip it would be kinda clumsy.

  • I intentionally designed the histogram feature in tckstats to centre the bins at multiples of the step size; therefore floating-point variations in quantified lengths shouldn't be a major issue here.

  • I also tweaked tckstats to be a little more explicit about the presence of empty streamlines (0 vertices) vs. zero-length streamlines (1 vertex).

  • I looked briefly into quantification of spline length rather than piecewise length (in the hope it'd be less sensitive to variations in vertex density), but it went straight into the too-hard basket.

Closes #1501.

Closes #1153.

@Lestropie Lestropie self-assigned this Nov 28, 2018

@Lestropie Lestropie requested a review from MRtrix3/mrtrix3-devs Nov 28, 2018

@Lestropie

This comment has been minimized.

Copy link
Member

Lestropie commented Dec 9, 2018

Some more musings on the forum, with potentially more to change in the code.

@jdtournier

This comment has been minimized.

Copy link
Member

jdtournier commented Dec 11, 2018

Looking at this, I'm reminded that we might want to change the default setting for the max length. Currently, it's set to 100× voxel size, which is really a bit useless. Might be best reserved for a separate pull request - but how do people feel about setting it to the largest image dimension instead (i.e. max FoV)?

@thijsdhollander

This comment has been minimized.

Copy link
Member

thijsdhollander commented Dec 11, 2018

Agreed the default is a bit useless. I don't think max FoV will be enough though: if you cropped your FoV to just the brain mask (which many people often do, to deal with large datasets / high resolutions), this doesn't allow a streamline to run "back and forth" through the brain anymore. The default should, in my opinion, just be something that is realistically not reached, but is there anyway to avoid streamlines looping infinitely. So going by my earlier reasoning/argument ... what about 2x max FoV...?

@jdtournier

This comment has been minimized.

Copy link
Member

jdtournier commented Dec 11, 2018

what about 2x max FoV...?

Actually seems fair enough to me... 👍

@thijsdhollander

This comment has been minimized.

Copy link
Member

thijsdhollander commented Dec 12, 2018

...and just to be safe: max(FoV) could be defined here as the maximal length that fits (as a straight line) in the FoV; i.e. the length of the diagonal connecting opposite corners.

@Lestropie

This comment has been minimized.

Copy link
Member

Lestropie commented Dec 12, 2018

max(FoV) could be defined here as the maximal length that fits (as a straight line) in the FoV; i.e. the length of the diagonal connecting opposite corners.

I think I might have proposed this last time around? Was still concerned about the influence of FoV cropping though. We've never figured out a better heuristic so it really needs its own issue listing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment