Hi,

I was just looking as this and noticed some oddities.

In the flirt call:
	in=data_FA , ref=FMRIB58
In the fnirt call:
	in=FMRIB58 , ref=data_FA  (!?)
they call the output warp field (coef)
	data_FA_to_FMRIB58  (!?)
then run invwarp with
	forward warp = data_FA_to_FMRIB58
	inv warp = FMRIB58_to_data_FA
	ref = data_FA
and finally in the applywarp:
	in = FMRIB58
	ref = data_FA
	warp = FMRIB58_to_data_FA  (invwarp output)

This fnirt call is backwards with respect to the rest.
You should have data_FA as the --in and the FMRIB58
as the --ref.  Only then does it make sense in the
context of the other calls, and only then should you
call the fnirt output the data_FA_to_FMRIB58 warp.

So try the fnirt call the other way around and see what
happens.  If you did this, then everything else looks OK.

All the best,
	Mark




On 23 Jan 2009, at 17:56, Jesper Andersson wrote:

> Dear Ryan,
>
>>
>> Let me know if you spot anything problematic. These commands work
>> fine for most of our DTI data, but fail for other data (as you
>> maybe saw in the jpeg I attached yesterday). For those data, the
>> only difference I could spot (using fslhd) was the voxel size
>> (2.5x2.5x2 vs 2x2x2).
>
> we had a bug in applywarp that gave problems for non-isotropic
> voxels. If you are using the latest versions that should be fixed.
>
> In your jpegs though it looks like the brains are actually swapped/
> rotated by 180 degrees, or I am seeing wrong there? That makes me
> concerned it might have something to do with the way we deal with
> the qform/sform in the file header.
>
> Could you please upload all the data (ref, in and warp) that
> pertains to the applywarp command that goes wrong? Go to http://www.fmrib.ox.ac.uk/cgi-bin/upload.cgi
>  and follow the instructions. You will be given a reference number
> that you can then email to me and Mark.
>
> Best regards Jesper
>
>
>>
>>
>> Thank you again for your help!
>>
>> -Ryan
>>
>>
>> On Jan 22 2009, Mark Jenkinson wrote:
>>
>>> Hi,
>>>
>>> We find that invwarp can take a very long time if either
>>> there is a particularly large FOV in the t1_brain (is there
>>> a lot of space around the brain in the image?) or if the
>>> resolution is very high.  It always helps to crop the
>>> original brain image down (just leave the brain but not
>>> much surrounding space - like the MNI152 images).
>>> However, if it is largely because of high resolution then
>>> it may be quite slow.  We are working on some ways of
>>> speeding this up, but at the moment the best options are
>>> to do the cropping (and you'll need to run fnirt again)
>>> and/or downsample the t1_brain image (e.g. with ApplyXFM)
>>> to a lower resolution just for the invwarp step, and then use the
>>> higher resolution one for the applywarp.
>>>
>>> I'm not sure what is going wrong in the second case.
>>> Can you please send us your command lines for
>>> invwarp and applywarp?  It should be possible to
>>> get the invwarp output to work fine with applywarp.
>>>
>>> All the best,
>>> 	Mark
>>>
>>>
>>>
>>>
>>>
>>> On 22 Jan 2009, at 17:50, Ryan Muetzel wrote:
>>>
>>>> Hello,
>>>>
>>>> We are having a few problems with the FNIRT and invwarp tools.
>>>>
>>>>
>>>> 1.) We are attempting to register our T1 image (1mm isotropic
>>>> voxels) to the MNI152_2mm_brain using FNIRT, and then use invwarp
>>>> to  invert the warp field. The FNIRT step works fine, but when we
>>>> use  invwarp, it takes 20+hrs and usually crashes. Instead of
>>>> using  invwarp, we have tried running FNIRT to align the
>>>> MNI152_2mm_brain  to our T1, and that works fine. We are using
>>>> CentOS5 on a dual core  AMD opteron with 8gb of RAM. Here are the
>>>> commands we are running:
>>>>
>>>> fnirtcfn=$FSLDIR/src/fnirt/fnirtcnf/T1_2_MNI152_2mm.cnf
>>>> $FSLDIR/bin/fnirt --in=t1_brain --ref=$FSLDIR/data/standard/
>>>> MNI152_T1_2mm_brain --aff=t1_to_MNI152_2mm_lin.mat --
>>>> cout=t1_to_MNI152_2mm_warp_coeff --
>>>> iout=t1_to_MNI152_2mm_nonlinear -- fout=t1_to_MNI152_2mm_fout --
>>>> logout=t1_to_MNI152_2mm_nonlinear.log -- config=$fnirtcfn
>>>>
>>>> $FSLDIR/bin/invwarp -w t1_to_MNI152_2mm_warp_coeff -o
>>>> MNI152_2mm_to_t1_coeff_warp -r t1_brain
>>>>
>>>>
>>>> 2.) The second issue we are seeing is when we attempt to obtain
>>>> the  inverse of a DTI (2mm x2.5mm x 2.5mm voxels) ->
>>>> FMRIB58_FA_1mm  alignment. We are using the same hardware and
>>>> commands as I  mentioned above (except we are using the DTI FA
>>>> map and the  FMRIB58_FA_1mm as --in and --ref). As before, FNIRT
>>>> works very well  in both directions (FAmap ->FMRIB58 and FMRIB58 -
>>>> > FAmap). In this  case, the invwarp of FAmap->FMRIB58 only takes
>>>> about 45min. However,  the images resulting from applywarp are
>>>> not correct, and I am unsure  if it is a problem with applywarp
>>>> or invwarp (see attached jpeg).  Because I am not seeing this
>>>> problem with 2mm isotropic DTI data, I  tried resampling these
>>>> data, but that didn't work either.
>>>>
>>>> Do you see any problems with the FNIRT and invwarp steps we are
>>>> doing? Instead of using invwarp, would you suggest only using
>>>> FNIRT  for these alignments, to get around these issues (i.e.,
>>>> native data - > standard and standard -> native data)?
>>>>
>>>> Any suggestions would be greatly appreciated!
>>>>
>>>> -Ryan
>>>>
>>>> <bad_alignment.jpg>
>>>
>>
>