Version 2.2, Jan 28th, 2003
This
document serves to define the protocol for accessing information from the database
being maintained at
This
database is maintained by Ms. Ramya Balachandran. She can be reached as follows:
Postal:
Department of Computer Science
Deliveries/Courier:
Room 363
Jacobs Hall
Phone (US
Central Time Zone):
Office: 615-343-6259, 615-322-2365
FAX: 615-343-5459
1. MAKING THE FTP CONNECTION
All
information will be accessed via ftp.
The address is
ip1.vuse.vanderbilt.edu
or
129.59.88.43
Users
gain access by logging in. The Login
name is “images”. A password is
required.
2. THE STRUCTURE OF THE DATABASE
The
database structure is effected via the UNIX directory tree. The tree is
organized as indicated by this schematic:
registration--\
|
|--admin-----------\
| |
| |
| |
| |--doc------------\
| | |--README
| | |--format.txt (this document)
| | |--transformations.txt
| | |--ftp.script
| | |--paper.ps
| | |--paper.ps.Z
| | |--paper_text.ps
| | |... (future additions)
| |
| |--news--\
| | |
| | | 96-08-01 (name = date of news item)
| | |
| | |
| | ... (future additions)
| |
| |
| |-templates--\
|
|--patient_001--\
| | |--ct.trans
| | |--pet.trans
| |
|
|--patient_002--\
| | |
| | ...
| ...
| |
|
|--patient_101--\
| | |--ct.trans
| | |--MP-RAGE.trans
| ...
|
|--images--\
|
|--README
|
|--patient_001--\
| |
| |----ct---\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |---pet---\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_T1--\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_PD--\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_T2--\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_T1_rectified--\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_PD_rectified--\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_T2_rectified--\
|
|--header.ascii
| |--image.bin
|
|--image.bin.Z
|
|--patient_002--\
| |
| |----ct---\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| ...
|
...
|
|--patient_101--\
| |
| |----ct---\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_MP-RAGE-\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_T1------\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_PD------\
| | |--header.ascii
| | |--image.bin
| | |--image.bin.Z
| |
| |--mr_T2------\
| |--header.ascii
| |--image.bin
| |--image.bin.Z
...
|
|--fiducial--\
|--patient_001--\
| |
| |----ct---\
| | |--image.bin
| | |--image.bin.Z
... ...
|
|--standard--\
| |--patient_001--\
| | |--ct_PD.trans
| | |--ct_T1.trans
| ... ...
(N.B. A
separate login and password is required for access to the 'fiducial' directory
tree.)
3. THE FILE FORMATS
3.1. Two files = one
image
Each image
will consist of two files, a header file and a data file. The header is in
ASCII with lines separated by line feeds.
The data file is a stream of two-byte two's complement integers. The two file names will be always be as
follows:
header.ascii
image.bin
The
suffix “ascii” indicates that the file is a text file coded in ASCII. The
suffix “bin” indicates that the file is a stream of binary numbers. The numbers
are encoded as two-byte two's complement integers. The byte order is big-endian. This order is the standard for Sun
workstations. Odd and even bytes must be interchanged for DEC VAX computers and
Intel 80x86 microprocessors.
An
additional file named
image.bin.Z
will be
included for convenience. The contents
of image.bin.Z are redundant: It contains a compressed version of
image.bin. It is produced with the UNIX
“compress” command. The UNIX compression
algorithm is lossless and can be reversed with the UNIX “uncompress”
command. This file is provided so that
file transfer time can be reduced for those with access to the UNIX compression
programs.
3.2. The voxel file
The
“.bin” file contains the voxels in row-column-slice order, meaning that the
first voxel in the file should be displayed in the upper left of the screen, the second voxel should be
displayed to the right of the first,
etc., until the end of the row is reached. The next voxel should be displayed below the
first voxel of the file, the next to the right of that, etc., until
one
complete slice is displayed. The first
voxel of the second slice follows the last voxel of the first slice, etc.
The
number of rows, columns, and slices is given in header.ascii. If the number of rows, columns, and slices
were, for example, 3, 5, 2, the 30 voxels of the image.bin file (each of which
occupies two bytes) should be displayed as follows:
Display of slice 1---
1
2 3 4
5
6
7 8 9 10
11
12 13 14 15
Display of slice 2---
16
17 18 19 20
21
22 23 24 25
26
27 28 29 30
(Once
this canonical display orientation is understood, other display orientations
are reasonable as long as they represent proper rotations from this basic
orientation.)
3.3. The header file
Our
header format is an adaptation of the guidelines outlined in the appendix to
Technical Report No. CUCS-369-88,
3.3.1. The information
groups
Each
header is organized into five groups.
Each group is organized into a set of keyword-value pairs separated by
“:=”. The first keyword in every group
is “Group length”:
Group length := n
Here n is
the number of bytes following that line and extending through the rest of the
entries in that group. Each group is
followed by a blank line (one extra line feed).
All five
groups are present in each image header, and they occur in the same order as
follows:
1. Identifying Information
2. Patient Information
3. Acquisition Information
4. Relationship Information
5. Image Presentation Information
These
group labels are not included explicitly in the header. They are listed as types of information
prescribed in Table 4-1 of the ACR/NEMA standard. (The guidelines of Maguire and Noz deal with
these types in subsections 3.3 through 3.6.)
3.3.2. Detailed group
descriptions
Each
group name is terminated with a colon here, but with := in the header
file. Sets of possible field values are
given within braces ({}) here. Descriptions of the meaning of the field are begun
here with a double slash (//).
3.3.2.1. Identifying
Information
Group length: //The number of bytes in
the rest of the group
Length to end: //the number of bytes in the rest of the header file
Modality: {MR,
CT, PET}
Manufacturer: {Siemens} //the manufacturer of the scanners in this
project
Institution ID: {
Comments: //a message to serve as a
reminder that the images may not used outside this project.
3.3.2.2. Patient
Information
Group length: //The number
of bytes in the rest of the group
Other Patient ID: //a serial number used only
for this project.
Comments: //a message stating that
“Other patient ID” is unrelated to the actual patient ID.
3.3.2.3. Acquisition
Information
Group length: //The number of bytes in
the rest of the group
Contrast/Bolus agent: //The value is
“none” if there is no contrast agent.
Scanning sequence: {SE} //This line
is present only for MR; only SE, meaning “Spin Echo”, is used in this project.
Radionuclide: //This line is
present only for PET; it is the name of the isotope administered.
Slice thickness: //The units are millimeters.
KVP: //This line
is present only for CT; it is the tube voltage.
Repetition time: //This line is
present only for MR; it is TR in milliseconds.
Echo time: //This line is
present only for MR; it is TE in milliseconds.
Number of averages: //This line is
present only for MR; it is the number of acquisitions without change in any
parameters (to reduce noise).
Gantry tilt: //This
line is present only for CT and PET; machine's tilt.
Exposure time: //This line is
present only for CT; units are milliseconds.
Exposure rate: //This line is
present only for CT; units are milliamperes.
Comments: {T1,PD,T2}
//This line is present only for MR; it labels the image as T1, PD, or T2
weighted (as determined by the TR and TE values).
3.3.3.4 Relationship
Information
Group length: //The number
of bytes in the rest of the group
Study: {1, 2, 3, 4}
//a set of series of one modality
Series: {1, 2, 3}
//a set of logically related acquisitions
Acquisition: {1, 2} //a
single continuous gathering of data over time
Patient Orientation: {L : P : H}
//indicates three directions within the patient: toward the Left, toward the
Posterior, and toward the top of the Head, respecti
same orientation
will be used throughout this project.
Source image IDs: //This line is
present only for rectified MR; it gives the Study\Series\Acquisition for each
of two images, one with forward and one with reverse readout
gradients. These are the two images that are used to
construct this image.
Modified
image description: {Rectified image} //This line is present only for rectified
MR.
Comments: //This line
is present only for rectified MR; it states that the image is a composition of
two acquisitions.
Only the
following nine combinations of Study\Series\Acquisition will be present in the
database of images in this project:
1\1\1 = CT
2\1\1 = PET
3\1\1 = MR-T1
3\2\1 = MR-PD
3\3\1 = MR-T2
4\1\1 = Rectified MR-T1
4\2\1 = Rectified MR-PD
4\3\1 = Rectified MR-T2
5\1\1 = MP-RAGE
(The
registration tasks will be to register each of the first two image types, CT
and PET, to each of the last six MR types for a total of 12 registrations per
patient.)
In the
value field of Patient Orientation three letters are given. These three letters
indicate the orientation of the patient relative to the volume image. The first letter indicates the direction that
corresponds to an increasing column index (along a row to the right on the
display screen according to the canonical display described above). The second letter indicates the direction
that corresponds to an increasing row index (down a column in the canonical
display). The third letter indicates the
direction that corresponds to an increasing slice number.
The 30
voxel file described in Section 2 provides a convenient example. We assume that
the Patient Orientation field is L : P : H.
Then the view displayed above is transverse as seen from the patient's
feet with the patient's nose up,
Display of slice 1, which is closer to the
bottom of the feet---
Anterior
----------------------------
|
1 2 3
4 5 |
Right |
6 7 8
9 10 | Left
| 11 12
13 14 15 |
----------------------------
Posterior
Display of slice 2, which is closer to the
top of the head---
Anterior
---------------------------
| 16 17
18 19 20 |
Right | 21
22 23 24
25 | Left
| 26 27
28 29 30 |
--------------------------
(In addition
to L, P, and H, the following letters are defined in the ACR-NEMA standard: R
for “toward the Right”, A for “toward the Anterior”, F for “toward the bottom
of the Feet”.)
3.3.3.5. Image
Presentation Information
Image dimensions := {3} //Always 3 in this
project.
Rows := {128,256,512}
//Number of rows in each slice
Columns := {128,256,512}
//Number of columns in each slice
Slices := //Number of
slices in the volume
Pixel size := 1.250000 :
1.250000 //The units are millimeters.
Compression code := //The .Z extension
indicates compression via the Unix compress command, employs adaptive
Lempel-Ziv coding.
Bits allocated := {16} //Before
compression
Bits stored := {16} //Before compression
High bit := {15} //Most significant bit;
Pixel representation := {1} //1 means two's complement integer
Smallest pixel value := -65,536 //equals -2^16
Largest pixel value := +65,535 //equals +2^16
- 1
(If the
reader is not interested in the ACR-NEMA guidelines per se, s/he need read no
further.)
While it
is not crucial to this project, it may be of interest to know that the
numbering used in the Relationship Information is an adaptation of the ACR-NEMA
guidelines. As shown in Figure 1 on the
next page, the labels are hierarchically related via a hierarchy defined in
those guidelines. (Those familiar with
this hierarchy will notice that we have not followed the guidelines
strictly. The guidelines dictate that
the subclass, “Image” should be included below the class Acquisition. We have omitted this finest division for
simplicity.)
The eight
image types that are listed above (i.e., the ones that occur in the database) are
denoted in the figure by asterisks (*).
The images without asterisks are additional MR images (with reversed
readout gradients) that are required for the production of the rectified MR
images.
The
values for Study\Series\Acquisition are given in brackets with each
acquisition.
Patient--
|--Study 1--(CT)
| |
| |
| |--Series 1--
| |
| |--Acquisition 1* [1\1\1]
|
|
|--Study 2--(PET)
| |
| |
| |--Series 1--
| |
| |--Acquisition 1* [2\1\1]
|
|
|--Study 3--(MR)
| |
| |
| |--Series 1--(T1)
| | |
| | |--Acquisition 1* (Forward gradient)
[3\1\1]
| | |
| | |--Acquisition 2 (Reverse gradient) [3\1\2]
| |
| |
| |--Series 2--(PD)
| | |
| | |--Acquisition 1* (Forward gradient)
[3\2\1]
|
| |
| | |--Acquisition 2 (Reverse gradient)
[3\2\2]
| |
| |
| |--Series 3--(T2)
| |
| |--Acquisition 1*
(Forward gradient) [3\3\1]
| |
| |--Acquisition 2 (Reverse
gradient) [3\3\2]
|
|
|
|--Study 4--(Rectified images derived
as composites from Study 2)
|
|
| |
| |--Series 1--(T1)
| | |
| | |--Acquisition 1* (from 3\1\1 and
3\1\2) [4\1\1]
| |
| |
| |--Series 2--(PD)
| | |
| | |--Acquisition 1* (from 3\2\1 and
3\2\2) [4\2\1]
| |
| |
| |--Series 3--(T2)
| |
| |--Acquisition 1* (from 3\3\1 and
3\3\2) [4\3\1]
|