I recently read your article (Glen et al., 2020). I have a question based on it/check_flip.
I have images that were acquired in RPI orientation (verified with a vitamin E capsule. When I ran align_epi_anat.py, I get the outcome NO_FLIP (using the raw images as input). So far, so good.
However, previously, I had reoriented the mprage and epi images to RAI (as I know that is the afni default) and then deobliqued them. I reoriented them using 3drefit -orient RAI. When I use THESE Images as the input to align_epi_anat.py, the outcome is DO_FLIP.
Could you please explain why this might happen?
Glad the article was of interest!
I think the main thing happening is noting the distinct usage of 2 AFNI programs for adjusting header information and datasets:
- 3dresample is useful when the current header information is correct (in the sense that the data on disk is consistent with the header info), and when you change a header property like orientation, the data also gets changed to stay correct.
- 3drefit is useful when the current header information is incorrect, and you want to change a header property like orientation, and the data will not be changed simultaneously.
As a corollary, if your data starts correct and you change the header property of orientation with 3drefit, then it will change to be incorrect.
If I understand correctly, that is what has happened in your case?
Aside from Paul’s sage advice, another important point is that RAI is not really the “default” in AFNI. There is no default, so you could use any orientation.
Ugh, I had it wrong. I DID use 3dresample to reorient the images. However, as I just tested it and found that the outcome was still DO_FLIP.
One other thing to note is that these are multiband images. Not sure that should make a difference, just letting you know. However, I think the EPI image may have gotten corrupted because it showed up as being in TLRC template space, which is incorrect, so I think we’re probably ok, though I have no idea how the corruption occurred.