Jesper,
if the back transformation computed by FNIRT in the first place is
fine, then I don't really need to bother with invwarp, no?
I could script the back-warp of the OxfHarv mask for each subject with
`applywarp`, e.g.
applywarp --ref=example_func_sub1run1 --in=OxfrHarv_ROI
--warp=sub1run1.feat/reg/standard2example_func.m --out=sub1run1_ROI
--interp=nn
and then run Featquey using as mask the output of the above command.
would this not be a faster strategy?
thanks for the help
martin
Jesper Andersson wrote:
> Dear Martin,
>
>> thank you for the input. However, considering that I'm going back
>> from the the HarvOxf mask (in MNI space), I'm not sure I see how to
>> reduce the FOV to speed things up.
>
> the important thing here is the FOV of the structural that was used as
> input to fnirt, i.e. your individual subjects structural. Quite often
> these are acquired with large margins, in particular in the
> z-direction. If one uses fslroi to prune it a little prior to putting
> it into Feat invwarp will run faster.
>
>> But, am I then condemned to wait up..? Alternatively I could re run
>> my first levels using FLIRT..
>
> That would be another option.
>
>> Jesper, one thing though. Are you saying that the
>> standard2example_func in the reg folder created by FNIRT would not be
>> a satisfactory transformation?
>
> No. What made you think I did?
>
> Jesper
>
>>
>> best
>>
>> martin
>>
>> On Tue, Jun 16, 2009 at 10:12 AM, Jesper Andersson
>> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>>
>> Dear Martin and Stéphane,
>>
>>
>> invwarp used to take as much as 40 hours on a dual core
>> machine with large f.ov. images... You can speed things up by
>> reducing the f.o.v. of your image if it is much larger than
>> the MNI template, and also by downsampling the resolution of
>> your highres anatomical.
>>
>>
>> it is true that invwarp will sometimes take an exceedingly long
>> time to run. We don't have a really good explanation yet for why
>> this sometimes happens, but we're working on it.
>>
>> Meanwhile your suggestions about FOV and resolution are very
>> sensible.
>>
>>
>> I think I read that a future version of FSL might contain a
>> config file for FNIRT to avoid using invwarp but instead do a
>> new registration from standard to highres space - is that
>> right, anyone?
>>
>>
>> The registration as implemented in FNIRT is inherently
>> non-symmetric since we are using the derivatives from one of the
>> images only. Hence, in general, B->fnirt->A will not yield
>> exactly the inverse of A->fnirt->B. I would therefore be quite
>> unhappy with that solution. So I'd much prefer that we manage to
>> speed up invwarp.
>>
>> Jesper
>>
>>
>
|