Hi - I would not use the 5th dimension as this is not yet fully
supported in most implementations of NIFTI - I would find a
workaround for that and re-test.
Cheers.
On 26 Jul 2007, at 11:11, Alle Meije Wink wrote:
> Hi -thanks for the quick reply!
>
> What I saw (with linear interpolation earlier, I thought sinc would be
> better for the real analysis) was that also took very long. I thought
> that something was happening outside just resampling.
>
> In the analysis there are some 4D files of 10 volumes -actually
> they are
> 5D, because they are not time series so we put everything in dim[5]-
> which are in <double> format. So they are quite big...
>
> But then, I assume that files are resampled on a 3D (volume by volume)
> basis? Why would it be necessary then to load the whole series of
> volume
> into the memory?
>
> My computer has 2 G of memory, so 91*109*91*8*10 = 72210320 = 69 M
> should not be a problem?
>
> I'll have another test with trilinear interpolation to see what that
> does to the speed. I'm afraid about what it will do to the quality
> though...
>
> I have written B-spline interpolation code before (whose interpolants
> for degrees >2 are almost sinc functions) and that didn't seem to
> suffer
> from increasing the degree that much. Are you sure this is what
> makes it
> so slow?
>
> Thanks!
> Alle Meije
>
> Steve Smith wrote:
>> Hi - I would have expected changing the interpolation to have a large
>> effect. It is possible instead that applying flirt to the 4D
>> dataset is
>> slow because doing that all in one is requiring too much RAM and your
>> computer is doing lots of swapping - in which case I would recommend
>> using avwsplit to split it down to 3D files, applying the
>> transform with
>> flirt, and then recombining with avwmerge.
>>
>> Cheers.
>
>> On 26 Jul 2007, at 10:41, Alle Meije Wink wrote:
>>> Hi,
>>>
>>> I am using flirt for standard space mapping in my analyses. The
>>> way I
>>> have set it up is as follows:
>>>
>>> All single-subject time series (4D) are in NifTI format, the time
>>> series
>>> averages (3D) are called *NatAverage.nii, and the statistic
>>> images (in
>>> native space) are all called Nat*.nii.
>>>
>>> I align the *NatAverage.nii file to the template $TEMPL (which in
>>> this
>>> case is EPI.nii) and then use that transformation to apply to all
>>> the
>>> other Nat*.nii files as well.
>>>
>>> The bash scripting bit that does the jobe looks like this
>>>
>>> for PREFIX in PREFIXES; do
>>>
>>> # all Nat's except NatAverage
>>> NATS=${PREFIX}Nat[BMNSV]*.nii
>>>
>>> echo "computing standard space mapping"
>>> ${FLIRT} \
>>> -in ${PREFIX}NatAverage.nii -ref ${TEMPL} \
>>> -out ${PREFIX}StdAverage.nii -omat ${PREFIX}Affine.txt \
>>> -bins 256 -cost corratio -dof 12 \
>>> -searchrx -90 90 -searchry -90 90 -searchrz -90 90 \
>>> -interp sinc -sincwidth 7 -sincwindow hanning
>>>
>>> echo "applying standard space mapping"
>>> for NAT in $NATS; do
>>>
>>> printf "."
>>> # use FLIRT to apply transformation to other Nat files
>>> ${FLIRT} -in ${NAT} -ref ${TEMPL} -out ${NAT//Nat/Std} \
>>> -applyxfm -init ${PREFIX}Affine.txt \
>>> -interp sinc -sincwidth 7 -sincwindow hanning
>>>
>>> done
>>> printf "\n"
>>>
>>> done
>>>
>>> And it works... but it is amazingly slow for the second part (the
>>> -applyxfm bit). It almost seems that flirt starts the
>>> registration all
>>> over again.
>>>
>>> I assumed that the other *Nat.nii images would just be resampled
>>> using
>>> the transformation parameters in *Affine.txt. That is correct, is
>>> it?
>>>
>>> Is there any way to speed up the process? Changing the
>>> interpolation to
>>> linear seems to have only a marginal effect. Resampling a 90x100x90
>>> volume should be done well inside a second?
>>>
>>> Thanks for any hints
>>> Alle Meije
------------------------------------------------------------------------
---
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
------------------------------------------------------------------------
---
