Add TFCE as inference option

[nicholst]

Request from Mary Heitzeg's group at the University of Michigan

[TomMaullin]

Hi @nicholst ,

I have been looking into how this could be done and I was wondering if the following is what you had in mind;

In the SwE GUI would be a TFCE option. This would be calculated by;

• First, computing the SwE{T/F} map parametricly.

• Second, converting the SwE{T/F} map to a TFCE statistic using a function like this (and saving the resultant map as swe_vox_TFCE_c{c#}.nii). Let this original TFCE statistic map be denoted O and O_v denote it's value at voxel v.

• Third, performing a wild bootstrap which for each bootstrap, bootstrap number $I$, does the following:

  • Calculate the SwE{T/F} as usual.

  • Convert the SwE{T/F} into a TFCE image (denote the TFCE image from the Ith bootstrap as B_I).

  • For every voxel, record: where 1() represents an indicator function.

  • Record the global maxima in the TFCE image:

• Fourth, obtaining:

  • The uncorrected TFCE P values from:
  • The FWE voxelwise corrected TFCE P values from looking at the distribution of the recorded maxima.
  • The FDR voxelwise corrected TFCE P values from performing: spm_P_FDR on the uncorrected TFCE P values.

The only additional choices the user should have is the variable dh for computing the TFCE integral.

The resultant output of this process should then be the maps:

• swe_vox_TFCE_c{c#}.nii - The parametric TFCE image.
• swe_vox_TFCE_lp-WB_c{c#}.nii - The TFCE uncorrected p value image.
• swe_vox_TFCE_lpFWE-WB_c{c#}.nii - The TFCE voxelwise FWE corrected p value image.
• swe_vox_TFCE_lpFDR-WB_c{c#}.nii - The TFCE voxelwise FDR corrected p value image

As well as the usual parametric maps.

The display should then only have columns for:

• set-level: P and c values.
• cluster-level: Nothing.
• peak-level: TFCE FWE corrected p values, TFCE FDR corrected p values, the TFCE statistic, TFCE uncorrected p values
• mm coordinates of peaks

Is this close to what you had in mind? Or should this be done using a different permutation method from wild bootstrap?

[nicholst]

Hi @TomMaullin ,

Right! I had forgotten about MatlabTFCE and amazed at the concision of that function https://github.com/markallenthornton/MatlabTFCE/blob/master/matlab_tfce_transform.m ... we only need that one function!

You've really got your head wrapped around it! Just a few things to note:

1. The TFCE transform is constructed for z-score like-quantities. That means that F-test values will need to be transformed to Z's via a probability integral transform... look it up; it basically a way to transform any r.v. via p-values, like

   d1=3;d2=100;
   SomeFs=frnd(d1,d2,1000,1);
   SomeSz=-norminv(fcdf(SomeFs,d1,d2,'upper'));

   where we've carefully used the complementary (upper tail) CDF to avoid extreme F-values creating near CDF values that underflow to 1.0.

2. "TFCE" is the statistic name/type, so the naming will be: swe_TFCE_... otherwise your naming is perfect.

Otherwise, you've nailed it! Once we do it here, it would be great to add it to SnPM, as per here: https://github.com/SnPM-toolbox/SnPM-devel/issues/54

[TomMaullin]

Ah great! Ah right of course yes! The only two things I am still unsure on are as follows:

• How would you want this to be implemented into the batch window? Should it be listed under WB if it is based on a wild bootstrap? If not then the user must not be able to select both WB and TFCE at the same time so maybe the batch window should have an "Alternative inference" option where WB and TFCE are both options the user can select?

• Just to double check; in the TFCE paper a permutation test is used to derive the uncorrected and FwE p-values but in the above suggestion we would be using wild bootstrap? As these two methods use different assumptions I thought I had best double check if deriving TFCE p values using a wild boostrap is a valid thing to do? Should I use a permutation test instead?

[nicholst]

Did our meeting sort all these out? As TFCE will be considerably slower than cluster inference, I think it does need to be a 'switch' somewhere. "TFCE inference: Off" vs "TFCE inference: On" with help explaining

Enabling TFCE inference will replace cluster inference with Threshold-Free Cluster Enhancement. A cluster-forming threshold can no longer be specified in the results, and only a FWE-corrected P-value can be used to set the threshold.

Is this good? Or maybe we want to have cluster inference recorded, and if TFCE was computed, the user can choose at results time to show TFCE or cluster inference???

[TomMaullin]

Yes, I guess the user could select between TFCE and cluster inside the WB. What do you think of this suggestion for the updated GUI WB menu option. I.e.

Non-Parametric Wild Bootstrap
-- Yes
---- Small sample adjustments for the resampling
---- Number of bootstraps
---- Type of SwE
---- Statistic Type
------ T/F
-------- Contrast
---- Inference Method (choose one of the three)
------ Voxelwise
------ Clusterwise
-------- Cluster-forming threshold
------ TFCE
-------- Options: T/F
-- No

[nicholst]

Yes, this looks good.

As for options, we could include the H and E values... some people want to mess with those.

[TomMaullin]

Ah right, yes! Should dh also be an input?

[TomMaullin]

Questions/Updates

Hi @nicholst ,

This is just a quick further questions/updates post. Currently, the code has been updated to compute TFCE uncorrected and FWE-corrected P-values for T statistics (and almost for F statistics also) for volumetric input. Below is the stages I plan on implementing the TFCE in (I will tick stages off as I complete them):

• [x] Implement TFCE into swe_cp_WB:
  • [x] Create TFCE uncorrected and fwe p value images for volumetric T tests.
  • [x] Create TFCE uncorrected and fwe p value images for volumetric F tests.
  • [ ] Create TFCE uncorrected and fwe p value images for surface T tests.
  • [ ] Create TFCE uncorrected and fwe p value images for surface F tests.
• [x] Update the GUI with TFCE options.
• [x] Update the Travis tests with updated SwE structures and new use cases.
• [x] Update the results display to display TFCE if TFCE has been selected.

I did have the following questions regarding the TFCE update, however:

• Just to double check, should I also be implementing TFCE for surface-based tests? I believe I can do this, I just wanted to check it would be valid/correct.
• For a T test, should the TFCE statistic be derived from the T statistic or the equivalent Z statistic? I have currently implemented it for the T statistic but it would be relatively quick to change. I only ask as the F test will have to be based on an equivalent Z statistic so for consistency it seems it would make sense to use the equivalent Z for a T test.
• When using an equivalent Z for the F contrast, as you suggest in the previous comments, what should I set the degrees of freedom to? Currently I am just using [1, 1].

[nicholst]

Quick answers:

Surface would be great, but I didn't think we had that functionality at all (e.g. for clusters); I'd put it at the bottom of the priority list (do it last). Yes, I think making an equivalent Z the basis of all TFCE makes sense. You need to get the F DF from the test... or am I missing something?

[TomMaullin]

Ah okay, sorry yes I should have been clearer - I thought I had best double check - should I use the spatially varying df or the nominal df?

[TomMaullin]

This issue has now been addressed by PR #48