Hi,

If you are matching high-resolution structural images from different
subjects with an affine registration, then the result is always poor.
This is partly why the registration accuracy is low and hence you
cannot expect too much - just look at the images and you will see
this.  However, such an affine registration is used in practice as an
initialisation for a non-linear registration, and so it only needs to be
approximate, and within 5mm would be sufficiently good in general
(although your 4.5mm combines two registrations and so is likely to
overestimate the single registration inaccuracy).

Furthermore, what you get from looking at the multiplication of
these matrices is a measure of consistency, not accuracy (although
they are related to some extent).  The default cost function that you
are using is correlation ratio and this is very asymmetric in its
formulation. Consequently, it is expected that it finds a different
registrations each way around to some degree.  The fact that it is
always finding a compromise situation (as the registration cannot
be that good for just an affine) means that this asymmetry tends
to be worse.  However, if you try a different cost function like 
normalised correlation (which is highly appropriate for this kind of
within-modality registration) then it should do much better.  I tried
this for a pair of OASIS images and the difference in registration
discrepancy (measured by how far off the multiplication is from a
perfect identity matrix) went from around 4mm to 0.18mm, which
is certainly a good level, at least for consistency, as the normalised
correlation is a much more symmetric measure of the alignment.
It does not mean that it is likely to be more accurate - just that the
solution it finds one way or the other way are more consistent.  I
suspect that all these registrations are effectively equivalent in terms
of quality, and all would be sufficiently good to run a successful 
non-linear registration.

I hope this clears things up.

All the best,
	Mark


On 14 Jan 2011, at 20:00, Andrew Asman wrote:

> Yes, the brain is extracted prior to registration. 
> 
> I pasted the image information (from MIPAV) for one of the OASIS volumes below. All of the volumes in the data set should have very similar information.
> 
> -Andrew
> 
>                      Image information
> 
> Dimension 0:          256
> Dimension 1:          256
> Dimension 2:          256
> Type:                 Unsigned Byte
> Min:                  0.0
> Max:                  227.0
> Modality:             Unknown Modality
> Slice origin upper left corner of image - right hand rule
>  Origin X (left to right) :         -128.0
>  Origin Y (top to bottom) :         11.0
>  Origin Z:(into the screen):        128.0
>  Origin T:(time):                   0.0
> Orientation:          Coronal 
> X axis orientation:   right to left 
> Y axis orientation:   superior to inferior 
> Z axis orientation:   posterior to anterior 
> Pixel resolution 0:  1.0  Millimeters 
> Pixel resolution 1:  1.0  Millimeters 
> Pixel resolution 2:  1.0  Millimeters 
> Slice thickness:     0.0
> Endianess: Little Endian 
> Matrix: 
>   1.0000  0.0000  0.0000  0.0000  
>   0.0000  1.0000  0.0000  0.0000  
>   0.0000  0.0000  1.0000  0.0000  
>   0.0000  0.0000  0.0000  1.0000  
> 
> 
> 
>                 Other information
> 
> Description = Unknown Modality
> Voxel Offset = 352.0
> Intent code = No intention
> X,Y,Z Coordinate system = Scanner-based anatomical
> Source type = sourceTypeString
> Slope scale = 1.0
> Added offset = 0.0
> Frequency encoding direction = none
> Phase encoding direction = none
> Slice acquisition direction = none
> Axis: x-orientation = Right to Left
> Axis: y-orientation = Superior to Inferior
> Axis: z-orientation = Posterior to Anterior
> X Origin: -128.0
> Y Origin: 11.0
> Z Origin: 128.0
> cal_min = 0.0
> cal_max = 0.0
> Bits per Pixel = 8
> Name or meaning of data = 
> No extended header is present
> Qform Matrix = 
>   1.0000  -0.0000  0.0000  -128.0000  
>   -0.0000  -0.0000  -1.0000  128.0000  
>   -0.0000  -1.0000  -0.0000  128.0000  
>   0.0000  0.0000  0.0000  1.0000  
> 
> On Fri, Jan 14, 2011 at 1:09 PM, Mark Jenkinson <[log in to unmask]> wrote:
> Hi,
> 
> Are you doing brain extraction prior to registration?
> We always recommend this before doing registrations.
> This may be the cause of the problems, especially if
> there is a lot of non-brain material, as FLIRT is optimised
> to work with brain extracted images.
> 
> All the best,
>        Mark
> 
> 
> On 14 Jan 2011, at 18:33, Andrew Asman wrote:
> 
> > Hello,
> >
> > Thanks for the response. The data that I am using is from the OASIS data set:
> >
> > http://www.oasis-brains.org/
> >
> > - The volumes are 1mm isotropic (256x256x256 voxels).
> > - Both the input image and the reference image are from the OASIS data set, thus, they should both be of approximately the same quality.
> > - The flirt command that I am using is fairly straightforward:
> >
> > flirt -in OAS1_0001.nii.gz -ref OAS1_0002.nii.gz -out OAS1_0001_to_OAS1_0002_affine_out.nii.gz -omat OAS1_0001_to_OAS1_0002_affine.txt
> >
> > - As far as I can tell, all images are of solid structural quality. I have used several different combinations of images and I get the reported result in all cases.
> >
> > Thanks,
> > Andrew
> >
> >
> >
> > On Thu, Jan 13, 2011 at 4:12 PM, Mark Jenkinson <[log in to unmask]> wrote:
> > Hi,
> >
> > Your method seems fine - flirt matrices should multiply
> > together in this way.  So this is a surprisingly large error.
> >
> > How big are your voxels?  If they are quite large then
> > this is possible.  Also, if you are running registration with
> > the reference image set to a lower quality image (e.g. an
> > EPI) then the cost functions can be poorly estimated and
> > the registrations can be worse for that.  Also, if there is a
> > lot of distortion (e.g. EPI) then this could cause problems
> > too.  However, if this is on two good quality structural images
> > then it is a bit surprising.
> >
> > Can you provide a bit more information about what kind of
> > images you've used?
> >
> > All the best,
> >        Mark
> >
> >
> > On 13 Jan 2011, at 20:17, Andrew Asman wrote:
> >
> > > I have two affine matrices resulting from two separate calls to flirt. One is used to register a2b and the other b2a. My minimal understanding of registration indicates that the product of these two matrices should be approximately the identity matrix, i.e. if I were to apply a2b and then b2a on 'a' then the result should be very close to the original 'a'. Is there any obvious reason why this should not be the case?
> > >
> > > The result of multiplying the two affine matrices gives the following result ....
> > >
> > >    1.0247    0.0059   -0.0048   -3.2806
> > >   -0.0022    1.0338   -0.0250   -0.4633
> > >    0.0126    0.0338    1.0336   -8.9326
> > >              0              0               0    1.0000
> > >
> > > where the main deviation from the identity matrix is in the 4th column. Note, the two images that I am registering have exactly the same dimensions and voxel resolution.
> > >
> > > I have written MATLAB code to convert the affine matrix to a deformation field and the resulting deformation field exactly matches the output of the 'img2imgcoord -vox ...' utility. Thus, I am confident that I am reading and applying the affine matrix appropriately. If I compose the two resulting deformation fields the mean displacement is about 4.5 mm, which seems a little high for simply applying an a2b then b2a affine transformation.
> > >
> > > -Andrew Asman
> > >
> >
>