Rick, Ziad:
Actually, I'm less concerned with the lack of NN interpolation (though that's interesting to know), that's not the main issue. The main issue is that interpolation of any kind *by itself* generates the wrong answer. I think Rick is getting more toward the issue in his answer, but I'm not sure we have the whole picture here.

Specifically -- supposed you have a volume which is coded with values
0: non-brain
1: Region A
2: Region B
3: Region C
4: Brain, but not of interest

... when rotating the brain, then on the border of Regions A and C you may wind up with interpolated values between 1 and 3, and in particular if the answer is close to 2 and then rounded it's definitely wrong.

So, a better way to do it, conceptually, is for the rotation calculation for each output voxel to look at the input voxels that contribute to this output voxel and note (for example) a 45% contribution from Region A and a 55% contribution from Region C, and call that a win for Region C. (For want of a better term, I call this "voting", and FWIW, some output voxels may get contributions from more than two regions).

If there's a dead heat then pick the answer randomly from the regions that really did contribute.

I *think* that's where Rick is going in the "break into separate briks then rotate" strategy (are we convinced that NN is necessarily the rotation strategy of choice here -- and why would "min" ever be the voting method for recombining -- I think I don't understand Rick or orstat here?) .

I'd add that in separating into separate briks, one for each region value, one needs to set the values of all the separate briks to (for example) 100 for that brik's particular region (and zero elsewhere).

This way all the briks have equal weight, so that after rotation their votes count equally.

OK, so I previously implemented that strategy, with afni functions used up through the rotation, and wrote some code to recombine all the volumes using voting (because I don't understand what orstat does, and I wanted to be absolutely sure I knew what was happening).

But though it gets the job done I regarded that method as pretty poor because of all the intermediate volumes it generates, and the tedious slowness of having to rotate so many volumes separately (we might have dozens of label values, or may not be readily able to detemine label values ahead of time)... so thought I should investigate whether there's a smart-person's way to do this

Thanks,
Graham