AFNI Message Board

Dear AFNI users-

We are very pleased to announce that the new AFNI Message Board framework is up! Please join us at:

https://discuss.afni.nimh.nih.gov

Existing user accounts have been migrated, so returning users can login by requesting a password reset. New users can create accounts, as well, through a standard account creation process. Please note that these setup emails might initially go to spam folders (esp. for NIH users!), so please check those locations in the beginning.

The current Message Board discussion threads have been migrated to the new framework. The current Message Board will remain visible, but read-only, for a little while.

Sincerely, AFNI HQ

History of AFNI updates  

|
August 26, 2004 02:01PM
1. -delta and -x_thresh: Qualitatively, what do they do. What range of numbers is useful (maybe relative to particular voxel size?) and what effect does adjustment in each direction have?

The algorithm used in 3dvolreg matches the base image J(x) to each target image I(x), separately (here, x is a 3-vector). The goal is to compute the 6 parameters p of the spatial rotation+shift T[x;p] such that I(T[x;p]) is close to J(x) in the least squares sense. To do this rapidly (one the hallmarks of AFNI), the program actually computes the inverse transformation to T[x;p] -- call this U[x;p] -- so that J(U[x;p]) is close to I(x). It then operates by expanding J(U[x;p]) in a 2 term McLaurin series for small p. The derivatives of J(U[x;p]) with respect to each component of p are computed by actually rotating/shifting J by the amount specified by the -delta option, then using finite differences to approximate the derivatives. You can imagine this as the distance that the program "reaches out" in parameter space to search for better matches between I and J. The default value is 0.7. For normal EPI alignment, this works well, since the usual amount of motion is small, so we don't have to reach out so far to make a better match (a 2 voxel shift would require 3 "reaches"). For SPGR alignment (which usually requires finding larger values of the p parameters), this results in a relatively slow algorithm; for this purpose, the -twopass option was layered on top to speed things up, where the first pass is done with a larger -delta value (in combination with using blurred I(x) and J(x) images) and the final (second) pass with the standard one.

-x_thresh and -rot_thresh determine the point at which the iterative search in p-space stops -- when the stepsizes in the translational parts of p are all less than -x_thresh and the stepsizes in the rotational parts of p are all less than -rot_thresh. The units are voxel-sizes and degrees, respectively. This is convenient for MRI of the head, since the head is usually 50-200 voxels across, so a 1 degree rotation is on the same order as a 1 voxel-size motion (since 1 degree is about 1/60-th of a radian). The default values are 0.02 voxel-sizes and 0.03 degrees, which are again accurate enough for most FMRI purposes, considering the amount of noise in typical images (IMHO). However, if you are carrying out simulations with a very low noise level, you need to reduce these defaults to get the full accuracy possible.

2. Edges: Qualitatively, what does 3dvolreg do with the edges of the volume (or the box defined with -edging)? How is it that the edges of the box don't become the most salient feature for alignment?

The edges of the box would become vastly important, if they occured in a region that had a high weighting. However, you should choose an edging size just to clip off the outer periphery of the volume, not any actual tissue (so that ghosts and other artifacts in the "air" are excised). The fitting of J(U[x;p]) to I(x) is done with a weighted least squares approach, where the default weight w(x) is a smoothed copy of J(x) (and then values below 2.5% of the max are set to zero). Using J(x) as the weight means that the noise in the air region won't count for matching, since it will have low weight. Smoothing J(x) means that the edges of the brain and the region immediately outside them will get some non-trivial weight. The effect is that regions of J(x) with high intensity and high gradients will count the most in the registration algorithm.

The real reason edging was introduced was when -twopass was added for registering inter-day SPGRs, I ran into problems with some image artifacts at the edge of the 3D volume (way out in the "air"). On the particular scanner we had at that time, these few bright points sometimes appeared and sometimes not, depending on the subject's head placement in the RF and gradient coil, and they caused problems with registration.

By the way, edging is implemented simply by setting the weight w(x) to 0 in the "edged" regions.

3. ... is there a way to extract the weighting values employed by default by 3dvolreg?

Not at this time. If you really want, I suppose some option to that effect could be created. The -weight option was put in there (like a lot of the other options) for my own experimentation -- back in 1998, when the program was instantiated.

Historically, 3dvolreg was an afterthought. The original purpose of the algorithm was to go in the AFNI realtime FMRI plugin -- the goal was to do volume registration of EPI data at least as fast as 3D acquisitions. On the computer we had at that time (mid-1998), the FFT-based interpolation wasn't quite fast enough to keep up with realtime (see the paper for a table). Hence the polynomial interpolation options -- I was searching for the best interpolation that could keep up with 10 128x128 images per second. I personally am fondest of the "heptic" interpolation (7th order polynomial), partly because one so seldom gets to use this word.

bob cox

P.S.:
Sorry for taking so long to respond. I'm getting kind of tired of the message board. I've been doing it for over 5 years now, and it's starting to wear.

Subject Author Posted

3dvolreg: Hoping for answers...

Graham Wideman August 23, 2004 03:52PM

Re: 3dvolreg: Hoping for answers...

rick reynolds August 23, 2004 04:58PM

Re: 3dvolreg: Hoping for answers...

Graham Wideman August 24, 2004 12:07AM

Re: 3dvolreg: Hoping for answers...

Rich Hammett August 24, 2004 03:35PM

Re: 3dvolreg: Hoping for answers...

Graham Wideman August 24, 2004 07:11PM

Re: 3dvolreg: Hoping for answers...

Robert Cox August 26, 2004 02:01PM

Re: 3dvolreg: Hoping for answers...

Graham Wideman August 26, 2004 06:03PM