Hi,
The existing fsl release (note that some of this will
change in the next release) does not attempt to calculate
left-right order anywhere. We say that fslview displays
in radiological convention only because that is how it
displays the standard image, where we know the left-right.
For all other programs (including flirt) we do not
assume anything about the left-right convention. Therefore
if all of your images are in the same convention then
everything is fine - flirt will *never* flip left and right.
However, if you have some neurologically stored data and
some radiologically stored data, like our standard image,
(in Analyze format) then registration will not work. You
must make your images consistent. We recommend swapping
the left-right order of all input data to be consistent
with the standard image - otherwise our mm coordinates will
be wrong. You can swap the order using
avwswapdim inputimage -x y z outputimage
Hope that makes things clearer.
I'm not sure whether the problem you have with volumeA vs
volumeB is about getting the left-right order correct or
just about registering images that are 180 degrees
different in initial orientation. Is it the case that
your images are 180 degrees different from the standard?
By default flirt only searches +/- 90 degrees from the
original orientation, so it is impressive that it actually
works for one of the images. This indicates a very large
basin of attraction for the optimisation. It not working
in the other image is what I would expect. You can control
the initial search range using either the -searchrx -searchry
and -searchrz options in the command line, or the
"incorrectly oriented" setting in the flirt gui advanced
options, or the "full search" setting in the registration
tab of feat.
Also note that after avwswapdim this may not be a problem,
as they may be much more closely aligned.
Hope this helps solve your problems.
All the best,
Mark
P.S. Note that in the next release that nifti files can hold
information about left-right convention, but that for the
initial release we will only be fully supporting
radiologically stored images, and that we will assume that
*all Analyze images* are stored radiologically.
On 6 Oct 2004, at 18:09, Bettyann Chodkowski wrote:
> hello all,
>
> after reading the notes at
> http://www.fmrib.ox.ac.uk/fslfaq/LRfaq.html, i have a question about
> the statement:
>
>> The FSL utility fslview displays the images in radiological
>> convention.
>
> how does fslview determine Left/Right in order to display the volume
> in radiological convention?
>
> i ask this question because i am unable to register a volume to the
> supplied standard volume via
> FEAT/FLIRT Registration. i know the problem is because my data is not
> in the same orientation as
> the standard volume. but i cannot figure out why my data is
> interpreted as being in the wrong
> orientation when other volumes i have are interpreted correctly. i
> checked the .hdr fields one-by-
> one and i can see no obvious reason for the interpretation differences.
>
> details:
> VolumeA registers successfully.
> VolumeB does not register.
>
> i open VolumeA, VolumeB, and standard/avg152T1_brain in MEDx with a
> file format of "Raw
> Generic". i did this as a way to bypass any information that might be
> supplied by the .hdr file, ie,
> there is no indication of Right/Left. i then define the volumes'
> characteristics in the [Options...]
> dialog box. VolumeA and VolumeB, loaded as "Raw Generic", have the
> same orientation;
> standard/avg152T1_brain is in a different orientation (a 180 degree
> rotation around the z-axis).
> yet VolumeA registers successfully with standard/avg152T1_brain via
> FLIRT but VolumeB does
> not.
>
> VolumeA and VolumeB are created from two different programs. i am
> trying to reconcile the
> differences. i've changed fields in the .hdr file one at a time to
> see if i can get the FLIRT
> registration with VolumeB to be successful. so far i have not found
> the magic .hdr field -- if there
> is one.
>
> is my conclusion that FLIRT somehow determines Left/Right (from the
> .hdr file?) correct? if so,
> how? what field does it use if it uses a .hdr field at all?
>
> thanks,
> - bettyann
