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:


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:


Signa 3.x formats consist of the following looking file names:


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:


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:

The following are not yet supported by the reading software: 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:


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:

The following are not yet supported by the reading software: 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:


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:



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:


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:

Currently Big and Little Endian files with the following data types are supported (converted to internal 16 bit signed format on loading):
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.



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:

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:

ECAT 7 Summary:  
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:

WARNINGS:   Currently the following data types in GIPL format are supported:
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:


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.


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:



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:

Pixel size
Slice thickness
Bits allocated  (must be 16 bit!)
Bits stored

rview also expects to find the data file 'image.bin' in the same directory as 'ascii.header'


As of version 8.117 rview/vxload.lib supports basic reading functionality for SMIS image data.

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:




To load the entire image volume only specify or drag/drop ONE slice file, and the entire
volume will be loaded.


Slice orientation is not recognised (check left and right!)