Hi, @zhengchencai :
Thanks for the version info. That is uptodate; some changes had been made prior to that to speed it up for the QC images.
To Q1 above: for the majority of volumetric FMRI processing, users want the EPI data to end up either in participant's own anatomical dataset space (like, the reference T1w anatomical) or in a template. (A differing case not discussed here is where the input EPI grid is desired to be the final space+grid for the FMRI data, like for some high-res acquisitions; we leave that for a different thread.) When wanting to use the participant anatomical or template to define a final space, then what we would like to do when the anatomical has obliquity is:
- remove the obliquity from the anatomical without blurring it;
- retain overlap with the EPI, without blurring the EPI either, which can be done by moving over the removed obliquity to the EPI
This is what obliquity_remover.py will do; furthermore, "EPI" can refer to multiple EPI runs simultaneously, whether the main FMRI dsets or the blip up/down partners (or phase datasets) that are on the same grids as the main EPI.
So, the answer to your Q1 is: yes.
Q2: The obliquity_remover.py program also saves out the oblique affine transformation piece that was removed from the anatomical, and saves it to a separate file to be able to apply it again later, should the need arise. Details below.
Details of applying affine after obliquity_remover.py
Setup: Let's say your input anatomical that has obliquity is called AAA.nii.gz.
To remove the obliquity (ignoring child dsets for a moment), you could create dataset BBB.nii.gz (which is not regridded, and shares the same coordinate origin as AAA.nii.gz):
obliquity_remover.py -prefix BBB.nii.gz -inset AAA.nii.gz
... which also creates two files containing the removed obliquity itself, stored as affine matrices:
BBB_mat.aff12.1D and BBB_mat_INV.aff12.1D. The latter is just the inverse of the former.
To see where the data in AAA would actually sit in scanner space when obliquity is applied, you could create the dataset CCC.nii.gz (which will be regridded during the application of the obliquity, and therefore blurred a bit):
3dWarp -deoblique -prefix CCC.nii.gz AAA.nii.gz
Applying matrices from obliquity_remover.py:
First, if you want to take the dataset from which you purged obliquity (BBB.nii.gz) and send it to the location where would be if that purged obliquity were applied, you could do this to create a new dset DDD.nii.gz:
3dAllineate \
-1Dmatrix_apply BBB_mat.aff12.1D \
-source BBB.nii.gz \
-prefix DDD.nii.gz
After this, you could overlay DDD.nii.gz on CCC.nii.gz, and they should have effectively the same overlap. Neither CCC.nii.gz nor DDD.nii.gz has any obliquity in their headers, and each will have undergone some blurring during the regridding process by which an oblique (=rotational) matrix was applied. It is possible that DDD.nii.gz will be slightly cut off/truncated, depending on the tightness of the original FOV and obliquity details. Also, CCC.nii.gz and DDD.nii.gz might have slightly different values at each voxel, depending on the interpolation kernels used during the regridding. But there you go.
Second, if you want to create a new dset from BBB.nii.gz that actually has its full obliquity again, you can do the following to create EEE.nii.gz. What we are doing is re-calculating the AFNI header attribute, IJK_TO_DICOM_REAL. So, you can take that attribute from BBB.nii.gz and append to it the BBB_mat_INV.aff12.1D matrix (NB: this is the _INV one) and save it to a text file:
cat_matvec -ONELINE \
BBB.nii.gz::IJK_TO_DICOM_REAL BBB_mat_INV.aff12.1D \
> BBB_full_mat.1D
Then, you can use 3drefit to update this attribute in dset. Since 3drefit overwrites header info in place, let's make a copy and edit the attribute there, in case we make a mistake or something:
3dcopy BBB.nii.gz EEE.nii.gz
3drefit \
-atrfloat IJK_TO_DICOM_REAL BBB_full_mat.1D \
EEE.nii.gz
After that, AAA.nii.gz and EEE.nii.gz should have the same grid setups and the same obliquity values. In fact, running this should show all 1s:
3dinfo -same_all_grid AAA.nii.gz EEE.nii.gz`
meaning all grid attributes, including obliquity, are the same. Note that AAA.nii.gz and EEE.nii.gz should also have the same voxelwise values, as EEE.nii.gz was never interpolated, it just went through a series of header changes: first purging obliquity to create BBB.nii.gz, and then re-inserting an oblique matrix to create EEE.nii.gz.
I will add this kind of info to the obliquity_remover.py help file, so it becomes long enough that no one will read it.
--pt