|
|
|
|
|
|
Method 1: Create datasets with program to3d
[principal subject of this talk] |
|
Input files are arrays of numbers ---
i.e., image files |
|
Method 2: Realtime input from an
external image source program (e.g., directly from scannerÕs reconstructed
images) |
|
AFNI program Imon reads image files
from GE realtime EPI output, checks them for various errors, sends them into
AFNI for display and formatting --- while acquisition continues |
|
Sample program rtfeedme can be used to
write your own image source program |
|
Method 3: AFNI programs can read other
formats for display and analysis |
|
ANALYZETM 7.5 format Þ.hdr/.img file pairs |
|
Used by SPM and many other programs |
|
Major drawback: lack of spatial
orientation and position information in header |
|
Can be difficult to overlay ANALYZE
datasets with other datasets |
|
MINC format Þ .mnc files |
|
Used by software from Montreal
Neurological Institute --- mnitools |
|
CTF format Þ .svl files |
|
Generated from CTF MEG data analysis
software package |
|
|
|
|
|
Dataset stored as columns of
ASCII-formatted numbers Þ .1D and .3D files |
|
Used to store datasets when knowing
where the data points are in space isnÕt important for the analysis |
|
Example: node-wise analysis of group
data on surfaces |
|
Each column corresponds to one
sub-brick |
|
Each row corresponds to one voxel or
node |
|
.1D files: just columns of numbers |
|
.3D files: contain an XML header with
geometrical information |
|
NIfTI-1 format Þ .hdr/.img file pairs or .nii files |
|
New format, modified from ANALYZE 7.5
compatible programs |
|
Supposed to be mostly compatible with
ANALYZE 7.5 compatible programs |
|
Format finalized late 2003; will be
supported by SPM, AFNI, FSL, Brain Voyager |
|
Method 4: Output of most AFNI programs
is AFNI-formatted datasets Þ .HEAD/.BRIK file pairs |
|
AFNI utility programs exist to re-write
AFNI-formatted datasets into ANALYZE, MINC, and .3D formats |
|
In the future, AFNI programs will be
able to write out NIfTI-1 .nii formatted datasets directly |
|
|
|
|
|
|
to3d reads image files -- each
containing 1 or more 2D slices -- and assembles them into AFNI datasets |
|
The collection of all the 2D slice data
forms the .BRIK file |
|
An AFNI dataset can contain a single
slice |
|
You must also provide to3d with some
auxiliary data (for the .HEAD file): |
|
Orientation of slices in space |
|
Size of slices or of the voxels |
|
Slice offset -- where is the dataset
volume located in space? |
|
For 3D+time datasets, you also need
slice timing information |
|
to3d ÔknowsÕ how to get some of this
auxiliary information from image file headers for some image file formats: |
|
ANALYZE 7.5 .hdr/.img pairs contain
voxel size information |
|
Siemens .ima Files contain voxel size
and orientation information |
|
GE I. Files contain voxel size and
orientation information |
|
DICOM Files contain lots of relevant
information |
|
But manufacturersÕ variations on DICOM
are frustrating |
|
|
|
|
|
to3d runs in two modes: |
|
Command line mode: you provide all
auxiliary information on command line |
|
Graphical interface (GUI) mode: you
provide auxiliary information by filling out an on-screen form |
|
Sample Study: data from NIH GE 3Tesla
Scanner |
|
Files stored in directory AFNI_data1/ |
|
Anatomical (SPGR) data Þ 3D dataset (no
time; 1 sub-brick) |
|
124 sagittal slices in subdirectory SPGR_anat/ |
|
Functional (EPI) time series data Þ 3D+time dataset
(110 sub-bricks or time pts) |
|
2970 images (27 sagittal slices, 110
reps) in subdirectory EPI_run1/ |
|
Visual motion task: Videos of moving
humans and tools (Beauchamp et al, 2002): |
|
|
|
|
|
|
Using to3d to assemble the EPI 3D+time
dataset: |
|
cd ../EPI_run1 ---> change directory
to get at images |
|
ls ---> to see what files are there
(should see files I.0001 . . . I.2970) |
|
We do not just do to3d I.* to create a
3D+time dataset |
|
For historical reasons, the time-axis
information must be given on the to3d command line. |
|
Cannot be modified from the GUI |
|
Command line: to3d -time:zt 27 110 0 alt+z I.* |
|
-time:zt Þ slices usually presented in
order of space (z), then time (t) |
|
-time:tz is needed at some sites |
|
If in doubt, do to3d I.* or aiv I.*,
use viewer to look at slices and see their order [aiv = AFNI Image Viewer
program] |
|
27 110 Þ
there are 27 slices in z and 110 in t
(2970 total) |
|
0 Þ
the TR for volume acquisition will be read
from the image headers |
|
If not available, could put 2.5s or 2500
instead of this 0 |
|
alt+z Þ
slices are gathered in alternating order
in the +z direction |
|
Most EPI acquisitions are really 2D
multislice, spread out through time |
|
AFNI header can contain information
about slice timing offsets |
|
Other possible modes: zero (for 3D), @filename
(to specify each slice) |
|
|
|
|
|
Imon can be run during a scanning
session on a GE scanner, to monitor the collection of time series I.*
files. The user is notified of
any missing or out-of-sequence slices |
|
Imon can also be run separate from
scanning, either to verify the integrity of I.* files, or to create AFNI
3D+time datasets by using the -GERT_Reco2 option |
|
Imon is run in command line mode |
|
The -GERT_Reco2 option is added to the
command line so that I.* files examined by Imon can then be assembled into an
AFNI 3D+time dataset |
|
When not being used in real-time mode,
the -quit option is added so that Imon will terminate after processing all of
the I.* files |
|
|
|
|
|
|
Why not use to3d directly to create
AFNI datasets? |
|
EPI images collected using GEÕs real
time EPI sequence are saved in a peculiar fashion |
|
Only 999 image files can be stored in a
single directory |
|
If a run consists of 110 volumes of 27
slices each, we have 2970 image files |
|
With a limit of 999 I.* files per
directory, a run made up of 2970 images would have to be saved in 3 separate
directories (numbered 001/, 021/, and 041/): |
|
E.g., 001/I.028ÉI.999 + 021/I.001ÉI.999 + 041/I.001ÉI.999 = 2970 I.* files total |
|
The second run would be stored in
directories 061/I.001 Þ 101/I.973, the third
run in 101/I.974 Þ 161/I.946, and the
nightmare continuesÉ |
|
This setup already makes it difficult
to delineate between runs. Now
image what happens if the scanner hiccups, if you stop a scan in the middle
and start a new one, or start collecting scans with a different number of
slices! |
|
Imon attempts to identify complete
scans from the images in those directories. It also monitors missing or out-of-order images, and
generates the commands necessary to turn them into AFNI bricks using the
script GERT_Reco2 |
|
|
|
|
|
|
Using Imon to assemble the EPI 3D+time
datasets |
|
cd ../EPI_manyruns Þ change
directory to get at GE subdirectories containing images |
|
ls Þ to view the GE subdirectories containing 4 runs worth
of I.* files |
|
Directories are numbered in multiples
of 20 (default naming system used by the GE scanner): 001/ 021/
041/ 061/. . . 201/ 221/ |
|
Command line: Imon -start_dir 001 -GERT_Reco2 -quit |
|
-start_dir specifies the starting
directory where Imon will begin monitoring the images. In this example, our start directory
is 001/ |
|
-GERT_Reco2 will create a script called
ÔGERT_Reco2Õ, similar to the one that program Ifile creates (for more info on
Ifile, type Ifile -help). |
|
The GERT_Reco2 script may be run to
create the AFNI datasets corresponding to the I.* files |
|
-quit will terminate Imon, after all
image files have been examined, |
|
If -quit is not used, the program will
forever wait for more images,
until <ctrl-c> is used to terminate the program |
|
For a full list of Imon options, type Imon
-help |
|
|
|
|
ls EPI_manyruns Þ to view the
newly created GERT_Reco2 script |
|
This script contains the commands that
will automatically create bricks from the complete scans and store them in a
newly created subdirectory called afni/ |
|
To run the script, type ./GERT_Reco2 |
|
|
|
cd afni Þ to get at datasets |
|
ls Þ to view the AFNI 3D+time datasets: |
|
Outbrick_r1+orig.HEAD Outbrick_r1+orig.BRIK |
|
Outbrick_r2+orig.HEAD Outbrick_r2+orig.BRIK |
|
Outbrick_r3+orig.HEAD Outbrick_r3+orig.BRIK |
|
Outbrick_r4+orig.HEAD Outbrick_r4+orig.BRIK |
|
|
|
|
|
On Linux/Intel computers: the peculiar
appearance of images shows that something is wrong: |
|
MR images from scanners that are stored
as shorts: 2 bytes per number |
|
Like a 2-digit decimal number: Ò93Ó
means Ò9 x 10 + 3Ó |
|
By universal custom, we write the Ò9Ó
first |
|
Could also write the same number as
Ò39Ó (if we had a different custom) |
|
Customs for computers are not so
universal |
|
Sun and SGI systems store 2 byte
numbers in reverse order from Intel |
|
Result is that numbers are mangled (and
some show up as negative) |
|
Solution: press to3dÕs [Byte Swap[2]]
button and images are fixed! |
|
|
|
|
|
Screen shot above shows correct
orientation for this dataset |
|
Use the image viewing window to judge
how images are laid out |
|
Click the arrows to scroll through the
6 possible options for each orientation to set correct values |
|
Òx orientationÓ of dataset is across
the screen (Anterior to Posterior) |
|
ÒyÓ orientation of dataset is down the
screen (Superior to Inferior) |
|
ÒzÓ orientationÓ of dataset is in
increasing slice order (from Left to Right) |
|
Must know subjectÕs right from left
(from experiment log sheet or vitamin E tablet placed on one side of the
head) |
|
Determine this by using the slider at
the bottom of image window |
|
|
|
|
To set dataset geometrical
size/location, experiment log sheet is essential |
|
Screen shot above shows setting slice
thickness to 1.2 mm |
|
Default Field of view (FOV) of 240 mm
is correct for these images |
|
The default voxel geometry is
ÒcubicalÓ, which is incorrect for this example |
|
Must set geometry to ÒsquareÓ (x size =
y size, z size different) |
|
Then set Òz voxel sizeÓ to correct
value (by typing in box) |
|
Screen shot shows setting of first
slice to 70.0 mm in Left (L) direction |
|
Default is that slices are centered in
the magnet |
|
This default is usually not the case in
the z direction |
|
Click Òz axis centeredÓ off |
|
Enter offset (here 70.0 mm) into the Òz
originÓ box |
|
|
|
|
|
Geometry parent lets you copy the
geometry data from a pre-existing dataset and apply it to the dataset now
under construction |
|
Enter name of pre-existing dataset into
[Copy geometry of this dataset] field |
|
If in another directory, you must
include that in the filename |
|
When you press ÔEnterÕ or move the
cursor from the text-entry field, to3d tries to read geometry parent dataset
header |
|
If geometry parent has same spatial
dimensions as current dataset, all geometry fields will be filled out |
|
Does not affect the time fields, which
must still be set using -time:zt or -time:tz on the
command line |
|
Geometry parent very useful when
constructing multiple EPI datasets from a single scanning session |
|
Using to3d in command line mode |
|
You can specify all needed inputs to
to3d by using command line options |
|
For a full list of options, type to3d
-help |
|
If enough information is present on
command line to define a dataset, then the GUI will not be opened, and the
dataset will be written to disk |
|
If the command line is incomplete, then
the GUI will be opened |
|
|
|
|
|
|
For the SPGR dataset example (ÔnakedÕ
image files): |
|
to3d -xFOV 120A-P -yFOV 120S-I
-zSLAB 70.0L-77.6R \ -prefix anatNaked -2swap -spgr N.* |
|
-xFOV 120A-P says that the x axis of
the images runs from 120 mm Anterior to 120 mm Posterior |
|
-yFOV 120S-I says that the y axis of
the images runs from 120 mm Superior to 120 mm Inferior |
|
-zSLAB 70.0L-77.6R says that the z axis
of the slices runs from 70 mm Left to 77.6 mm Right |
|
FOV refers to the coordinates of the
outer edge of the first voxel to the outer edge of the last voxel along the
relevant axis (x and y, in most cases) |
|
SLAB refers to coordinates of the
center of the outermost voxels (z=slice direction, in most cases) |
|
-prefix anatNaked gives the prefix for
output dataset filenames (in this case, anatNaked+orig.HEAD and anatNaked+orig.BRIK) |
|
-2swap means to byte-swap the images
while reading them |
|
-spgr means to label this data as being
of SPGR (SPoiled GRass) type |
|
N.* means to read the images from the
files whose names start with string ÒN.Ó and end with anything (Ò*Ó is a
wildcard) |
|
|
|
|
|
For the EPI dataset example (if image
files were ÔnakedÕ): |
|
to3d -xFOV 120S-I -yFOV 120P-A -zSLAB 69.0R-61.0L
-2swap \ |
|
-time:zt 27 110 2500
alt+z -prefix epiRun1 -epan I.* |
|
(this is all on one command line) |
|
Options (with their arguments) can
appear in any order |
|
Input image filenames always appear
last (i.e., I.*) |
|
Conclusion |
|
With practice, command line usage for to3d
becomes more useful than the GUI |
|
Usually need to create many datasets at
once |
|
Can put commands in a script file and
execute them |
|
Then edit the file to change a few
things, and run it again |
|
Just create the file with your favorite
UNIX text editor (emacs, nedit, vi), typing each command on a separate line |
|
Long commands can be split across
multiple lines by ending all but the last line with the Ò\Ó character |
|
There must not be a blank after the Ò\Ó!!! |
|
You can execute a script file by typing
a command like tcsh <filename>, which just means to read commands from
ÒfilenameÓ |
|
As time goes on, you build up a set of
scripts that automate various tasks for you, and ensure you do things the
same way each time |