Dear Benjamin,
I'm surprised that this extends quite so far.
If you transform a mask with applywarp do you get a drop off in the
values the further away from the brain in this part of this image?
If so then you should be able to threshold this transformed mask at
some appropriate value (say 0.95) to get a fairly close mask.
However, if the values stay constant over this 1.5cm extrapolated
region then I guess it is indicative of a problem within applywarp.
Can you experiment with this and let us know the outcome?
All the best,
Mark
On 23 Aug 2011, at 15:17, Benjamin Kay wrote:
> On Tuesday, August 23, 2011 03:54:41 you wrote:
>> On 22 Aug 2011, at 23:51, Benjamin Kay wrote:
>>> On Monday, August 22, 2011 17:59:13 you wrote:
>>>> On 22 Aug 2011, at 22:29, Benjamin Kay wrote:
>>>>> I am trying to apply a linear transformation using the --premat option
>>>>> of applywarp. The reason I am trying to do this is so that I can apply
>>>>> a linear and a non-linear transformation simultaneously, thereby
>>>>> interpolating once rather than twice. Unexpectedly, the output of
>>>>> applywarp and ApplyXFM are substantially different. The output of
>>>>> ApplyXFM is what I expect to see. The output of applywarp has some
>>>>> kind of artifact along the superior margin of the brain. Does anyone
>>>>> know what this artifact is or what I am doing wrong? Is this a bug in
>>>>> FSL?
>>>>>
>>>>> Screenshots are attached to this e-mail. If you wish, you can download
>>>>> the NIFTI files needed to reproduce this issue from my personal
>>>>> website. reference volume: http://benkay.net/fsl/anat-brain.nii.gz
>>>>> input volume: http://benkay.net/fsl/mean-func.nii.gz
>>>>> transformation matrix: http://benkay.net/fsl/mean-to-anat.mat
>>>>> output of applywarp: http://benkay.net/fsl/applywarp.nii.gz
>>>>> output of ApplyXFM: http://benkay.net/fsl/ApplyXFM.nii.gz
>>>>>
>>>>> The transformation matrix was generated via:
>>>>> fsl4.1-flirt -ref anat-brain.nii.gz -in mean-func.nii.gz -out
>>>>> ApplyXFM.nii.gz -omat mean-to-anat.mat -dof 7 -interp sinc
>>>>>
>>>>> applywarp was invoked thusly:
>>>>> fsl4.1-applywarp --ref=anat-brain.nii.gz --in=mean-func.nii.gz
>>>>> --out=applywarp.nii.gz --premat=mean-to-anat.mat --interp=sinc
>>>>>
>>>>> ApplyXFM is, of course, a GUI. Run it with sinc interpolation or just
>>>>> use the output of flirt (above), which ought to be pretty much the
>>>>> same thing.
>>>>>
>>>>> All fun was had using fsl-4.1.8 on Debian unstable, Linux
>>>>> 3.0.0-1-amd64. <applywarp.jpeg><ApplyXFM.jpeg>
>>>>
>>>> Dear Ben,
>>>>
>>>> I have a vague recollection of there once being a bug that caused images
>>>> to look like that when outside the original FOV. Can you just confirm
>>>> for me that you are using the latest version of FSL?
>>>>
>>>> Jesper
>>>
>>> I am using the Debian build of fsl-4.1.8, which I am given to believe is
>>> the most recent stable release.
>>>
>>> fsl4.1-applywarp
>>> Part of FSL (build 416)
>>> applywarp (Version 1.2)
>>>
>>> fsl4.1-flirt -version
>>> FLIRT version 5.5
>>>
>>> I am not afraid to go playing in the source code, so if you happen to
>>> have a reference to the FOV bug handy then please do share.
>> Dear Ben,
>>
>> This is the most recent release.
>> I think that what you are seeing is not a bug but simply an arbitrary
>> masking issue. In FLIRT (which is called by ApplyXFM) there is a
>> -paddingsize option to control this but in applywarp there is not. What
>> to do in voxels where the old image voxels overlap by around 50% is quite
>> arbitrary and I think you are just seeing the more inclusive choice. If
>> you do not like this then I suggest that you transform a mask by the same
>> transform, threshold it at a high value (e.g., 0.9) to exclude voxels with
>> smaller partial volume overlaps, and apply this to your output. That
>> should mask
>> out the areas that you are concerned about.
>>
>> All the best,
>> Mark
>>
> Dear Mark,
>
> Thank you for your suggestion. I had not thought of using a mask.
> Unfortunately this is not straightforward as the mask is susceptible to the
> same artifact as the volume when transformed using applywarp. (I am not
> entirely sure what you mean by "threshold it at a high value".) As a
> workaround, I am now doing the following:
>
> # strip brain and produce mask
> $ fsl4.1-bet my-raw-volume.nii.gz mean-func.nii.gz -R -m
> # compute linear transform
> $ fsl4.1-flirt -ref anat-brain.nii.gz -in mean-func.nii.gz -out
> ApplyXFM.nii.gz -omat mean-to-anat.mat -dof 7 -interp sinc
> # apply linear transform to mask
> $ fsl4.1-flirt -in mean-func_mask.nii.gz -applyxfm -init mean-to-anat.mat -out
> mean-func_mask-anat.nii.gz -paddingsize 0.0 -interp nearestneighbour -ref
> anat-brain.nii.gz
> # apply nonlinear transform to linearly-transformed mask
> $ fsl4.1-applywarp --ref=standard.nii.gz --out=applywarp_mask.nii.gz --
> interp=nn --in=mean-func_mask-anat.nii.gz --warp=my-nonlinear-warp-to-
> standard.nii.gz
> # use of the fully-transformed mask
> $ fsl4.1-applywarp --ref=standard.nii.gz --out=applywarp.nii.gz --interp=sinc
> --in=mean-func.nii.gz --warp=my-nonlinear-warp-to-standard.nii.gz --
> premat=mean-to-anat.mat --mask=applywarp_mask.nii.gz
>
> With regards to your other comments, I am not entirely sure of your
> overlapping-voxels explanation. The artifact is quite wide (~1.5 cm outside
> the brain) to have arisen from inclusion of a few borderline voxels. Also, the
> volume generated using ApplyXFM in my original message was generated with -
> paddingsize 0.0 (the default) and yet there is no artifact.
>
> Benjamin
>
|