This is still a bit under investigation, but the issue appears to be that the R script didn't propagate header information when making the output dset. So, instead of applying 3dresample immediately, 3drefit should have been applied to fix the header information.
Note that 3dresample is typically used when the header and data information match each other. Then, 3dresample is used to adjust the header information, while also adapting the data information to be consistent with the new header and also correct.
3drefit is typically used when a piece of header information is known to be incorrect, and so it should be changed *and the data is not accompanyingly changed*. Also, 3drefit does *not* produce a new dset (3dresample does, via the "-prefix .." option), so we would typically recommend copying the dset in question first, and putting the copy through 3drefit. In case something goes wrong or you decide you are unhappy with that change, you have the untouched original still.
So, if I started with a dset with LAI information, then:
+ "3dresample -orient RAI ..." would lead to a new dset that would still match exactly with the original dset in the viewer---if I overlay the new RAI one on the old LAI one, all features line up still between them.
+ "3dcopy .. .. ; 3drefit -orient RAI ..." would lead to a new dset that does *not* generally match the original in the viewer (assuming the left and right are not exactly symmetric). If I overlay the new RAI one on the old LAI one, the features will *not* line up between them.
When created new dsets in Matlab, R, Python, etc. one should always be very careful about what header information gets propagated, and how---it is very tricky and requires a lot of verification. Using packaged software when possible, which should manage both data and header aspects consistently, is often safer to use.
This is also another reason why visualizing the data during intermediate steps is so important---noticing that the new brain here was tiny was key to noting an issue occurred. If the data had just been thresholded and only looked at at output time, for example, in some cases such problems can be hidden. So, great to notice this issue, and now it is just a matter of tracking where/why it occurs in the R script, and how to re-set things appropriately afterward.
--pt
