Special handling for two-sided Z maps?

[jflournoy]

Hi and thank you for the great software.

I ran this on a test Z map that has both positive and negative Z values, and it seems to have discarded the voxels with negative values. It appears that the user should manipulate the Z-map to be "one sided" and then reintegrate sign info if necessary. Is that correct?

[jflournoy]

I see in Smith and Nichols (2009) the advice is this:

By default, voxels that were originally negative will be given zero TFCE score. However, if it is desired to apply the enhancement to both negative and positive values, the original image can be simply negated, passed through the enhancement, re-negated and combined (via addition) with the positive enhancement.

This suggests I should run pTFCE on the negative and positive voxels separately, recombine, and then threshold at a voxel Z value to control the two-sided FWE p < .05 by using, say fwer0.025.Z=fwe.p2z(pTFCE$number_of_resels, 0.025).

[johnaeanderson]

That sounds correct - but likely you'd want to apply the updated threshold before combining. Alternatively, you could take the absolute value of the image, threshold as normal & binarize the output. Multiply the binary image by the original values to get the thresholded image.

[spisakt]

Dear @jflournoy and dear @janderz8,

Sorry for the late replay, for some reason I didn't get notifications about this github issue.
You are absolutely right and both of the suggestion work well (1. Running pTFCE separately with the original and the inverted image threshold and combine, but also, 2. taking the absolute value, threshold and fix signs).
Just like with the original TFCE.
The latter solution is quite creative, I think! :)

Thank you for your interests!

Cheers,
Tamas

[maitra]

Dear @jflournoy and dear @janderz8,

Sorry for the late replay, for some reason I didn't get notifications about this github issue.
You are absolutely right and both of the suggestion work well (1. Running pTFCE separately with the original and the inverted image threshold and combine, but also, 2. taking the absolute value, threshold and fix signs).
Just like with the original TFCE.
The latter solution is quite creative, I think! :)

Thank you for your interests!

Cheers,
Tamas

The latter solution is however not equivalent. Perhaps not even correct. So, if there are 2 voxels next to each other, one negative and the other positive, then why should both be considered as candidates in a cluster which is what taking absolute values would do. I think that the right way to do this is as suggested in the paper.

[spisakt]

In theory, you are right, but in practice, pTFCE uses a "simplification" at low thresholds (Z<1.1), as GRF theory is not accurate below these thresholds. The simplification is actually that no boosting is applied based on these low-threshold clusters. Thus I believe, cluster merging is only a problem if you have very strange data, e.g. neighbouring voxels having z-score values +1.2 and -1.2.
Pretty unlikely. Otherwise, cluster sizes will follow the same distributions as in the original images (but there will be approximately twice as much) and statistics should remain valid.

But again, I agree that having two separate runs is better, as the absolute value-based solution works only due to an implementation-dependent phenomenon...

[maitra]

In theory, you are right, but in practice, pTFCE uses a "simplification" at low thresholds (Z<1.1), as GRF theory is not accurate below these thresholds. The simplification is actually that no boosting is applied based on these low-threshold clusters. Thus I believe, cluster merging is only a problem if you have very strange data, e.g. neighbouring voxels having z-score values +1.2 and -1.2.
Pretty unlikely. Otherwise, cluster sizes will follow the same distributions as in the original images (but there will be approximately twice as much) and statistics should remain valid.

But again, I agree that having two separate runs is better, as the absolute value-based solution works only due to an implementation-dependent phenomenon...

You are the author so you know your methods best, but it appears to me that the premise of cluster-based thresholding (actually, all the postprocessing that is usually done) is that we are looking for spatially contiguous clusters (that act and behave together). Using the absolute value of the image will cause false positives because negative and positive values are going to be candidates for the same cluster (but from different association types which will not be biologically meaningful) and I don't quite see its relevance to low or high thresholds.

We wrestled with this issue in our recent work FAST-fMRI and came across a solution exactly the same as your original solution. Too bad that we were not aware of pTFCE at that time (and none of the reviewers brought it up over a 2-year review process, largely caused by Hurricane Maria) otherwise we would have also evaluated the method.

But it would be nice if the script does the 2-sided case also. Ideally, a R wrapper function calling the individual functions for both cases would be easy to write and ideal to avoid issues of errors being made.

[spisakt]

I absolutely agree, still, if the image if smooth enough and we exclude low thresholds (as the algorithm actually does) then negative and positive clusters simply won't merge with each other. Therefore, cluster stats should remain valid on the level of individual clusters. Right?
Of course, smoothness is not always homogenous, so one should rather use the two-step approach, indeed. And the alpha-level should be always adjusted for two-sided testing.

The wrapper for 2-sided analysis is a good idea, I will open a new issue with a feature request so that we will remember and implement it later.

Thanks for the recommendation!

[maitra]

If the image is smooth, strictly speaking, clusters will likely be formed naturally. In any case, the original recommendation is the correct approach.
I feel that the wrapper is very quickly done and that the software would benefit from doing this relatively soon simply because otherwise you may have people making fixes that can in my mind be erroneous. We had the same issue, as I said, in RFAST-fMRI: look at the FASTfMRI function in fastfMRI.R.
Thanks again!

[michaelhallquist]

Hi there,

I came across this thread with the same question as @jflournoy. I found the discussion useful and coded up an R script that wraps ptfce and accepts command line arguments. If requested, it applies the two-sided correction described above by running pTFCE on the negative and positive sub-images. At present, this is a standalone script, but in the near future, it will use some classes internal to a broader R package, so make sure to use this version: https://github.com/UNCDEPENdLab/fmri.pipeline/blob/a65d4edb43d1c2c2401a3df64d63a9dc74ff1d28/inst/bin/ptfce_zstat.R. Hope this helps others, and please let me know if you see mistakes or oversights!

Best wishes,
Michael