Subject: Medical Image Format FAQ, Part 3/8
Date: 9 Apr 1996 13:34:06 -0400
Summary: This posting contains answers to the most Frequently Asked
. Question on alt.image.medical - how do I convert from image
. format X from vendor Y to something I can use ? In addition
. it contains information about various standard formats.

Posting-Frequency: monthly
Version: 3.01

3.  Proprietary Formats

    3.1 Proprietary Formats - General Information

.3.1.1 SPI (Standard Product Interconnect)

.      Used for files exported from:

..- Siemens Somatom Plus
..- Siemens Magnetom Impact
..- Siemens Magnetom SP
..- Siemens Magnetom Vision
..- Philips Gyroscan S5
..- ? what else ?

.      SPI is a standard based on the old ACR/NEMA 1 standard, devised I
.      gather by Siemens and Philips, for use in a PACS environment. Who
.      currently maintains it and whether or not Sienet PACS systems are
.      based on it, I am not certain. Many machines in the workplace use
.      it in some shape or form, or can export files in SPI format. I
.      gather it has been around since 1987 or so, but I do not yet have
.      access to the reference documents, nor permission to disclose
.      their contents, so much of the following is guess work or hearsay
.      from Usenet.

.      Like the ACR/NEMA standard, SPI is designed to define
.      interconnections between pieces of equipment from the physical
.      level through to the application level. Where appropriate it
.      utilized relevant parts of ACR/NEMA. Unlike ACR/NEMA, I gather
.      that SPI is aware of the concept of networks, objects containing
.      information, the need to uniquely identify instances of objects,
.      and defines an offline file format. Thus in many ways it sounds
.      like the missing link between ACR/NEMA 2.0 and DICOM 3.0.

.      SPI makes use of ACR/NEMA data elements and groups, and in
.      addition provides "shadow" private odd-numbered groups as
.      dictated by the ACR/NEMA standard for the purpose of storing
.      additional items of information, including a means of uniquely
.      identifying objects, as well as allowing for enumerated values
.      for elements beyond those defined by ACR/NEMA. SPI also defines a
.      byte order for offline storage of data streams. Integers are
.      stored in little endian format (least significant byte first).

.      The private groups mechanism works as follows. For each odd
.      numbered group (other than 0x0001,0x0003,0x0005,0x0007 and
.      0xffff), the elements 0x00nn in the range 0x0010 through 0x00ff
.      contain a single valued string identification code that
.      identifies the creator of the range of elements 0xnn00 through
.      0xnnff. Neat eh ? For example:

.(0x0009,0x0010) PrivateCreatorDataElement
.(0x0009,0x0011) PrivateCreatorDataElement
....
.(0x0009,0x1000) DavidElement1
.(0x0009,0x1001) DavidElement2
....
.(0x0009,0x1100) HarryElement1
.(0x0009,0x1101) HarryElement2

.      You get the idea. The nice thing about this scheme is that each
.      creator dictionary considers its elements numbered from 0x0000,
.      but these will be remapped to a block of elements depending on
.      exactly which PrivateCreatorDataElement is used in the particular
.      data set. Hence multiple groups from different creators can
.      co-exist happily in the same data set, and vary in position
.      between data sets.

.      Note that the group number IS taken into consideration ... a
.      private element with the same element offset and the same creator
.      will have a different meaning depending on which group it is in.

.      SPI uses this concept extensively and defines a large dictionary
.      with different creators with convoluted names for different
.      modalities and PACS operations. A few sample elements are
.      described here. Particularly important are those elements for
.      purposes that were not envisaged when ACR/NEMA 1 was written, but
.      are necessary to create valid DICOM 3 data sets. Such things as
.      FlipAngle for MR scans for example. Note that the SPI UID is not
.      the same as a DICOM UID, but presumably it is unique ! Note also
.      that the creator of "SPI RELEASE 1" is the same as "SPI Release
.      1" and "SPI" ... presumably someone messed up between machines or
.      modalities or manufacturers. For a more extensive SPI data
.      dictionary see the DICOM conversion tools. The value
.      representation fields are shown here using the modern DICOM
.      equivalents rather than the older, less specific ACR/NEMA names.
.      The "owner" is what is used as the string value of the
.      PrivateCreatorDataElement when a range of elements in a group is
.      claimed.

Element     Owner                 Name                  VR VM

(0009,0010) SPI                   Comments              LO  1
(0009,0015) SPI                   UID                   LO  1
(0009,0010) SIEMENS MED           RecognitionCode       LO  1

(0011,0010) SPI RELEASE 1         Organ                 LO  1
(0011,0015) SPI RELEASE 1         AllergyIndication     LO  1
(0011,0020) SPI RELEASE 1         Pregnancy             LO  1
(0011,0010) SIEMENS CM VA0  CMS   RegistrationDate      DA  1
(0011,0011) SIEMENS CM VA0  CMS   RegistrationTime      TM  1
(0011,0023) SIEMENS CM VA0  CMS   UsedPatientWeight     IS  1

(0013,0020) SIEMENS CM VA0  CMS   PatientName           LO  1
(0013,0022) SIEMENS CM VA0  CMS   PatientId             LO  1
(0013,0030) SIEMENS CM VA0  CMS   PatientBirthdate      LO  1
(0013,0031) SIEMENS CM VA0  CMS   PatientWeight         DS  1
(0013,0035) SIEMENS CM VA0  CMS   PatientSex            LO  1
(0013,0040) SIEMENS CM VA0  CMS   ProcedureDescription  LO  1
(0013,0042) SIEMENS CM VA0  CMS   RestDirection         LO  1
(0013,0044) SIEMENS CM VA0  CMS   PatientPosition       LO  1

(0019,0010) SIEMENS CM VA0  CMS   NetFrequency          DS  1
(0019,0011) SIEMENS CM VA0  ACQU  SequenceFileName      LO  1
(0019,0021) SIEMENS CT VA0  GEN   Exposure              DS  1
(0019,0026) SIEMENS CT VA0  GEN   GeneratorVoltage      DS  1
(0019,0050) SIEMENS MR VA0  GEN   NumberOfAverages      IS  1
(0019,0060) SIEMENS MR VA0  GEN   FlipAngle             DS  1
(0019,0012) SIEMENS MR VA0  COAD  MagneticFieldStrength DS  1

(0021,0010) SIEMENS MED           Zoom                  DS  1
(0021,0011) SIEMENS MED           Target                DS  2
(0021,0020) SIEMENS CM VA0  CMS   FoV                   DS  2
(0021,0060) SIEMENS CM VA0  CMS   ImagePosition         DS  3
(0021,0061) SIEMENS CM VA0  CMS   ImageNormal           DS  3
(0021,006a) SIEMENS CM VA0  CMS   ImageRow              DS  3
(0021,006b) SIEMENS CM VA0  CMS   ImageColumn           DS  3
(0021,0039) SIEMENS MR VA0  GEN   SlabThickness         DS  1
(0021,0070) SIEMENS MR VA0  GEN   NumberOfEchoes        IS  1

    3.2 CT - Proprietary Formats

.3.2.1 General Electric CT

.      Now we get to the meaty part. After years of being faced with the
.      problem of either a) hours of detective work, or b) tediously
.      tracking down the name of the responsible person and exercising a
.      non-disclosure agreement, General Electric (or Generous Electric
.      as I heard them described the other day) now really are being
.      generous, as well as sensible, and are making their image format
.      description documents freely available. For details see the GEMS
.      image format information contacts section later on. In the
.      meantime, both for historical completeness, educational purposes,
.      and for those who can't wait for document to come in the mail, a
.      summary of the relevant formats and decompression algorithms is
.      provided here.

.      3.2.1.1 GE CT 9800

..      References (see the GEMS image format information
..      contacts section):

....- 46-021855 CT 9800 Image Data Format

..      3.2.1.1.1 GE CT 9800 Image data

....- "block format" header
....- perimeter encoding
....- optional DPCM compression
....- Data General host (various)
....- RDOS (yuck !)

....Almost everyone in this field has at some stage
....encountered the dreaded CT 9800 format. The
....world is divided into two groups of people ...
....those who have seen the documents or the
....critical piece of code in another program or
....have been given a handy hint, and those who
....will never figure out the format themselves.

....Essentially the format fits into the "block
....format" described earlier, with pointers to
....each of the major header components. Rarely, if
....ever, does one encounter a file that doesn't
....have the same size blocks in the same place, so
....most people treat it as a fixed layout. I
....believe that reformatted images may have
....another header stored in there, but I have
....never tested for it.

....The data itself is stored in one of two forms
....depending on whether compression is selected or
....not during archival. In the uncompressed form,
....a type of perimeter encoding is used (see later
....section) in which for an essentially circular
....object, the outer parts of a rectangular image
....are discarded (and expected to be filled in
....with a background pixel value during
....reconstitution of the image). In the case of
....the CT9800 then, the image pixel data is
....interpreted using a map, which contains an
....entry for each row of the image (either 256,
....320 or 512 entries) which specifies the length
....of the row that is actually stored, centered
....about the midline of the image. This obviously
....saves a lot of space.

....If compression is selected on one of the later
....model machines, then a form of Differential
....Pulse Code Modulation is used, in which
....advantage is taken of the fact that not all the
....bits of a 16 bit word are need to store a CT
....value. I gather only 12 bits of data are
....actually significant, but one can theoretically
....represent 15 using this scheme. Essentially,
....the first 16 bit word is read and used as is.
....Then another byte is read. If its most
....significant bit is set, then the remaining 7
....bits represent a signed difference value
....relative to the previous pixel. If its most
....significant bit is not set, then the difference
....must have exceeded the range of 7 bits, and
....hence the next byte is read to complete a valid
....16 bit word (15 bits really) which is the
....actual pixel value. The really neat thing about
....this scheme is that the same algorithm can be
....used for compressed or uncompressed data as an
....uncompressed stream of words will never have
....the most significant bit set !

....The following piece of C++ code pulled out of a
....CT9800 to DICOM translator will give you the
....general idea. Note that the perimeter encoding
....map has already been read in. Note in
....particular the need to deal with sign extension
....of the difference value. Also note that the
....code doesn't handle the first pixel specially
....because its high bit will not be set.

static void
copy9800image(ifstream& instream,DC3ofstream& outstream,
.      Uint16 resolution,Uint16 *map)
{
.unsigned i;
.Int16 last_pixel;

.last_pixel=0;
.for (i=0; i<resolution; ++i) {
..unsigned line   = map[i];
..unsigned start  = resolution/2-line;
..unsigned end    = start+line*2;
..unsigned j;

..// Pad the first "empty" part of the line ...
..for (j=0; j<start; j++) outstream.write16(0);

..// Copy the middle of the line (compressed or uncompressed)
..while (start<end) {
...unsigned char byte;
...instream.read(&byte,1);
...if (!instream) break;
...if (byte & 0x80) {
....signed char delta;
....if (byte & 0x40) {
.....delta=byte;
....}
....else {
.....delta=byte & 0x3f;
....}
....last_pixel+=delta;
...}
...else {
....last_pixel=byte << 8;
....instream.read(&byte,1);
....if (!instream) break;
....last_pixel+=byte;
...}
...outstream.write16((Uint16)last_pixel & 0x0fff);
...++start;
..}

..// Pad the last "empty" part of the line ...
..for (j=end; j<resolution; j++) outstream.write16(0);
.}
}

....What about the rest of the header information
....and where is this map stored anyway ? Well, the
....file is described as a series of 256 by 16 bit
....word blocks, blocks numbered from 0, words
....numbered from 1, integers are 16 bit words, as
....follows:

.block 0 - global header

.       word 34   - Int - pointer to global header
.       word 35   - Int - pointer to exam header
.       word 36   - Int - pointer to image header
.       word 37   - Int - pointer to image header2
.       word 38   - Int - pointer to image map
.       word 39   - Int - pointer to image data
.       word 40   - Int - number of blocks in global header
.       word 41   - Int - number of blocks in exam header
.       word 42   - Int - number of blocks in image header
.       word 43   - Int - number of blocks in image header2
.       word 44   - Int - number of blocks in image map
.       word 45   - Int - number of blocks in image data

....Now almost always the layout is as follows, for
....non-reformatted images:

.block 0 - global header
.block 1 - exam header
.block 2 - image header
.block 3 - image header 2
.block 4 - image map
.block 6 - image data

....For reformatted images the layout is said to be
....different, but I have never seen a description
....of the contents of the so-called "arrange
....header", nor do I know where in the global
....header the pointer and length are stored:

.block 0 - global header
.block 1 - exam header
.block 2 - image header
.block 3 - image header 2
.block 4 - arrange header
.block 9 - image map
.block 11 - image data

....Some of the more important contents of the
....various headers are listed here. For more
....complete information get the documents from GE
....or study any one of a number of programs
....kicking around to dump the header of this kind
....of file (see sources later). Integers are 16
....bit words, ascii strings are Fortran style
....specifications with two characters per word,
....and reals are 4 bytes long (see Host machines -
....Data General):

.block 0 - global header

.       word 17-23    - 7A2  - file name

.block 1 - exam header

.       word  4       - Int  - exam number
.       word  5-11    - 7A2  - exam number
.       word  12-17   - 6A2  - patient id
.       word  18-32   - 15A2 - patient name

.block 2 - image header

.       word  11      - Int  - position (study) number
.       word  13      - Int  - group type (2=scout,3=standard,4=dynamic)
.       word  14      - Int  - group number
.       word  47      - Int  - scan number
.       word  48      - Int  - image number
.       word  50      - Int  - patient orientation (1=head first,2=feet)
.       word  51      - Int  - AP orientation (1=prone,2=sup,3=lt,4=rt)
.       word  55      - Int  - contrast (0=no,1=yes)
.       word  93-94   - Real - gantry tilt
.       word  95-96   - Real - table height mm
.       word  97-98   - Real - axial table location mm
.       word  124     - Int  - image size (256,320,512) NOT FOR SCOUTS
.       word  132     - Int  - detectors/view        - width  for scouts
.       word  137     - Int  - compressed views/scan - height for scouts
.       word  144-145 - Real - X diameter of recon mm
.       word  146-147 - Real - Y diameter of recon mm
.       word  155-156 - Real - magnification factor
.       word  157-158 - Real - X center
.       word  159-160 - Real - Y center
.       word  175     - Int  - image map used (1=yes,2=no)
.       word  218     - Int  - file type (1=prospective,2=scout,
....      3=retrospective,4=segmented,
....      5=screen save,6=plot)
.       word  219     - Int  - data range (number of bits)
.       word  236     - Int  - scout orientation (0=ap,1=lateral)
....      (the 9800 rotates the scout magically)

....It is important to check the filetype and image
....map used entries, particularly if trying to
....read scouts rather just prospective images. If
....the map is not in use, it is filled with zeroes
....and hence if the flag is not checked a
....simplistic demapping algorithm will fail.
....Furthermore the number of rows and columns in
....the image is not specified as such. For
....prospective images, the imagesize field is
....valid for both (images are square). For scouts,
....one must use the detectors/view field for the
....width and the compressed views/scan field as
....the height.

....The filename entry is quite useful. Therein is
....stored the RDOS filename of the image, which
....follows the following convention:

.seeeeeppdd.tt

.s     = originating scan station id
.eeeee = exam number
.pp    = prs number (position related set)
.dd    = image number
.tt    = file type
..YP = prospective
..YV = scout
..YR = retrospective
..YG = segmented recon
..YS = screen save
..YL = plot
..YF = reformatted

.eg. B038500165.YP

....Having said this, my GE 9800 stores its scouts
....on tape at least with no file extension at all,
....rather than the .YV that it is supposed to
....use.

..      3.2.1.1.2 GE CT 9800 Tape format

....Probably more CT images have been exchanged for
....clinical and research purposes using GE 9800
....9-track magnetic tapes than any other means.
....These things are just ubiquitous, particularly
....considering the proliferation of services
....providing 3D reconstruction and fabrication a
....few years ago. Fortunately the format is easy
....to deal with. The tapes are produced on a
....primitive DG tape drive and hence are never
....more than 1600bpi. The first thing on the tape
....is a directory consisting of two 4096 word
....(8192 byte) records, then two EOF marks, then
....20" of blank tape (because the directory keeps
....getting updated) followed by image files each
....separated by an EOF mark and finally an
....additional EOF mark after the last file.

....I won't describe the tape directory format here
....unless someone specifically asks for it, though
....it is very simple. I usually just read
....everything on the tape and sort the files out
....later. Remember that their filenames are stored
....in the global header.

....Don't forget to set the input magnetic tape
....record size to 8192 bytes when you are copying
....these files. If you don't do this some systems
....quietly truncate each record to some default
....size. It took me a week to figure out why my
....files were screwed up the first time I tried
....this on a DG under AOS/VS (I was desperate and
....using a networked Signa to read files off a
....non-networked 9800).

....A simple script to read an entire tape from a
....SCSI tape drive /dev/nrst1 under SunOS, which
....will peek in each image file to extract the
....correct filename (simpler than trying to
....decipher the directory) looks like this:

#!/bin/sh

echo "Rewinding"
mt -f /dev/nrst1 rewind

echo "Extracting directory ..."
dd if=/dev/nrst1 ibs=8192 of=TAPEDIR

while dd if=/dev/nrst1 ibs=8192 of=tape.tmp
do
.name=`dd if=tape.tmp ibs=16 skip=2 count=1 2>/dev/null`
.if [ -z "$name" ]; then break; fi
.mv tape.tmp $name
.echo "Extracted $name"
done

echo "Rewinding"
mt -f /dev/nrst1 rewind
echo "Finished"

..      3.2.1.1.2 GE CT 9800 Raw data MR

....No idea about this one ... I have never had the
....need or seen any documention. Anyone who does
....or has please fill in this space.

.      3.2.1.2 GE CT Advantage - Genesis

..      References (see the GEMS image format information
..      contacts section):

....- 46-021861 Image Data Format
....- 46-021863 Optical Disk Raw Partition
....- 46-021864 Image Extract Tool
....- 46-021865 DAT Archive Format

..      General Electric now uses the same Sun based architecture
..      for its Advantage CT and Signa 5X MR family, referred to
..      as Genesis, and hence the general details of this scheme
..      will be discussed under the GE MR Signa 5.x - Genesis
..      section. Specifics related to the CT modality will be
..      described here.

..      3.2.1.2.1 GE CT Advantage Image data

....The Image Extract Tool is used in the same way
....as on the Signa to extract an image from the
....database into a single file, either asis or
....using the requested compression and packing
....mode. The Genesis file contains headers
....consisting of several components in common with
....MR and then a specific CT or MR header.
....Theroetically, one should be able to use
...."/usr/g/insite/bin/ximg -g" to extract a
....prototype C header file describing the file
....format, as on the Signa, though last time I
....tried this on a High Speed Advantage this
....didn't work. Some of the more interesting
....fields in the CT image header include:

.image header - for CT (1020 bytes long):

..26  - float    - slice thickness (mm)
..30  - short    - image matrix size - X
..32  - short    - image matrix size - Y
..34  - float    - display field of view - X
..38  - float    - display field of view - Y
..42  - float    - image dimension - X
..46  - float    - image dimension - Y
..50  - float    - pixel size - X
..54  - float    - pixel size - Y
..58  - char[14] - pixel data ID
..72  - char[17] - iv contrast agent
..89  - char[17] - oral contrast agent
..194 - float    - table start Location
..198 - float    - table end Location
..202 - float    - table speed (mm/sec)
..206 - float    - table height
..224 - float    - gantry tilt (degrees)

..      3.2.1.2.2 GE CT Advantage Archive format

....See the GE MR Signa 5.x Archive format.

..      3.2.1.2.3 GE CT Advantage Raw data

....Again, unknown. Please fill in this space.

.      3.2.1.3 GE CT Pace

..      References (see the GEMS image format information
..      contacts section):

....- 46-021856 CT Pace Image Data Format
....- 46-021862 MR Max  Image Data Format

..      The Pace is a CT scanner made by Yokogawa Medical
..      Systems(YMS) in Japan. The format documents I have for it
..      are partially in Japanese and partially in English, but
..      they get the job done. I have only tested the following
..      on a few images that were extracted off a nine-track
..      tape, so the offsets to the image header fields may not
..      be correct in other cases, but here are "eye-catcher"
..      fields at the start of each header which should be easy
..      to find. The format seems to be shared with the GE MR Max
..      family.

..      The images described in the documents have a 512 byte
..      study header that begins with "!STD" and an image header
..      of 1024 bytes that begins with "!IMG". In the image that
..      I had to play with, there was a 256 byte header that I am
..      not familiar with tacked on the front, presumambly
..      something to do with being a mag tape rather than a disk
..      image. Anyway this meant that the offset to the study
..      header was 256 bytes, the image header was 768 bytes, and
..      the compressed image data began at 1792 bytes.

..      I don't know what kind of host is used on the Pace though
..      I have seen some cryptic references to "DOS-68K" in the
..      documents. Regardless, the integers are 16 or 32 bit
..      big-endian. The image data is stored as SIGNED not
..      unsigned 16 bit values, same as on the Sytec and
..      presumably all the YMS systems. Most of the useful dates
..      and times are provided as string values, however there
..      are some dates and times that are 32 bit binary integers.
..      Though not specified in the docs it seems that the dates
..      are days since an epoch of "0 Jan 1980" and the times are
..      in milliseconds. Floats are 32 bit IEEE format, dfined in
..      the Pace documentation as follows:

.bit  31         sign (s)        (0 is +ve)

.bits 30-23      exponent (e)
...- unsigned integer
...- e == 0 for denormalized numbers
...- 0 < e < 255 for normalized numbers
...- e == 255 for other reserved operands

.bits 22-0       significand (f)

.Normalized numbers:
..Exponent:
...- bias 127
...- range 0 < e < 255
..Significand:
...- interpreted as 1.f
...- range 1.0 <= f < 2.0

..(-1)^s * 2^(e-127) * 1.f

.Denormalized numbers:
..Exponent:
...- e == 0
...- bias 126
..Significand:
...- interpreted as 0.f
...- range f != 0

..(-1)^s * 2^(-126) * 0.f

.Signed Infinities:
..- e == 255
..- f == 0

.Not-a-numbers:
..- e == 255
..- f != 0

..       The image header has a chunk in the middle where
..       different values are defined for CT and MR. One can use
..       the first byte of the model number field to distinuish
..       the two modalities. Some of the more important study and
..       image header values are:

    Study header (offset 256 bytes, length 512 bytes):

.Offset  Type    Length  Meaning       Units or values

.0x0     string  4        Eyecatcher         !STD
.0x6     byte    1        Modality           1=CT,2=MR
.0xa     string  5        Study Number
.0x10    datestring       Study Date         yyyy/mm/dd
.0x1a    timestring       Study Time         hh/mm/ss.xxx
.0x26    string  12       Patient ID
.0x36    string  12       Patient Name
.0x50    string  6        Patient Age        yyy;mm
.0x5c    string  2        PatientSex"        'M ','F '
.0xbc    string  4        Contrast media     'NO C','+C  '

    Image header (offset 768 bytes, length 1024 bytes):

.Offset  Type    Length  Meaning       Units or values

.0x0     string  4       Eyecatcher          !IMG
.0x6     byte    1       Modality            1=CT,2=MR
.0xa     string  5       Study Number
.0x10    string  2       Series Number
.0x12    string  2       Acquisition Number
.0x14    string  2       Image Number
.0x20    datestring      Image Date          yyyy/mm/dd
.0x2a    timestring      Image Time          hh/mm/ss.xxx
.0x40    string  2       'H '=Head First,'F '=Feet First
.0x42    string  2       'SP'=Supine,'PR'=Prone,
....'LL'=Left Lateral Decubitus,
....'RL'=Right Lateral Decubitus,'OT'=Other
.0x44    string  6       Anatomic location
.0x50    string  4       'AX  '=Axial,'SAG '=Sagittal,'COR '=Coronal
.0x54    float32         Slice position by body coords HF mm
.0x58    float32         Slice position by body coords AP mm
.0x5c    float32         Slice position by body coords LR mm
.0x6c    string  4       Scan fov cm
.0x70    string  4       Scan thickness mm
.0xa0    string  4       Contrast media      'NO C','+C  '

.0x188   float32         Recon center X mm
.0x18c   float32         Recon center Y mm
.0x190   string  4       Recon FOV cm [xx.x]
.0x1a0   u_int16         Pixels in X-axis
.0x1a2   u_int16         Pixels in Y-axis
.0x1a4   float32         Pixel size mm
.0x1b0   float32         Mag center X mm
.0x1b4   float32         Mag center Y mm
.0x1b8   float32         Mag factor

    For CT only:

.0xc8    string  5       Gantry tilt machine coords degrees
.0xe0    string  5       Exposure time ms
.0xe6    string  3       Tube current mA
.0xea    string  5       Exposure mAS
.0xf0    string  3       KVP
.0xf4    string  2       'CW'=Clockwise,'CC'=CounterClockwise

    For MR only:

.0xc0    string  5       Tilt ordered by user Axis+/-Angle [xx+/-xx]
.0x100   string  2       Echo number
.0x102   string  2       Number of echoes
.0x104   string  2       Slice number
.0x106   string  2       Number of slices
.0x108   string  2       Number of excitations
.0x10a   string  5       Repetition time ms
.0x110   string  5       Inversion time ms
.0x115   string  5       Echo time ms
.0x130   string  4       Magnetic flux density (T)

..       Unlike the Sytec sample images I had, compression was
..       used in the Pace images I received. This is a neat
..       scheme that uses both Run Length Encoding and
..       Differential Pulse Code Modulation. Essentially, each
..       byte may be a flag value 0x81 which indicates the next
..       byte is a run length of the current pixel, or a flag
..       value 0x80 which indicates that the current mode should
..       be toggled between "reference" mode, in which the
..       subsequent 16 bit words are new pixel values, or
..       "difference" mode, in which case subsequent bytes are
..       signed differences added to the current pixel value. The
..       initial mode is "reference" mode. Runs do extended
..       across horizontal line boundaries.

..       I am not totally clear from the documentation or the
..       sample images where in the header is the flag to say
..       compression is in use or not. It is probably bit 5 of
..       the Image Attribute field in offset 0x1ac in the image
..       header, where a false value specifies DPCM and a true
..       value specifies uncompressed or "Original" encoding. The
..       docs say this is for optical disk only, but the
..       compressed image from tape I have has this bit false,
..       which is correct.

..       The following piece of code will decode such a
..       compressed image:

static void
copypaceimage(istream& instream,ostream& outstream,
.      Uint16 width,Uint16 height)
{
// NB. the exclusive or with 0x8000 makes the signed Pace values unsigned
// which is what the PGM convention is ... just omit the ^0x8000
// everywhere if you want the data left signed.

.unsigned i;
.Int16 pixel=0;
.enum Mode { Difference, Reference } mode = Reference;
.for (i=0; i<height*width;) {
..unsigned char byte;
..instream.read(&byte,1);
..if (!instream) break;
..if (byte == 0x80) {             // Mode switch
...if (mode == Difference)
....mode=Reference;
...else
....mode=Difference;
..}
..else if (byte == 0x81) {        // Run length flag
...instream.read(&byte,1);
...if (!instream) break;
...unsigned repeat=byte;
...i+=repeat;
...while (repeat--) write16little(outstream,pixel^0x8000);
..}
..else {
...if (mode == Difference) {
....pixel+=(signed char)byte;
...}
...else {
....pixel=byte<<8;
....instream.read(&byte,1);
....if (!instream) break;
....pixel|=byte;
...}
...write16little(outstream,pixel^0x8000);
...++i;
..}
.}
.if (!instream) cerr << "Premature EOF byte " << i << "\n" << flush;
}

.      3.2.1.4 GE CT Sytec

..      I don't have one of these either, and it turns out that
..      the format is NOT the same as the Pace as GE Milwaukee
..      initially thought. The format may be shared with the
..      Vectra, but this is not known for certain. I do have a
..      few sample images and have worked out many of the values
..      in the headers. The format may be available from Yokogawa
..      in Japan. Milwaukee apparently doesn't have it.

..      The host is an MS-DOS clone using the J-DOS operating
..      system, a Japanese version of DOS to handle 16 bit Kanji
..      characters. Alan Rowberg tells me it has a 5.25" drive
..      that writes disks that are unreadable by anything else in
..      the universe.

..      The images have a header of 3752 bytes and are followed
..      by 16-bit signed integers. The surround is -1500 which is
..      probably -1500 H.U. The sample files I had did not use
..      any form of compression.

..      The data formats are big-endian. Fortuitously the
..      date/time format is the same as unix ... a 32 bit
..      unsigned integer containing seconds since an epoch of
..      00:00:00 GMT 1 Jan 1970. Floats are 32 bit IEEE format as
..      described in the Pace format.

..      The head first/feet first and prone/supine fields in the
..      Sytec file are not known. The sense and identification of
..      corners in the Sytec sample files was done by guess work,
..      and may be wrong if the samples weren't scanned head
..      first supine, and the images are not supposed to be
..      looked at from bottom up in the usual convention.

..      The header is 3752 bytes long. The known header values
..      are (byte offsets from 0):

      Offset   Type         Meaning               Units or values

.7      string       ModelNumber

.126    string       Organization
.204    string       PatientID
.217    string       PatientName

.328    datetime     ExamDateTime
.402    string       ExamDescription
.425    string       Modality
.444    string       ExamStationID

.1164   int16        ExamNumber
.1166   int16        SeriesNumber
.1172   datetime     SeriesDate
.1176   string       SeriesDescription
.1206   string       SeriesStationID

.1224   int16        ScanType                # 1=axial,3=scout
.1240   string       AnatomicalReference

.1280   float32      SeriesStartLocation
.1288   float32      SeriesEndLocation

.2192   u_int16      ImageExamNumber
.2194   u_int16      ImageSeriesNumber
.2196   u_int16      ImageNumber
.2204   datetime     ScanDateTime
.2208   float32      ScanDuration            #? secs
.2212   float32      SliceThickness          # mm
.2216   u_int16      XMatrix
.2218   u_int16      YMatrix
.2220   float32      FieldOfView             # mm
.2224   float32      ScoutLength             # mm
.2228   float32      XDimension              # mm
.2232   float32      YDimension              # mm
.2236   float32      XPixelSize              # mm
.2240   float32      YPixelSize              # mm

.2310   u_int16      ScoutOrientation        # 0=none,1=ap,2=lateral
.2316   float32      TablePosition           # mm
.2320   float32      SliceCenterX            # mm
.2324   float32      SliceCenterY            # mm
.2328   float32      SliceCenterZ            # mm
.2332   float32      NormalVectorX           # unitized
.2336   float32      NormalVectorY           # unitized
.2340   float32      NormalVectorZ           # unitized
.2344   float32      TopRightHandCornerX     # mm
.2348   float32      TopRightHandCornerY     # mm
.2352   float32      TopRightHandCornerZ     # mm
.2356   float32      TopLeftHandCornerX      # mm
.2360   float32      TopLeftHandCornerY      # mm
.2364   float32      TopLeftHandCornerZ      # mm
.2368   float32      BottomLeftHandCornerX   # mm
.2372   float32      BottomLeftHandCornerY   # mm
.2376   float32      BottomLeftHandCornerZ   # mm
.2384   float32      ScoutStartLocation      # mm
.2388   float32      ScoutEndLocation        # mm
.2408   int32        GeneratorVoltage        # kVP
.2412   int32        TubeCurrent             # mA
.2416   float32      GantryTilt              # degrees

.2716   float32      XReconOffset            # mm
.2720   float32      YReconOffset            # mm

.3256   int32        BitsPerSample
.3264   int32        DefaultWindowWidth
.3268   int32        DefaultWindowLevel

.3.2.2 Siemens CT

..Some general comments about the way in which Siemens image
..headers, and the concept of native file formats and exported
..SPI formats are to be found in the section on Siemens MR.

.      3.2.1.1 Siemens Somatom DR

..      - NOT in SPI format
..      - fixed format
..      - files 133120 bytes (for 256 square images)
..      - image pixel data 256*256*2 little endian
..      - image pixel offset 2048 bytes
..      - same for axial images and topograms (scouts)

..      This description pertains to the DR family, and possibly
..      also earlier Siemens CT models, but I have no files from
..      these to test.

..      The files are in fixed format (cf. the early Magnetom
..      format which is similar, but has block pointers) with
..      three major blocks of entries:

.- binary data      - offset 0    - 512 bytes
.- text overlay     - offset 512  - 960 bytes plus 676 bytes free
.- image pixel data - offset 2048 - 131072 bytes

..      The binary data block is filled with the usual cryptic
..      enumerated values and useful parameters. Some of the more
..      interesting ones are:

.- binary data block:

..66  - byte        - archive mode (0=raw data,B=256,C=512)
..67  - byte        - archive mode (0=uncompressed,
....    2=compressed)

..72  - short       - matrix size (256 or 512)

..130 - byte        - scan mode (P=image data,R=raw data)
..131 - byte        - scan mode (0=tomogram,Q=quick,S=serial,
....    C=cardiac,T=topogram,X=test,H=chronogram)
..132 - short       - fov - mm
..134 - short       - scan time - secs * 10
..136 - short       - kv
..138 - short       - dose - maS
..140 - short       - slice thickness - mm
..142 - short       - gantry tilt - degrees
..144 - short       - table position - mm
..146 - short       - table height - mm
..148 - short       - scan mode (1=standard(360),
....    2=quickscan(240),4=topogram)

..236 - short       - view direction (1=cranial,-1=caudal)
..238 - byte        - head position (0=head first,
....    1=feet first)
..239 - byte        - patient position (0=supine,
....    1=prone,2=r lat dec,3=l lat dec)

..310 - short       - window width  A
..312 - short       - window center A
..314 - short       - window width  B
..316 - short       - window center B

..      Unfortunately, the patient identification information is
..      NOT stored in the binary data block, rather one has to
..      extract it from the image text overlay block, which
..      consists of 960 characters (24 lines of 40 characters
..      WITHOUT carriage control characters) in a fixed format.
..      This is where what you see overlayed on the filmed images
..      is stored. Some of these values are duplicates of what is
..      in the binary data block, but things like the patient
..      name and so on are here and nowhere else :(

..    0123456789012345678901234567890123456789

..0   SOMATOM DR2       ST. ELSEWHERE GEN HOSP
..40  999999-9999  JOHN DOE                EF2
..80  01-JAN-90        FRONT               35B
..120 13:31:22                            H/SP
..160
..200 SCAN 60                             L
..240                                     E
..280                                     F
..320                                     T
..360
..400
..440
..480
..520
..560
..600
..640
..680
..720 TI 5
..760 KV 125
..800 AS .35
..840 SL 2
..880 GT 0
..920 TP 144

.- text overlay block: (some of this is guess work)

..0   - char[14]    - product
..15  - char[25]    - hospital name
..40  - char[12]    - patient number
..53  - char[22]    - patient name
..80  - char[2]     - date - dd
..83  - char[3]     - date - mmm
..87  - char[2]     - date - yy
..120 - char[2]     - time - hh
..123 - char[2]     - time - mm
..126 - char[2]     - time - ss
..156 - char[1]     - H=head first,F=feet first
..158 - char[2]     - SP=supine,PR=prone,
....    RP=right lateral decubitus,
....    LP=left lateral decubitus
..205 - char[4]     - slice number
..723 - char[4]     - scan time - secs
..763 - char[4]     - kv
..803 - char[4]     - dose - AmpS
..843 - char[4]     - slice thickness - mm
..883 - char[4]     - gantry tilt - degrees
..923 - char[4]     - table position - mm

..      If anyone knows what "EF2" and "35B" stand for I would
..      love to know - I presume they are something like the
..      filter used, or field of view or something ?

..      Also the DR family don't seem to be aware of the concept
..      of a hierarchy of examination/study and series numbering,
..      which makes it annoying to try to import them into PACS
..      systems :( Correct me if I am wrong but they just seem to
..      keep bumping up the slice number for each patient as each
..      group of scans is done.

.      3.2.2.2 Siemens Somatom Plus

..      There seem to be different formats for different versions
..      of the machine. Either that or some sites have PACS
..      software and some don't or something. Anyway, one set of
..      files that were sent to me used a fixed format header
..      much like the DR family, but of different length and with
..      different fields. I have not yet adequately deciphered
..      this header but will include it here when I have. This
..      may be what is referred to as the "original header"
..      stored in the SPI format.

..      Another site uses a Siemens version of SPI, containing
..      the following private data elements. Note that there is
..      overlayed data in the high four bytes of the image pixel
..      data, and that there seems to be a bunch of padding in
..      the middle. The intent seems to be to store the "original
..      header" and the image pixel data at accessible,
..      presumably standard locations, presumably indexed by the
..      byte offsets and lengths described in group 9. This is a
..      shame because it seems that none of the really
..      interesting CT attributes have been included in the SPI
..      form, although SPI private tags are available for lots of
..      CT parameters. I don't have one of these image to test
..      this theory, someone just sent me an output of the
..      attribute dump.

SPI private tags:

(0009,0010)                                      <SPI RELEASE 1>
(0009,0011)                                        <SIEMENS MED>
(0009,1011) SPI RELEASE 1   UID     <049S03CT031995011712072452>
(0009,1040) SPI RELEASE 1   DataObjectSubtype           [0x0000]
(0009,1041) SPI RELEASE 1   DataObjectSubtype         <IMA TOPO>
(0009,1110) SIEMENS MED     RecognitionCode             <CT 1.4>
(0009,1130) SIEMENS MED     ByteOffsetOfOriginalHeader
(0009,1131) SIEMENS MED     LengthOfOriginalHeader
(0009,1140) SIEMENS MED     ByteOffsetOfPixelmatrix
(0009,1141) SIEMENS MED     LengthOfPixelmatrixInBytes

(0011,0010)                                      <SPI RELEASE 1>

(0021,0010)                                        <SIEMENS MED>
(0021,1010) SIEMENS MED     Zoom                          <01.0>
(0021,1011) SIEMENS MED     Target              <000.000\00.000>
(0021,1012) SIEMENS MED     TubeAngle                     <0270>
(0021,1020) SIEMENS MED     ROIMask                     [0xf000]

Overlay descriptions (overlays already in image pixel data):

(6000,0040)                 ROI                              <G>
(6000,0102)                 BitPosition                 [0x000c]
(6000,0102)                 OverlayLocation             [0x7fe0]

(6002,0040)                 ROI                              <G>
(6002,0102)                 BitPosition                 [0x000d]
(6002,0102)                 OverlayLocation             [0x7fe0]

(6004,0040)                 ROI                              <G>
(6004,0102)                 BitPosition                 [0x000e]
(6004,0102)                 OverlayLocation             [0x7fe0]

(6006,0040)                 ROI                              <G>
(6006,0102)                 BitPosition                 [0x000f]
(6006,0102)                 OverlayLocation             [0x7fe0]

More SPI private stuff ... padding and original header ...

(7001,0010)                                        <SIEMENS MED>
(7001,1010) SIEMENS MED     Dummy

(7003,0010)                                        <SIEMENS MED>
(7003,1010) SIEMENS MED     Header

(7005,0010)                                        <SIEMENS MED>
(7005,1010) SIEMENS MED     Dummy

.      3.2.2.3 Siemens Somatom AR

.      Unknown.

.3.2.3 Philips CT - Big black hole

.3.2.4 Picker CT

.      Grey hole perhaps. This information probably pertains to the IQ
.      and PQ CT models, though I have no sample images to experiment
.      with yet. I am told that:

.      - axial images are 512x512
.      - pilot images are 1024x1024
.      - uncompressed images are 12 bits stored in 16 bits
.      - don't know how to handle compression scheme
.      - raster order is as usual, by row, TLHC first
.      - 8k header to be skipped

.3.2.5 Toshiba CT - another black hole
.3.2.6 Hitachi CT - another black hole
.3.2.7 Shimadzu CT - another black hole
.3.2.8 Elscint CT - another black hole

.3.2.9 Imatron CT

.      The following information is included verbatim from that kindly
.      supplied by Cameron Ritchie:

Imatron File Format

In this document, the Imatron file format is described.   Imatron
makes no guarantees that future Imatron files will be compatible with
the attached format.  This format is current as of 2/29/96.

The format described here is generally true for files produced by
all Imatron scanners (C-100, C-150L, C-150, C-150XP, C-150LXP);
however, some small differences may be found.  The file format
described below is valid for image files on the scanner's RT-11 disks.
What is not described is how to actually get one of these files off the
RT-11 and on to a workstation or PC for conversion.  This procedure
is actually almost more difficult than the conversion!  There
are three options for getting files off the scanner;  only one
does not require additional hardware.  The options are as follows:

  -Use the RT-11 program &quot;XFR&quot; to transfer the image
      file from the RT-11 to the VxWorks based VME computer.  XFR can
      be run from the RT-11 dot prompt.  Following an XFR transfer (provided
      that the VME computer is on a network), one can ftp to the VME
      computer and transfer the file to some other computer.  One may
      or may not need to swap the bytes in the file after the ftp transfer.
      The actual procedure for using XFR is relatively complicated,
      and we recommend that the interested researcher talk to his or
      her field service engineer to get all the details.

  -Use the PC-program &quot;UPOW&quot;.  The use of this program
      requires that GPIB interface cards be installed in both the PC
      and in the scanner console.  Interested researchers should contact
      Imatron about how to obtain the UPOW software and hardware.

  -Use the shared memory interface &quot;MEGALINK&quot;.  The
      use of this program requires that shared memory interface boards
      be installed in the VME computer and in a compatible workstation.
      Compatible workstations can be purchased from Siemens, ISG Technologies,
      or Cemax.

Two demo image extractors are available for download.  Both are available
with source code, and Imatron does not guarantee either program's
accuracy.  The
first program converts Imatron format files to headerless files.  The
 second program
converts Imatron files to Siemens Somatom, headerless, DICOM, or TIFF. Command
line help can be obtained for either program by typing program_name -h.

Imatron hopes that the information contained here is useful to the
research community.  Assistance, within reason, can be obtained by
contacting:

Cameron J. Ritchie, Ph.D.
Applications Scientist
Imatron Inc.
389 Oyster Point Blvd.
South San Francisco, CA 94080
E-mail: cameron_ritchie@imatron.com

Disk Data-File Formats

Scan data collected are stored as raw data in files on the VME
disk drive.  After reconstruction they are stored as image data
files on the RT-11 disks.  These files comprise header information
and the acquired data.  An Imatron file is a set of information
about multiple slices.  Each file contains:

-A Control Block
-A Single File Header
-A Slice-Header Position Table, and
-One Slice Header (for each slice in the file).

Block 0:  Control Block

The control block is the first block of an Imatron file and contains
information necessary for interpreting the rest of the file (Table
2-1).

Table 2-1: Words in a Control Block

   WORD                         DESCRIPTION

     0      Pointer to first block in the file header

     1      Number of entries in the file header

     2      Pointer to first block of the file header data

     3      Pointer to first block in the slice header

     4      Number of entries in the slice header

     5      Pointer to first block of the slice header position
.    table

     6      Number of words in a header table entry

     7      File type version number

     8      Number of blocks of detector offset data

     9      Number of blocks in file header table

    10      Number of blocks of file header data

    11      Number of blocks in slice header

    12      Number of blocks in slice header position table

    13      Number of blocks for each section of slice header
.    data

    14      Pointer to start of detector offset blocks

  15-255    0
   --->

File and Slice Headers

Imatron file and slice headers store information about:  file
organization, the patient, scanning, reconstruction, and how to
perform image analysis on the data.  Information in these headers
is not stored in fixed locations in the file.  Instead,
there is a symbol table that references the header values by name.
 There are two symbol tables in each file:  the file-header symbol
table (referred to as the file header or file-header table), containing
names and pointers into a single file-header data area; and the
slice-header symbol table (referred to as the slice header or
slice-header table), which uses the same format but its pointers
are used for all the slice-header data areas (one per slice).

The file header and the slice header are composed of pointer/descriptor
units which point to variables in the data blocks.  Each unit
is 6 words (12 bytes) long and organized as shown in Table 2-2.

Table 2-2: Unit Organization

   BYTE                           Contents

   1-6     ASCII variable name, padded with null bytes

    7      Null byte (0)

    8      ASCII variable type (I => Integer, B => Byte, F =>
.   Floating Pt.)

   9-10    Integer pointer to the word number in the block where
.   the data for this variable starts

  11-12    Number of data values of the type described in byte 8.

The integers contained in bytes 9-10 and 11-12 are stored with
the least significant byte in the first byte, and the most significant
byte in the second byte.

The following is an example of how the file-header parameter ICMNTS
is defined:

BYTE:     1-6         7       8     9      10     11     12

.  ICMNTS      0      'B'    37     0      80     0

Parameter variables:

-name is ICMNTS (bytes 1-6)
-and is a byte variable (byte 8)
-and starts at word number 37 in the block (bytes 9,10)
-and contains 80 bytes of data (bytes 11,12).

One block can contain up to 42 pointer/descriptor units.

Slice-Header Position Table

The slice-header position table contains a list of unsigned integer
pointers to the various slice-header data blocks.  The first word
of this table points to slice-header data block 1, the second
to slice-header data block 2, etc.

ECG Data

ECG data is stored in the raw (.VME) and image files for ECG-triggered
studies.  The file header variable ITRTYP, points to the starting
block in the file for this set of data, which, if present, is
32 blocks long.  There is no slice header associated with the
data.

File header parameters are shown in Table 2-3; slice headers are
shown in Table 2-4.

Image Data-File Formats

The C-150 scanner produces axial slices by sweeping an electron
beam along one of four target rings (Target A, B, C, or D).  X-rays
produced by the scanning electron beam are detected by a pair
of solid-state detector rings (Detector Rings 1 and 2).

In an N-image (Imatron image) file there are N slices, 1 slice
per image.  The slice-header parameters, NROWS and NCOLS, define
the number of rows and columns in the stored rectangular image.
 Data is not compressed.  The first NCOLS words in the
slice are the first row, the second NCOLS words are the second
row, etc.  Image data are converted to Hounsfield units by subtracting
1000 (decimal) from each word.  The resulting numbers range from
-1000 to +3095 inclusive (Imagraph).

Table 2-3:  Data File Header Format

 INDEX  NWDS      NAME                  DESCRIPTION

   1      1      IFHLEN       The number of 256 word blocks in the
...      file header.

   2      1      ISHLEN       The number of 256 word blocks in the
...      slice header.

   3      5      IAFN         The ASCII file descriptor.  (6 char.
...      name,'.',3 char. extension)

   8      5      IADATE       ASCII date string. (9 character
...      string right-padded with a blank.

  13      4      IATIME       ASCII time string. (8 character
...      string)

  17      6      IPATID       ASCII patient ID number. (12 chars.)

  23     15      IPATNA       ASCII patient name. (30 chars.)

  38     40      ICMNTS       ASCII comments. (80 chars.)

  78      1      NDETS        The number of detectors. (432 or
...      864)

  79     63      IDEMAP       The detector status map for the
...      file.  All bits defined as
...      1=working, 0=inoperative. Channel
...      k's status is indicated in word
...      IW=1+(k-1)/16, [integer arith.] of
...      IDEMAP, by bit
...       IBIT = k - (IW-1)*16 - 1.

  142     1      ISTOB        The starting block for detector
...      offset measurements. (0 for no
...      offsets recorded.)

  143     1      NSLICE       The number of slices in the file.

  144     1      IORGAN       The file organization code:

...      -2 = unsorted raw MM data (AIR, PIN
...      or OFFSET)
...      -1 = unsorted raw MM data
...      (Non-calibration)
...      0 = source-fan data
...      1 = detector-fan data
...      2 = image (rectangular) data
...      3 = tuning point data
...      4 = deflection buffer data
...      5 = processed calibration data
...      6 = processed AIR data
...      7 = processed OFFSET data

145       1      ITTICK       The DAS clock period is
...      microseconds.

146       1      NPHVEW       The number of phantoms.

147       1      IDATYP       0 = DAS output words (All RAW data)
...      1 = Integer
...      2 = Floating point (Sinogram,
...      tuning,offsets)
...      3 = Scaled 11-bit integer data
...      (image & screen save)
...      4 = AP400 block floating point
...      mantissas
...      5 = MM address data (calibration
...      data)
...      6 = Octal data (deflection buffer
...      files)
...      7 = Packed Fast Raw Averaged Data
...      8 = Scaled 12-bit integer data
...      (image & screen save)

148       1      NDETOM       No. of detector offset measurements

149       2      XMMTMU       The scale factor to change from mm
...      to MIP machine units (units are
...      m.u./mm)

151       1      IREP         The no. of DAS samples per detector
...      per source fan. IREP = 3 for a 50ms
...      scan, IREP = 6 for a 100ms scan.

152       2      PIXLEN       Length in mm. of a pixel, from
...      reconstruction

154       1      NLEVEL       Number of levels in the file

155       1      NPLEVL       Number of images per level (valid in
...      raw image files. Level number is an
...      integer from 1 to NLEVEL.  Closest
...      to the gun is first.)

156       1      IREF         2 Byte ASCII description of the
...      reference pt.

157       1      ISTUDY       Study type:

...      -199 to -100 reserved for test &
...      calibration &quot;studys&quot; (Not
...      Reconstructable!)
...      -1 = SCREEN SAVE   => No analysis
...      possible.
...      0 = SPECIAL STUDY => Anything not
...      covered
...      below.  Atypical study
...      1 = LOCALIZATION  => single scans, 2
...      images per scan, N scans at
...      arbitrary levels (in pairs) (50 ms)
...      2 = FLOW STUDY    => Typically, a
...      set of scans triggered periodically.
...      3 = MOVIE STUDY   => Typically, many
...      scans taken continuously.
...      4 = AVERAGE VOLUME=> Averaged data
...      from a volume study on a single
...      target ring
...      5 = VOLUME STUDY  => various times
...      at lots of levels (table motion)
...      6 = AVERAGE FLOW  => Averaged data
...      from a flow study on a single target
...      ring
...      7 = CONTINUOUS VOLUME (CVS)

...      51 = IMAGE AVERAGING
...      52 = REFORMAT
...      53 to 61 reserved for FUNCTIONAL
...      IMAGE PROC.
...      53 = FIP Maximum Difference
...      54 = FIP Time to Peak
...      55 = FIP Area Under the Curve
...      56 = FIP Center of Mass
...      102 = IMAGE SUBTRACTION FLOW
...      103 = IMAGE SUBTRACTION MOVIE
...      105 = IMAGE SUBTRACTION VOLUME
...      106 = IMAGE SUBTRACTION AVERAGE FLOW

158      10      ICONTR       Type of contrast (20 characters)

168       2      DOSECN       Contrast dose in cc

170      10      INJSIT       Injection Site (20 characters)

180      10      ISTRES       Type of stress (20 characters)

190       7      IRPHYS       Referring physician's last name (14
...      chars)

197       7      IRADIO       Radiologist's last name (14 chars)

204       2      ITECH        Radiation technologist's initials (3
...      chars)

206       5      IBDATE       Patient's birthdate (9 chars (ex.
...      07-jan-17))

211       1      ISTHCK       Slice thickness, mm.

212       1      ICALIB       Calibration number

213       1      KERNEL       Desired kernel flag

214       1      ITRTYP       trigger type:
...      1 = manual
...      2 = timed
...      3 = ecg with no extra data else it's
...      a pointer to ecg data in the file

215       1       IPATSZ      patient size:
...      1 = small
...      2 = medium
...      3 = large
...      4 = shoulder/pelvis kluge

216       1      IPRLVL       regular reconstruction's first level
...      to recon:0 = none  else 1 to nlevel

217      20      IDIAG        diagnosis comment

237       9      IHOSP        hospital (actually scanner)

246       4      BOLTIM       Bolus times

250       1      NSPLIT       Number of images to be created from
...      each raw slice

251       1      IDLINP       Delete raw data flag:
...      0 = do NOT delete after recon
...      1 = delete after complete recon

252       2      CDENS        Density of contrast

254       1      IOFMIN       Time since midnight in minutes of
...      last offsets

255       1      IOFDAT       Day since dec 31 of last offsets

256       1      NRINGS       Number of detector rings used.

257       1      NTARGT       Number of targets used.

258       1      ICNREC       0 = not suitable for cone beam
...      algorithm.
...      1 = suitable for cone beam
...      algorithm.
...      2 = suitable and cone beam alg used.

259       6      KERNAM       ASCII kernel name used.

260       1      ISNTYP       Sinogram type.

261       1      IANTYP       Analysis type for ASA
...      1 = Cone analysis
...      2 = Air analysis
...      3 = Pin analysis

262       1      ISTHCF       Slice thickness.  LSB = 1/100 mm.

263       1      ICOLL        Collimator setting (1=1.5mm, 3, 6)

Table 2-4:  Data Slice Header Format

 INDEX     NWDS     NAME                  DESCRIPTION

   1        1      ISDATP      Pointer to data for this slice
...       (Always here!)

   2        2      R1MU        Linear attenuation co-efficient for
...       water at this energy and current,
...       ring 1.

   4        1      IROTA       = 1 clockwise scan,
...       or
...       = -1 for counter-clockwise scan.

   5        2      HVDES       Desired high voltage for this scan,
...       in kV.

   7        2      HVACT       Actual high voltage for this scan,
...       in kV

   9        1      ICURNT      Actual electron beam current, in
...       milliamps.

  10        2      FVDES       Desired filament voltage, in volts.

  12        2      FVACT       Actual filament voltage, in volts.

  14        2      FCACT       Actual filament current, in
...       milliamps.

  16        1      IRING       The detector ring used:
...       0 = Raw slice with both RINGs
...       interleaved
...       1 = RING 1 (closest to gun)
...       2 = RING 2 (farther from gun)

  17        1      ITARGT      The target ring used.

  18        1      NSLAVG      The number of scans averaged to
...       produce this slice.

  19        2      PICRAD      Floating point picture radius in
...       mm.

  21        2      XORG        Floating point X coordinate of
...       reconstruction center (0.0 is
...       isocenter) in mm.

  23        2      YORG        Floating point Y coordinate of
...       reconstruction center (0.0 is
...       isocenter) in mm.

  25        2      ZOOM        Floating point zoom factor (1.0 =
...       no zoom) for reconstruction

  27        1      NROWS       The number of rows in the
...       reconstructed image.

  28        1      NCOLS       The number of cols in the
...       reconstructed image.

  29        2      VALMAX      Maximum value in the slice (in
...       floating point)

  31        2      VALMIN      Minimum value in the slice (in
...       floating point)

  33        2      RSCALE      Data has been scaled and biased
...       such that

  35        2      RMIN        actual data = data/RSCALE + RMIN

  37        1      IPATH       Holding path flag:
...       0 = path was HOLDING PATH
...       1 = path was the first for that
...       pulse
...       2 = the slice was NOT the first of
...       that pulse (slices 2-N for a movie
...       or volume)

  38        2      ELAPSE      Time, in seconds, since the first
...       scan

  40        1      LEVELN      The level number for a given slice

  41        2      ISTAGE      Old:2 word array, 2nd word unused,
...       1st word is >=0 if data is present
...       and useful.

  43        1      INOUT       In-out table pos. relative to ref.
...       (-0.1 mm)

  44        1      IHITE       Up-down table pos. relative to
...       reference (mm)

  45        1      ITILT       Table tilt relative to horizontal
...       (degrees)

  46        1      ISLEW       Table slew relative to straight
...       (degrees)

  47        1      ICPHAS      Cardiac phase in % R-R-wave
...       interval

  48        1      IBEAT       Heart beat # for this image

  49        2      HRATE       Heart rate in beats per minute

  51        1      IPATOR      Integer code for patient
...       orientation:
...       0 = not applicable or special case
...       5 = prone head first flipped
...       + 1 = supine

....+ 2 = prone
....+ 3 = decubitus right
....+ 4 = decubitus left
....-5 = supine ff (flipped to match
...       1)
....-6 = prone ff (ditto 2)
....-7 = decub right (ditto 3)
....-8 = decub left (ditto 4)
...       Positive refers to HEAD FIRST (head
...       closest to gun).  Negative refers
...       to FEET FIRST.

  52        2      SLSIZE      Size of slice in words

  54        1      ITN         Order of Chebychev polynomial
...       applied to data (only if valid
...       during calibration, for normal
...       recon ITN = 0).

  55        2      R2MU        Linear attenuation coefficient for
...       water at this energy and current,
...       ring 2.

  57        1      IVMFLAG     Contains bit-map of flags used by
...       recon.

  58        1      NTARGS      Number of target sections of this
...       target ring.

Scanner Operating Modes

The scanner operates in two different modes:  Single-Slice Mode
(SSM) and Multi-Slice Mode (MSM).

Single-Slice Mode:

  The FILE HEADER variable &quot;IREP&quot; defines Single-Slice
Mode:

IREP = 6 for SSM

  The total number of images in the file is the FILE HEADER variable
NSLICE.

  The total number of axial slice positions in the file is the
FILE HEADER variable NLEVEL.

  In SSM, only Target Ring C and Detector Ring 2 are used.

  Each sweep of the beam along Target Ring C takes 100 milliseconds.

  The exposure time (in seconds) is determined by the SLICE HEADER
variable &quot;NSLAVG&quot;:

Exposure time (seconds) = NSLAVG * 0.1

  The axial position for each slice is determined by the SLICE
HEADER variable &quot;INOUT&quot; (which is in tenth
mm units):

Slice position relative to reference (in mm) = INOUT/10

Multi-Slice Mode:

  The FILE HEADER variable &quot;IREP&quot; defines Multi-Slice
Mode:

IREP = 3 for MSM

  The total number of images in the file is the FILE HEADER variable
NSLICE.

  The total number of axial slice positions in the file is the
FILE HEADER variable NLEVEL.

  In MSM Mode, each sweep of the electron beam along a single
target ring produces a pair of simultaneously acquired, side-by-side
axial slices (1 from each detector ring).

  Any combination of target rings (A, B, C, or D) may be used.

  Each sweep of the beam along any single target ring takes 50
milliseconds.

  The exposure time (in seconds) is determined by the SLICE HEADER
variable &quot;NSLAVG&quot;:

Exposure time (seconds) = NSLAVG * 0.05

  The axial position for each slice is determined by the SLICE
HEADER variables &quot;INOUT,&quot;  &quot;ITARGET,&quot; and
&quot;IRING&quot; and may be calculated as follows:

KTARGT = ITARGT - 64  /* Convert ascii target to integer */

TAROFF = -20.0 + (4 - KTARGT)*20.0  /* Distance from C to target
*/

DETOFF = mod(IRING,2)*8 /* Distance from detector Ring 2 to detector
*/

Slice position relative to reference (in mm) = INOUT/10. + TAROFF
+ DETOFF

Study Types

The six Imatron study types are described as follows:

SSM Flow (IREP = 6, ISTUDY = 6)

Description:         For an N-slice SSM Flow Study, the following
..     is repeated NSLICE times:  A 100-ms sweep of
..     the beam is performed NSLAVG times along
..     ring C (with 16 ms between sweeps), and the
..     data for the NSLAVG sweeps are summed
..     together to produce a single image.  All of
..     the data are acquired at a single axial
..     slice position, sequentially in time.

File Organization:   Slice 1 in the file is the first &quot;time,&quot;
..     slice 2 is the second &quot;time,&quot; ...slice n is
..     the nth &quot;time.&quot;

SSM Cine (IREP = 6, ISTUDY = 3)

Description:         For an N-slice SSM Cine study, NSLICE 100-ms
..     sweeps of the beam are performed along
..     Target Ring C (with 16 ms between sweeps).
..     Each sweep of the beam produces a single
..     image.  All of the data are acquired at a
..     single axial slice position, sequentially in
..     time.

File Organization:   Slice 1 in the file is the first &quot;time,&quot;
..     slice 2 is the second &quot;time,&quot;  ... slice n
..     is the nth &quot;time.&quot;

SSM Volume (IREP = 6, ISTUDY = 5)

Description:         In an N-slice volume study, the following
..     sequence is repeated NSLICE times in
..     succession:  A 100 ms sweep of the beam is
..     performed NSLAVG times along ring C (with
..     16-ms between sweeps), and the data for the
..     NSLAVG sweeps are summed together to produce
..     a single image.  Then the patient table
..     moves to a new axial position.

File Organization:   Slice 1 in the file is the first &quot;level,&quot;
..     slice 2 is the second &quot;level,&quot; ... slice n
..     is the nth &quot;level.&quot;

MSM Volume (IREP = 3, ISTUDY = 5)

Description:         MSM Volume Studies always use Target Ring C
..     (only), and both Detector Rings 1 and 2.  In
..     an MSM VOLUME STUDY, the following sequence
..     is repeated NLEVEL/2 times in succession:  A
..     50-ms sweep of the beam is performed NSLAVG
..     times along ring C (with 8-ms between
..     sweeps) and the data for the NSLAVG sweeps
..     are summed together to produce a pair of
..     side-by-side images acquired at adjacent
..     axial positions.  Then the patient table
..     moves to a new axial position.

File Organization:   Slice 1 in the file is the first &quot;level,&quot;
..     slice 2 is the second &quot;level,&quot; ...slice n is
..     the nth &quot;level.&quot;

MSM Flow (IREP = 3, ISTUDY = 1 or 2)

Description:         Refer to the general Multi-Slice Mode
..     description, above. In an MSM Flow study,
..     the following applies:

..     N_T = The number of times = NSLICE/NLEVEL

..     The following action is repeated N_T times:

..       For a 2-level MSM Flow, the beam sweeps
..     once on a single target ring (A, B, C, or D)
..     to produce a pair of side-by-side images
..     acquired at the same &quot;time.&quot;

..       For a 4-level MSM Flow, the beam sweeps
..     once on one target ring, then 8 ms later,
..     sweeps on a second target ring; this
..     produces 4 side-by-side images acquired at
..     the same &quot;time.&quot;

..       For a 6-level MSM Flow, the beam sweeps
..     once on one target ring, then 8 ms later,
..     sweeps on a second target ring; followed 8
..     ms later by another sweep, on a third target
..     ring; this produces 6, side-by-side images
..     acquired at the same &quot;time.&quot;

..     For an 8-level MSM Flow, the beam sweeps
..     once on one target ring, then 8 ms later,
..     sweeps on a second target ring; followed 8
..     ms later by another sweep on a third target
..     ring, and again, 8 ms later on the fourth
..     target ring; this produces 8, side-by-side
..     images acquired at the same &quot;time&quot; (Table
..     2-5).

Table 2-5:  File Organization for MSM Flow

  Slice in File     Time            Axial Position
..   Index

.1             1     use MSM Template info => axial
...    index i

.2             1     use MSM Template info => axial
...    index ii

.3             1     use MSM Templace info => axial
...    index iii

..             .     .

..             .     .

..             .     .

     NLEVEL           1     use MSM Template info => index
...    nlevel

    NLEVEL+1          2     axial index i

    NLEVEL+2          2     axial index ii

..             .     .

..             .     .

..             .     .

    2*NLEVEL          2     axial index nlevel

   2*NLEVEL+1         3     axial index i

..             .     .

..             .     .

..             .     .

(N_T-1)*NLEVEL+1     N_T    axial index i

(N_T-1)*NLEVEL+2     N_T    axial index ii

..             .     .

..             .     .

..             .     .

   N_T*NLEVEL        N_T    axial index nlevel

MSM Cine (IREP = 3, ISTUDY = 3)

Description          Refer to the general MSM description above.
..     In an MSM Cine study, the following applies:

..     N_T = The number of times = NSLICE/NLEVEL

..     NTARGS = The number of targets used =
..     NLEVEL/2

The following action is repeated NTARGS times (once for each target):
 N_T 50-ms sweeps of the beam are performed, with 8-ms between
sweeps, along a single target ring (A, B, C, or D); this produces
a pair of images acquired at adjacent axial positions.  (See Table
9, below.)

Table 2-6:  File Organization for MSM Cine

Slice in File       Time              Axial Position
..    Index

      1               1     use MSM Template info => axial index
...    i

      2               1     use MSM Template info => axial index
...    ii

      3               2     axial index i

      4               2     axial index ii

      5               3     axial index i

      6               3     axial index ii

      .               .     .

      .               .     .

   2*N_T-1           N_T    axial index i

   2*N_T             N_T    axial index ii

   2*N_T+1            1     use MSM Template info => axial index
...    iii

   2*N_T+2            1     use MSM Template info => axial index
...    iv

   2*N_T+3            2     axial index iii

   2*N_T+4            2     axial index iv

      .               .     .

      .               .     .

   4*N_T-1           N_T    axial index iii

   4*N_T             N_T    axial index iv

      .               .     .

      .               .     .

(NLEVEL-2)*N_T+1      1     use MSM Template info => axial index
...    nlevel-1

(NLEVEL-2)*N_T+2      1     use MSM Template info => axial index
...    nlevel

(NLEVEL-2)*N_T+3      2     axial index nlevel-1

(NLEVEL-2)*N_T+4      2     axial index nlevel

      .               .     .

      .               .     .

NLEVEL*N_T-1         N_T    axial index nlevel-1

NLEVEL*N_T           N_T    axial index nlevel

The next part is part4 -  proprietary MR formats.

