Regarding TDI endpoint maps: interpretation, thresholding, and smoothing

Hello MRtrix3 community,
I first wanted to say it has been a pleasure working with MRtrix3! I would like to express my sincere appreciation for all the hard work of the developers and the support they provide here and in the documentation. This, along with publishing so much of your work, is a huge service to the field. Thank you!

The goal of our current study was to map the axonal projections from two distinct regions in the ventral occipitotemporal cortex, to understand what areas these regions are structurally connected to (at the group level) and, importantly, the extent to which their projection targets differ within subjects.

I have a few questions that pertain to endpoint track density image (TDI) maps generated from the -ends_only option in tckmap. I have created these images for each ROI/subject in MNI152 space, then smoothed them using a 4mm gaussian kernel with mrfilter. I then performed a paired t-test and cluster correction using AFNI tools. The result shows large clusters of statistically significant difference in endpoint density, but the effect size across areas is quite variable. Before interpreting these contrast maps, I am interested in thresholding the result such that I eliminate projection targets which are not biologically “plausible” or “meaningful.” For instance, it seems that some streamlines reliably arrive in distant prefrontal areas from one ROI and not the other, but the average (SIFT2-weighted) endpoint density values there are very small, e.g. 0.002 in prefrontal vs 0.2 to posterior occipital areas. Note that this is exacerbated by the intentional over-sampling of streamlines projecting from these ROIs (see pipeline details below). A few questions:

  1. Can the resulting endpoint density values in each voxel be interpreted as indicating the cross-sectional area of arriving fibers? And, can a particular unit be ascribed to these values? (edited for clarity)
  2. Do you have any thoughts on whether/best way to threshold these maps?
  3. Does gaussian smoothing of TDI endpoint maps seem appropriate?

To briefly summarize my processing pipeline if it matters for the consideration of my questions (or in case it is helpful for others): my pipeline for this single-shell (b=2000) 3T data involved FSL-based preprocessing (including dwidenoise and distortion correction using Synb0-DisCo), Dhollander response function estimation, SS3T-CSD (using the the group mean response parameters), mtnormalize correction, tractography using iFOD2 with ACT / GMWMI seeding (based on FreeSurfer segmentation) / 10 million streamlines, and finally SIFT2. Prior to SIFT2, I generated an additional 500k streamlines from each ROI mask and combined these with the whole-brain streamline set (to more densely sample the projections from these ROIs). The ROIs were defined on the surface and sampled to volumetric space, respecting the cortical GM definition from FreeSurfer. Tractography was performed in subject’s native DWI space (after distortion correction), then a nonlinear transformation of the .tck files to MNI152 space was performed prior to TDI map creation/smoothing.

P.S. I look forward to the long-awaited paper by @rsmith which might help with some of these questions, though no pressure of course! :wink:

Thanks again for your time.

-Ben

Welcome Ben; glad you’re having fun!

I’ve in the past thought about the prospect of an experiment like this, but have never had the right opportunity to invest in it. Looking forward to seeing what could come from it.

Firstly, it’s really the kind of application that would benefit from a surface-based analysis; not only in achieving alignment between subjects, but also in performing surface-based smoothing. It sounds like you’re probably too far down the pipeline to make such a drastic change, and allowing tractography in MRtrix3 to interact natively with surface-based data is not yet in the release code, but it’s something to contemplate for the future.

Another thing that I decided a long time ago but have never had the opportunity to state explicitly in a manuscript is that because the errors in streamlines-based connection densities are far closer to multiplicative than additive (see Figure 4), it may be preferable to log-transform the data prior to fitting a linear model.

  1. It’s certainly proportional to cross-sectional area relative to different areas of cortex within a subject. To make those cross-sectional areas comparable between subjects requires appropriate scaling. My manuscript will explain this all in more detail, but if you take a look at the expression for mu (equation 1), it’ll tell you what the units are… :shushing_face:

  2. What is the fundamental purpose of this thresholding? Are you simply trying to omit certain areas of no interest from your statistical testing in order to increase statistical power? The trouble here is that this is technically a decision that needs to be made before you ever set eyes on the results without such masking; otherwise you have a circular hypothesis test problem. So for instance, restricting testing to one specific hemisphere, or omitting a whole lobe from the analysis because connections are known to not exist, would be permissible; but this is information that needs to be known a priori. If you’re wanting to omit weakly-connected regions from statistical inference, then it’s exceptionally difficult to devise a robust mechanism for doing such without having already completed such an experiment with different data. You could potentially devise a priori a heuristic for doing something reasonable by, e.g. generating for each subject a map of voxels where the endpoint density is at least equivalent to 1 streamline with unity weight, and then generating a mask of voxels where at least 50% of subjects exceed this threshold. But importantly this would only be used to omit certain voxels from statistical inference; I don’t think you would want to have your spatial smoothing influenced by such a mask.

  3. It’s not the ideal basis on which to be operating, because you’re smoothing cross-sectional area quantities in a volume space; but as long as your registration is good enough and your smoothing kernel is large enough for the data to become normally distributed in the presence of variations in cortical folding, I don’t personally see any fundamental mathematical reason for it to not be permissible.

P.S. I look forward to the long-awaited paper by @rsmith which might help with some of these questions …

Don’t look at me; look at @jdtournier :crazy_face:
Fingers crossed for a preprint within a week or so…

Cheers
Rob

1 Like

Ben (& all),

A more thorough explanation of why these methods operate in the way that they do, and how they should be utilised for inter-subject comparisons (not just of your endpoint density maps, but of endpoint-to-endpoint connection density also), can now be found here.

Regards
Rob

1 Like

I agree that a surface-based analysis would be ideal for this project, for the reasons you mention, and also because we only have hypotheses about cortical-cortical connections (rather than to subcortical). I have been doing surface-based fMRI processing in AFNI/SUMA, starting from FreeSurfer files, and so am familiar with the tools/methods. I turned away though from the idea of going surface-based for this tractography project due to the lack of support for surface data in MRtrix3.

With that being said, the ROIs are firstly defined on a subject’s standard surface mesh (as a circle with 7mm radius) around peak nodes from the MNI152 standard mesh (where the peaks are defined from a published fMRI paper), then sampled+transformed to DWI volumetric space for tractography. So, each subject has a slightly different volumetric ROI, according to how their particular surface anatomy aligns with the MNI152 surface. In this sense, we are taking advantage cortical surface alignment.

You mentioned smoothing on the cortical surface, which is something I have not done yet but makes sense. I can sample the raw endpoint density results to subjects’ standard surface meshes, and then perform 2D smoothing as well as conduct the group-level statistical contrasts in standard surface space. I fear that there may be some complications in regards to where the streamlines actually terminate relative to the surfaces’ white-matter boundary, and subsequent volume-to-surface sampling done by AFNI. But the 5TT/ACT masks were defined from the same FreeSurfer data, so perhaps there will be no real issue. I’ll look into it, thanks for the suggestion!

Thanks for mentioning this and seems to make sense statistically… I do think a useful product of using these methods is that results can be described physically in terms cross-sectional area, so I will just make sure to transform back to those units for reporting.

Thanks so much for posting the preprint, really helpful to affirm my understanding of things, and thanks as well for the link to your MRM letter (hadn’t seen this, interesting exchange :wink:). I implemented the use of group-average response functions as well as intensity normalization via mtnormalize, which I believe satisfy the requirements laid out in your preprint regarding connection density normalization. I then apply the SIFT2 weights when performing tckmap to create the TDI/endpoint images (via -tck_weights_in flag). All of this together should amount to the appropriate scaling you mention here, but please correct me if I am wrong.

I appreciate your response here and the discussion about a priori masking before the results are known, fully agree. The thresholding I proposed is of the latter kind you mention, and would only be applied after smoothing, statistical testing, and cluster correction. The purpose would be to remove areas from the result (or at least from the manuscript discussion!) where the difference in endpoint density was so small that it may be considered in some sense to be “biologically negligible” (despite being statistically significant), and/or an artifact of streamline generation with oversampling from the ROIs. I take your point about how this is difficult without guidance from a previous experiment, but also the potential method you propose is along the lines of what I was after and seems reasonable. Thanks!

Ok, this all makes sense, just wanted to run it by the experts! Perhaps I will avoid this entirely if I instead go the surface-based route.

I will report back with how things turned out, hopefully with a preprint!

Thanks again for your reply. Cheers!

-Ben

Oops, I am missing something here (right?). I need to multiply the final values, in my case the voxel-wise values in the TDI maps, by the subject-specific proportionality coefficient (mu)? Looks like I’ll need to re-run tcksift2 with the -out_mu flag to get these values.

… thanks as well for the link to your MRM letter (hadn’t seen this, interesting exchange :wink:).

You ain’t seen anything yet…

The purpose would be to remove areas from the result (or at least from the manuscript discussion!) where the difference in endpoint density was so small that it may be considered in some sense to be “biologically negligible” (despite being statistically significant), and/or an artifact of streamline generation with oversampling from the ROIs.

In that case it may be marginally preferable to use this as a mask constraining where statistical inference is performed, rather than performing statistical inference and then masking the results. The former will have a marginal gain in statistical power as the multiplicity of testing is reduced.

I need to multiply the final values, in my case the voxel-wise values in the TDI maps, by the subject-specific proportionality coefficient (mu)?

Correct; the weights exported by tcksift2 are distributed around unity as per the formulation shown in the manuscript describing the method; the multiplication by mu is considered a separate explicit step.

Looks like I’ll need to re-run tcksift2 with the -out_mu flag to get these values.

Currently yes. Or you can run tcksift with the -nofilter option. Admittedly it’s kinda clumsy. In retrospect what I should do is utilise the new capability in 3.0.0 for writing header information to text files, and write the value of this parameter to a comment line in the output text file…

Cheers
Rob