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?