 |
 |
Thank you very much for all of your help! Your explanation makes perfect sense. Thanks again, Andrew On Fri, Jan 14, 2011 at 6:33 PM, Mark Jenkinson <[log in to unmask]> wrote: > 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 > > > > > > > > > >