I would guess that the starting estimates for the spatial normalization
are not so good. The spatial normalization works by iteratively updating
its estimates of the parameters. In the first iteration, the sum of
squared difference between the images is computed based on the starting
estimates. Then these estimates are changed slightly so as to reduce
the sum of squared difference in the next iteration, and so on.
If the starting estimates are not sufficiently close to the final solution,
then it is very likely that the registration may get caught in a local
minimum. An analagy would be to consider a blindfolded person who is asked
to find the highest point on earth. All the person can do is to continue
climbing uphill. Clearly our intrepid climber would not find the correct
solution from most starting points.
Our climber only has a two dimensional problem to solve. The image
registration is a problem with many more dimensions (beginning with 12
for the affine registration - and going up to many more for the nonlinear
bit).
The starting estimates for the affine part of the spatial normalization
are from two sources:
1) The starting estimates for the affine registration as specified by the
spm_defaults.m file that can be modified by the Defaults button. The
estimates are three translations in millimeters (in x, y and z), followed
by three rotations in radians (pitch, roll and yaw), three zooms (x, y and
z) and finally three shears. By default, the zooms are [-1 1 1], which
causes a left-right flip in the x direction, but no flips in y and z.
Tweeking these starting estimates (possibly by trial and error) can give
you better results.
2) The ".mat" files of the images. If the ".mat" files do not exist, then
the origin and voxel sizes specified in the image headers are used to
generate this information (see spm_matrix.m). Ideally, before you do
anything with the data in SPM96, it is useful to set the values in the
voxel size and origin fields of the header. Voxel sizes are in millimeters
- and represent the distances between the centres of adjascent voxels.
The origin field represents the co-ordinates of a voxel that is somewhere
close to the AC. The first voxel in the image is at [1,1,1].
Once the images have ".mat" files associated with them, then the vox-size and
origin fields in the headers are ignored. This is because much more
information can be described by these mat files - particularly the orientation
of the images. Therefore, if you want to modify the origin field, then you
will have to delete the ".mat" files for the changes to have any effect. When
you delete the ".mat" files, any changes made to them (via realignment or
coregistration) will be lost.
If your images are in a strange orientation, then you may need to modify the
defaults, setting rotations and negative zooms as appropriate. You will also
need to confirm the left-right orientation of your images after spatial
normalization.
Also, if your images have a limited field of view, then it may be advisable to
reduce the number of parameters used for the spatial normalization. Try
turning off the nonlinear part (by setting the number of basis functions to
zero via the Defaulst button). If there are still problems, then try
reducing the number of affine registration parameters, possibly to something
like 9.
The "divide by zero" error is a result of your image and the template image
having no overlapping pixels. From this position, it is not possible for
the registration to achieve a good solution (kind of like our blindfolded
climber falling off a cliff).
Regards,
-John
> does anybody know what a "divide by zero" error means during the
> normalization step of analyzing PET images?
> i have a set of images where the raw data looks good and the realigned
> images look good. however, when i try to normalize, i get an error that
> reads "divide by zero" and the images turn out terribly distorted
> -compacted and smooshed into an oval shape. does anybody know how to fix
> this?
> any advice would be much appreciated.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|