I was wondering if you might be able to help me wrap my head around a feature of randomize_parallel’s output. I’ve talked to a number of users around the department, and we haven’t quite been able to identify the reason that--what we believe to be the unthresholded p-stat map from Randomise--the p_tstat1.nii.gz image has large swaths of brain showing values of [exactly] zero.
An earlier comment on the message board ("Randomise parallel: masking changed between versions 4.1.9 and 5.0.4” from 1 Sept.) flagged this as a feature characteristic to less recent versions of FSL (e.g., 4.1.9). Running the exact same code in both versions (with the same underlying inputs) yields non-zero values for all brain voxels in version 5.0.4, while large swaths of voxels will be zeroed out in the older version’s output. Importantly, this happens even when no -m <mask image> was specified.
It’s my understanding that all the p-values (more precisely 1-p-values) would be greater than or equal to zero. It doesn’t appear to be a thresholding issue in FSLview, per se. At first blush, it would appear as though there’s some (unspecified?) threshold that is applied at some point during significance testing, at least in the older FSL package. Might this be related to the mean across all subject images in the input file, perhaps? In my particular case, I’m using a statistic created from an MVPA searchlight as the input (one 3d volume for each subject, with subjects running in the fourth dimension).
My worry is that certain voxels may be unintentionally excluded, altering the factors that go into determining the significance (and size) of a cluster. Some of the zeroed-out voxels from the old version are associated with large 1-p-values (e.g., 0.93) when run in the new version and suggesting that it’s more than just a rounding error.
I suppose my main questions are:
1) How should I interpret those “clusters” of zero-values in the p_tstat1.nii.gz file?
2) What is leading to the difference between versions?
Any advice would be most appreciated,