On Tue, 10 Mar 2009 14:31:19 +0000, Mark Jenkinson <[log in to unmask]> wrote:
As indicated off-list, I tried to reproduce the problem using uncomplicated
"gold standard" datasets, but was unable to do so. That is, flirt behaved
While trying to reproduce the problem, I noticed an error message during the
preprocessing that indicated a problem with the NIfTI header written by a
third-party axializing utility. This error surfaced this time around during
a QC step not present during the processing stream that led to the report
below. So I think a bad NIfTI header caused the earlier problem.
>I'm quite perturbed by this.
>We did extensive testing in-house prior to the last release (4.1) to
>make sure that registrations and FEAT runs (as well as other things)
>were fine with different combinations of left/right (or radio/neuro-logical)
>orderings. Everything tested fine here.
>What can be confusing is whether the sform or qform are set or not,
>as if they are not then there can be real problems in that the "flip"
>operation may not do anything - depending on what you ran. Also,
>displaying images with different software can be a problem. I'm
>not sure if these relate to you or not. I would really like to be able
>to track this problem down though. Would you be able to run some
>tests for me if you cannot send the data?
>To start with, it would be very helpful to see the fslhd output for
>the pre and post registration image, and the reference image.
>Hopefully we can sort out whether there is a problem to be fixed
>in FSL or not.
>All the best,
>Donna Dierker wrote:
>> Hi Mark,
>> Recently, I had an experience with flirt where a LPI->LPI registration
>> did not compute properly. The data (brainA.nii) was in Freesurfer
>> form and came from an outside lab, so I am not at liberty to provide
>> it. I used the Wash U 711-2B template, which I flipped to LPI using
>> AFNI's 3daxialize. I similarly flipped brainA.nii to LPI. (The
>> talairach_avi xfm was bad in this case, owing to the brain being
>> rotated off AC-PC. Source and template were initially not in the same
>> orientation, and the associated surfaces were in LPI orientation, so
>> to save a bit of sanity, I flipped all to LPI.)
>> Flirt did a very fine job of rotating the volume to AC-PC and keeping
>> the brain within the template bounding box / cerebral hull. The
>> origin was 8mm anterior to the AC, but this brain did have some issues
>> (tumor/lesion in the frontal lobe).
>> The reason I'm posting is that the transform was somehow confused so
>> that what started as a very pronounced occipital petalia (left
>> torquing into right) ended up flipped -- right torquing into left. It
>> wasn't just a translation or x-flip; the affine transform itself was
>> Anyway, flipped both source and target to RPI, and then flirt gave me
>> a very sensible result (although the origin was still translated a bit
>> I think if you take any source and target on your end; flip them to
>> LPI; try flirt on them; and don't see any misbehavior, then I wouldn't
>> worry. My brainA.nii did have extenuating circumstances, which is why
>> I didn't post before seeing Regina's post.
>> On 03/10/2009 08:20 AM, Mark Jenkinson wrote:
>>> FSL should currently handle radiological and neurological
>>> data fine, even if it is mixed - although I'd still probably
>>> avoid mixing them if possible.
>>> All the best,
>>> On 10 Mar 2009, at 13:06, Regina Lapate wrote:
>>>> I have a pretty straightforward question that I haven't been able to
>>>> find a
>>>> definite answer to by searching in the documentation of fsl: how
>>>> well does
>>>> fslview and flirt currently handle NIFTI images with a LPI
>>>> (RAS/neurological) orientation?
>>>> I found that for the fsl version 3.3, images in neurological
>>>> were not recommended (cf.
>>>> http://www.fmrib.ox.ac.uk/fslfaq/#general_lr), but
>>>> is that still the case? I currently have a preprocessed dataset in the
>>>> neurological orientation I would like to run first and second level
>>>> with using fsl. Before converting everything to radiological
>>>> orientation, I
>>>> would like to make sure that this step is actually necessary- or still
>>>> highly recommended.
>>>> Thank you very much for any input.