Hello, I realized that some of our diffusion data are oblique, therefore I used 3dWarp to deoblique. I then checked the output using 3dinfo. While the angle from plumb is now 0, it appears that the matrix size has changed. It would be helpful if someone could explain why this happened and confirm whether this should be fixed. Thanks!
Below I pasted the input commands of 3dWarp and 3dInfo and also the output of 3dInfo.
cd SPN01_ZHP_0060_01/afni;
3dWarp
-deoblique
-prefix dwi_ec_deob.nii.gz …/data.nii.gz
-overwrite
Can I ask what your aim is for this DWIs? Having obliquity means that the matrix mapping your data to physical coordinate space is rotated relative to the original scanner coords. We can’t rotate the image display rectangle in the GUI to match that, so we would have some choices:
create a new data set by applying the obliquity (“3dWarp -deoblique …” does this), which means that the dataset is re-gridded, and hence interpolated/smoothed a bit; after this, the dset appears in its scanner coordinates.
ignore or purge the obliquity (“3drefit -deoblique …” purges that rotation info from the dset; the GUI just ignores it), which means that the dataset is NOT re-gridded, so not smoothed/interpolated, and the dset appears in a different set of coordinates that the scanner’s, most “as if” the subject’s head hadn’t been at an odd angle to the scanner coords to begin with. NB: when going this approach with 3drefit, you should copy the data and then run 3drefit on the copy, in order to keep the original information if you ever do decide you need it (3drefit changes header info; it doesn’t make a new dset).
Using the first one (with 3dWarp) can lead to getting a new FOV. But as a big downside, the data gets smoothed a bit by being regridded. Are you sure you really need to apply the obliquity?
The reason I applied 3dWarp -deoblique is because I believe the dwi is oblique. A few weeks ago you asked me to check that the data used for 3dTrackID are on the same grid using 3dInfo (because I was encountering an error when running 3dTrackID). 3dInfo revealed that data weren’t on the same grid (see our thread https://afni.nimh.nih.gov/afni/community/board/read.php?1,164744,164897#msg-164897).
Basically, for some subjects, the angle from plumb for dwi is 6.6 whereas T1 is at 0 degrees. I was under the impression that I would need to change the dwi angle to 0 before transforming the T1 parcellation into diffusion space.
Well, the obliquity is just one part of the story; there are several ways to deal with data on different grids, but this one will add unnecessary smoothing to the data (and probably not make grids the same, either).
Can you please remind me what data you are starting with? Do you have a T1w volume, a T2w volume, DWIs (are they dual phase encoded?) and anything else?
At least now everything is on the same grid. Would it then be ok that there is obliquity since they all reflect the same degree from plumb? What is the 7th column, which seems to be the only difference? (6 vs 1)
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.