I re-ran your registration and it worked fine.
However, I did get the brain in the corner of the image on the
old non-patched version, because of the bug for small voxels
(one or more dims less than 0.5mm). So it looks like your site
hasn't applied the patch that we sent out a couple of months ago.
If you do this then I think the registrations should be fine.
take the appropriate small patch file from
gunzip [your downloaded patch file]
tar xvf [the uncompressed patch file]
All the best,
On 17 Dec 2004, at 07:36, Gaby Pell wrote:
> Hi Mark,
> Thanks for your response on this matter. I am still having problems
> the registration task, as follows. I am simply trying to register the
> large FOV scan to the standard space template and am finding that the
> registration leaves the brain lodged in the bottom left corner.
> the fix you suggest in the FSL FAQ of shifting it with the translation
> matrices does not seem to do the trick.
> Interestingly, a registration with the FSL3.1 version of flirt works
> in this case.
> On Thu, 9 Dec 2004 16:08:38 +0000, Mark Jenkinson <[log in to unmask]>
>> Hi Gaby,
>> The origin, as far as Flirt is concerned, is always in the
>> corner, however Fslview and other programs will report
>> standard space coordinates for images when the appropriate
>> sform (for nifti) or origin (for analyze) is set. Therefore
>> you can't go by what they report.
>> As for getting the COV shift correct, the offsets you
>> calculate seem fine - the only question is which transform
>> are you adding them to? The answer to this depends on
>> what you are doing and why. For instance, if you wanted
>> to create a larger FOV for the output image which had the
>> same coordinate system as the reference, but with some
>> "padding" around the edges, and then keep the COV of the
>> enlarged output at the same point in the object as the
>> COV of the reference image, then adding this shift to the
>> input->reference transformation would be the right thing
>> to do. However, if you wanted the output volume to be
>> different, say in the coordinate system of the input volume,
>> but somehow reoriented and with a new FOV then you'd need
>> something else. I guess that, except for having some padding
>> around the reference space of the standard brain, I'm not
>> sure what you would want to do. If this is what you want to
>> do then I think the following should work:
>> flirt -in invol -ref avg152T1_brain -omat in2avg.mtx
>> emacs in2avg.mtx (and add the offsets to the last column)
>> flirt -in invol -ref bigrefvol -applyxfm -init in2avg.mtx -out
>> If bigrefvol is 250x196x250mm then this should do what you want.
>> If it doesn't, let me know exactly what you've done and what
>> went wrong.
>> All the best,
>> P.S. An alternative to editing the matrix file (in2avg.mtx) is to
>> make a new matrix that just has the offsets and concatenate
>> the two matrices using convert_xfm. This is slightly more complicated
>> (you need to get the order right in convert_xfm) but is much
>> more script-friendly.
>> On 26 Nov 2004, at 07:22, Gaby Pell wrote:
>>> Hi Mark,
>>> I seem to have a problem applying the COV shift to some registered
>>> I am registering a 250x196x250mm volume to the 182x218x182mm standard
>>> brain - so I have added the calculated FOV offsets to the last
>>> x,y,z translation entries (34,-11,34mm respectively). After appplying
>>> modified mat file to the original image, it is still far from being
>>> centred in the image. Am I missing something?
>>> One clue might be that the registered image after the initial
>>> registrations step does not seem to follow the rule you give of
>>> being the origin voxel. In this image, it is only the "upper" and
>>> most parts of the brain that are visible and they are both lodged
>>> this lower left corner.
>>> On Mon, 22 Nov 2004 08:37:04 +0000, Mark Jenkinson
>>> <[log in to unmask]>
>>>> Hi Gaby,
>>>> Sorry not to reply sooner.
>>>> We don't have any scripts written to do this FOV correction
>>>> as we've never used it ourselves. However, all you need to
>>>> do is extract the FOV difference (use avwhd to get the relevant
>>>> sizes) and add/subtract half of this from the last column in
>>>> the registration matrix.
>>>> You could also pad if you like, but the above method is
>>>> probably easier.
>>>> All the best,
>>>> On 16 Nov 2004, at 06:21, Gaby Pell wrote:
>>>>> Hi Mark,
>>>>> Is there anyway to script this process for registration on multiple
>>>>> Another registration option I guess would be take the small FOV
>>>>> image and pad it in such a way as to keep the same voxel size but
>>>>> the FOV? Is this a sensible approach?