I’m analyzing a few datasets, one of which has an oblique anat and epi and a diff dataset w/non-oblique anat and oblique epi. Trying to understand how 3dWarp figures into the afni.proc script generation and had a few questions:
Prior to generating the afni proc scripts with a diff script, I’m running a FS subcortical parcellation (recon-all -autorecon1) which generates anat.nii.gz file, which is what I’m using as anatomical input for the afni proc script. My understanding is that it doesn’t matter with that script if the image is oblique going in and that it gets resliced and diced and comes out as non-oblique. Just want to confirm that this is the case.
If #1 is true above then I have an anat that’s no longer oblique, but my epi in one of the studies is still oblique at the point - hence I get errors suggesting I run 3dWarp -deoblique as I generate the afni proc script. My questions about this are:
a) If I put in the oblique epi and then add the 3dWarp -deoblique into my model afni proc script that is used to generate the afni proc for multiple subs, where does it go in the order of commands?
b) If I also do nonlinear warping during the single sub afni proc script does that become affected at all by 3dWarp? Just trying to understand how 3dWarp “warps” the data, or if it’s more of an affine transformation.
c) If I stick this command (3dWarp) in the script will it use the output of the script (which I think is tagged as “warped” by my having run it in command line) to feed into the rest of the afni proc script?
Thanks in advance for any help that you might be able to give me in this matter.
OK, you may not have to do anything to handle obliquity here. There are no “errors” reported, only “warnings”, just for you to be aware that you are working with oblique datasets. So it’s likely you don’t have to do anything about it really. If your anatomical dataset is cardinal, there is no issue here really. The FreeSurfer output is also cardinal. If your anatomical dataset is oblique, then there might be something to do, but I haven’t seen that myself. Check the output from Freesurfer with 3dinfo to see if it is marked as oblique. You could reapply the oblique information with this command for each of the volumetric datasets including parcellation that share the same grid as the original :
3drefit -atrcopy IJK_TO_DICOM_REAL my_orig_anat+orig brain.nii
In any case, you will have to check your output for alignment of the EPI with the anatomical dataset and the anatomical dataset with the reference template if you are using one.
Adding in 3dWarp commands will introduce more interpolation and smoothing into your results. In some cases, it doesn’t matter if the anatomical dataset has an extra interpolation, and you may want to cardinalize it or remove the obliquity information from the header as an initial step. You can use 3dWarp to cardinalize the data or 3drefit to remove the obliquity from the header. If you do either, you will probably also want to allow for larger movement in the alignment between anatomical and EPI data using the “-giant_move” or “-ginormous_move” options for align_epi_anat.py. 3dWarp is useful for checking if the obliquity information is correct, but you typically won’t have to use it unless you run into alignment problems.
One thing to keep in mind, as long as we’re talking about FreeSurfer is the reminder that FS recon-all slightly moves volumes that have an odd number of voxels in any direction. This doesn’t appear to be widely known, but it introduces a slight misalignment unless you then align that volume to your experimental data with @SUMA_AlignToExperiment. There are several things to consider that are described in these two previous posts: