Mark,

Thanks for your thorough response!  It has been a bit confusing, but this has
helped clarify.

One additional question.. currently we are working in a freesurfer environment,
which doesn't recognize fslreorient2std as a command.  In this case is it okay
if we continue with our current protocol, ie using fslswapdim and fslorient?  We
have looked over some of our old data (images with hemispheric adnormalities) in
fslview against tkmedit (freesurfer viewer) where we know the orientation is
correct and it appears that all our images are in correct orientation with the
correct labels (L/R).  Has there been any changes in FSL recently (past year)
that would have effected the way FSL unpacks and orients, ie does FSL
automatically swap/reorient images at any stage?

Thank you for your help!

Sandra 



Sandra Woodman
Mood and Motor Control Laboratory
Athinoula Martinos Center for Biomedical Imaging
Massachusetts General Hospital 
120 6th St.
Charlestown, MA 02129
Tel: 617-643-6245
Fax: 617-726-1351
Email: [log in to unmask]



-----Original Message-----
From: FSL - FMRIB's Software Library on behalf of Mark Jenkinson
Sent: Fri 11/19/2010 5:21 AM
To: [log in to unmask]
Subject: Re: [FSL] FSL orientation/swap query
 
Dear Sandra,

Once upon a time the nifti fairy gave us a new data format.
Unlike the nasty old Analyze format, this new format allowed
us to store information about orientation in the image itself
and so the analysis programs no longer had to guess which
way around the images were stored (or, as was more common,
assume a given default and let the users make sure that their
images adhered to that ordering).

So this was the situation in 2004 when FSL 3.2beta was
released.  We put in nifti support, but although most of our
tools could cope with different orientations, not 100% of
them were able to do this, so we stuck with the convention
that people needed to make sure that their images adhered
to the "old" style FSL convention - which was to be "like" the
MNI152 template images. By "like" we mean that you could
rotate your image to make it match this template (that is,
no reflections were needed).  This is related to left-right
ordering but a little more complicated.  I decided (in one
of the worst decisions I've ever made in FSL) to call this
convention "radiological ordering".  This terminology, and
the intrinsic complicated nature of storage vs voxel coordinates
vs "world" coordinates, has caused a lot of confusion.  However,
this was a *temporary* situation (that is, requiring things be
stored in the "old" FSL convention) and was resolved fully in 
the FSL4.0 (2007).  Unfortunately, the belief that FSL *needed*
things in the old convention (radiologically-ordered) persisted
well past the point that this was actually true.  It has been
happy for quite a long time now with data in *any* ordering.
So there is *no* need to convert anything between different
orderings (i.e. between "radiological" and "neurological").

As I said though, people still wanted to swap between these
and so fslswapdim and fslorient were regularly used and
these are *dangerous* operations as it is really very, very
easy to get the left and right parts of the images mislabeled
as a result of using these tools incorrectly.  Partly to help
avoid these problems I introduced a label-based syntax
for fslswapdim a while ago, and more recently have introduced
a new tool, fslreorient2std.  This new tool is there for a different
reason - not to convert between orderings ("radiological" and
"neurological") but, instead, to reorient the image so that it 
appears, in FSLView, with the same slicings as the standard
template brains (MNI152).  This therefore changes the 
*orientation* but not the *ordering*.  It seems that a lot of
people confuse these two issues, and a lot of people are 
unhappy if their images are not in the same orientation as
the MNI152 template images.  However, for the analysis
it doesn't matter if they are in the same orientation or not,
which is why we'd never worried about it much in the past.
It is purely an issue of display (although there can be minor
benefits in the registration).

The other important issue to bring up here is labels in FSLView.
These are *THE MOST IMPORTANT* aspect of data orientation
and need to be checked.  It is absolutely crucial that these
labels are correct (as seen in FSLView) when you look at your data.
If the labels are not correct then *DO NOT* do any processing until
they are fixed.  To fix these labels, if they are incorrect, requires the
use of fslswapdim and fslorient, and this is really one of the few
instances where people need to interact with these tools.  If the
labels are fine, then I *strongly* advise people not to use fslswapdim 
or fslorient.  In the early days of nifti it was quite common that images
were incorrectly labeled when they were converted to the nifti format
from their native scanner format, but these days it is rare.  However,
be vigilant and always check the labels.  Obviously it is extremely
difficult/impossible to tell left from right in the brain by visual inspection
(at least for most healthy brains) and so it is a *really good idea* to
attach something like a vitamin/oil capsule to the subject when 
scanning so that you can tell left from right in the actual MR images.

As different centres have different scanners, protocols, conversion
routines and so forth, we cannot recommend a general workflow
beyond inspecting your data and fixing problems if they arise.
If there is no *problem* with the labels, but you just want your
images to look like the MNI152 images, in terms of orientation,
then use fslreorient2std.  There is no need in FSL (and hasn't
been for some time) to convert anything between "radiological"
and "neurological" ordering.  Just forget about this in the way
that you can forget about the datatype that the image is stored
in.  It is a technical detail and is currently dealt with fine within
the software.  The only instance I can imagine that it might 
play a role is when you are using data across several different
packages and some of them are not fully compliant with 
both orderings (as the very old versions of FSL used to be).

There is more information on the tools and some technical
details about orientations and orderings on the webpage
for FSLUTILS.  Look at the "Orientation-related Utilities"
section of:  http://www.fmrib.ox.ac.uk/fsl/avwutils/index.html

I really strongly recommend that people do not use fslswapdim
or fslorient unless they absolutely have to because their
labels are *incorrect*.  I know I said this above, but I would
really like to emphasize this point, as I've seen far too much
incorrect, and unnecessary, use of these tools causing problems.

If you are worried about old data then just *check the labels*
in FSLView.  As long as these are correct then everything is fine.
The labels are the only crucial thing.  Then, if you like, you can
apply fslreorient2std to put the images in the same orientation
as the MNI152 brains, but this is not necessary, it is only if that
is what you like to see in the viewer.  It will not affect the analysis.
Once again, it is *only the labels* which are important.  OK, I
think I've probably emphasized that enough now.

I hope this has answered all your questions.  It is a pity that
there is so much confusion about these issues, and I hope
that this has helped.

All the best,
	Mark


On 18 Nov 2010, at 22:34, Woodman, Sandra wrote:

> Hi,
> 
> We recently spoke with someone doing fMRI analysis with FSL and they ran 
> into some issues with finding that using fslswapdim and fslorient was 
> actually flipping their data such that right was left and left was right 
> (the functional header said it was in neurologic orientation and the 
> structural said radiologic; when he swapped only the functional images, 
> the functional and structural became mirror images of each other). I 
> believe he heard from someone on the FSL list who mentioned that the 
> procedures for dealing with orientation have changed recently, and that he 
> no longer needs to use fslswapdim (and maybe fslorient, too?).
> 
> So here are our questions: Was there really a change in how orientation 
> is dealt with, and if so, does it affect all types of images (fMRI, 
> structural, DTI, etc.)? Do we need to still run fslorient or is it just 
> fslswap that should not be used? If orientation procedures have indeed 
> changed, when did this change take effect? And finally, at what stage do 
> the changes apply, i.e. was there a change at the stage of unpacking or 
> is the change further downstream (I'm asking this because we did some 
> recent processing of images that were unpacked awhile ago, so they may 
> not be affected by this change and would still need to be swapped--I 
> think).
> 
> Our current questions are specifically about DTI analysis, but we will 
> also be using FSL for fMRI in the near future. We are currently using both 
> bedpostx/probtrackx and randomise for the DTI analyses. Also, we are using 
> unpacksdcmdir to unpack our images.  We are using NIFTI format images.
> 
> Thank you!
> 
> Sandra Woodman
> 
> 
> 
> 
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the e-mail
> contains patient information, please contact the Partners Compliance HelpLine
at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
error
> but does not contain patient information, please contact the sender and
properly
> dispose of the e-mail.
>