Medical Image Format FAQ - Part 3 Medical Image Format FAQ - Part 3Used for files exported from:
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
The Numaris (MRI) and Somaris (CT) software contains certain common features, especially when running on common platforms. This is particularly true of more recent versions that are Sparc and SunOS based rather than the older Vax/VMS systems .
Under construction.
This information is derived mostly from some recent experiments with Numaris VB21B on an Open and Somaris on an AR-C. There is a lot of useful information to be found in the System Manual for both families, not to mention the configuration release notes. Both use bog standard Sun OS 4.1.x, and tend to keep the platform/application specific information in the /usr/appl tree. The user interface is standard OpenWindows.
This will become apparent when the system is started up. The normal SunOS boot procedure is observed. On somaris, the system automatically loads Open Windows and followed by the Somaris application. On Numaris one logs in as the "mr" user, usually without any password, and gets OpenWindows and the Numaris application. Interrupting this process will be described later.
The first step in exploring the system is getting a console. On Numaris this is easy. Running all the way down the right hand side of the screen is an information area from the Numaris application. About a third of the way down the edge, a little grayed out icon is visible. Clicking or dragging on this will expose the fact that this is an iconified console window. On Somaris, the console is still iconified but completely hidden by the right information area. The trick to grabbing this is to do a System/End (menu with right mouse button down) and select Application and Restart, which brings the application and the OpenWindows down and back up again. While this is happening you can see the iconified console and drag it into the middle of the screen, where you can open it later.
While on the subject of System/End, the various options are permuations of normal commands like logout, halt or shutdown.
Once one has a Unix prompt one can explore the system, and create directories in which to save exported images. The Numaris manual's example suggested /usr/appl/external as a place to store exported files. On Numaris this already exists and is empty. On Somaris it doesn't but the normal user has the permission to create it with a "mkdir /usr/appl/external". The normal commands like telnet and ftp are available if one wants to use these to go outward bound on the network, if it is configured (which will be discussed later).
Images are stored in native form in /usr/appl/data/disk1, at least on the systems that I have examined. They are stored one image per file, and named something like nnn-ss-iii.ima, where nnn is some sequential number that pertains to the patient (or instance of the examination ... I am not sure), ss is the series number (always 1 on Somaris), and iii is the sequential image number within nnn. The hard part is figuring out what nnn is for the patient you want ... this number is not displayed in the normal Patient Select dialogs or anywhere else I can find. Counting back from the latest patient and comparing the highest value of iii seems to be a crude but effective approach.
The native images are stored in the usual Siemens style, with a binary header of fixed length (that varies from product to product in length and layout) and trailing uncompressed image pixel data. The specifics where known are described elsewhere.
On any of these products one can use the System/External Data menu option to bring up a dialog with Import or Export choices. Select Export, enter /usr/appl/external or whatever as the destination, and choose the image numbers (eg. "1-6,10,22-24" is quite acceptable) and they will be written where you asked. The patient name must be exactly as it is registered. The catch is that the exported SPI files will be named with the patient's name and the current date and time of export, not the time of acquisition or reconstruction or whatever, so sorting through these to determine what they are is a pain. The form of the date and time stamp in the name is "yyyymmddhhmmssff".
So you know where the images are ... how do you get them off. One way is by ethernet connection. One doesn't have to have the PACSNet or DICOM option to be able to connect to the network. If you haven't paid for the PAL that provides hardware protection for these functions, it doesn't mean that the ethernet software in Sun OS and the ethernet port on the Sparc host is not live. During installation of the Somaris or Numaris software the Siemens Field Engineer can configure the interface with a IP address of your choice (it defaults to 1.0.0.1 under Numaris, and the le0 interface is not configured by default under Numaris).
If the Siemens FE is unfamiliar with the procedure tell them to use the "install" login, choose SSC (Site Specific Configuration) then RC (Reset host Configuration), accepting the defaults until you get to "Internet Address". If you know the "install" password (or can change it as root) you can do this yourself. I don't think the additional layer of Siemens password protection applies to this particular tool, though there are many you won't be able to run.
If you are really desperate you can gain root access and manually configure the SunOS network configuration without using the Siemens tool, but you need to be pretty familiar with SunOS to do this. You need to put in a real IP address in /etc/hosts, create an /etc/hostname.le0, and if necessary set up /etc/netmasks if the default is not appropriate. I tried this and it works but it somehow messed up camera communications, so doing it with the Siemens FE is probably better. Don't forget to back up the critical files first just in case.
The standalone configuration on the AR/C had just the loopback address (127.0.0.1) in /etc/hosts and no /etc/hostname.le0.
The physical ethernet connector is normally unused, and is located on the Sparc host board and is the usual AUI connector (ie. you need an AUI to 10BaseT or whatever transceiver). On the AR/C I tested it was located under the desktop (ie. lift the desktop off, and then the metal cover), sticking up on the left hand side. On the Magnetom Open it was in the computer room in the cabinet with the host processor at the bottom on the left hand side. In this installation it was connected to a lead going to a breakout panel on the top cover of the cabinet. This is unused so just disconnect it and plugin your own.
Another way to get the images off is to just use the QIC streaming tape drive. This is probably still installed in older machines, but the newer software is being distributed on CD-ROM so the tape drive is being pulled and replaced with a CD. It is probably still in the maintenence closet though and would be easy to swap back in. No configuration is necessary. It is accessed as usual as /dev/rst0 and its rewinding and non-rewinding variants, and one can just tar image files off to it. Very handy. No messing with wierd Pioneer WORM's and MOD's !
The drive is physically located on the front of the processor box in the desk models and in the host processor cabinet beside the optical drive in the computer room in the larger installations.
Speaking of WORM's and MOD's, they are the same unreadable media as used by GE, but of course have a different filesystem. When used as archive devices these are not the standard unix file system, and you will not see any evidence of a mounted device doing a "mount" or "df", even though when you stick one in the drive the application automatically detects it and mounts it. It is said in the release notes that one can actually format and mount one of these as a unix filesystem instead (the MOD at least) but I don't know how to do it, and haven't discovered, not possessing one of them there Pioneer drives to read one on.
If you thought you could mess up a perfectly good scanner already, try becoming root. Why would one need to do this ? To manually reconfigure the network, to change passwords for critical logins like install, to create your own login some place clean and safe, etc. Since this is standard SunOS, the usual principles apply ... first try rebooting in single user mode. Do this with a System/End choosing System/Norestart and you will get a boot prompt. Type "b -s" and it comes up in single user mode, allowing you to mess with /etc all you like as root.
If this mode has been password protected (and one can do this by removing "secure" from "console" in /etc/ttytab ... see "man 5 ttytab") then one is not out of luck yet. Now you have to put a SunOS boot disk in the CDROM drive (or plugin an external CDROM drive) and boot SunOS mini-root, then mount /dev/sd0 as /mount and you are in business. (If you don't have a SunOS CDROM then you probably shouldn't be doing this kind of thing in the first place).
If you are messing about in SunOS, periodically the Somatom application will get out of sync with the new reality you have created and will complain that an Init/Reset is necessary ... well, do an Init/Reset. I have forgotten exactly where it is in the menus, whether under System or Measurement. It is documented in the system manual and seems harmless.
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, this is now no longer necessary, as General Electric 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.
References (see the GEMS image format information contacts section):
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.
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"
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.
References (see the GEMS image format information contacts section):
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.
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):
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)
See the GE MR Signa 5.x Archive format.
Again, unknown. Please fill in this space.
References (see the GEMS image format information contacts section):
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;
}
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
The GE CTI family of scanners are based on the IOS platform, but fully support DICOM both on the network and on MOD media. hence it is rarely if ever desirable or necessary to get involved with the internal format within the SGI host that runs these scanners. Having said that, it is worth pointing out that internally images may be stored in a Genesis like format, with the same header layout except that some fields are 32 bit rather than 16 bit aligned (like on AW from which the IOS platform was derived), or in a true DICOM format, with a Part 10 style meta-header, except that the meta-header is encoded in implicit not explicit little endian (since it was designed and implemented before the standard Part 10 was finished and hence used the convention of early drafts).
None of this should be of consequence however, since images should always be exported from CTI scanners using network transfer or on DICOM media.
There are a few caveats however, both for the network and for media.
For network transfers, be absolutely sure that the storage SCP accepts only DICOM standard SOP classes during association negotiation, and is not promiscuous ("I will store anything of any SOP class"). Otherwise the CTI will by preference send proprietary GE SOP Classes of the ID/NET 2.0 variety, which are very DICOM like but are sufficiently different from the standard CT sop class to cause problems. The SOP Class UIDs of the ID/NET 2.0 SOP CLasses are specified in the conformance statement and if you absolutely must know what they contain there is an old service direction that describes them that is probably still available.
For the DICOM MOD media, the problems are more serious, and some of them are described in the more recent CTI conformance statement and are further explained here. Note that all these problems have been fixed, so that more recent CTI, MR LX and AW 3X devices should be writing good conformant media but still be able to read the old "bad" media". However since there may be shelves full of "bad" media one needs to be aware of the details of the problem. There is more bad CT media around than MR and AW since the fix came later to the CTI.
General details of the encapulsation and JPEG encoding are defined in DICOM Part 5 and ISO 10918-1, and explained in this FAQ in DICOM Compression. Specific details of the GE bugs are defined here, as well as being described in more recent GE CTI Conformance statements. See for example section 3.4.2 of GE Direction 2162114-100 High Speed Advantage 4.1 and 5.3 Conformance Statement.
There are two classes of problem, one related to the DICOM encapsulation, and the other to the JPEG encoding itself.
Even though all DICOM encapsulated transfer syntaxes specify little endian byte order for all non-pixel data values and for all element tags and value lengths, inadvertantly some of the delimiter and item tags in GE encapsulated pixel data are sent in either big endian for each of the group and element of the item and sequence delimited tags, or in little endian for the concatenated value of group and element as af they were a 32 bit word. That is instead of (FFFE,E000) Item being sent as FE,FF,00,EO as specified in the standard, it might be seen as FF,FE,E0,00 or 00,E0,FE,FF. Instead of (FFFE,E0DD) Sequence Delimiter being sent as FE,FF,DD,EO, it might be seen as FF,FE,E0,DD or DD,E0,FE,FF. Note also that if the Item tag is encoded wrong, then the VL field is also incorrectly encoded as a big endian 32 bit word instead of a little endian 32 bit word.
In the GE JPEG codec output, the JPEG 'SOS' header defines the Huffman table selector codes to find the appropriate Huffman table. These are incorrectly coded these as 0x11. They should have been 0x00, since those are the values assigned in the "DHI" header where the Huffman tables are actually sent. This bug manifests itself as a "Huffman table not found" error from an unpatached decoder. It also serves as a useful flag to a patched decoder that this bug (and others are present) and allows a single decoder to handle both good and bad GE compressed bit streams.
The incorrect GE JPEG computation of the difference to be Huffman encoded was computed as (Predictor - value) when it should have been calculated as (value - Predictor). The result is that the decompression with an unpatched decoder results in a "negative" of the original image. Note that GE only uses Selection Value 1 predication, so there is no need to patch other predictors.
The predictor value used at the beginning of each line used the last value of the previous line in the image, instead of the first element of the line above the current line, and for the first line, the unsigned value that is half the full scale range for the "sample precision". This manifests itself as a wierd "banding" across the image as predictions get offset by increasing errors.
An example of code that copes with both the standard and GE bugs in JPEG compression can be found in the patches to the Stanford PVRG JPEG (see JPEG Sources).
An example of code that copes with both the standard encapsluation and GE bugs in encapsulation can be found in dicom3tools "libsrc/include/pixeld/unencap.h". A section of that code (with some of the error handling removed) is reproduced here.
size_t read(void)
{
// - non-pixel data is always LE, including fragment delimiters and lengths
// - 1st item is offset table, may have zero VL
// - other items are fragments
// - finally sequence delimitation tag (with zero VL)
// - each delimiter is 2 byte group,2 byte element, 4 byte VL, little endian
// - Item tag is (0xfffe,0xe000) (GE mistake is 0xfeff,0x00e0 or 0xe000,0xfffe)
// - Seq delimiter is (0xfffe,0xe0dd) (GE mistake is 0xfeff,0xdde0 or 0xe0dd,0xfffe)
// - when GE mistake is present, fragment 32 bit VL is also swapped
length=0;
while (!lefttoreadthisfragment && !finished && !bad) {
Uint16 group=read16();
Uint16 element=read16();
Uint32 vl=read32();
if (group == 0xfffe || group == 0xfeff || group == 0xe000 || group == 0xe0dd) {
if (group != 0xfffe) {
cerr << "UnencapsulatePixelData::unexpected group (? bad byte order)=" << hex << group << dec << endl;
}
if (element == 0xe0dd || element == 0xdde0 || group == 0xe0dd) { // Sequence Delimiter Tag
if (element != 0xe0dd) {
cerr << "UnencapsulatePixelData::unexpected element (? bad byte order)=0x" << hex << element << dec << endl;
}
Assert(vl == 0);
finished=true;
}
else /* if (element == 0xe000) */ { // Item Tag
bool vlbyteorderwrong=false;
if (element != 0xe000) {
cerr << "UnencapsulatePixelData::unexpected element (? bad byte order)=0x" << hex << element << dec << endl;
vlbyteorderwrong=true;
}
if (++fragmentnumber > 0) {
Assert(vl); // Zero length fragments thought not to be legal
if (vlbyteorderwrong) {
lefttoreadthisfragment=
(((Uint32)vl&0xff000000)>>24)
+(((Uint32)vl&0x00ff0000)>>8)
+(((Uint32)vl&0x0000ff00)<<8)
+(((Uint32)vl&0x000000ff)<<24);
cerr << "UnencapsulatePixelData::assuming VL also had bad byte order, using 0x" << hex << lefttoreadthisfragment << dec << endl;
}
else {
lefttoreadthisfragment=vl;
}
}
else {
// skip the offset table
Assert(vl%4 == 0);
unsigned i=0;
while (vl) {
Uint32 offset=read32();
vl-=4;
++i;
}
}
}
}
else {
// bad tag group in encapsulated data
bad=true;
}
}
if (lefttoreadthisfragment && !bad) {
length=unsigned(lefttoreadthisfragment > maxlength ? maxlength : lefttoreadthisfragment);
if (istr->read(buffer,length)) {
length=istr->gcount();
}
else {
bad=true;
length=0;
}
lefttoreadthisfragment-=length;
}
return length;
}
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.
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
Unknown.
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:
The following information is included verbatim from that kindly supplied by Cameron Ritchie:
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:
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
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:
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).
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
--->
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.
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:
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 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.
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).
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 "studys" (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)
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.
The scanner operates in two different modes: Single-Slice Mode (SSM) and Multi-Slice Mode (MSM).
The FILE HEADER variable "IREP" 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 "NSLAVG":
Exposure time (seconds) = NSLAVG * 0.1
The axial position for each slice is determined by the SLICE HEADER variable "INOUT" (which is in tenth mm units):
Slice position relative to reference (in mm) = INOUT/10
The FILE HEADER variable "IREP" 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 "NSLAVG":
Exposure time (seconds) = NSLAVG * 0.05
The axial position for each slice is determined by the SLICE HEADER variables "INOUT," "ITARGET," and "IRING" 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
The six Imatron study types are described as follows:
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 "time,"
slice 2 is the second "time," ...slice n is
the nth "time."
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 "time,"
slice 2 is the second "time," ... slice n
is the nth "time."
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 "level,"
slice 2 is the second "level," ... slice n
is the nth "level."
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 "level,"
slice 2 is the second "level," ...slice n is
the nth "level."
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 "time."
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 "time."
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 "time."
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 "time" (Table
2-5).
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
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.)
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.
END OF PART 3