3dWarp changes matrix size?

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;
-prefix dwi_ec_deob.nii.gz …/data.nii.gz


1 5.837 0 128 128 66 60 2.000000 2.000000 2.000000 data.nii.gz
0 0.000 0 134 138 82 60 2.000000 2.000000 2.000000 dwi_ec_deob.nii.gz

(also, what is the column of 60s? It doesn’t seem to belong to n4 or ad3)


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?


Hi pt,

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?


Hi pt, yes we obtained T1, T2 and dwis. I don’t think T2 was used in any step of the process and tbh I’m not sure if dwis were dual phase encoded.

On a related note, I now left out 3dWarp -deoblique and then ran 3dInfo to look at the data necessary for 3dTrackID:

3dinfo \

1 4.159 1 128 128 66 6 2.000000 2.000000 2.000000 DWUncert
1 4.159 1 128 128 66 1 2.000000 2.000000 2.000000 parc5002dwi.nii.gz
1 4.159 1 128 128 66 1 2.000000 2.000000 2.000000 MASK.nii.gz
1 4.159 1 128 128 66 6 2.000000 2.000000 2.000000 3dDWItoDT_DT.nii.gz

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)