General
Where can I find help, tutorials or papers about FSL?
Every installation of FSL comes with html documentation in $FSLDIR/doc
In addition, there are general FSL web pages, including some
documentation and related references, at www.fmrib.ox.ac.uk/fsl
A tutorial-based set of lecture slides and practicals can be found at
www.fmrib.ox.ac.uk/fslcourse and is related to the content of the FSL/Freesurfer course
which is held once or twice each year - see www.fmrib.ox.ac.uk/fslcourse/announce.html for details on upcoming/recent courses.
Further help can also be obtained via the public
FSL email list.
Note that you must join the list in order to post questions.
Finally, detailed technical reports can be found at
www.fmrib.ox.ac.uk/analysis/techrep/ and a full list of conference and journal papers produced
by the FMRIB Analysis Group can be found at
www.fmrib.ox.ac.uk/analysis/fmribindex/.
How do I best report problems to the FSL email list?
In order to understand and analyse problems please provide the
following pieces of information:
- What part of FSL did not work as expected?
In the case of FEAT /
MELODIC problems, please check the log
(report.log/melodic.log) files first, e.g. you might be out
of space or certain files might actually not be readable.
- What type of input data were you running the sofware on?
Please make sure that the data is not corrupted: check your input data by loading it into fslview (or slices). If your
input data is not what you expect, try and fix this first. You
can also obtain
useful header information with fslhd filename and
useful information about the image intensity range from
fslstats -r -R. If you need to report a problem, please
provide this information in an email.
- Does the software run on the FEEDS example data?
- If you cannot resolve the problem then please run the command:
fslerrorreport in the directory that the
problem occurred.
The output from this gives information on log files,
the platform are you running FSL on: CPU type, OS type &
version, how much RAM, Swap space etc. is available, etc.
Please attach the entire output of this command to your email.
Note that the output is written to a file in /tmp (filename
is given at the end of the output message) for convenience in
attaching it to an email.
Also, please be as specific as possible about command line error
messages.
NOTE: Please do not send Analyze files (AVW) to the email list; If
these are needed to resolve the problem, place them somewhere to download!
-
What image format does FSL need?
FSL programs expect to read Analyze (AVW) or NIFTI-1 format
images. These files can be read and written in compressed (gzip
format) or uncompressed form. To convert between these different formats,
use the fslchfiletype utility or the environment
variable FSLOUTPUTTYPE. These are described more fully in the
nifti1 page.
An image can be 2D or 3D or 4D (multiple time points).
FSL programs for FMRI analysis use single 4D Analyze/NIFTI images,
not lots of 3D images (such as SPM does).
You will need some other program to convert between formats
(e.g. DICOM). A list of such converters can be found at:
www.sph.sc.edu/comd/rorden/mricron/dcm2nii.html
How do I convert between 3D and 4D Analyze images?
In order to convert between multiple 3D and single 4D images, use the
following programs (found in $FSLDIR/bin):
3D -> 4D
fslmerge -t outputname in1 in2 ....... inN
note that if your 3D files have numbers that are zero padded (eg
in0001 etc.) then you can do this more easily. For example, with Analyze files:
fslmerge -t outputname in*.hdr
will work.
In general, due to the multiple file formats, we recommend using
the utility imglob for getting filenames. For example:
fslmerge -t outputname `imglob -oneperimage in*`
(NB: the above command contains backquotes, not forward quotes)
4D -> 3D
fslsplit input
this program automatically chooses the output name.
-
How do I know right from left in the images?
Left/Right orientation can now be encoded in nifti images. With the
current version of FSL (3.3) we do not recommend storing in "neurological"
convention as not all utilities will work in an intuitive or
"correct" manner with "neurologically" ordered data, especially when
mixing it with "radiologically" ordered data. Please be careful to read
our detailed defintion of "neurological"
convention as these terms can easily be misinterpretted.
Also note that nifti stores orientation information in either the
sform of the qform matrix (standard space and scanner space
respectively) and that FSL3.3 will now use either the qform or sform
matrices (the sform has priority if both are set). All orientation
information, is determined from the appropriate sform or qform matrix,
if they are set (at least one has a non-zero code as reported by
fslhd). If neither is set then it is assumed to be
"radiological" storage - this is also the default for all
Analyze files.
The orientation
("radiological" or "neurological") can be found out by running
fslorient -getorient and can also be modified by this command
(though, see next question for more info
on this).
Although storing different left/right orientations is sometimes also
attempted with Analyze images, there is no convention which is
widely adhered to. Hence the latest version of FSL treats all
Analyze images as "radiological". This is consistent with previous
releases since the standard image (avg152T1) is in
"radiological" order and all processing steps in previous versions did
not alter the left/right orientation. (Note that FSL now also saves
a negative pixdim for X - unless other pixdims are negative - in order to
keep consistency with the avg152T1 images and some third-party
display software).
In previous versions the FSL tools, including FLIRT, would not change
the way that left/right is stored in the image. This is no longer true.
FLIRT will swap left/right if necessary (i.e. when the images have opposite
left-right orderings).
FSLVIEW always displays images "radiologically". Hence, any
"neurologically" ordered nifti image will be flipped in the (voxel)
x-axis when it is displayed in FSLVIEW. FSLVIEW also now labels the
axes (e.g. L, R, P, A, I, S -
Left, Right, Posterior, Anterior, Inferior, Superior). In the case of
oblique acquisitions it chooses the "closest" axis label.
-
What exactly is the definition of "radiological convention"
or "neurological convention" used in FSL?
The terms "radiological" and "neurological" are not ideal for
describing the ordering of data, but we have adopted them because in
the familiar case of axial data as in the avg152T1 images
(with slices starting inferior and moving superior - often described
as LAS) then these terms take their familiar meanings. However,
there are many possible situations where these terms are not intuitive,
and so we have defined a technical meaning of them for the purposes
of describing FSL behaviour.
Our technical definition of "neurological" convention for image
storage is that the mapping between the voxel-coordinate-system and
the nifti-real-world-coordinate-system (i.e. the sform or qform
matrix) has a positive determinant. Note that the standard images,
the avg152T1 images, are all in "radiological" convention as
was the convention for most Analyze images. The avg152T1
image is now our definition of "radiological", and we now strictly
enforce this convention for Analyze images (see previous question).
Once again, note that with the current version of FSL (3.3) we do
not recommend storing in "neurological" convention as not all
programs will function correctly. We recommend that all data be
converted to "radiological" convention before processed further
with FSL. To do this see the FAQ entry on changing left-right ordering.
Furthermore, note that it is not sufficient to look at a single
axial image slice to tell if it is "neurological" or "radiological".
For instance, flipping the avg152T1 image in the
superior-inferior direction would keep left-right the same in all the
axial slices, but would change the sense of the coordinate system
from "radiological" to "neurological" (in our definition). This
is easily seen by looking at the determinant of the sform or qform.
In general, any flip in any direction will invert the
left-right nature of the coordinate system, while rotations all
preserve the left-right nature of the coordinate system. Hence
FLIRT, which uses rotations but not flips, will preserve the
left-right nature (and hence the "radiological"/"neurological"
convention).
For reference, the avg152T1 image has:
- z-axis as the inferior-superior direction (moving in the superior direction increases the z voxel index and the z millimetre coordinate)
- y-axis as the posterior-anterior direction (moving in the anterior direction increases the y voxel index and the y millimetre coordinate)
- x-axis as the right-left direction (moving in the left direction increases the x voxel index but decreases the x millimetre coordinate)
To see this, load the volume avg152T1_LR-marked into
fslview and look at the voxel and mm coordinates as you move about.
-
How can I modify the left/right or "radiological"/"neurological"
ordering of my data?
When it is absolutely necessary, there are two ways to modify the
orientation of a nifti image. Note, however, that these operations
easily lead to confusion about which side of an image is left or
right. Therefore, use with caution. The most appropriate place to
use these tools is: (1) in the initial reconstruction of images (where
it may be necessary to force the correct orientation (or change the
data ordering); (2) to convert "neurologically" ordered data into
"radiological" order for further processing in FSL (this is our
strong recommendation); or (3) to correct
for poor converters or to suit the user's preference.
In order to use the FSL tools to convert "neurologically" ordered
data into the "radiologically" ordered format for use with the current
version of FSL (3.3) the following commands should be run:
fslswapdim input -x y z output
fslorient -swaporient output
This will create a new image (output) which has the opposite
left-right ordering as the input image. That is, if the input image
was "neurologically" ordered, the output will be "radiologically"
ordered. This assumes that the original orientation information in
the input image is set correctly. If these commands are used on
Analyze images, or nifti images where neither qform or sform are set,
then the fslorient command will not change anything, but the
underlying data will be changed by fslswapdim and the
left-right orientation will still have changed, although the
default orientation of "radiological" will be used.
The first of the above commands changes the order of the data that is
stored in the file. The command fslswapdim input -x y z
output swaps the order of the x-axis of the input image to
create the output image. It will not change the orientation
information in the header, and so fslorient -getorient will report the
same orientation for both input and output images, although looking at
them in FSLVIEW will clearly show that flipping has occurred. Note
that this way also changes the orientation for Analyze files (and in
previous versions of FSL it was the only tool that could affect
left/right orientation).
The other command that affects orientation is fslorient.
This can either report the current orientation, swap the orientation,
or force "radiological" or "neurological" orientation. This does not
change the order that the data is stored - it only changes the
information in the header which tells programs how to interpret the
stored data.
Both methods of changing the orientation only change half of the
information on orientation and so when run separately on a correct and
valid nifti file they will cause the orientation to be inconsistent
between data and header. For instance, if the data is originally
correctly stored in "neurological" order, the correct way to change it
to a valid "radiologically" ordered image (as shown above) is to run
both fslorient and fslswapdim on the data.
Alternatively, if the image is know to have the data
stored "neurologically", but the header says it is (incorrectly) in
"radiological" order, then running fslorient -forceneurological
will turn it into a valid "neurologically" ordered image. On the other
hand, running fslswapdim input -x y z output on the same
incorrect image will create an output image that is a valid
"radiologically" ordered image.
-
How do I run the GUIs or command lines?
On most machines the GUIs can be run by:
- Typing fsl at the (terminal/shell) prompt, which brings
up a graphical menu of the main FSL GUIs
- Typing the name of the required program, with the first
letter capitalised: e.g. Flirt
However, under MacOSX and Windows XP/cygwin the GUIs are run by:
- Typing fsl_gui at the (terminal/shell) prompt, which brings
up a graphical menu of the main FSL GUIs
- Typing the name of the required program, with the first
letter capitalised followed by _gui: e.g. Flirt_gui
On all machines, the command line versions can be run by typing the
name of the program, all in lower case: e.g. flirt
Note: with no arguments the command line versions return a help
statement that includes usage lines and available options.
-
How can I make old scripts work with FSL3.2?
Due to the use of new file formats, with different extensions, most
scripts need some modification to work fully with FSL3.2. However,
the changes are relatively straightforward and are described in
a separate scripting page.
INSTALLATION
-
How do I install (or compile) FSL?
Instructions on downloading and installing FSL can be found at:
www.fmrib.ox.ac.uk/fsl/fsl/downloading.html
Instructions on compiling FSL can be found at:
www.fmrib.ox.ac.uk/fsl/fsl/compiling.html
Note the special instructions for installing on MacOSX and Windows XP/cygwin.
Note that you must set up the environment variable FSLDIR
to point to the directory where FSL is installed on your machine.
It is also necessary to source a setup file. This can be
done by:
- bash users: . $FSLDIR/etc/fslconf/fsl.sh
- tcsh users: source $FSLDIR/etc/fslconf/fsl.csh
Also, you would normally want to include $FSLDIR/bin in
your PATH. In general
these are best done in your shell startup file (e.g. .bashrc or
.profile). The syntax required depends on the shell you use,
but is normally either one of the following (where /usr/local/fsl
is used as an example for the installation location):
- bash users: export FSLDIR=/usr/local/fsl; . $FSLDIR/etc/fslconf/fsl.sh ; export PATH=$PATH:$FSLDIR/bin;
- tcsh users: setenv FSLDIR /usr/local/fsl; source $FSLDIR/etc/fslconf/fsl.csh ; setenv PATH ${PATH}:$FSLDIR/bin; rehash;
-
What sort of system requirements does FSL have?
FSL is supported on the following hardware: PC, Mac, Sun, Silicon Graphics
FSL is supported for the following operating systems: Linux (redhat 7,8,9), MacOS X,
Windows XP (with cygwin), Solaris, IRIX
Note: that FSL also works with other flavours of Linux such as suse and debian - although
they may need to be built from source rather than using the precompiled redhat binaries.
It is recommended that the following memory and disk requirements are met:
- RAM - 512MB or more
- Swap space - at least equal to RAM (2GB min recommended; check with top)
- Disk space - at least 10 times the size of your data sets
Be warned that too little swap space causes "unexplained" crashes!
-
How can I test if my installation works?
Download and run the FSL Evaluation and Example Data Suite (FEEDS).
See also: How do I get and run FEEDS?
-
How do I get and run FEEDS?
Information on how to run the FSL Evaluation and Example Data
Suite (useful for testing that your installation is working
and to get a benchmark for speed) can be found at:
www.fmrib.ox.ac.uk/fsl/feeds/doc/index.html
This site includes a link to the download URL at:
www.fmrib.ox.ac.uk/fsldownloads
A timing table using FEEDS as a benchmark for comparing relative performance
between machines can be found at:
www.fmrib.ox.ac.uk/fsl/feeds/doc/timings.html
Why does an FSL program crash when it is trying to process a very large dataset?
Certain programs in FSL can require a large amount of memory (RAM)
to run, depending on the size of the data that you are trying to
analyse. For example:
- FMRI timeseries analysis with FILM (called by FEAT), if you have a
large number of timepoints and/or regressors
- FMRI timeseries analysis with MELODIC, if you have a large number
of timepoints
- FMRI multi-subject analysis with MELODIC, if you have a large
image matrix or large number of timepoints or subjects
- DTI FA analysis with TBSS (at the stage of running tbss_skeleton
or randomise) if you have a large number of subjects
The memory available to a program depends on how much physical RAM
you have on your computer, what other programs are already running,
and how much "virtual memory" (swap) you have configured. Swap is
hard disk space that is used to act as additional memory on top of
your actual memory, allowing programs larger than your physical memory
to run, but much more slowly. Hence, if your program is running out of
memory you should consider increasing your physcial RAM and/or your
swap space (the latter is cheaper but a slower solution). Your local
sysadmin can easily increase swap space if you have spare hard disk
space available.
However, there is one further caveat. On 32-bit computers there is
a limit on the size that a single program can be, regardless of how
much RAM/swap you have. This limit is normally 2GB. The best solution
to this is to move to a 64-bit computer (for example, all Apple
computers are now 64-bit, and it is easy to find cheap 64-bit PCs to
install 64-bit Linux on). On a 64-bit computer, as long as you have
enough RAM/swap, there is effectively no limit to the size of the
programs that you can run.
FDT (diffusion)
-
How many diffusion encoding directions do I need for FDT tractography?
We would not recommend using fewer than 25 directions.
-
What resolution do I need for tractography?
It depends on what structures you're interested in, but everything we
have published so far works well on data which is 2.5x2.5x2.5 mm^3 or
better for the adult human brain. Imaging infants or non-human species would
ideally require higher resolution.
-
Do I need isotropic voxel resolution for tractography?
No, tractography will work with any voxel sizes. However, we have no
experience of dealing with data where the voxels are a long way from
isotropic.
-
How many reference (b=0) scans should I take?
It depends on what b-factor you use, but for middle of the range
b-factors (b=1000) you should take something like 1 b=0 image for every 8
or 9 diffusion-weighted image. (see Jones et al. 1999)
What do I need before I can run dtifit or bedpost?
You need raw diffusion-weighted data in a 4D volume (the 4th
dimension indexes gradient dimensions). You also need to know the
orientation of the diffusion-encoding gradient and the b-value applied
during each diffusion weighted volume. Lastly, you need a binary mask
of brain/non-brain.
How do I know the gradient information?
Most modern scanners will output gradient information. If yours does
not, you should ask your local physics team. NB, gradient information
should be stored in bvecs and bvals files as
described in the
FDT documentation. NB2 - every volume in data
requires an element in both bvals and bvecs.
Do I have to put an entry in my gradient files even for the reference
(b=0) scans?
Yes - you can put any direction in the bvecs file, and you must put a zero in the correct location in the bvals file.
If something's worth saying, should I say it three times?
Yes - every volume in data requires an element in bvecs and bvals. If your input directory is in FDT standard form you can do a quick check for the correct dimensions of all your files using bedpost_datacheck.
How do I normalise my bvecs?
Each direction in bvecs should have a magnitude of 1. In order to
achieve this, compute (x_n,y_n,z_n)=(x,y,z)/sqrt(x2+y2+z2).
-
Before I run dtifit or bedpost, I need a brain mask - where do I get
that from?
The brain mask needs to be in the same space as the diffusion data. We
tend to run bet on one of our reference (b=0) scans.
-
dtifit runs, but my outputs are all zero - what is wrong?
In most cases this is because your bvecs and bvals do not have carriage returns at the end. Make sure these files end in a new line, and rerun.
-
dtifit crashes - what is happening?
In most cases, dtifit is crashing because your bvectors or bvalues are
stored wrong, or don't match your data. If you have run dtifit from a
standard directory, you check the basics with
bedpost_datacheck <dirname>
-
Bedpost is taking ages and ages and ages and ages to finish, and I can't write may paper because my computer has seized up. Is this normal?
Yep.
(On a 2.4GHz pentium, bedpost will take about 20 cpu hours to process a
2.5x2.5x2.5 mm^3 dataset - however, at any one time, the process is v.
small, so it shouldn't overburden your machine (hopefully!!) )
-
Can I parallelise bedpost?
Bedpost is now sge-capable, see here for information on setting up sge on your local system.
-
When I've got my bedposted directory, how long will tractography take?
This depends on a few things, but the main ones are:
- Number of seed voxels: Apart from lots of data loading at the
beginning, and data saving at the end, the actually tractography will take
about 10-12 seconds per seed voxel on standard settings on a 2.4GHz
pentium.
- Number of samples: The time taken for tractography scales linearly
with the number of samples drawn from the distribution at each seed voxel.
In our experience, the distribution is well sampled by after 5000 samples
are drawn, hence this is the default number. However, when you are doing
quick testing, you can reduce this number. e.g. you could test with 1000
samples (which would take 1/5 of the time) and then when it came to doing
detailed quantitative analysis, you could go back to 5000 samples.
-
How should I threshold the path distribution estimates from ProbTrack?
There is no right or wrong way to threshold these values. They form a
continuous distribution which has been discretised in an arbitrary
fashion (for example, if you double the voxel size, the probability of
passing through each voxel will roughly double!). Note that this is
NOT true for the "connectivity-based seed-voxel classification" mode
where the discretisation is generally anatomically meaningful (the
target masks are prespecified anatomical regions). In practice,
thresholding at very low values (e.g., 10 out of 5000 samples) often
tidies up path distribution estimates considerably. You will have to
choose where to threshold based on your own specific question.
-
I've checked my data carefully and I've run bedpost_datacheck.
Something still isn't working and I'm really baffled. What can I do now?
Send an email to the FSL list (see How do I best report problems to the FSL email list?)
FEAT
-
How long does it take FEAT to analyse a data-set?
There are many factors that affect how long FEAT takes to analyse a data-set.
These include the speed of the machine, the amount of RAM and swap space available, the number of time points, the
amount of activation present and the number of voxels in the data. In
addition, higher level analyses take longer since first level analyses
are carried out in native EPI
space whilst higher level analyses are carried out in standard space
and use FLAME - a sophisticated Bayesian mixed-effects estimation technique.
Hence it is very difficult to give an accurate estimation for the length of
time that FEAT should run.
As a very rough guide, FEEDS includes (among
other tests) a
first level analysis with 180 time points and 64 x 64 x 21 voxels
which takes less than 30 minutes on a modern PC (Athlon 2GHz) - for other
machines see the
FEEDS Timing Results. Higher level analyses is slower than this, and can often take 1-3
hours on a modern PC with a standard group size of 6-12 subjects.
-
Can I use FEAT to analyse fmri data from an animal study?
Analysing animal data in FEAT is, in theory, straightforward although there are
some practical difficulties. The basic GLM and statistics are no different
for animal data, however difficulties can occur during preprocessing - particularly
with motion correction and brain extraction.
One reason that problems occur is due to the scales used in motion
correction, which starts at 8mm and is often too large for animal
brains (e.g. rats). A work-around for this is to modify the voxel
size recorded in the Analyze header (using fslchpixdim) so
that the total brain size is similar to that of a human (150-200mm in
each dimension). Once this is done note that all values entered into
FEAT in mm will refer to this expanded image, hence the spatial
smoothing should be set taking this into account.
Problems with brain extraction are more serious and for animals with
brains that are considerably different from humans (e.g. rats) then
BET normally will not work. In such cases it is necessary to turn off
brain extraction in the pre-stats and, if necessary, perform it
manually or with some other specific software.
Note that we do not supply any standard or template images for animals, and
although "Talairach" coordinates will still be reported, they are meaningless.
If an animal-specific template image is available it can easily be used as the
Standard Space image and all registrations should work correctly once
the voxel size change (see above) has been made.
-
Can I use FEAT to analyse PET data?
It is possible to use FEAT for analysing PET data although the default
settings are designed for FMRI data and need modification. In
particular: turn on intensity normalisation; turn off slice timing correction;
use a higher value for spatial smoothing (8mm or more); turn convolution (with
either basis functions or the HRF) off for each EV; do not include
temporal derivatives nor high pass filtering (as PET doesn't have the
issues of aliasing nor temporal drift); and, similarly, turn
pre-whitening off (no FILM) because PET also doesn't have the problem of
temporal autocorrelation. Note that TR is meaningless for PET so the
default value (or any other value) is fine.
-
How do I analyse a "sparse-sampling" dataset?
- Set the TR to be the actual time from the start of one volume to the
start of the next, regardless of how long each one actually takes to
acquire.
- If this TR is longer than say 10s then you should probably turn off
"FILM prewhitening" in the "Stats" section.
- What you do next, to create the model, depends on the following. If
you are always presenting the stimuli at the same point within the
"effective" TR (which would normally be setup so that you are actually
gathering data near the peak of the response) and your effective TR is
long enough so that you don't have different stimulus responses
getting mixed up together, then you can use the simple modelling
approach below. Otherwise you need the "full" modelling approach.
SIMPLE MODELLING
- In this approach you can simply assume that the response to each
stimulus is sampled purely by the TR following that stimulus. You can
therefore use the single-column custom timing EV design, with an EV
for each event type, and a 0 for all TRs except a 1 for each TR
following a relevant stimulus.
"FULL" MODELLING
- The easiest way of setting up your design (in "Full model setup") is
to use the "Custom (3 column format)" option. You should keep all
the defaults including normal convolution. Create a different
3-column-format text file for each event type (ie for each
EV). Within each text file you put a triplet of numbers for each
event. The first number in each triplet is the onset time of the
event in seconds and is described in detail below. The second number
is the duration of the event in seconds and should be set to the
real duration. The third number is the "height" or "strength" of the
event and should normally be left at "1". (You could try to correct
for sparse design timings using slice-timing-correction in
pre-stats, but this is definitely not recommended, for various
reasons, one being that this introduces extra temporal smoothness to
the data.)
- For sparse designs the tricky part is to set the onset timings for
each event correctly. Start by setting the onset timings according
to the actual time (in seconds) when the event started, where zero
seconds refers to the beginning of the first "TR". However, these
now need correcting because of the sparse timing. Remember that FEAT
assumes that all data in each volume was actually gathered
instantaneously at the mid-point of that volume's TR; you now need
to correct for the difference between the real TR length and the
time between volumes (the latter being what you told FEAT was the
TR). The timings need to be corrected by half of this difference -
i.e., increased by (TR given to FEAT)/2 - (real TR)/2. See the
following example:
- Example. Each volume acquisition takes 3s. However, between each
real volume acquisition there is 6s of non-scanning. Thus set the TR
in FEAT to 9. One stimulus (event) lasted 1s and began 3s after the
start of the third volume, i.e. at 21s in real time.
Now, if you set the event in the 3-column file to "21 1 1" then FEAT
would assume that E _began_ 1.5s _before_ the 3rd volume was acquired
(because it assumes data is acquired halfway through the "TR") when in
fact it began 1.5s _after_. Therefore you need to adjust the timings
by (9/2)-(3/2)=3s - so the triplet should be "24 1 1" so that the
event is modelled as beginning 1.5s after the mid-point of the 9s
"TR".
Note that you do still need to get FEAT to carry out the HRF
convolution in the normal way, because the measured FMRI signal
resulting from the event is still delayed and blurred as normal.
-
What is FLAME and when do I use it?
FLAME (FMRIB's Local Analysis of Mixed Effects) is a sophisticated
Bayesian estimation method used for higher-level mixed-effects analysis.
It is recommended that FLAME is always used for higher-level analysis
as it provides the most accurate statistics available in FEAT.
FLAME uses MH MCMC (Metropolis-Hastings Markov Chain Monte Carlo) sampling
methods to generate the distribution for the higher-level contrasts of
parameter estimates (copes), and then fits a general t-distribution to this.
In addition, it incorporates knowledge of the first-level results,
particularly the variances in order to avoid the "negative variance problem"
(where the estimated mixed effects variance is less than the first
level variance implying negative random effects variance).
See the FEAT
Manual or relevant publications for more details about
higher-level modelling, analysis and the use of FLAME.
-
My FEAT run doesn't finish - what do I do?
It can take FEAT a long time to analyse large data sets, as discussed above. Some progress
should be apparent by using FeatWatcher or by inspecting the report.log file. In addition, by using top the currently active
process run by FEAT should be apparent. After pre-stats most of the
time is spent running film or flame and these should have
current running status if things are working correctly. If the run does
not seem to be active or it does not finish after an appropriate length of
time then there may be problems - refer to the "file not found" question for more details on debugging FEAT sessions.
Also note that the FEAT GUI does not disappear once FEAT is finished
but remains so that other FEAT runs can be started. To see if FEAT is
finished, the best method is to load the report.html web page
inside the output .feat or .gfeat directory.
-
A file not found error occurs during my FEAT run - what do I do?
Errors of this type usually arise as a result of previous stages (such as certain
steps in the pre-stats) failing. This can occur due to lack of disk space to
write output files, or insufficient swap space to run the necessary programs.
The first thing to try once problems with disk space and swap space are ruled out is to re-run the FEAT analysis and see if the same problem occurs. If it does, check the report.log file in the .feat or .gfeat output directory to see if any programs reported error messages.
If an error is found then check whether that command can be run at the
command line. If not, refer to debugging for that command. If the individual
command can be run but not within FEAT, try setting up the entire design
again from the beginning and re-running the analysis. If all else fails, email
the FSL email list with details of the analysis, and attach both the report.log and
design.fsf files.
-
Can I ignore time points or use a dummy EV to model missing values in FEAT?
Yes - time points can be effectively "ignored" by creating a dummy EV (a
confound) which has a value of one for the time point to be ignored
and zero everywhere else. This can be created either as a custom
input file (1 or 3 column) or using the Square wave input
option and correctly setting the Skip and Stop after
fields. Filtering should be applied as normal, but no convolution or
temporal derivative should be
set for this dummy EV.
-
FEAT says my design is rank deficient - why?
Rank Deficiency refers to the case when a combination of the EVs is
equal to (or close to) zero. This often occurs in very large design
matrices with temporal derivatives, as certain EVs are effectively the
same as a combination of other EVs, meaning that their parameter
estimates (strengths) cannot be uniquely determined. The default
threshold for the rank deficiency test in FEAT is quite conservative
and often the analysis can be performed successfully without problems
even when the rank deficiency warning occurs (especially for ratios
more than 10e-4). However, whenever the warning occurs the design
matrix should be examined, together with the matrices that depict
correlation and eigenvalues (see FSL
Course Slides
or the FEAT Manual
for some more information). High correlation between
semantically distinct EVs (shown as light values off the diagonal in
the correlation matrix) is an indication that a real problem exists in
estimating parameters of the specified design and such cases need to
be assessed individually.
Note that in the first level analysis in FEAT all EVs are demeaned and so combinations of
EVs which add up to a constant level (through time) before demeaning will end up as zero
and hence be rank deficient. For higher levels the EVs are not demeaned and so it is
possible to have EVs that add up to a constant, non-zero, regressor without problems of
rank deficiency.
-
What contrast should I use to get ...?
Contrasts are used to formulate statistical questions related to the
particular EVs used in an experiment. Consequently the construction
of contrasts varies greatly depending on the particular
experiment and question to be asked. Some standard t-contrasts exist,
such as [1 0 ... 0] which asks the question "when is the first EV's parameter estimate (PE) significantly greater than zero?", and similarly
for [0 1 0 ... 0] for the second PE and so forth.
Another common contrast is [1 -1 0 0 ... 0] which asks: "when is the first PE
significantly greater than the second PE?". As all t-contrasts are
thresholded looking for positive t values, the
previous questions refer to "greater than" and not "less than". In order to
ask "less than" questions, all that needs to be done is to reverse the signs
in the previous contrasts. For more information on t-contrasts and on f-contrasts, refer to the FEAT Manual or
to any standard reference on statistics and the General Linear Model (GLM).
What's the right terminology for "sessions", "runs" etc?
Of course - there's no "right" answer, but for consistency, let's
suggest the following:
- Study - the period (normally between 30 minutes and 2
hours) that a subject is in the scanner. A study may consist of
several sessions....
- Session / series / run - a continuous run of image
acquisitions, normally eventually saved by the scanner as a single raw
FMRI file. A session is the smallest "logical unit" of FMRI data that
can be analysed in its own right and would normally be saved on file
(after reconstruction) as a single 4D Analyze file pair. Thus we refer
to "single-session" or "first-level" analysis of such data.
- Block - normally a set of images during which the stimulus
state is constant - either constantly at "rest" or in a constant state
of activation.
- Cycle - a complete pattern of blocks. For example, if block
A is rest and block B is activation, a cycle is AB, and the session
might be ABABABABAB. If there is also a second kind of stimulation, C,
then the cycle might be ABAC, and the session might be
ABACABACABACABAC.
Thus a subject goes in the scanner for a study, during which
several sessions take place. Each FMRI session is made
up of a continuous run of images. In the case of a block-design
paradigm, the images are grouped into blocks of constant
stimulus state.
-
What does orthogonalisation of EVs mean, and when do I use it?
Orthogonalisation is a process of modifying an EV so that it does not
share any common signal with the other EVs present. Technically, the
vectors are altered so that they have zero dot product (i.e. are
orthogonal). When applying orthogonalisation in FEAT it alters the
current EV to be orthogonal to the specified EVs. This means that
any signal which this EV shared with the other EVs is, after
orthogonalisation, attributed solely to these other EVs.
Orthogonalisation should be used to prevent additional EVs changing the
parameter estimates (betas) associated with previous EVs. For example,
when adding a confound like a motion parameter it is desirable to
orthogonalise the confounds with respect to the EVs of interest.
This prevents the power in the activation signals being shared between
the EVs of interest and the additional confound. For more information
on orthogonality see the
FEAT Manual or the
FSL Course Slides.
-
When do you add temporal derivatives and what are they for?
Temporal derivatives are used to allow the model to fit even when the timing is
not exactly correct (e.g. the response is slightly before or after the specified timing).
This is useful in compensating for differences between the actual and modelled HRF (Haemodynamic
Response Function) as it is fitted on a per-voxel basis and so can also account for
regional differences in HRF.
Another common way to account for HRF differences is to use basis function sets
which perform the same function although they usually also allow for substantial changes in
the HRF shape as well as its timing. Technically the use of temporal derivatives is an
instance of basis functions and hence the theory for their estimation is identical.
-
What are the red lines in the registration results?
The red lines are edges from one image overlaid on top of the usual
grey-scale view of the other image. This is used to assess the
registration quality - a good registration should align the red lines
with the structural boundaries (major changes in grey-level) of the
other image. If there is substantial visible mis-alignment (e.g. in
the ventricle boundaries) then alternative settings of the
registration should be tried to improve the registration.
-
Can I use my own (study-specific) template image instead of the avg152?
Yes - simply replace the standard image (avg152T1_brain)
in the Registration tab with your own image. NB: make sure that
the template and input images have the same left/right convention.
-
Are the mm coordinates reported by FEAT in MNI space or Talariach space?
Technically they are in MNI space although most of the documentation, as well as many
publications, refer to it still as "Talairach" space.
-
How can I insert a custom registration into a FEAT analysis?
If you want to run any custom registrations outside of FEAT then you
should do the following in order to re-generate the FEAT registration
images and co-ordinate tables:
- First run FEAT including the normal FEAT registration.
- According to which part of the registration chain you want to
amend, overwrite example_func2highres.mat, highres2standard.mat,
example_func2initial_highres.mat or initial_highres2highres.mat in the
reg directory inside the FEAT output directory.
- Run
updatefeatreg <featdir.feat> -gifs - this
generates all the other transforms and registration summary images.
- Start
Feat and change the mode to run
Post-stats only. Select the FEAT output directory as
input. Go into the registration tab and turn off all
registration. Press GO. This will regenerate the tables with
activation co-ordinates in them.
-
How do I run FEAT on single-slice data?
The current version of FEAT works with single-slice data in the same
way as normal multi-slice data. It does not require any special settings.
-
How do I run higher-level FEAT when some inputs are first-level and some are higher-level?
For example, if you have some subjects where you have just a single
session, and some where you have a couple, and you want to do a
multi-subject higher-level analysis:
- Run all first-level FEAT analyses for all sessions and all
subjects, including running the normal registration.
- For each subject with more than one scan, run a higher-level
analysis for that subject's sessions, using fixed-effects stats
option. Use a group-mean
model (i.e., single EV, all 1s in that EV and a single contrast with a
single 1 in it).
- Now do the multi-subject higher-level analysis: Select the "Inputs
are 3D cope images" input option. For the single-session subjects,
choose the relevant subject.feat/stats/copeN image as input, and for
the multi-session FEATs that you have just run, select the relevant
subject.gfeat/copeN.feat/stats/cope1 image (note that N will be the
same in both cases). The rest of the higher-level settings are as
normal.
MELODIC
-
What is an Independent Component (IC) and how do I know what each one means?
Independent Component Analysis (ICA) attempts to split the 4D functional data into a set
of spatial maps, each with an associated time course. This is a way of breaking up the
original data set in a way which does not require the experimental paradigm to be
specified and hopefully separates out signals of interest from other signals or artefacts.
It is particularly useful when examining data where the timecourse of the response is
uncertain.
Ideally the result of running ICA will be a set of Independent Components (ICs), some of which
are clearly related to activation while some are related to other
physiological processes (e.g. respiration, resting-state signals, etc)
or to imaging artefacts (e.g. motion, ghosting, slice dropout, noise,
etc). An example of several different artefacts can be found in The
Little FMRI Shop of Horror. An example of some simple
activation-related signals can be found in the FSL
Course Examples. There is no automatic way of determining which
ICs are artefacts and which are not (since the process is model-free)
and some knowledge of the experiment (and standard artefacts) is
usually required to interpret the results.
Technically, ICA performs a linear decomposition of the original data,
such that when all the Independent Components (ICs) are added together
(each one being a 4D signal formed by the outer product of the spatial
map and timecourse) they equal the original data. This is a similar
concept to PCA but enforces independence between the components
spatially while PCA enforces orthogonality both spatially and
temporally. Note that in ICA for FMRI no relationship between the timecourses
is imposed - they can be very similar. In addition, MELODIC uses a
dimensionality estimation technique which separates out
much of the noise before performing the ICA, thus reducing the number of purely noise-driven
ICs in the output.
-
How do I use MELODIC to filter out unwanted components from my functional data?
To filter out unwanted components from the original data using MELODIC
you will need (i) the name of the original data, (ii) the mixing matrix that defines the decomposition
and (iii) a list of component numbers to remove. This is described more fully in an FSL Course Example.
In brief, the required command is:
melodic -i inputdata -v -o outputname.ica --mix=inputdata.ica/melodic_mix -f "a,b,c,d,e,f,..."
where inputdata has previously been run through MELODIC, creating the output directory
inputdata.ica and a,b,c etc. are the component numbers of the unwanted components found in
this ouptut.
Note: You need those doublequotes so that the entire list of numbers is passed to melodic as the argument
of the -f option!
-
How does MELODIC calculate the number of Independent Components (ICs)?
The number of components is calculated using Bayesian dimensionality estimation techniques, as
detailed in the FMRIB technical report TR02CB1.
Refer to this report for full details on this and other aspects of the probabilistic ICA method
used in MELODIC.
This dimensionality estimation is used by default in both the command
line and GUI versions. It can be turned off and the number of
components specified manually, although this is not recommended for FMRI data.
BET
-
BET does not give me good results - what can I do?
Firstly, check that the input image is OK. This can be
done using slices as described in the
first part of the flirt checklist.
If the image contains a lot of neck (large superior-inferior FOV),
then the default centre used by BET is often poor. This can be fixed
by using the -c option to select good centre coordinates.
Note that these coordinates are in voxels, not mm, so if you are using
voxel coordinates (starting at 0 in the corner) then you must multiply
these coordinates by the voxel dimensions - as the (0,0,0)mm point is
in the corner, not in the middle of the image.
If all of the above appears to be OK, then the main parameters to
alter in BET are the -f and -g parameters which can
cause general expansion or contraction of the brain segmentation.
Note that very local errors are unlikely to be fixed by varying these
parameters. For more information about these parameters see: What do the -f and -g options in BET do?
-
What do the -f and -g options in BET do?
The -f option in BET is used to set a fractional intensity
threshold which determines where the edge of the final segmented brain
is located. The default value is 0.5 and the valid range is 0 to 1.
A smaller value for this threshold will cause the segmented brain to be
larger and should be used when the overall result from BET is too small
(inside the brain boundary). Obviously, larger values for this threshold
have the opposite effect (making the segmented brain smaller). This
parameter does not normally need to be used, but sometimes requires
tuning for specific scanners/sequences to get the best results. It is
not advisable to tune it for each individual image in general.
The -g option in BET causes a gradient change to be
applied to the previous threshold value. That is, the value of
the -f intensity threshold will vary from the top to the
bottom of the image, centred around the value specified with the
-f option. The default value for this gradient option
is 0, and the valid range is -1 to +1. A positive value will
cause the intensity threshold to be smaller at the bottom of the
image and larger at the top of the image. This will have the effect
of increasing the estimated brain size in the bottom slices and reducing
it in the top slices.
-
Can I use BET with animal brains?
Past experience is that BET will work with brains from some animals,
like monkeys, but will not work well with others, like rats. What is
crucial is that there is a sufficient band of dark intensity (csf or
skull) surrounding the brain. When this is not true (e.g. because of
a relatively large brain stem/spinal cord) then the brain outline
tends to expand well beyond the brain boundary and is very obviously
wrong. In any case, the best strategy is to try BET on some example
images and see if it succeeds. However, it is necessary to use the
-c and -r options to make it work on non human-sized
brains. When setting these options note that (1) the co-ordinates of
the centre are most easily found using FSLView to select a position in
the middle of the brain, and recording the mm co-ordinate values, and
(2) for animals, the initial radius, set via -r, should be
set for the brain size, not the head size.
FLIRT
My FLIRT registration doesn't work well - what can I do?
There are many reasons why a registration may not work well. Here is
a general checklist of things to test and try in order to improve the
registration results (please do not post a query to the FSL email list
about registration results until you have gone through this list):
- Check that the input image looks fine and that the
voxel size is correct by (a) looking at the
images with slices (none of the views should look squashed
or stretched) and (b) checking the voxel dimensions (pixdim) with fslhd
(Note: voxel size can be fixed using fslchpixdim)
- Remove non-brain structures with BET from both images (Note that
small errors in the BET results will only have a very small impact
on the registration quality)
- Use the image with the best contrast and resolution as the reference
image. If this gives you the registration in the opposite direction
than you wanted then the result can be easily inverted using InvertXFM
or convert_xfm.
- For 2D images (single slices) you must use one of the valid 2D
degrees of freedom options (or -2D and appropriate schedules from the
command line - see below)
- If there is large bias field (slow intensity variation - especially
near the end slices) then try using fast to create a restored
image (one with no bias field) and then register using the
restored image.
- If there are relatively small errors in some crucial region of
interest (e.g. ventricles) then the registration may benefit from
using cost function weighting to enhance the importance of this
region. To do this a weighting image must be made which has the
value of 1.0 everywhere except in the region of interest where
a higher weight (e.g. 10.0) should be used. Using this weighting
volume in either the GUI or command line registration calls should
improve the fit in this region.
What determines the FOV and voxel size in FLIRT?
The reference image in FLIRT determines the Field of View (FOV) and voxel
size of the output image. This works in either registration mode (where
it is finding the transformation that aligns the input and reference
images) and also in applyxfm mode (where it is applying a saved transformation
to the input image). Note that only in registration mode does it use
the intensity information from the reference image. To apply saved
transformations, the GUI ApplyXFM can also be used which provides the
option of specifying the number of voxels and voxel size directly.
-
What cost function and/or degrees of freedom (DOF) should I use in FLIRT?
There are two main types of cost function: intra-modal (least squares and
normalised correlation) and inter-modal (correlation ratio and mutual information-based options). If you are registering two images of different modality
then you must use an inter-modal cost function, whereas for images
of the same modality either can be used, although the intra-modal options
may be more accurate. Within each category there is not much
to choose from - it is a practical, experience-based decision. The
recommended options (to try first) are: correlation ratio (which is the
default) for inter-modal and normalised correlation for intra-modal.
The choice of DOF (Degrees of Freedom) depends largely on whether the
images to be registered are intra/inter-subject and small/large FOV.
When the images are of the same subject then 6 DOF is appropriate
for large FOV and 3 DOF is appropriate for small FOV/single slice.
If the scanner voxel size may have changed (due to calibration shifts)
then it is appropriate to use 7 DOF instead of 6 (or 4 instead of 3)
to compensate for global scale changes. When the images are of
different subjects, including registering to standard space, then
12 DOF is appropriate for large FOV, and 6 DOF (using 2D schedule
files) for small FOV.
Note that for difficult registrations there is a translation only
schedule file which is effectively 3 DOF, but only includes x,y,z
translations. This is useful for obtaining initial position
estimates when matching small FOV to large FOV, and can then be
further refined.
How do I transform a mask with FLIRT from one space to another?
Transforming masks with FLIRT requires a little extra care. In
general you need to
rethreshold the transformed mask to make it into a binary
mask again.
To transform masks correctly the command line version of
flirt must be used.
For example, the commands you need to
transform a standard space mask into highres space are:
flirt -in standard_mask -ref highres -applyxfm -init standard2highres.mat -out highres_mask
fslmaths highres_mask -thr 0.5 -bin highres_mask
Note that flirt forces the output to be floating point, even when
the input is integer
and the thresholding and binarising done by fslmaths in the second
call.
The threshold used in the fslmaths should be set depending on
how conservative the output mask should be. These guidelines should
help in determining the correct value to use:
- a threshold near 1 (say 0.9) is conservative
only voxels in the new space that overlap by 90% with
the original mask will be included in the new binary mask
- a threshold near 0 (say 0.1) is liberal
any voxel in the new space that overlaps by 10% or
more with the original mask will be included in the new binary mask
- a threshold of 0.5 will (approximately) preserve the size of the original mask
any voxel in the new space that overlaps by 50% or
more with the original mask will be included in the new binary mask
The best choice of threshold will depend on the application in which the
mask is being used.
-
How do I do 2D (or limited DOF) registration with FLIRT?
A simple 2D registration (including translation in x and y and rotation
about the z axis) can be easily acheived by selecting the 2D-2D rigid
body (3 parameter model) option under model/DOF in the GUI, or by using
the -2D option on the command line (note that the dof does not
need to be set in this case).
Registrations with different numbers of DOF or different combinations
of parameters can only be achieved using schedule files and the command
line version of flirt. If the input images are 2D it is
still necessary to use the -2D option as well. For more
details see the section on available schedule
files.
Note that when the FOV is limited, but still 3D (multiple slices)
then 2D or limited DOF transformations
are normally required in order for the registration to be robust. In this
context a limited FOV is normally around 50% brain coverage or less.
-
Can I register to an image but use higher/lower resolution (voxel size)?
The registration and resampling stages in FLIRT are totally
independent. In the registration stage it tries to find the transformation
that best aligns the images, using a customised global optimisation
technique that operates over multiple resolutions. Once the best
transformation has been found the original input image is resampled,
using the transformation found previously, to match the reference image.
That is, the final output image will contain intensities derived from
the input image but will have a Field Of View (FOV) and voxel size
that matches the reference image. If a higher or lower resolution version
of the final image is required it is necessary to save the transformation
from the registration stage and then apply it in a separate stage where
a new reference is used to specify the desired voxel size and FOV.
In the FLIRT GUI, the transformation is automatically saved in a file
with an extension of .mat and this transformation can be
applied to the input image (for resampling) with the GUI
ApplyXFM which allows the output image voxel size and FOV to
be specified either directly or by using a reference image with the
appropriate size. Note that if a reference image is used it does
not have to be the same image as in the registration and in
fact the contents of the image (the intensities) are not used at all -
only the voxel size and FOV are used.
At the command line, the transformation can be saved using the -omat
option. This file can then be used for resampling by specifying it with
the -init and -applyxfm options. That is, the resampling
is done using flirt with the following syntax:
flirt -in inimage -out outimage -ref refimage -applyxfm -init savedtransform.mat
In this form the reference image is used to specify the voxel size and
FOV only - all intensities within it are ignored. To create a reference
image of the appropriate size, if none already exists, use fslcreatehd
to make a blank image (one filled with zeros) of appropriate dimensions.
Note that in previous versions fslcreatehd did not create an image,
only the .hdr part of an Analyze file.
Note that when changing the FOV rather than the voxel size, the bottom
left corner remains fixed. Hence, resampling to a smaller FOV will
tend to cut-off the portions of the image with large x, y or z coordinates
(near the right/top). In order to resample to a smaller FOV but keep
say the Centre of Volume (COV) in the centre of both images it is
necessary to add an extra translation to the transformation file. This
can be done by adding the appropriate offsets (in mm) to the values in
the right hand column (first row is x, second is y, third is z) of the
transformation (.mat) file - which is in plain text. The
appropriate offset to keep the COV constant is half of the difference
in the respective FOVs (in mm).
-
How do I do a two-stage registration using the command line?
The command line calls made in a two-stage registration of imageA to imageB to imageC are as follows:
flirt [desired options] -in imageA -ref imageB -omat transf_A_to_B.mat
flirt [desired options] -in imageB -ref imageC -omat transf_B_to_C.mat
convert_xfm -omat transf_A_to_C.mat -concat transf_B_to_C.mat transf_A_to_B.mat
flirt -in imageA -ref imageC -out imageoutput -applyxfm -init transf_A_to_C.mat
The above steps perform two registrations (the first two steps) saving
the respective transformations as .mat files, then concatenate
the transformations using convert_xfm, then apply the
concatenated transformation to resample the original image using
flirt. Note that the first two calls to flirt would normally
require the cost function or degrees of freedom (dof) to be set in the
desired options. In the final call to flirt the option
-interp is useful for specifying the interpolation method to
be used (the default is trilinear).
Also note that the FLIRT GUI outputs the command line calls used to effect
the two stage registration, and will be similar to the above, although
they will include specification of many of the default settings.
-
What are FLIRT schedule files?
A FLIRT schedule file controls the way that the optimisation is run
inside FLIRT. It consists of a list of statements in a basic
scripting language that was created for FLIRT. Several schedule
files are contained in the directory $FSLDIR/etc/flirtsch and
provide different levels of degrees of freedom control, such as
specific settings for 2D registrations. It is only possible to
perform 2D registration on the command line using schedule files
(via the -schedule option). A list of currently provided
schedule files is:
- sch2D_3dof - standard 2D registration with 3 DOF (1 rotation + 2 translation)
- sch2D_5dof - expanded 2D registration with 5 DOF (1 rotation + 2 translation + 2 scale)
- sch2D_6dof - expanded 2D registration with 6 DOF (1 rotation + 2 translation + 2 scale + 1 skew)
- sch3Dtrans_3dof - translation only 3D registration (x, y and z translation searched together)
- xyztrans.sch - same as sch3Dtrans_3dof
- ztransonly.sch - single z-axis translation registration
- simple3D.sch - reduced search form of normal 3D schedule (close to local optimisation only)
- pairreg*.sch - used for siena/sienax to register using the
skull scaling as a constraint
No support is provided for users to write their own schedule files,
but some limited documentation is available in
$FSLDIR/doc/flirt/schedule.html or at
www.fmrib.ox.ac.uk/fsl/flirt/schedule.html for those who want to understand more
or try their hand at writing new schedule files.
-
How do I make my own study-specific template image with FLIRT?
A study-specific template is an average image created from a set of
structural images which represent the particular study group. For the
population in general the standard template image, created from 152
individuals, is supplied as $FSLDIR/etc/standard/avg152T1.
However, for many applications this image will not represent the
study group very accurately, say due to differing age or disease.
Therefore it is desirable in these cases to create a study-specific
template image. An affine template image (as is the avg152T1)
can be created using the following steps:
- Choose a reference image from among the set
- Register each image in the set to the reference image, using flirt, and saving the output images
e.g. flirt -in im3 -ref imref -dof 12 -out imout3 -omat im3_to_imref.mat
- Average the output images together using fslmaths
e.g. fslmaths imout1 -add imout2 -add imout3 -add imout4 ... -add imoutN -div N avg_im -odt float
The final image, avg_im is the average, or template, image.
Note that it is advisable to check each registration manually, "by eye",
in order to make sure that the average template image is not corrupted
with a poor registration result.
More sophisticated schemes for making the target image less sensitive
to the choice of the reference image can also be carried out. The
simplest of these is to redo the registration and averaging using
the initial average image, from above, as the reference. This process
can be iterated several times if desired. Another alternative is to
perform all pair-wise registrations and choose the best consensus
registration, possibly using convert_xfm and rmsdiff
to detect and reject "outlier" registrations.
FUGUE
-
What type of field maps do I need for (PRELUDE and) FUGUE?
The fieldmaps required by FUGUE must be in undistorted coordinates.
That is, the field map should not have any geometric distortion
in it (or negligible amounts) as can be obtained from a spin-echo
sequence, or gradient-echo sequences if the echo time is
sufficiently small. The distortion present in a sequence can readily
be seen in the absolute (or magnitude) image and normally manifests
itself as a depression or extension of the inferior frontal lobes
(when the scans are acquired axially - it is different for other
acquisition planes).
It is recommended that a symmetric-asymmetric spin-echo sequence
is used for the field mapping. This sequence acquires one
conventional spin-echo image and then another with the same settings
except with the 180-degree RF pulse offset by a small delay, known
as the asym-time. The difference in the phase of the two images is
then proportional to the field offset.
Note that the input to PRELUDE, for phase unwrapping, must be
a complex image either presented as a single 3D or 4D complex
Analyze image or as a set of two 3D or 4D Analyze images - one for the
phase and one for the absolute (or magnitude) part. The input
to FUGUE must be a 4D Analyze image containing two unwrapped
phase maps. To convert
between 3D and 4D Analyze files the utilities fslmerge
and fslsplit can be used (see above). To convert between pairs of real
images and complex images, the utility fslcomplex can be
used.
-
How do I get a fieldmap sequence for my scanner?
We cannot provide field-map sequences for different scanners.
The recommended sequence is a symmetric-asymetric spin-echo
sequence as described above. If such a
sequence is not available at your site, try contacting the
FSL email list to see if others have a sequence for your
scanner that could be used.
FAST
How can I get the total volume of CSF/White-Matter/Grey-Matter from FAST?
The best estimate of volume for any of the segmented matter types is
obtained by summing up the partial volume estimates (PVE) which
should be saved as separate outputs using the -e and -ov options.
To obtain the sum, the easiest way is to use fslstats to get the
mean value and the total volume - the product of these values is
then equal to the desired volume. For example, if mybrain_pve_0
is the output corresponding to the CSF segmentation, then the
fslstats calls are:
fslstats mybrain_pve_0 -m
fslstats mybrain_pve_0 -v
The resulting mean value from the first call should then be multiplied by the
first output of the second call to get the volume in voxels, or by the second
output of the second call to get the volume in mm^3.
Note that to get a good estimate of intracranial CSF volume it is necessary
to use an input image to FAST that has good contrast between CSF and
skull. A T2-weighted image is suitable for this, but a normal T1-weighted
image is not.
What is the difference between partial volume estimation (PVE) and tissue-type probability in FAST?
Technically the probability maps give the probability that a voxel is
completely grey matter, or completely white matter, or completely CSF.
PVE on the other hand gives the best estimate of the proportion of grey matter,
white matter or CSF in a voxel.
Normally there is only a small difference between the two cases due to
the almost linear nature of the intensity mixing and also the
estimation methods. One practical difference in the estimation using
the -e (PVE) option is that it takes the partial volume vector for
each voxel and spatially regularises it using a second MRF. Therefore
this is likely to be closer to "the truth" than the simple probability
outputs.
-
How can I perform multi-channel segmentation with FAST?
To perform multi-channel segmentation it is necessary to have at least
two images (taken with different MR sequences - e.g. T1-weighted
and T2-weighted) which have already been registered and resampled
into a common space - normally the native space of one of the
inputs (see FLIRT for more details on registration). On the command
line, the utility mfast must then be used, whereas the
GUI for FAST deals with both single and multi-channel segmentation.
SIENA/SIENAX
-
What type of images can I use in SIENA/SIENAX?
Good quality structural images should be used (T1-weighted, T2-weighted, PD, etc)
where the in-plane resolution is better than 2mm (ideally 1mm). The slice
thickness is less critical and can be substantially larger than the in-place
resolution; see
test results from "normal" subjects which shows that the error is almost independent of slice thickness
in the range of 1mm to 6mm for 2D acquisitions.
Grey/White-matter contrast is not critical to the accuracy of the results as
the computations are done using the outer-grey matter surface and the
ventricle surface.
-
Can I get regional/local atrophy or change values using SIENA/SIENAX?
A regional breakdown of SIENAX results is available using the -r option.
This gives peripheral GM volume and ventricular CSF volume, using standard-space masks.
At present, research is being done to obtain finer regional
discrimination. However, in the short term, there are no plans to
release any code as to do that sensibly would require a much more
sophisticated integration of nonlinear registration and structural
segmentation. For the reasons given above it is likely that the
regional measurements are less accurate than the numbers
published for global measures (though within-subject repeatability
should be similar as the masking should be consistent).
SLICES
-
What are the red lines in the images from slices?
When two input images are given to slices it displays the first image
in grey-scale with edges from the second image overlaid in red.
FSLUTILS
-
What other utilities are available, and where is documentation for them?
The current list of utilities is: fsl2ascii fslanimate fslcc fslcheck
fslchfiletype
fslchpixdim fslcomplex fslcpgeom fslcreatehd fslfill fslhd fslinfo
fslinterleave fslmaths fslmeants fslmerge fslnvols fslorient fslroi fslsize
fslsplit fslstats fslswapdim fslval sliceanimate
Documentation for some of the most useful of these utilities can be found
at www.fmrib.ox.ac.uk/fsl/avwutils/index.html. Usage information, as with all FSL programs, can be
obtained by running the utility with no arguments.
-
What do the values of datatype in fslhd and fslcreatehd mean?
The datatype values refer to codes used in the Analyze format to specify the
type of data stored in the image. The valid values supported by FSL are:
- 2 = unsigned char [8 bit]
- 4 = short int [16 bit]
- 8 = int [32 bit]
- 16 = float [32 bit]
- 64 = double [64 bit]
Also, there is limited support (mainly in prelude, fugue and
fslcomplex) for:
- 32 = complex [64 bit as 2 by 32 bit floats]
