Dear Michael,
I am currently working on a more sophisticated solution
that will incorporate this information, but not rely on it.
The reason I don't want to rely on it is the same reason
that we have not made -usesqform the default (which
would already do as you suggest). That reason is that
we still see a non insignificant percentage of images
where things are not correctly set and labelled. Making
people use fslreorient2std forces people to check the
images to make sure that it worked.
The method I am developing now and hope to release
soon, will use the best solution that can be found from
either doing things the way they are now, using this
information and using another process I'm developing in
order to make things more robust.
So hopefully fslreorient2std will become a thing of the
past in the near future! :)
All the best,
Mark
On 13 Jul 2011, at 14:25, Michael Harms wrote:
> Hi Mark,
> Just a quick follow-up related to this thread: In the process of
> registering highres to MNI152, is the orientation of the highres used to
> bring the highres used to bring it into at least approximate initial
> alignment? e.g., If the highres is in say a PSR orientation (common for
> a sagittal acquisition), is that information used to apply the
> appropriate flips/rotations to bring it into the LAS orientation of
> MNI152 prior to beginning to optimize the registration cost function?
> If not (which I think is the case), is there any particular reason that
> step couldn't be incorporated into the registration as a default check,
> since it doesn't seem like having to run fslreorient2std on everything
> should be necessary to get the registration to work robustly.
>
> thanks,
> -MH
>
> On Wed, 2011-07-13 at 14:05 +0100, Mark Jenkinson wrote:
>> Dear Lukasz,
>>
>> I'm glad that it worked. That's a major puzzle solved.
>>
>> As for the original problem, registering sagittal images is more
>> difficult and so it is probably just that a high percentage failed
>> because of this. If the registration worked OK then there is
>> nothing to be gained from redoing it. It is only necessary to
>> fix the ones that failed. However, in future it might be easier
>> just to run fslreorient2std on everything first.
>>
>> In terms of what fslreorient2std does - it keeps all the voxel
>> values *exactly* the same and simply shuffles their order in
>> the file. The resulting file represents *exactly* the same
>> information, just in a different order and thus a different
>> intrinsic orientation, which helps the registration.
>>
>> Hope this helps.
>> All the best,
>> Mark
>>
>>
>> On 13 Jul 2011, at 13:43, SUBSCRIBE FSL lukasz priba wrote:
>>
>>> Dear Mark,
>>>
>>> Thanks for your reply. I had another go at registration of reoriented images and it worked!!!!
>>> I guesss now all I need to do is to apply that to the rest of my images and re-do the segmentation.
>>>
>>> With reference to he problem I had I'd like to ask few questions:
>>>
>>> Does fslreorient2std change my images-do I get the same ''volume'' back?
>>> I'm still not quite sure why 11 of my sagittal images were fine but 9 were a bit dodgy. Was the registation problem due to the orientation of my images or was it something else?
>>> Should I re-do my segementation on the entire sagittal data set (with preprocessing using flsreorient2std on all sagittal data) for sake of consistency in my results.
>>>
>>> cheers,
>>> Lukasz
>>>
>
|