Thanks for your response on this matter. I am still having problems with
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. However,
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 fine
in this case.
On Thu, 9 Dec 2004 16:08:38 +0000, Mark Jenkinson <[log in to unmask]>
>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 in2big
>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
>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
>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 column's
>> 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 (0,0,0)
>> 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 into
>> 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?