Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Medical Image Format FAQ, Part 3/8

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Business Photos and Profiles ]
Archive-name: medical-image-faq/part3
Posting-Frequency: monthly
Last-modified: Sun Dec 21 09:16:34 EST 2003
Version: 4.26

See reader questions & answers on this topic! - Help others by sharing your knowledge
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.


User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
dclunie@dclunie.com (David A. Clunie)





Last Update March 27 2014 @ 02:11 PM