Print

Print


Hi Gaby,

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.

Re patches:
take the appropriate small patch file from
http://www.fmrib.ox.ac.uk/fsldownloads/patches/3.2
and then:
cd $FSLDIR/..
gunzip [your downloaded patch file]
tar xvf [the uncompressed patch file]

All the best,
        Mark


On 17 Dec 2004, at 07:36, Gaby Pell wrote:

> Hi Mark,
>
> 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.
>
> Thanks,
>
> Gaby
>
> On Thu, 9 Dec 2004 16:08:38 +0000, Mark Jenkinson <[log in to unmask]>
> wrote:
>
>> 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
>> 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
>> went wrong.
>>
>> All the best,
>>        Mark
>>
>> 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
>>> images.
>>> 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
>>> the
>>> 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
>>> "right"-
>>> most parts of the brain that are visible and they are both lodged
>>> into
>>> this lower left corner.
>>>
>>> Thanks,
>>>
>>> Gaby
>>>
>>> On Mon, 22 Nov 2004 08:37:04 +0000, Mark Jenkinson
>>> <[log in to unmask]>
>>> wrote:
>>>
>>>> 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,
>>>>        Mark
>>>>
>>>>
>>>>
>>>> On 16 Nov 2004, at 06:21, Gaby Pell wrote:
>>>>
>>>>> Hi Mark,
>>>>>
>>>>> Is there anyway to script this process for registration on multiple
>>>>> volumes?
>>>>> Another registration option I guess would be take the small FOV
>>>>> reference
>>>>> image and pad it in such a way as to keep the same voxel size but
>>>>> increase
>>>>> the FOV? Is this a sensible approach?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gaby