rview/mmvreg/vxload.lib:
Volumetric Medical Image File Format Support
Scanner/PACS Formats:
Image Processing
Formats:
Colin Studholme, Jan 1998,
Oct 1999, April 2000, August 2000, Nov 2001, 2003, 2004...2007...
Note: To ensure the software correctly
detects slice acqusition orientation
(left-right/ up down etc) it is recommended to use DICOM or NIFTI
(if slice info is correctly encoded in the header) input formats.
Picker SPECT Image Files
Picker files with
XP3000, 3000, 2000, AXIS and PRISM formats are recognised (by the
presence of these names as text starting at byte 2 of the files) . A
Picker SPECT volume image consists of a single file. Voxel dimensions
should be read directly from
the format along with the following image information:
- Patient Name
- Patient ID (MRN)
- Acquisition Date
- Acquisition Time
- Reconstruction Date
- Reconstruction Time
Using GE SIGNA MR Image Files
Many (but not all!)
SIGNA 5.x and 3.x MR Image files are recognized. A SIGNA volume image
consists of a set of single slice files within a directory. Signa 5.x
formats consist of the following looking file names:
E111111S1I1.MR
E111111S1I2.MR
...
Signa 3.x formats
consist of the following looking file names:
i.001
i.002
...
It is possible to load
either format directly if all the files for the image volume to be
viewed are stored in the same directory. Do not drag all these files
onto rview but one file (eg slice 1: the actual number is not
important) only. Along with the voxel separation, the following image
properties are read automatically:
- Patient Name
- Patient ID (MRN)
- Acquisition Date
- Acquisition Time
- Slice Orientation
(not fully tested!)
- Slice Order (not
fully tested!)
Using GE
SIGNA
Horizon LX
This is the non-DICOM
format which is exported from the Signa Horizon LX database. It is
closely related to the SIGNA 5x format with fixed header locations. It
is not fully implemented but the following are read directly:
- Voxel Dimensions +
(inc. slice thickness and slice separation)
- Patient Name
(often blanked: see exporting software)
- Patient ID (MRN)
(often blanked: see exporting software)
The following are not
yet supported by the reading software:
- Slice Orientation:
ASSUMED TRANSAXIAL
- Acquisition Date
and Time
As with Signa 5.x formats
the data should arrive in a multi-file format with one slice per file.
Following exporting from the database, the files for an image volume
should all be in the same directory and be named with a similar format
to 5.x such as:
e10s2i1
e10s2i2
e10s2i3
e10s2i4
e10s2i5
...
Specifying one of these
slices will load the entire volume. In general, as long as the last
number in the filename is the slice, then the files should load ok.
Using
Siemens
Vision Magnatom MRI Data
This is the non-DICOM
format which is exported from Siemens Magnatom Vision MRI scanner's. It
is not fully
implemented but the following are read directly:
- Voxel Dimensions +
(inc. slice thickness and slice separation)
- Patient Name
(often blanked: see exporting software)
- Patient ID (MRN)
(often blanked: see exporting software)
- Scan Acquisition
date.
The following are not
yet supported by the reading software:
- Slice Orientation:
ASSUMED TRANSAXIAL
- Acquisition Time
As with GE Signa formats
the data should arrive in a multi-file format with one slice per file.
Following exporting from the database, the files for an image volume
should all be in the same directory. Each slice file should have a name
ending with a '.' followed by a three digit number increasing with
slice number for example:
AD509-9.001
AD509-9.002
AD509-9.003
...
AD509-9.160
Specifying one of these
slices will load the entire volume. In general, as long as the last
number in the filename is the slice, then the files should load ok. The
image volume is constructed only from those slice files which are in
the consecutively numbered sequence around the supplied slice file name.
Note: BEWARE
Slice ordering and patient orientation are still not completely
supported or tested!
Using DICOM
Image Files
Some (but certainly not
all!) DICOM Image files are recognised and read by rview directly. As of rview version 8.130B the dicom
reader has been re-written to handle the file format more robustly.
(but probably still not perfect!). The files no longer have to be named
or numbered in any particular order e.g. slices can be named:
S87835987354
S55388888444
img999.dic
778884.img
etc...
As in earlier versions,
and with any other multi-file image format in rview/vxload.lib: Simply
select and drag ONE
slice/image file
from the volume to
load the ENTIRE volume. rview
(should) read the entire contents of the directory (folder) containing
the slice file you selected and work out which images correspond to
the same series/acquisition and study as the slice file you selected.
It should then hopefully load all these images.
rview should be able to estimate the following information from DICOM
data:
- Number of Pixels,
Slices and Frames.
- Voxel Dimensions
(from the slice spacing/field of view and image location vectors).
- Max and Min Data
Values [which are used to initialize colour lookup display).
- Patient Name/ Scan
Date/Time
- Slice Orientation
and order with respect to Subject (i.e. should display
transaxial/coronal/sagittal) correctly
- Should Separate
Multiple MRI Echos into different volumes (and only load the echo
slices corresponding to the slice file you selected to load)
- Should support
(some) gantry angles in CT.
- Should support Big
and Little Endian Byte Orders (As of rview Version 8.131B)
WARNINGS/NOTES:
1.When loading the images, rview checks all slice files in the folder
to
see which ones
correspond to the same acquisition volume:
This can take a LONG time for dicom
folders containing many files
(sometimes >1000!, particularly from CD/DVD/or networked drives):
It is therefore advisable to organize groups of slices for a
given
acquisition
or study into separate folders prior to loading into rview.
2. Please check the slice orientation (left right) and slice thickness
for
your scanner/acquisition type when trying for the first time:
There are so many redundant and inconsistent ways of
encoding
slice separation, rview (and me) sometimes
gets confused!
3. Remaining problems seen (V8.130B) :
Some multi-frame/time acquisitions (EG some
perfusion and fmri EPI data) not recognised correctly:
Either 1 slice only loaded or: When dual
acquisitions stored, both are loaded and interleaved
(voxel dimensions are mis-calculated and twice the
number of slices loaded)
4. Don't rely on other software to convert DICOM to analyze and then
load the analyze files into rview:
Incorrect conversion of voxel dimensions by other
format conversion programs
has resulted in many badly (and also subtly)
mis-registered datasets
which are not the fault of rview but the conversion
software used!!!
(eg left-right swapped or voxel dims set to 1mm when
should be 1.05mm !)
If rview doesn't load your data: send me examples of
the data and I will try and fix the problem
so everyone who uses rview will benefit.
5. There is still currently no support for internal DICOM compression
(but you can load unix compressed (.Z) DCIOM slices)
Using
Mayo-Analyze
Image Files
Analyze image files (16
bit signed and unsigned only) can be both read from and written to. The
images consist of a header file (.hdr) and a data file (.img). Both the
header and
image data files must be in the same directory. To load the analyze
files,
drag the header (.hdr) file into the main window. It is not
possible to
load an analyze data file (.img) directly, it can only be loaded
indirectly via the header file (this is because
rview has to support other older medical image formats that also use
the .img extension, and there is no safe way of distinguishing these
from raw analyze format files! sorry!).
Header value support
includes:
- Number of Pixels,
Slices and Frames.
- Voxel Dimensions.
- Max and Min Data
Values used to initialize colour lookup display.
- Multiple Frame
Image Volumes (t>1).
Currently Big and Little
Endian files with the following data types are supported (converted to
internal 16 bit signed format on loading):
- 16 bit signed and
unsigned integer (short)
- 8 bit unsigned (char)
- 32 bit integer (int)
- 32 bit floating
point (float)
A common problem using
analyze files is to ensure the voxels dimensions have been set
correctly to represent the sampling intervals of the original scanner
data. A they often may have been set to (1.0 1.0 1.0)mm:
rview cannot detect if you have set them wrong! If they are set
to 0.0 the file will not be loaded. A second problem can occur if the
image data has not been stored in the conventional analyze orientation
(See the analyze manual). In general: please be careful when importing
analyze image data (particularly that which has not been
converted using analyze) to ensure left-right and top-bottom
orientation
of the image data. It is preferable to import the original scanner
files
if possible: This will also ensure that such things as acquisition time
and
patient related information are available directly.
WARNINGS:
- Slice orientation
is currently assumed to be TRANSAXIAL with conventional (original
version) analyze
orientation. (which is then swapped round to remain consistent with the
rview internal data order)
- If Max and Min in
the header are
wrong then the display will be incorrect on loading:
- If Max<Min in
the header, then
the data volume is scanned when loaded by rview and the Max and Min
calculated from the range of data values in the volume.
- Rview has supported
both big and little endian Analyze format files (as written by the
original versions of analyze and Medx on PC's and workstations) from
1998: It does not support MIXED byte order Analyze formats (where the
header and data are different byte orders! [as written by some format
conversion programs]. Basically: analyze byte ordering is a big mess
for many datasets and rview cannot support all of them: So stick to
DICOM!
- rview writes only
one byte order/analyze format to remain compatible with the original
users of rview (who use rview with other workstation based software).
NIFTI
Image Format
As of version 8.199B rview
will detect NIFTI format files. These are generally recognized with the
.nii extension and the magic number.
(note until version 8.215B NIFTI files with .hdr/.img are loaded my the
analyze loader, after this release NIFTI can be .nii or .hdr/.img
combinations,
and detection is based on magic number).
Both single file and double file nifti formats are supported. NIFTI
data with dimensions above 4 are not yet supported. The following data
types are recognised:
- 16 bit signed and
unsigned integer
- 8 bit unsigned
- 32 bit floating point
As of
8.215B there is significant support for detection of image data slice
orientation via the quaternion representation in the header.
Many orientations have been tested, but not ALL: please be careful!
NIFTI
format support is still in early development and many bugs still exist!
CTI Image
formats
Support for CTI image
data includes reading both the old style format derived from VAX data
storage types and the newer ECAT 7 format. However, both formats are
not fully supported:
Old Style Summary:
- File type
recognition is poor!
- Voxel extent and
voxel dimensions are read automatically from the file.
- In this older
format each slice is stored with a separate intensity scaling: When the
slices
are loaded the individual scaling factors for each slice are used to
rescale
each to a common global intensity scale.
- WARNING:
Slicing orientation is not automatically recognised and currently
assumed to be
TRANSAXIAL.
ECAT 7 Summary:
- The file type is
recognised reliably by the text string 'MATRIX71' at location 0 in the
file (and thus reading may not work for other releases of the MAXTRIX
format.
- Voxel extent and
voxel dimensions are read automatically from the file.
- A single frame
(time slice) of data is assumed to be present in the file.
- WARNING:
Slice orientation is not automatically recognised and is currently
assumed to
be TRANSAXIAL.
- Patient name read
automatically from header.
GIPL: Guys
Image
Processing Lab Format
UMDS GIPL format files
(extension '.gipl') are recognised and loaded. Each image volume is
stored in a single file consisting of a 256 byte header followed by
binary voxel data values. However only 16 and 8 bit (signed and
unsigned) data types are supported (each of these are converted to
signed 16 bit values internally).
Header value support
includes:
- Number of Pixels,
Slices and Frames.
- Voxel Dimensions.
- Max and Min Data
Values used to initialize colour lookup table for display.
- Multiple Frame
Images (t>1).
WARNINGS:
- Slice orientation
is currently assumed to be TRANSAXIAL.
- If Max and Min are
wrong then the display will be incorrect on loading.
- If Max<Min then
the data volume is scanned and Max and Min set from the Data Values.
Currently the
following data types in GIPL format are supported:
- 16 bit signed and
unsigned integer (short)
- 8 bit signed and
unsigned (char)
- 32 bit integer (int)
- 32 bit floating
point (float)
All these
types are converted to internal 16 bit signed numbers inside rview.
An auto scaling is applied to floating point numbers: please be careful
when loading
floating point
data with a large or small data range into rview.
N.C.S.A.
HDF
Scientific Data Format.
The N.C.S.A. Scientific
Data format is supported at a basic level. This volume image format is
a single file format where the file ends with a '.hdf' extension.
Header value support currently includes:
- Number of Pixels,
Slices and Frames.
- Voxel Dimensions.
- 16 and 8 bit
signed and unsigned voxel values.
- Multiple Frame
Images (t>1).
WARNINGS:
- Slice orientation
is currently detected when the data has been converted from the
medical format using specific tools at the MRSUNIT at the VAMC, UCSF.
- Gantry angles are
ignored.
VPX Format
The VPX image format as
used by the Utrecht group is recognised and supported in a very basic
form. VPX consists of a data file ('.vpx' extension) and sometimes a
header file ('.vhd' extension). Currently only the vpx file is read and
the header file is ignored. Because of the number of alternative
methods of voxel dimension storage,
reading of these is not currently supported. As a result IT IS NOT
RECOMMENDED that vpx files are used in registration/visualization
of volumetric medical image data.
- Number of Pixels
and Slices
- Signed and
Unsigned 16 and 8 bit data values.
- Max and Min Data
Values Calculated from Data Values
WARNINGS:
- No Voxel
Dimensions
are read
- Slice orientation
is currently assumed to be TRANSAXIAL.
Interfile
Format
The Interfile image
format has been used for many years to transfer mainly nuclear medicine
images between
different image processing and viewing programs. Because of the many
different
ways of acquiring and reconstructing nuclear medicine image data the
format
can be quite varied. Rview currently supports a subset of data formats
which
are loaded by specifying the ascii header file. It is assumed that the
raw
pixel data is stored in the same directory with an extension '.IMG'.
The
ascii header must contain valid values for the items 'matrix size'
, 'total number of images', 'scaling factor', '
centre-centre
slice separation'. The item 'number of reference frame' is
used
to skip any 3D non-volume image data. Using these the following volume
information
is extracted:
- Number of Pixels
and Slices
- Voxel Dimensions
derived from slice thickness/separation/FOV etc.
- Signed and
Unsigned 16 and 8 bit data values.
- Max and Min Data
Values Calculated from Data Values
WARNINGS:
- If scaling
factor', is not present then pixel dimensions are assumed to be
1.0mm.
- If 'centre-centre
slice separation'. is not present then slice separation is set to
slice thickness.
- Slice orientation
is currently assumed to be TRANSAXIAL.
Vanderbilt
RREP
Format
This format is
supported at
a very basic level. rview expects to be supplied with the header
file
'ascii.header' which should contain entries for:
Rows
Columns
Slices
Pixel size
Slice thickness
Bits allocated (must be 16 bit!)
Bits stored
representation
rview also expects to find the data file 'image.bin' in the same
directory as 'ascii.header'
SMIS
MRD/SUR MRI Format
As of version 8.117
rview/vxload.lib
supports basic reading functionality for SMIS image data.
Rows
Columns
Slices
Pixel size (Calculated from FOV and number of pixels, assuming square
field
of view)
Slice thickness
Bits per voxel (16 bit signed short and 32 bit floating point)
For MRD format rview
expects
32 bit floating point data values and loads 1 volume per file images.
For SUR format rview
expects
16 bit per voxel short integer data. The slice data for this format
is expected to be stored in separate files with names containing the
slice
number for example:
SE78001.SUR
SE78002.SUR
SE78003.SUR
....
SE78011.SUR
To load the entire
image
volume only specify or drag/drop ONE slice file, and the entire
volume will be loaded.
Warnings:
Slice orientation is
not
recognised (check left and right!)