3dresample/3drefit/3dWarp for oblique datasets and slice timing

AFNI Message Board
1

Hi Afni Experts,
I have a dataset collected at an oblique angle (RPI). When using 3dresample -orient LPI the header shows that the angle is now plumb using 3dinfo. Similarly if I use the 3drefit -deoblique command the dataset is now plumb but in the original RPI orientation when using 3dinfo. However when I use 3dWarp -deoblique the dataset appears in the viewer oblique (similar most likely to the actual acquisition) and now plumb in the RPI orientation according to 3dinfo.

  1. In terms of the 3dresample is it essentially performing a similar process to 3drefit in which the data is not moved, but the information of the oblique angle is removed from the fileheader in addition to switching the coordinates to LPI (from RPI)?

  2. Using 3dresample in this manner on the input dataset, is the slice timing information still preserved for slice timing correction or could this potentially cause issues and it is better to use 3dresample (or one of these other options )downstream after pre-processing with afni_proc.py? Or should this be performed directly after slice timing correction? If so, which of these tools is recommended?

Thanks,
Ajay

2

These are all quite different operations.

  1. 3drefit is not changing the data at all, just removing information from the header. This shouldn’t have any effect on the slice timing.
  2. 3dresample -orient LPI. This also loses the oblique information, but more importantly changes the definition of what a slice is (the 3rd dimension ‘k’) and if you include voxel resolutions or grids potentially introduces interpolation. This will make slice timing correction wrong unless your data is LPI in the first place.
  3. 3dWarp - either of the obliquity options will change the oblique angle of the dataset and alter the data. Again slice timing correction will not be possible and wrong if used.

For more info on oblique datasets, see this link:

https://afni.nimh.nih.gov/sscc/dglen/Obliquity

3

Hi Daniel,
Thanks for the link and info. The reason why I was asking is that the MNI template is LPI, the anatomical for this study is RAI (oblique angle after some preprocessing), and the resting state for this study is RAI (different oblique angle). I have also had analyses where the anatomical and functional are not in the same orientation as well as different oblique angles so I wanted to make sure my pipeline is flexible to handle all cases of orientations and oblique angle differences when moving to using afni_proc.py. I wanted my resting state and my aligned2EPI anatomical scan to be in LPI format to match the MNI template, although this may be unnecessary based on how AFNI handles things internally.

Overall I align the anatomical to a resting state EPI reference volume (3dresample -orient LPI for single reference) and then warp the anatomical to MNI. I was looking to test afni_proc.py. My question is I do not think there is a block where I can do despike, slice time, 3dresample (orient to LPI) and then volreg, smoothing regress. The reason why I want to orient to LPI is that down the line I may want to incorporate a fieldmap or other distortion correction and then simultaneously combine my motion correction, distortion correction and warp to MNI in one step (minimize interpolation). If volreg or the volume is in RAI (assuming no 3dresample/3dWarp/3drefit -deoblique -orient), the filedmap is RAI (collected same as EPI), the warp to MNI is LPI (anatomical after alignment to LPI reference EPI volume) to LPI (MNIj template), would this all be handled within AFNI or would it be better to make sure they are all in LPI space to ensure no issues of concatenation for all options down the line. Since each study has a different orientation, and oblique vs axial cut, I want this to be as flexible as possible to handle all cases.

Is this unnecessary to deal with the various orientation and obliquity differences between anatomical/EPI and MNI templates because this is all natively handled by AFNI in all of these cases or if it is better the way I proposed of using 3dresample -orient LPI after slicetiming?

Is there an easy way to introduce 3dresample into afni_proc.py after slice timing or just use an empty block and then after the script is generated, fix that block?

Thanks,
Ajay

4

Hi Afni Experts
I wanted to follow up regarding my previous question.

  1. If my anatomical file (already rigidly aligned to resting state scan) is RPI and warped to an LPI MNI template, is it necessary to first use 3dResample -orient LPI on my anatomical scan to match the MNI template or does it not matter (i.e. AFNI deals with those differences automatically)?

  2. If I apply that transform to warp my resting state scan to MNI, does it matter if my Resting state scan is starting off as RAI (instead of the anatomical RPI) or would I need to first run 3dResample -orient to convert it to RPI (to match the anatomical scan) or LPI to match the final MNI template?

Thanks
Ajay

5

Hi Ajay,

  1. No, that alignment should work fine.

  2. No, 3dAllineate will apply that xyz to xyz transformation
    correctly, regardless of the orientaion. You can verify
    this by bouncing between the anat and EPI in orig space
    (e.g. with ‘u’) at some location, and then doing the same
    thing in standard space, and seeing that they align in a
    similar way in each view (of course, at the same brain
    location the coordinates will differ).

  • rick
6

Thanks Rick.

Does this hold true for all AFNI warping/alignment tools such as concatenation of 3dvolreg (RAI) with 3dAllineate (LPI) and 3dQwarp (LPI)? I am assuming so based on your previous email it I just wanted to verify. Or it may be better to say is there any AFNI tools (including DTI/rotate bvecs etc) where this is not the case?

Thanks,
Ajay

7

Not sure why you have the RAI/LPI next to the different programs, but the transformation matrices are defined independently of the storage order of the datasets generally. Programs that save or apply transformation matrices use the xyz coordinates in RAI order. The only exception I can think of is the application of obliquity transformation matrices defined for ijk storage order to xyz RAI order, as in the IJK_TO_DICOM_REAL attribute in the AFNI header.

8

Hi Daniel,
Thank you very much for your help. I wanted to make sure I was not overlooking something simple such as ensuring the resting state and anatomical having to be in the same storage order for the transforms to be valid, as this was not the case for all of the scans I am looking at. Based on the fact that the transform and storage order are handled separately, this should not be an issue moving forward.

Thanks,
Ajay