Hi Paul,

I think I know what happened.

I did not split the file, it had been split by ARM/NMT creators. The split versions are registered with AFNI as single-subbrick "ARM Level x" atlases, along with the full 6-subbrick "ARM". Probably to facilitate subbrick selection which - as we have found out - does not seem to work in standard way with whereami.

But here is the actual reason which, as Daniel suggested, was caused by resampling.

NMT2.1 and ARM come in three versions which differ in resolution and/or FOV. The version that registers with afni by running a script provided with NMT/ARM and is consequently used by whereami, is different from the one I was using as the basis of the alignment and then as the atlas. The script registers the large-FOV/0.25 mm version while I am using the tight-FOV/0.5 mm version.

So "my" whereami was resampling my cluster to match the high-res/large FOV version, while the Matlab script directly used the low-res/tight FOV version, also the version whose grid had been imposed on the data. My step-by-step process also explicitly used the low-res version. And you probably registered the 0.5 mm version that I sent you with your AFNI, and your whereami was using it.

Thank you for your help and patience! The good news is that my Matlab script is accurate - ensuring that was the only reason why I compared it to whereami. I will have to use it instead of whereami because I need the percentages of atlas ROIs intersecting with my ROIs, not the other way around.