AFNI file: README.volreg
Using 3dvolreg and 3drotate to Align Intra-Subject Inter-Session Datasets
=========================================================================
When you study the same subject on different days, to compare the datasets
gathered in different sessions, it is first necessary to align the volume
images. This note discusses the practical difficulties posed by this
problem, and the AFNI solution.
The difficulties include:
(A) Subject's head will be positioned differently in the scanner -- both
in location and orientation.
(B) Low resolution echo-planar images are harder to re-align accurately
that high resolution SPGR images, when the subject's head is rotated.
(C) Anatomical coverage of the slices will be different, meaning that
exact overlap of the data from two sessions may not be possible.
(D) The anatomical relationship between the EPI and SPGR (MP-RAGE, etc.)
images may be different on different days.
(E) The coordinates in the scanner used for the two scanning sessions
may be different (e.g., slice coverage from 40I to 50S on one day,
and from 30I to 60S on another).
(B-D) imply that simply using 3dvolreg to align the EPI data from session 2
with EPI data from session 1 won't work well. 3dvolreg's calculations are
based on matching voxel data, but if the images don't cover the same
part of the brain fully, they won't register well.
The AFNI solution is to register the SPGR images from session 2 to session 1,
to use this transformation to move the EPI data from session 2 in the same
way. The use of the SPGR images as the "parents" gets around difficulty (B),
and is consistent with the extant AFNI processing philosophy. The SPGR
alignment procedure specifically ignores the data at the edges of the bricks,
so that small (5%) mismatches in anatomical coverage shouldn't be important.
(This also helps eliminate problems with various artifacts that occur at the
edges of images.)
Problem (C) is addressed by zero-padding the EPI datasets in the slice-
direction. In this way, if the EPI data from session 2 covers a somewhat
different patch of brain than from session 1, the bricks can still be made
to overlap, as long as the zero-padding is large enough to accommodate the
required data shifts. Zero-padding can be done in one of 3 ways:
(1) At dataset assembly time, in to3d (using the -zpad option); or
(2) At any later time, using the program 3dZeropad; or
(3) By 3drotate (using -gridparent with a previously zero-padded dataset).
Suppose that you have the following 4 datasets:
S1 = SPGR from session 1 E1 = EPI from session 1
S2 = SPGR from session 2 E2 = EPI from session 2
Then the following commands will create datasets registered from session 2
into alignment with session 1:
3dvolreg -twopass -twodup -heptic -clipit -base S1+orig \
-prefix S2reg S2+orig
3drotate -heptic -clipit -rotparent S2reg+orig -gridparent E1+orig \
-prefix E2reg E2+orig
You may want to create the datasets E1 and E2 using the -zpad option to
to3d, so that they have some buffer space on either side to allow for
mismatches in anatomical coverage in the slice direction. Note that
the use of the "-gridparent" option to 3drotate implies that the output
dataset E2reg will be sampled to the same grid as dataset E1. If needed,
E2reg will be zeropadded in the slice-direction to make it have the same
size as E1.
If you want to zeropad a dataset after creation, this can be done using
a command line like:
3dZeropad -prefix E1pad -z 2 E1+orig
which will add 2 slices of zeros to each slice-direction face of each
sub-brick of dataset E1, and write the results to dataset E1pad.
*****************************************************************************
Registration Information Stored in Output Dataset Header by 3dvolreg
=====================================================================
The following attributes are stored in the header of the new dataset:
VOLREG_ROTCOM_NUM = number of sub-bricks registered
(1 int) [may differ from number of sub-bricks in dataset]
[if "3dTcat -glueto" is used later to add images]
VOLREG_ROTCOM_xxxxxx = the string that would be input to 3drotate to
(string) describe the operation, as in
-rotate 1.000I 2.000R 3.000A -ashift 0.100S 0.200L 0.300P
[xxxxxx = printf("%06d",n); n=0 to ROTCOM_NUM-1]
VOLREG_MATVEC_xxxxxx = the 3x3 matrix and 3 vector of the transformation
(12 floats) generated by the above 3drotate parameters; if
U is the matrix and v the vector, then they are
stored in the order
u11 u12 u13 v1
u21 u22 u23 v2
u31 u32 u33 v3
If extracted from the header and stored in a file
in just this way (3 rows of 4 numbers), then that
file can be used as input to "3drotate -matvec_dicom"
to specify the rotation/translation.
VOLREG_CENTER_OLD = Dicom order coordinates of the center of the input
(3 floats) dataset (about which the rotation takes place).
VOLREG_CENTER_BASE = Dicom order coordinates of the center of the base
(3 floats) dataset.
VOLREG_BASE_IDCODE = Dataset idcode for base dataset.
(string)
VOLREG_BASE_NAME = Dataset .HEAD filename for base dataset.
(string)
These attributes can be extracted in a shell script using the program
3dAttribute, as in the csh example:
set rcom = `3dAttribute VOLREG_ROTCOM_000000 Xreg+orig`
3drotate $rcom -heptic -clipit -prefix Yreg Y+orig
which would apply the same rotation/translation to dataset Y+orig as was
used to produce sub-brick #0 of dataset Xreg+orig.
To see all these attributes, one could execute
3dAttribute -all Xreg+orig | grep VOLREG
*****************************************************************************
Robert W Cox - 07 Feb 2001
National Institutes of Mental Health
rwcox@codon.nih.gov
This page auto-generated on
Tue Dec 17 06:56:54 PM EST 2024