Docstoc

file_format

Document Sample
file_format Powered By Docstoc
					                                         Version 1.00
                                          Paul Haeberli
                               Silicon Graphics Computer Systems
                                     paulhaeberli@yahoo.com
Introduction
This is the definitive document describing the SGI image file format. This is a low level
spec that describes the actual byte level format of SGI image files. On SGI machines the
preferred way of reading and writing SGI image files is to use the image library -limage.
This library provides a set of functions that make it easy to read and write SGI images. If
you are on an SGI workstation you can get info on -limage by doing:
        % man 4 rgb
A note on byte order of values in the SGI image files
In the following description a notation like bits[7..0] is used to denote a range of bits in a
binary value. Bit 0 is the lowest order bit in the value.
All short values are represented by 2 bytes. The first byte stores the high order 8 bits of
the value: bits[15..8]. The second byte stores the low order 8 bits of the value: bits[7..0].
So this function will read a short value from the file:
   unsigned short getshort(inf)
  FILE *inf;
  {
         unsigned char buf[2];


         fread(buf,2,1,inf);
         return (buf[0]<<8)+(buf[1]<<0);
   }
All long values are represented by 4 bytes. The first byte stores the high order 8 bits of the
value: bits[31..24]. The second byte stores bits[23..16]. The third byte stores bits[15..8].
The forth byte stores the low order 8 bits of the value: bits[7..0].
And this function will read a long value from the file:
   static long getlong(inf)
  FILE *inf;
  {
         unsigned char buf[4];


         fread(buf,4,1,inf);
         return (buf[0]<<24)+(buf[1]<<16)+(buf[2]<<8)+(buf[3]<<0);
  }
The general structure of an SGI image file
The header indicates whether the image is run length encoded (RLE).
If the image is not run length encoded, this is the structure:
       The Header
       The Image Data
If the image is run length encoded, this is the structure:
       The Header
       The Offset Tables
       The Image Data
The Header
The header consists of the following:
    Size | Type | Name        | Description


   2 bytes | short | MAGIC      | IRIS image file magic number
   1 byte | char | STORAGE | Storage format
   1 byte | char | BPC        | Number of bytes per pixel channel
   2 bytes | ushort | DIMENSION | Number of dimensions
   2 bytes | ushort | XSIZE     | X size in pixels
   2 bytes | ushort | YSIZE     | Y size in pixels
   2 bytes | ushort | ZSIZE     | Number of channels
   4 bytes | long | PIXMIN      | Minimum pixel value
   4 bytes | long | PIXMAX       | Maximum pixel value
   4 bytes | char | DUMMY        | Ignored
   80 bytes | char | IMAGENAME | Image name
   4 bytes | long | COLORMAP | Colormap ID
  404 bytes | char | DUMMY         | Ignored
       Here is a description of each field in the image file header:
       MAGIC - This is the decimal value 474 saved as a short. This identifies the
       file as an SGI image file.
       STORAGE - specifies whether the image is stored using run length encoding
       (RLE) or not (VERBATIM). If RLE is used, the value of this byte will be 1.
       Otherwise the value of this byte will be 0. The only allowed values for this
       field are 0 or 1.
       BPC - describes the precision that is used to store each channel of an
       image. This is the number of bytes per pixel component. The majority of SGI
       image files use 1 byte per pixel component, giving 256 levels. Some SGI
       image files use 2 bytes per component. The only allowed values for this field
       are 1 or 2.
       DIMENSION - described the number of dimensions in the data stored in the
       image file. The only allowed values are 1, 2, or 3. If this value is 1, the image
      file consists of only 1 channel and only 1 scanline (row). The length of this
      scanline is given by the value of XSIZE below. If this value is 2, the file
      consists of a single channel with a number of scanlines. The width and
      height of the image are given by the values of XSIZE and YSIZE below. If
      this value is 3, the file consists of a number of channels. The width and
      height of the image are given by the values of XSIZE and YSIZE below. The
      number of channels is given by the value of ZSIZE below.
      XSIZE - The width of the image in pixels
      YSIZE - The height of the image in pixels
      ZSIZE - The number of channels in the image. B/W (greyscale) images are
      stored as 2 dimensional images with a ZSIZE or 1. RGB color images are
      stored as 3 dimensional images with a ZSIZE of 3. An RGB image with an
      ALPHA channel is stored as a 3 dimensional image with a ZSIZE of 4. There
      are no inherent limitations in the SGI image file format that would preclude
      the creation of image files with more than 4 channels.
      PINMIN - The minimum pixel value in the image. The value of 0 may be used
      if no pixel has a value that is smaller than 0.
      PINMAX - The maximum pixel value in the image. The value of 255 may be
      used if no pixel has a value that is greater than 255. This is the value that is
      considered to be full brightness in the image.
      DUMMY - This 4 bytes of data should be set to 0.
      IMAGENAME - An null terminated ascii string of up to 79 characters
      terminated by a null may be included here. This is not commonly used.
      COLORMAP - This controls how the pixel values in the file should be
      interpreted. It can have one of these four values:
      0: NORMAL - The data in the channels represent B/W values for images with
      1 channel, RGB values for images with 3 channels, and RGBA values for
      images with 4 channels. Almost all the SGI image files are of this type.
      1: DITHERED - The image will have only 1 channel of data. For each pixel,
      RGB data is packed into one 8 bit value. 3 bits are used for red and green,
      while blue uses 2 bits. Red data is found in bits[2..0], green data in bits[5..3],
      and blue data in bits[7..6]. This format is obsolete.
      2: SCREEN - The image will have only 1 channel of data. This format was
      used to store color-indexed pixels. To convert the pixel values into RGB
      values a colormap must be used. The appropriate color map varies from
      image to image. This format is obsolete.
      3: COLORMAP - The image is used to store a color map from an SGI
      machine. In this case the image is not displayable in the conventional sense.
      DUMMY - This 404 bytes of data should be set to 0. This makes the header
      exactly 512 bytes.
The Image Data (if not RLE)
If the image is stored verbatim (without RLE), then image data directly follows the 512 byte
header. The data for each scanline of the first channel is written first. If the image has
more than 1 channel, all the data for the first channel is written, followed by the remaining
channels. If the BPC value is 1, then each scanline is written as XSIZE bytes. If the BPC
value is 2, then each scanline is written as XSIZE shorts. These shorts are stored in the
byte order described above.
The Offset Tables (if RLE)
If the image is stored using run length encoding, offset tables follow the header that
describe what the file offsets are to the RLE for each scanline. This information only
applies if the value for STORAGE above is 1.
       Size | Type | Name       | Description


 tablen longs | long | STARTTAB | Start table
  tablen longs | long | LENGTHTAB | Length table
One entry in each table is needed for each scanline of RLE data. The total number of
scanlines in the image (tablen) is determined by the product of the YSIZE and ZSIZE.
There are two tables of longs that are written. Each consists of tablen longs of data. The
first table has the file offsets to the RLE data for each scanline in the image. In a file with
more than 1 channel (ZSIZE > 1) this table first has all the offsets for the scanlines in the
first channel, followed be offsets for the scanlines in the second channel, etc. The second
table has the RLE data length for each scanline in the image. In a file with more than 1
channel (ZSIZE > 1) this table first has all the RLE data lengths for the scanlines in the first
channel, followed be RLE data lengths for the scanlines in the second channel, etc.
To find the the file offset, and the number of bytes in the RLE data for a particular scanline,
these two arrays may be read in and indexed as follows:
To read in the tables:
    unsigned long *starttab, *lengthtab;


  tablen = YSIZE*ZSIZE*sizeof(long);
  starttab = (unsigned long *)mymalloc(tablen);
  lengthtab = (unsigned long *)mymalloc(tablen);
  fseek(inf,512,SEEK_SET);
  readlongtab(inf,starttab);
  readlongtab(ing,lengthtab);
To find the file offset and RLE data length for a scanline:
rowno is an integer in the range 0 to YSIZE-1 channo is an integer in the range 0 to
ZSIZE-1
  rleoffset = starttab[rowno+channo*YSIZE]
    rlelength = lengthtab[rowno+channo*YSIZE]
It is possible for two identical rows (scanlines) to share compressed data. A completely
white image could be written as a single compressed row and having all table entries point
to that row. Another little hack that should work is if you are writing out a RGB RLE file,
and a particular scanline is achromatic (greyscale), you could just make the r, g and b
rows point to the same data!!
The Image Data (if RLE)
This information only applies if the value for STORAGE above is 1. If the image is stored
using run length encoding, the image data follows the offset tables above. The RLE data is
not in any particular order. The offset tables above are used to locate the rle data for any
scanline.
The RLE data must be read in from the file and expanded into pixel data in the following
manner:
If BPC is 1, then there is one byte per pixel. In this case the RLE data should be read into
an array of chars. To expand data, the low order seven bits of the first byte: bits[6..0] are
used to form a count. If the high order bit of the first byte is 1: bit[7], then the count is used
to specify how many bytes to copy from the RLE data buffer to the destination. Otherwise,
if the high order bit of the first byte is 0: bit[7], then the count is used to specify how many
times to repeat the value of the following byte, in the destination. This process continues
until a count of 0 is found. This should decompress exactly XSIZE pixels.
Here is example code to decompress a scanline:
    expandrow(optr,iptr,z)
  unsigned char *optr, *iptr;
  int z;
  {
           unsigned char pixel, count;


           optr += z;
           while(1) {
               pixel = *iptr++;
               if ( !(count = (pixel & 0x7f)) )
                      return;
               if(pixel & 0x80) {
                      while(count--)
                          *optr++ = *iptr++;
               } else {
                      pixel = *iptr++;
                      while(count--)
                          *optr++ = pixel;
               }
           }
   }
If BPC is 2, there is one short (2 bytes) per pixel. In this case the RLE data should be read
into an array of shorts. To expand data, the low order seven bits of the first short: bits[6..0]
are used to form a count. If bit[7] of the first short is 1, then the count is used to specify
how many shorts to copy from the RLE data buffer to the destination. Otherwise, if bit[7] of
the first short is 0, then the count is used to specify how many times to repeat the value of
the following short, in the destination. This process proceeds until a count of 0 is found.
This should decompress exactly XSIZE pixels. Note that the byte order of short data in the
input file should be used, as described above.
Implementation notes
Implementation of both RLE and VERBATIM format for images with BPC of 1 is required
since the great majority of SGI images are in this format. Support for images with a 2 BPC
is encouraged.
If the ZSIZE of an image is 1, it is assumed to represent B/W values. If the ZSIZE is 3, it is
assumed to represent RGB data, and if ZSIZE is 4, it is assumed to contain RGB data with
alpha.
The origin for all SGI images is the lower left hand corner. The first scanline (row 0) is
always the bottom row of the image.
Naming Conventions
On SGI systems, SGI image files end with the extension .bw if they are B/W images, they
end in .rgb if they contain RGB image data, and end in .rgba if they are RGB images with
alpha channel.
Sometimes the .sgi extension is used as well.
An example
This program will write out a valid B/W SGI image file:
  #include "stdio.h"


  #define IXSIZE         (23)
  #define IYSIZE         (15)


  putbyte(outf,val)
  FILE *outf;
  unsigned char val;
  {
         unsigned char buf[1];


         buf[0] = val;
         fwrite(buf,1,1,outf);
  }


  putshort(outf,val)
  FILE *outf;
  unsigned short val;
{
      unsigned char buf[2];


      buf[0] = (val>>8);
      buf[1] = (val>>0);
      fwrite(buf,2,1,outf);
}


static int putlong(outf,val)
FILE *outf;
unsigned long val;
{
      unsigned char buf[4];


      buf[0] = (val>>24);
      buf[1] = (val>>16);
      buf[2] = (val>>8);
      buf[3] = (val>>0);
      return fwrite(buf,4,1,outf);
}


main()
{
      FILE *of;
      char iname[80];
      unsigned char outbuf[IXSIZE];
      int i, x, y;


      of = fopen("example.rgb","w");
      if(!of) {
          fprintf(stderr,"sgiimage: can't open output file\n");
          exit(1);
      }
      putshort(of,474);        /* MAGIC           */
     putbyte(of,0);         /* STORAGE is VERBATIM */
     putbyte(of,1);         /* BPC is 1      */
     putshort(of,2);        /* DIMENSION is 2           */
     putshort(of,IXSIZE);     /* XSIZE             */
     putshort(of,IYSIZE);     /* YSIZE             */
     putshort(of,1);        /* ZSIZE         */
     putlong(of,0);         /* PIXMIN is 0        */
     putlong(of,255);        /* PIXMAX is 255           */
     for(i=0; i<4; i++)     /* DUMMY 4 bytes            */
         putbyte(of,0);
     strcpy(iname,"No Name");
     fwrite(iname,80,1,of); /* IMAGENAME                     */
     putlong(of,0);         /* COLORMAP is 0            */
     for(i=0; i<404; i++)    /* DUMMY 404 bytes              */
         putbyte(of,0);


     for(y=0; y<IYSIZE; y++) {
         for(x=0; x<IXSIZE; x++)
    outbuf[x] = (255*x)/(IXSIZE-1);
         fwrite(outbuf,IXSIZE,1,of);
     }
     fclose(of);
}
Archive-name: medical-image-faq/part3
Posting-Frequency: monthly
Last-modified: Wed Aug 4 11:42:08 EDT 1999
Version: 3.25




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.1.2 Siemens - Features common to multiple families




          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 .


          3.1.2.1 Siemens Vax/VMS


                  Under construction.




          3.1.2.2 Siemens Sparc SunOS


                  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.
3.1.2.2.1 Starting up


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.


3.1.2.2.2 Getting a console


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).


3.1.2.2.3 Native images


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.
3.1.2.2.4 Exporting images


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".


3.1.2.2.5 Physical connection


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.


3.1.2.2.6 Archive devices


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.


3.1.2.2.7 Becoming root


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).


3.1.2.2.8 Reset


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.




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, 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.


         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):


        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.1.5 GE CTI


             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.




- DICOM encapsulation
                                - Incorrect byte order of Item
                                and Sequence Delimiter tags
- JPEG Encoding


                                - Incorrect Huffman Table
                                selector (11 not 00)
                                - Incorrect predictor
                                calculation (inverted)
                                - Incorrect predictor
                                initialization at end of row




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;
         }


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.
Image File Formats


Introduction
Image files come in many formats. Each file represents a picture
that has been converted to a numerical form so that it can be
stored and redisplayed by a computer. Each format has its own
characteristics, advantages and disadvantages, and many are
particular to certain hardware or operating systems. Generally
speaking, what differentiates one format from another is:
whether the file contains a bitmap or vector representation of the
image.
how many different colours (bits-per-pixel) the file is capable of storing.
the type of compression (if any) that is applied to the image.


The format of a file can usually be identified by its three letter file extension. Click below for
more information on the different image file formats.
Table summarizing most of the more common file formats.
Details of the most common cross-platform formats.
Detail of the most common system dependent formats.




Bits-Per-Pixel
A computer monitor is made up of a large number of dots, each of which can be set to
display a certain colour. These dots are called pixels, which is a contraction of "picture
element". The standard PC screen resolution has 480 lines down the screen, each of
which contains 640 pixels, thus it contains 307,200 pixels. When a screen image is saved
to a file, the colour of each pixel needs to be stored numerically, since computers talk only
in bits where each bit can represent a 0 or a 1. The more bits allocated for the
representation of each pixel, the greater the number of colours available. For example,
one bit can store two values (0 or 1), two bits can represent four different values, four bits
can store 16 different values etc.
Bits-per-pixel is a measure of the number of bits that a file uses to represent the colour of
a single pixel. Since one bit can store two values (0 or 1), an image stored as one bit-per-
pixel can have a maximum of two different colours (black or white). If it has 4 bits-per-pixel,
16 different colours can be shown. 256 colours requires eight bits-per-pixel. Consequently,
the more colours an image displays, the larger the file required to store it. For example, a
200x200 2 colour image will take 5Kb., a 256 colour version of the same image will take
40Kb.
     Top       Home




Compression
As image quality and size increases, so the size of the subsequent file must increase.
Large images with millions of colours (i.e. photographic quality) can create huge files. For
example, a full screen (640x480) photo will use around one megabyte of file storage if
saved using conventional methods. If there is unlimited disk space available, this is not a
problem. But where space is limited, or where transfer time is at a premium (imagine
downloading a one magabyte file across the Internet!), one obvious way to save storage
space is to compress the file.
Some formats use some kind of compression technique to try and overcome the large
storage size image files require. These techniques can be categorised into lossless or
lossy formats. Lossless formats use routines to compress all of the original data and are
thus able to recreate the image without loss of data, hence the name. Lossy formats
discard some data during compression. This data is usually beyond the boundaries of
human visual perception so there is no discernable difference between the original and
recreated image in most cases, but lossy formats produce much smaller files than lossless
ones.




     Top        Home




Vector Images
In a vector file, the image is deconstructed into a set of geometric shapes, and the
resulting set of geometrical formula representations are stored in the file. This format is
generally used for line drawings produced by technical drawing software such as CAD.
The major advantage of vector graphics is they can be scaled up or down in size or
resolution simply by changing the numbers in the stored formulas.
Below is a vector and a bitmap representation of the same graphic file. Note that when
each is scaled up 200%, the vector graphic retains its quality, while the bitmap image has
developed "jaggy" edges.
Vector image                       Bitmap image




Vector image scaled x 4            Bitmap image scaled x 4




     Top       Home




Bitmap Images
A modern computer monitor is capable of displaying millions of different colours. Bitmap
image files come in a range of resolutions that represent a trade-off between file size and
reproduction quality. Some of the more common resolutions are listed below, together with
a sample of each. Note that the visual quality of the samples may be limited by the
resolution of your computer monitor.



                Monochrome, in which the colour of each pixel
                is stored in a single bit, 0 for black or 1 for
                white. While resolution is poor, the file size is
                very small. A standard full screen (640x480
      pixels) monochrome image can be stored in a
      file of around 40 kilobytes.


      Grayscale image files provide 256 shades of
      gray, and so need 8 bits, or one byte, to store
      each pixel. A full screen grayscale image needs
      about 300 kilobytes of file storage space.




      4-bit files can hold up to 16 different colours, so
      each pixel takes 4 bits of file space. They
      provide rudimentary colour quality.




      8-bit files can store up to 256 colours, and so
      also uses one byte per pixel. This gives
      acceptable colour quality, but cannot compare
      to a photgraphic image.




      24-bit bitmap files do provide photographic
      quality. Each pixel is represented by three
      bytes, each of which allows for 256 shades of
      red, green or blue that constitutes the actual
      colour, thus giving 256x256x256 or 16,777,216
      different colours. A full screen image would
      require a file of almost 1 Megabyte.




Top   Home
Standard Cross-Platform Formats
GIF Graphics Interchange Format was devised by UNISYS and Compuserve for
transmission of image files over telephone lines via modems. Due to the transfer rate
limitations via modem, small file size was the design goal, so complex algorithms were
developed to achieve high compression rates, and resolutions were limited to 256 colours
(i.e. 8 bits-per-pixel), which is not a problem since most PC monitors are set to 256 colour
resolutions anyway. GIF files are the dominant non-photographic quality image file format
for the Internet, and are especially good for cartoons and line drawings.
JPG JPEG is a standard created by the Joint Photographics Experts Group, and uses
compression techniques specifically designed for photographic images. It works best on
photos, naturalistic artwork, complex computer generated art and similar images, but not
so well with line drawings, cartoons or lettering, which may suffer some blurring due to the
compression techniques used. JPEG is a lossy format which lets the user set the level of
quality (and therefore the level of lossiness) required. This control gives JPEG a big
advantage since it allows how the image is to be used, and how big the file will be to be
taken into account for each particular application. Compression rates of up to 20:1 will not
reveal any discernable loss of quality, and up to 50:1 without much visible loss. JPEG is
the format of choice for photgraphic image files on the Internet. The Mona Lisa at the top
of this page is in JPEG format.
Visual comparison of JPEG and GIF formats for various graphic types.


EPS Postscript was originally designed as a typesetting language for text and vector
graphics, although it also contains the facility to store bitmapped graphics. Popular
drawing packages such as Illustrator and Freehand use postscript for graphic
representation. This format can cause files to be quite large compared to other formats.
TIF The Tagged Image File Format can store many different types of images by describing
the image type within the file header. It was developed by Aldus and later supported by
Microsoft. The popularity of the TIFF format is on the decline due to the advantages the
JPEG format provides.




     Top       Home




Standard System Dependent Formats
BMP Windows had developed for it a system standard graphics file format - BMP. Images
can be manipulated in the Paintbrush application, and the image files can deal with
monochrome to 24-bit images.
PIC Macintosh first used the paint format, which was the first commerically successful
image format created, and was used with the original MacPaint program. The paint format
was only used to store monochrome bitmap images, although the format has since been
extended. Apple also created one of the first popular vector drawing programs, MacDraw,
which uses the pict format.
XBM X-windows primary graphic format is xbm. It, like the Microsoft BMP format, can
store images from monochrome to 24-bit colour. The most popular graphic editor for this
format is called xv.




     Top      Home




Written by Michael Adams Q3901042X 16 September 1997
Common Image Format File Extensions
There are literally hundreds of image file formats in existence. Those below are the most
common, but click here for a more comprehensive listing.



       Description     Compressed Bits-per-         Comments
                                  pixel

BMP    Standard     No                 1, 4, 8 or
       MS-Windows                      24
       bitmap image
       format.

CGM Computer           No                           Vector oriented,
    Graphics                                        but can also
    Metafile. US                                    store bitmapped
    Govt.                                           graphics. Files
    standard.                                       have fixed
                                                    length of 512
                                                    bytes.

DIB    Device          No              1, 4, 8 or   Interchangeable
       Independent                     24           with BMP files.
       Bitmap.

EPS    Encapsulated No                 1, 4, 8 or   Postscript is a
       Postscript                      24           typesetting
                                                    language that
                                                    contains
                                                    routines to
                                                    allow storage of
                                                    bitmapped and
                                                    vector graphics.

IMG    Format          No              1, 4 or 8    Original
       generated by                                 specification
       GEM Paint                                    handled
       program                                      monochrome or
                                                    grayscale only.

GIF    Graphics        Yes             1, 4 or 8    Preferred non-
       Interchange     Lossless                     photographic
       Format.                                      image format
                                                    for internet
                                                    browsers.
JAS   Similar to    Yes     Colour -
      JPEG file     Lossy   24
      format, but           Grayscale
      also supports         -8
      grayscale
      images
      separately.

JPG   JPEG file    Yes      24           Compression
      format,      Lossy                 algorithm
      developed by                       discards data
      the Joint                          beyond human
      Photographic                       vision
      Experts                            capabilities.
      Group.                             Format allows
                                         user to trade-off
                                         between image
                                         quality and file
                                         size. No visible
                                         loss at
                                         compression
                                         rates of 20:1.
                                         Preferred
                                         photographic
                                         quality image
                                         format for the
                                         Internet.

MAC   Macintosh     No      1            Monochrome
      Paint                              only. Size of
                                         images must be
                                         576x720 pixels.

MSP   Microsoft     No      1            Monochrome
      Paint                              only. Used by
                                         the Paint
                                         program
                                         supplied with
                                         MS Windows
                                         version 2.0.
                                         Can be
                                         converted to
                                         BMP format.

PCX   Default       No      1, 4, 8 or   Developed by
      standard PC           24           Zsoft for PC
      format late                        Paintbrush
      1980's.                            program. This
                                               format now
                                               supported by
                                               more
                                               applications
                                               than any other

PIC   Used by     No             Pictor - 1
      PICTOR, PC-                or 8
      Paint and                  PC Paint
      GRASP                      -4
      programs.

RAS   Standard        No         1, 8, 24 or
      raster format              32
      for Sun
      Microsystem
      computers.

RAW Flexible          No         8             Simply a stream
    bitmapped                                  of bytes (ie. the
    file format                                file contains no
                                               other format
                                               information),
                                               where each
                                               byte represents
                                               the colour of
                                               one pixel.

RLE   Run-Length-     Yes        4 or 8        RLE files are
      Encoded.        Lossless                 used as
      Simply a DIB                             opening screen
      image with                               images for MS
      compression                              Windows.
      applied.

TGA   Developed       Yes/No     8, 16, 24     Industry
      by Truevision   Lossless   or 32         standard for
      for the Targa                            high end paint
      program.                                 & ray tracing
                                               packages. May
                                               be compressed
                                               using RLE. The
                                               32 bit files
                                               contain 8 bits of
                                               special effects
                                               information.
TIF        Tagged              Yes/No              1, 4, 8 or     Used to transfer
           Image               6 different         24             documents
           Format              compression                        between
                               algorithms                         different
                                                                  platforms.
                                                                  Designed to
                                                                  become
                                                                  industry
                                                                  standard, but
                                                                  many variations
                                                                  developed to
                                                                  cover all
                                                                  possibilities, so
                                                                  now too
                                                                  confusing to be
                                                                  widely used.

WPG WordPerfect                No                  1, 4 or 8      Can contain
    Graphic File                                                  bitmaps, line art
                                                                  and vector
                                                                  graphics.
                                                                  Vector
                                                                  elements are
                                                                  discarded when
                                                                  this format is
                                                                  read by
                                                                  applications
                                                                  other than
                                                                  WordPerfect.




          Back




Written by Michael Adams Q3901042X 16 September 1997

COLOR MODELS

          To explain the properties or behavior of color within some particular context. No single color model has
           yet been devised that can encompass all aspects of color. Color image processing (enhancement, coding,
           printing or analysis) dictates the use of color space transformations.

          Display devices (RGB) and printing devices (CMY) use distinct color image representations, each of
           which do not provide an intuitive information representation for monochrome image processing
           algorithms. For example, histogram equalization or filtering each of the red, green and blue primaries,
           will cause chromatic distortions of the image. For a fixed image compression level, higher image quality
       is perceived after reconstruction when luminance and chrominance components are compressed
       separately. Since the human eye is much more sensitive to variations in luminance (or shades of gray in
       the image) than chrominance, one would adjust the compression technique for each separately.


Primary Colors: Colors chosen to be mixed together in various proportions in order to
produce a wide range of other colors. Usually, though not always, used in sets of three.
- Subtractive primaries: cyan (W-R), magenta (W-G),
yellow (W-B).
- Additive primaries: red (B-C), green (B-M), blue (B-Y).

      Brightness or lightness: attribute of a color that locates it along a gray continuum from light to dark, or
       white to black. Light, medium, dark, very light, very dark.

"Lightness" applied to reflecting surfaces
"Brightness" applied to self-luminous surfaces.
      Hue: attribute of a color known by terms such as red, yellow, green and blue. Dominant spectral
       wavelength. Color of the light.

      Saturation: the departure of a color from an achromatic color (gray) of the same lightness, e.g., pink and
       red have nearly same hue, but red has high saturation while pink has low. Black, gray and white have
       zero saturation. Color purity. Grayish, vivid, ...


IDEAL COLOR SPACE
      Perceptually uniform: equal steps in the color space should be equally discriminable, e.g., a step of 10
       units should be 10 times more salient than a single step.

      Easy to navigate: intuitive to move around in selecting or mixing a particular color.

      Closely related to the physiology of the visual system.

      Accurate color specification: e.g., in generating hard-copy from a display.

      Easily implementable.


MUNSELL COLOR SPACE
Commonly used in the design industry for specifying a color according to its appearance,
where a color is assigned a number by matching it against a standard series of paint chips
(the Munsell Book of Color).
      Hue: Purple, Blue, Green, Yellow, Red, PB, BG, GY, YR and RP with a number on a ten-point scale to
       define it more specifically.

      Value: lightness of a color, a number between 0 (very dark) and 10 (very light).

      Chroma: saturation, a number between 0 (gray) and 14 (highly saturated).

Easy to use, simple to navigate. The samples must be viewed under controlled
illumination. Matching a reflective color from the Book to a self-luminous color from the
display is not easy.
CIE (Commission Internationale de l'Eclairage)
      International standard by International Commission on illumination for primary colors in 1931. Define
       all real colors as the weighted sum of the three primaries (imaginary). Eliminate the practical difficulty
       of making routine color matches and observer variability in spectral sensitivity.

      Allow use of a physical measurement of the spectral energy distribution in a color to calculate the
       amount of three primaries defined to obtain a visual match with the color.

x = X/(X+Y+Z), y = Y/(X+Y+Z), z = Z/(X+Y+Z)
X,Y,Z: tristimulus values,
x,y,z: chromaticity coordinates
Any two of these three quantities are sufficient to define a color, most commonly, x and y.
      The most widespread method of color specification. There are a number of colorimeters to measure the
       CIE chromaticity coordinates of display phosphors. Also, most display manufacturers supply the CIE
       coordinates on request. Even the CIE coordinates of all Munsell samples are specified and available.


      CIE Chromaticity Diagram: tongue-shaped curve, provide a means for quantitatively defining purity
       and dominant wavelength.

Illuminant C: a white-light source approximating "average daylight."
Purity: relative distance of the color from the white-light point C along the straight line
joining C to the curve.
Dominant frequency: wavelength on the spectral curve intersecting the line joining C and
that color point.
Complementary colors: two endpoints of a line passing through point C.
      CIE 1976 Chromaticity Diagram: reshaped CIE 1931 Chromaticity Diagram via

u' = 4x/ (-2x + 12y + 3)
v' = 9y/ (-2x + 12y + 3)

RGB COLOR SPACE
      We perceive color by three visual pigments in the cones of the retina, peak sensitivity at wavelength of
       about 630 nm (red), 530 nm (green) and 450 nm (blue). Displaying color output on a video monitor.

      Additive model: intensities of the primary colors are added to produce other colors. Shades of gray
       represented along the main diagonal of the cube from the origin (black) to the white vertex.

      Very easy to specify display colors. Equal geometric steps in this space are not equally discriminable.

      Difficult to navigate since users are more used to thinking of mixing color pigments. Luminance and
       saturation are not simple to visualize.

      Different monitors use different sets of primaries. Color space coordinates are not colorimetrically
       specified.


CMY COLOR MODEL
      Cyan, magenta, yellow: primary colors, useful for describing color out to hardcopy devices where a
       color picture is produced by coating a paper with color pigments.

      Subtractive model: e.g., the cyan-colored ink should absorb (subtract) all red component so that the
       reflected light has no red component.

      Four ink dots: cyan, magenta, yellow, black. A black dot is included because the CMY ink combination
       typically produce dark gray instead of black.


HSV COLOR SPACE
      Hue, saturation and value derived from the RGB cube. Deformed version of the RGB cube by viewing
       the cube along the diagonal from the white vertex to the origin ---> hexagonal outline (HSV) or
       triangular outline (HSI).

      Hue: an angle axis, ranging from 0 (red), 60 (yellow), 120 (green), 180 (cyan), 240 (blue), 300 (magenta)
       complementary colors are 180 apart.

      Saturation: the ratio of the purity of a selected hue to its maximum purity at S=1. Radial distance from
       the perpendicular axis. S = 0 ---> gray scale.

      Adding black decreases V while S is held constant. When white is to be added to the hue selected, S is
       decreased while keeping V constant.

      More intuitive in mixing colors than the RGB or CMY color space. Separate control for saturation and
       value. Easy to navigate.

      Equal geometric steps are not equally discriminable. Color space coordinates are not portable across
       different monitors.

      Can be easily converted into RGB or vice versa in software, hardware or ASICs.

      Most useful for color image processing


HLS COLOR SPACE
Hue, lightness and saturation. Very similar to HSV. One of the many variations of HSV.
NCS COLOR SPACE
      Natural Color System recommended by the Swedish Standards Institution.

      Three coordinates are hue, blackness and chromaticness. Based on the apparent uniqueness of the color
       pairs red and green, blue and yellow, and black and white. These six colors represent the reference
       points of the system. Each color pair forms a continuum where each continuum is divided into 100 parts.

      Easy to use and colors are evenly spaced. Little difference between the NCS space and Munsell color
       space. Stimulated a great deal of research on color.

Linguistic Color Space: Color Naming System (CNS) can be used when accurate verbal
color specification is required.

REPRESENTING GRAYSCALE IMAGES
      Gray scale image can be represented as a matrix indexed by row and column. Origin usually at top-left.

      More efficient representation is a vector of size NxM where rows are concatenated, indexed by a single
       number (row*width + column).
        Data Types: Bit, Byte (signed or unsigned), Short (2 bytes, signed or unsigned), Integer (4 bytes, signed
         or unsigned), Long (8 bytes, signed or unsigned), Float, or Double.

        A sample C data structure for image storage:

struct Image {
int width;
int height;
int num_bits;
void *data;
};

REPRESENTING COLOR AND OTHER IMAGES
        Three values per pixel (e.g., Red, Green, Blue): Can be represented as

              o   3-dimensional array of size MxNx3

              o   2-dimensional matrix of size 3M x N or 3N x M

              o   1-dimensional vector of size 3MN

              o   Three vectors or matrices of the same size (bands)

        One value per pixel with a colormap

              o   Colormap is a look-up table (hash table) which maps the value of a pixel to a given color

        Other types of images:

              o   Multiband image - multiple values per pixel, e.g., LANDSAT image or MRI image.

              o   Symbolic image - values on the image represent objects in the image, e.g., 1 = background, 2 =
                  tree, 3=flower, etc.


STORING IMAGES ON DISK
        Raw (No) Format -- Binary or ASCII

        Other formats: Information Necessary: width, height, number of bands, bits per pixel, & byte ordering.
         Many different file formats, open and proprietary, GIF, JPEG, TIFF, PCX, BMP, PGM, DICOM.

        PBMPlus - A public domain software package.

              o   Defines formats for bit, byte, and color images

              o   PBM - Portable Bitmap (0 or 1)

P1 <- identifier (magic number)
3 5 <- width and height of image
0 0 0 1 1 1 0 0 0 1 1 0 0 1 0 <- ASCII Data
OR
P4 with binary data
        PGM - Portable Graymap
P2 <- identifier
3 5 <- width and height
15 <- maximum gray value
3 4 8 10 15 12 8 9 1 0 3 4 5 6 7 <- ASCII
OR
P5 with binary data
      PPM - Portable pixmap (color images)

P3 <- identifier
2 2 <- width and height
15 <- maximum color component
0 0 10 15 0 15 0 0 0 5 6 6 <- RGB
OR
P6 with binary data

TIFF (TAGGED IMAGE FILE FORMAT)
Supported by Aldus, Microsoft, HP, and many desktop publishing programs. Designed
from the ground up to alleviate the problems associated with fixed file formats. TIFF
incorporates enough flexibility, extendability and portability to lower the need or
justification for proprietary image file formats. Every major scanner manufacturer and
every desktop publishing programs TIFF. Also, translator programs that translate other
image-file formats to TIFF format are available.
TIFF files are made up of unique data structures: an 8-byte Image File Header (IFH), a
variable-length Image File Directory (IFD), a Directory Entry (DE), and a set of values.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:2/14/2012
language:English
pages:103