ETAC output issues

AFNI Message Board
1

Hello AFNI experts,

Long time reader; first time writer here. The research I’m involved with usually uses the -Clustsim option in 3dttest++ when obtaining whole brain results. However, after reading about ETAC and its benefits, we wanted to try using that option. We ran our typical 3dttest++ command but also added the following arguments:

-ETAC
-ETAC_blur 0 4
-ETAC_opt NN=1:sid=1:hpow=2:pthr=0.01/0.001/10:fpr=5:name=Test
-ETAC_arg -verb

After running without any errors, we immediately noticed that the free 1D text files were not generated. However, since the other output files (.ETACmask and .ETACmaskALL) for positive and negative seemed to be generated and contained non-zero values, we decided to continue. In AFNI, the positive binary mask looked like one giant cluster of 17862 voxels, so we followed the instructions on this forum thread. We ran a command like this:

3dClusterize -ithr 0 -idat 0 -inset INPUT_ETAC_MASK
-NN 1 -1sided RIGHT_TAIL 0.5 -clust_nvox 5
-pref_map Clust_OUTPUT

However, this did not change anything. 3dhistog revealed that we still had one giant cluster of 17862 voxels in our output file. First, we double-checked our 3dttest++ command, removing -Clustsim (which we kept to compare results) and running ETAC only with no extra blurring (mostly to speed up our troubleshooting).

This did not change our output: No errors but also no text files and only one large cluster. It was at this point that a colleague suggested that we instead use the regular 3dttest++ results (which were outputted like normal) and run those through 3dClusterize with the binary ETAC mask as the 3dClusterize mask. To compare results, we could also go into AFNI and check out the uncorrected results at p < .01, k = 5. We ran the following 3dClusterize command:

3dClusterize
-inset RegularOutput
-ithr 2
-idat 1
-mask ETAC_BinaryMask
-NN 1
-1sided RIGHT_TAIL p=.01
-clust_nvox 5

This command gave us in different results than using 3dClusterize on the ETAC mask, and these results had various clusters! However, the results actually included clusters that were larger than the uncorrected AFNI results, which, obviously, is not right. This is when I thought to reach out to you all. Another development occurred while writing this though: 3dClustsim recommended the argument p = .005 for a one-sided test while my colleague was trying to solve this puzzle himself, so he decided to plug that value in (with all other arguments in the last 3dClustsim command I listed kept the same). The 3dClustsim results, at that point, mirrored what was seen in AFNI at uncorrected p < .01 (aside from some clusters that seemingly fell outside of the binary mask).

I am sure we went wrong somewhere in this process or our thinking, as we just cannot figure out why our “solution” would be the solution. Also, I am just not sure where those free text files would be since they are not with any of the other output. I’m sorry if this ends up being some obvious mistake, and any help would be greatly appreciated!

Regards,
David

2

Hi, David-

I a little concerned about the ETAC options as written:


-ETAC_opt NN=1:sid=1:hpow=2:pthr=0.01/0.001/10:fpr=5:name=Test

Namely, the pthr values—is the third value really 10?

Re. sidedness, is 1-sided testing appropriate? Often times 2-sided matches better with hypotheses:
A tail of two sides: Artificially doubled false positive rates in neuroimaging due to the sidedness choice with t-tests
https://pubmed.ncbi.nlm.nih.gov/30265768/

Re. 3dClusterize, can I ask what kind of values you are visualizing? A value of 0.5 seems pretty low for many types of output (is it Fisher Z-transforms of Pearson correlations, say?).

Re. comparing 3dClusterize: the two commands you are using have different “-idat …” and “-istat …” index values, so those are looking at different volumes. Also, you have different thresholds set: one is just a direct value of “0.5”, and the other is using AFNI’s internal logic/header-reading to translate p=0.01 into a threshold for that statistical data.

–pt

3

Hi PT,

Thanks for the response!

For the first question, the “pthr=0.01/0.001/10” argument, per the 3dttest++ instruction site, inputs into ETAC that I will use 10 separate evenly-spaced pthr values, ranging from .01 to .001. Unless this has since changed but hasn’t been updated, it should be equivalent to “pthr=0.010,0.009,0.008,0.007,0.006,0.005,0.004,0.003,0.002,0.001”, or the ETAC default.

Regarding the sidedness, we do have several one-way hypotheses for some of our contrasts, so the sidedness does have scientific justification and was not done out of some mechanical or arbitrary reason. Nevertheless, we also ran a 2-sided t-test for one of our contrasts that we had no sidedness hypotheses for (both to check a different contrast and to see if sidedness might be causing the problems). Unfortunately, this did not end up with text files or solving any of the subsequent confusion.

For 3dClusterize, I was following a previous post about how to interpret the output from ETAC. Our binarized map had that one cluster of ~18000 voxels. Of course, we needed to know how to use this to generate the typical clusters of activation, ranked by size. In that previous post, the OP and responder used…

3dClusterize -ithr 0 -idat 0 -inset ETAC.global.2sid.5perc.nii.gz
-NN 2 -1sided RIGHT_TAIL 0.5 -clust_nvox 2
-pref_map ETAC.clust.order.nii.gz

…To get that cluster map. Of course, this struck me as a bit odd, as it seems to be thresholding a map of 1’s and 0’s, but maybe this was just something I wasn’t fully understanding.

Lastly, yes, we used 3dClusterize in two ways: the first way was the unorthodox way that was suggested to use ETAC output based on that previous AFNI post that seemingly had the same problem that we did. ETAC binary mask output has only one volume, so ithr and idat were both 0. The latter way was the typical way to use 3dClusterize, which used the regular t-test output, which is why it has a different ithr and idat and a typical p-value to generate a threshold. Again, however, this did not seemingly solve our problem.