Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!canyon.sr.hp.com!col.hp.com!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!news.mathworks.com!gatech!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
From: dclunie@flash.us.com (David A. Clunie)
Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
Subject: Medical Image Format FAQ, Part 1/8
Followup-To: alt.image.medical
Date: 30 Jan 1996 16:03:40 -0500
Organization: Mollard Consultants
Lines: 677
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 28 Feb 1996 00:00:00 GMT
Message-ID: <4em13c$3ae@flash.ksapax>
Reply-To: dclunie@flash.us.com (David A. Clunie)
NNTP-Posting-Host: flash.ksapax
Summary: This posting contains answers to the most Frequently Asked
	 Question on alt.image.medical - how do I convert from image
	 format X from vendor Y to something I can use ? In addition
	 it contains information about various standard formats.
Xref: senator-bedfellow.mit.edu alt.image.medical:4245 comp.protocols.dicom:1429 sci.data.formats:1399 sci.med.informatics:5238 sci.med.radiology:4949 alt.answers:15295 comp.answers:16736 sci.answers:3818 news.answers:63381

Archive-name: medical-image-faq/part1
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

This message is automatically posted once a month to help readers looking
for information about medical image formats. If you don't want to see this
posting every month, please add the subject line to your kill file.

Contents:

    part1    - contains index, general information & standard formats
    part2    - contains standard formats (continued)
    part3    - contains information about proprietary CT formats
    part4    - contains information about proprietary MR formats
    part5    - contains information about proprietary other formats
    part6    - contains information about hosts & compression
    part7    - contains information sources
    part8    - contains information sources (continued)

Tools that describe and convert many of the formats described in this document
are available in the dicom3tools package from

    "ftp://ftp.rahul.net/pub/dclunie/".

A Mosaic browsable version of this FAQ is available at:

    "http://www.rahul.net/dclunie/medical-image-faq/html/".

Html, postscript and text forms of the FAQ are available at:

    "ftp://ftp.rahul.net/pub/dclunie/medical-image-faq/".

Many FAQs, including this Listing, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.  The name under
which a FAQ is archived appears in the Archive-name line at the top of
the article.

There's a mail server on that machine. You send a e-mail message to
mail-server@rtfm.mit.edu containing the keyword "help" (without quotes!)
in the message body. To fetch this particular FAQ send a message with the
following body:

    send usenet/news.answers/medical-image-faq/part1
    ...
    send usenet/news.answers/medical-image-faq/part8

Please direct comments or questions and especially contributions to

    "dclunie@flash.us.com"

or reply to this article. All unknown formats and test images gratefully
accepted, but please don't email them, rather contact me and we can
arrange to exchange documents or disks or tapes by snail mail.

Changes this issue

    Add "impending" Shimadzu MR format.
    Add UCDMC publically accessible DICOM server site.
    Add Loral DICOM CS site.
    Add DICOM IS integration entry for Philips Inturis,Mitra.Intech HiCube.
    Add DICOM to web gateways from Medweb,Passport.
    Add Mitra web site.
    Clean up Picker Conformance Statement links.
    Add UCDMC Conformance Statement link.
    Update DesAcc phone number.
    Add FITS Browser web page.

Changes last issue

    New FDA fax number.
    Add PET Mail list.
    Add DICOM to BMP software site.
    Add Medweb html site.
    Add Designed Access html site.
    Add Interformat html site.
    Add Applicare DICOM conformance site.
    More medical image sites.
    Add DICOM Santel web site.
    Add DICOM Chile web site.
    Add Medx web site and DICOM dump utility.
    Add Merge web site and DICOM resource directory.
    Add Philips entries.

The next part is table of contents.


Subject: Contents

1.  Introduction

    1.1 Objective
    1.2 Types of Formats
    1.3 In Desperation - Quick & Dirty Tricks

2.  Standard Formats

    2.1 ACR/NEMA 1.0 and 2.0
    2.2 ACR/NEMA DICOM 3.0
    2.3 Papyrus
    2.4 Interfile V3.3
    2.5 Qsh
    2.6 DEFF

3.  Proprietary Formats

    3.1 Proprietary Formats - General Information

	3.1.1 SPI (Standard Product Interconnect)

    3.2 CT - Proprietary Formats

	3.2.1 General Electric CT

	      3.2.1.1 GE CT 9800

		      3.2.1.1.1 GE CT 9800 Image data
		      3.2.1.1.2 GE CT 9800 Tape format
		      3.2.1.1.3 GE CT 9800 Raw data MR

	      3.2.1.2 GE CT Advantage - Genesis

		      3.2.1.2.1 GE CT Advantage Image data
		      3.2.1.2.2 GE CT Advantage Archive format
		      3.2.1.2.3 GE CT Advantage Raw data

	      3.2.1.3 GE CT Pace
	      3.2.1.4 GE CT Sytec

	3.2.2 Siemens CT

	      3.2.2.1 Siemens Somatom DR
	      3.2.2.2 Siemens Somatom Plus
	      3.2.2.3 Siemens Somatom AR

	3.2.3 Philips CT
	3.2.4 Picker CT
	3.2.5 Toshiba CT
	3.2.6 Hitachi CT
	3.2.7 Shimadzu CT
	3.2.8 Elscint CT

    3.3 MR - Proprietary Formats

	3.3.1 General Electric MR

	      3.3.1.1 GE MR Signa 3.x,4.x

		      3.3.1.1.1 GE MR Signa 3.x,4.x Image data
		      3.3.1.1.2 GE MR Signa 3.x,4.x Tape format
		      3.3.1.1.3 GE MR Signa 3.x,4.x Raw data

	      3.3.1.2 GE MR Signa 5.x - Genesis

		      3.3.1.2.1 GE MR Signa 5.x Image data
		      3.3.1.2.2 GE MR Signa 5.x Archive format
		      3.3.1.2.3 GE MR Signa 5.x Raw data

	      3.3.1.3 GE MR Max
	      3.3.1.4 GE MR Vectra

	3.3.2 Siemens MR

	      3.3.2.1 Siemens Magnetom GBS/GBS II

		      3.3.2.1.1 Siemens Magnetom GBS/GBS II Native Format
		      3.3.2.1.2 Siemens Magnetom GBS/GBS II SPI Format

	      3.3.2.2 Siemens Magnetom SP

		      3.3.2.2.1 Siemens Magnetom SP Native Format
		      3.3.2.2.2 Siemens Magnetom SP SPI Format

	      3.3.2.3 Siemens Magnetom Impact

		      3.3.2.3.1 Siemens Magnetom Impact Native Format
		      3.3.2.3.2 Siemens Magnetom Impact SPI Format

	      3.3.2.4 Siemens Magnetom Vision

		      3.3.2.4.1 Siemens Magnetom Vision Native Format
		      3.3.2.4.2 Siemens Magnetom Vision SPI Format

	3.3.3 Philips MR

	      3.3.3.1 Philips Gyroscan S5
	      3.3.3.2 Philips Gyroscan ACS
	      3.3.3.3 Philips Gyroscan T5
	      3.3.3.4 Philips Gyroscan NT5 & NT15

	3.3.4 Picker MR
	3.3.5 Toshiba MR
	3.3.6 Hitachi MR
	3.3.7 Shimadzu MR
	3.3.8 Elscint MR

    3.4 Proprietary Workstations

	3.4.1 ISG Workstations

	      3.4.1.1 Gyroview

    3.5 Other Proprietary Formats

	3.5.1 Analyze From Mayo

4.  Host Machines

    4.1 Data General

	4.1.1 Data General Data

	      4.1.1.1 Data General Integers
	      4.1.1.2 Data General Floating Point

	4.1.2 Data General Operating System

	      4.1.2.1 Data General RDOS
	      4.1.2.2 Data General AOS/VS

	4.1.3 Data General Network

    4.2 Vax

	4.2.1 Vax Data

	      4.2.1.1 Vax Integers
	      4.2.1.2 Vax Floating Point
	      4.2.1.3 Vax Strings

	4.2.2 Vax Operating System

	      4.2.2.1 Vax VMS
	      4.2.2.2 ULTRIX
	      4.2.2.3 OSF

    4.3 Sun - Sun3 68000 and Sun4 Sparc

	4.3.1 Sun Data

	      4.3.1.1 Sun Integers
	      4.3.1.2 Sun Floating Point
	      4.3.1.3 Sun Strings

	4.3.2 Sun Operating System

5.  Compression Schemes

    5.1 Reversible Compression
    5.2 Irreversible Compression

	5.2.1 Perimeter Encoding

6.  Getting Connected

    6.1 Tapes
    6.2 Ethernet
    6.3 Serial Ports

7.  Sources of Information

    7.1 Vendor Contacts
    7.2 Relevant FAQ's
    7.3 Source Code
    7.4 Commercial Offerings
    7.5 FTP/WWW sites
    7.6 Mailservers
    7.7 References
    7.8 Organizations and Societies
    7.9 Usenet Newsgroups

8.  Acknowledgements

The next part is part1 - general information & standard formats.


1.  Introduction

    1.1 Objective

	The goal of this FAQ is to facilitate access to medical images stored
	on digital imaging modalities such as CT and MR scanners, and their
	accompanying descriptive information. The document is designed
	particularly for those who do not have access to the necessary
	proprietary tools or descriptions, particularly in those moments when
	inspiration strikes and one just can't wait for the local sales person
	to track down the necessary authority and go through the cycle of
	correspondence necessary to get a non-disclosure agreement in place, by
	which time interest in the project has usually faded, and another great
	research opportunity has passed! It may also be helpful for those keen
	to experiment with home-grown PACS-like systems using their existing
	equipment, and also for those who still have equipment that is still
	useful but so old even the host computer vendor doesn't support it any
	more!

	There is of course no substitute for the genuine tools or descriptions
	from the equipment vendors themselves, and pointers to helpful
	individuals in various organizations, as well as names and catalog
	numbers of various useful documents, are included here where known.

	In addition there are several small companies that specialize in such
	connectivity problems that have a good reputation and are well known.
	Contact information is provided for them, though I personally have no
	experience with their products and am not endorsing them.

	Finally, great care has been taken not to include any information that
	has been released under non-disclosure agreements. What is included
	here is the result of either information freely released by vendors,
	handy hints from others working in the field, or in many cases close
	scrutiny of hex dumps and experimentation with scanner parameters and
	study of the effects on the image files. The intent is to spread
	hard-earned knowledge gained over many years amongst those new to the
	field or a particular piece of equipment, not to threaten anyone's
	proprietary interests, or to substitute for the technical support
	available from vendors that ranges from free to extortionate, and
	excellent to abysmal, depending on who your are dealing with and where
	in the world you are located!

	 Please use this information in the spirit in which is intended, and
	 where possible contribute whatever you know in order to expand the
	 information to cover more vendors and equipment.

    1.2 Types of Formats

	Later sections will deal with the problems of getting the image files
	from the modality to the workstation, but for the moment assume the
	files are there and need to be deciphered.

	Four types of information are generally present in these files:

	   - image data, which may be unmodified or compressed,
	   - patient identification and demographics,
	   - technique information about the exam, series, and slice/image.

	Extracting the image information alone is usually straightforward and
	is described in 1.3. Dealing with the descriptive information, for
	example to make use of the data for dissemination in a PACS
	environment, or to extract geometry details in order to combine images
	into 3D datasets, is more difficult and requires deeper understanding
	of how the files are constructed.

	There are three basis families of formats that are in popular use:

	   - fixed format, where layout is identical in each file,
	   - block format, where the header contains pointers to information,
	   - tag based format, where each item contains its own length.

	The block format is one of the most popular, though in most cases, the
	early part of the header contains only a limited number of pointers to
	large blocks, the blocks are almost always in the same place and a
	constant length, for standard rather than reformatted images at least,
	and if one doesn't know the specifics of the layout one can get by
	assumming a fixed format. I presume this reflects the intent of the
	designers to handle future expansion and revision of the format.

	 The example par excellence of the tag based format is the ACR/NEMA
	 style of data stream, which, though never intended as a file format
	 per se has proven useful as model. See for example the sections
	 dealing with the ACR/NEMA standards as well as DICOM (whose creators
	 are about to vote on a media interchange format after all this time)
	 and Papyrus. ACR/NEMA style tags are described in more detail
	 elsewhere, but each is self-contained and self-describing (at least if
	 you have the appropriate data dictionary) and contains its own length,
	 so if you can't interpret it you can skip it! Very convenient. Most
	 file formats based on this scheme are just concatenated series of
	 tags, and apart from having to guess the byte order, which is not
	 specified (unlike TIFF which is a similar deal for those in the "real"
	 imaging world), and sometimes skip a fixed length but short header,
	 are dead easy to handle.

	 To identify such a file just do a "strings <file | grep 'ACR-NEMA'" -
	 if it is such a file, just look through the start of the hex dump
	 until you start to see the characteristic sequentially ordered pairs
	 of 16 bit words that identify ACR/NEMA attributes, decide the byte
	 order, et voila, you can pipe it into any general ACR/NEMA dumping
	 program to see what it contains. If you see even group tags, they will
	 be described in the standard. If you see odd group tags then they are
	 vendor specific and you will have to ask the vendor or correlate them
	 with identification information printed on the film until you figure
	 out the ones that are important to you.

    1.3 In Desperation - Quick & Dirty Tricks

	Because radiologists, radiographers, technologists, physicists and
	imaging programmers are dedicated long suffering creatures who work
	long hours under adverse conditions for little reward, the vendors in
	their generosity have seen fit to make life a little easier, by almost
	universally putting the image data at the end of the file. Rarely you
	will see files that are padded out to fixed record size boundaries (eg.
	Vax VMS 512 byte records), and sometimes overlay plane data may be
	stored after the image data. Furthermore there is almost always an
	option at archive time to allow for storage in an uncompressed and
	totally unadulterated form. Even in ACR/NEMA the tag for image pixel
	data is numerically the highest and hence the last to appear in the
	sequence which is guaranteed to be sorted. They could have screwed us
	up totally by gratuitously adding variable length blocks of other stuff
	at the end, but the only time I have encountered this was on a Siemens
	Impact with the ACR/NEMA based SPI format padd

	In other words, if an image is 256 by 256, uncompressed, and 12-16 bits
	deep (and hence usually, though not always, stored as two bytes per
	pixel), then we all know that the file is going to contain
	256*256*2=131072 bytes of pixel data at the end of the file. If the
	file is say 145408 bytes long, as all GE Signa 3X/4X files are for
	example, then you need to skip 14336 bytes of header before you get to
	the data. Presume row by row starting with top left hand corner raster
	order, try both alternatives for byte order, deal with the 16 to 8 bit
	windowing problem, and very soon you have your image on the screen of
	your workstation.

	 This technique is so useful, even NIH Image for the Macintosh (an
	 excellent must-have free program BTW.) provides a raw import tool to
	 do this, and describes it in the manual using the 14336 byte offset!
	 This tool is something that is sadly lacking in most commercial image
	 handling programs for non-medical applications, which can't import
	 images with more than 8 bits per channel.

	 Of course you have to live without the identification, demographic and
	 technique information (other than what can be derived from the file
	 name in some cases), but for many research and presentation purposes
	 this is quite adequate.

	 Occasionally one runs into clever files where four 12 bit words are
	 packed into three 16 bit words and one goes crazy trying to figure out
	 the logic of how they are packed. The back of the old ACR/NEMA
	 standard describes somewhere one way in which this is done. One should
	 still be able to calculate the length easily enough.

	 I haven't yet encountered a format that did nasty things like have
	 strips of rows seperated by padding ... I guess we are lucky that most
	 images are nice powers of two or even multiples thereof
	 (256,320,512).

	 Of course the GE CT 9800 uses perimeter encoding even when DPCM
	 compression is not selected, so this technique won't work.

2.  Standard Formats

    2.1 ACR/NEMA 1.0 and 2.0

	ACR/NEMA Standards Publication No. 300-1985      <- ACR/NEMA 1.0
	ACR/NEMA Standards Publication No. 300-1988      <- ACR/NEMA 2.0
	ACR/NEMA Standards Publication PS2-1989          <- data compression

	The American College of Radiologists (ACR) and the National Electrical
	Manufacturers Association (NEMA) recognized some time ago the need for
	standards to facilitate multi-vendor connectivity to promote the
	development of PACS and what is now referred to as Wide Area
	Networking. The first such standard was version 1.0 which was released
	in 1985 as ACR/NEMA Standards Publication No. 300-1985, subsequently
	revised several times, then revised again and released as version 2.0
	in 1988, described in ACR/NEMA Standards Publication No. 300-1988.
	There it remained until a radically revised and reorganized approach,
	preserving backward compatibility, was released during 1992-1993 as
	ACR/NEMA Standards Publication PS3, also referred to as DICOM 3.

	In the interim, to facilitate the transfer of compressed images,
	another standard described in ACR/NEMA Standards Publication PS2-1989,
	was released which described various means fo extending standard
	300-1985 to handle compression utilizing a broad range of reversible
	and irreversible schemes. Though this part of the standard was never
	apparently implemented by anyone, and has been quietly bypassed by
	those working on DICOM 3 compression, it makes very interesting reading
	and is a nice summary of applicable techniques.

	What does one need to know about ACR/NEMA 1.0 and 2.0 ? The standards
	define a mechanism along the lines of the layered ISO-OSI (Open Systems
	Interconnect) model, with physical, transport/network, session, and
	presentation and application layers. Unless one actually wants to
	physically connect to a device that supports the unique 50 pin
	point-to-point electrical interface, then one really only needs to be
	aware of how ACR/NEMA implements the presentation and application
	layers, which are described in terms of a "message format". This
	message format is important to many people, not because anyone
	seriously wants to connect devices in the limited fashion envisaged by
	these early standards, but because many proprietary formats and other
	de facto standards have adopted the ACR/NEMA message format and its
	corresponding data dictionary and extension mechanisms.

	 The message format is described in sections 4, 5 and 10 of ACR/NEMA SP
	 300-1988 which are summarized briefly here. Section 6 describes
	 command structure which is not really relevant other than that
	 commands are also structured in the same way as data and consume part
	 of the data dictionary. You will not encounter command tags in data
	 streams ("messages") encapsulated in file formats though.

	 A message consists of a series of "data elements" each of which
	 contains a piece of information. Each element is described by an
	 "element name" consisting of a pair of 16 bit unsigned integers
	 ("group number", "data element number"). The data stream is ordered by
	 ascending group number, and within each group by ascending data
	 element number. Each element may occur only once in a message. Even
	 numbered groups describe elements defined by the standard. Odd
	 numbered groups are available for use by vendors or users, but must
	 conform to the same structure as standard elements. Following the
	 (group number, data element number) pair is a length field that is a
	 32 bit unsigned even integer that describes the number of bytes from
	 the end of the length field to the beginning of the next data element.
	 The last part of a data element is its value, which is defined by the
	 data dictionary to be an ascii (numeric AN or text AT) or binary value
	 (BI 16 bit or BD 32 bit), which may be single values or multiple in
	 whi

	For example:

	    0008 0010  000C 0000  4341 2D52 454E 414D
				  3120 302E

	is data element "Recognition Code" because that is what the dictionary
	defines group 0008 element 0010 to be. The dictionary says it is of
	type AT (ascii text), has a value multiplicity of single and only
	enumerated values are allowed, in this case the ascii string "ACR-NEMA
	2.0". It is of length 0000000C hex or 12 bytes long.

	The electrical interface is a 16 bit one, and hence even though 32
	binary values are defined to be transmitted least significant word
	first (though the order for the 32 bit length is not actually
	specified), there is no mention in the standard as to how to
	encapsulate the message in an 8 bit world, hence different users and
	vendors have chosen little or big endian schemes. The new DICOM
	standard assumes a default little endian representation which seems to
	be the most appropriate considering the old definition for 32 bit
	words, which specified that the least significant 16 bit word be
	transmitted first.

	Hence there are three likely possible byte orders that a vendor
	interpreting the ACR/NEMA standard in a byte oriented world may have
	used:

	    - little endian 16 and 32 bit words, as in DICOM 3,
	    - big endian 16 and 32 bit words, as in DICOM 3,
	    - big endian 16 bit words, but the least significant half of
	      a 32 bit word is sent first (as per ACR/NEMA 2.0).

	The choice seems to be made usually on the basis of the native byte
	order of integers on the host processor. Most of the formats I have
	encountered are one of the first two, but I did encounter one from
	Philips that used the last scheme and it drove me crazy for a while,
	until I appreciated the subtlety of it ! I call it "Big Bad Endian"
	format in my implementation that recognizes it, but that may be a value
	judgement on my part :)

	Notice particularly how this design allows one to parse the message
	even if the data dictionary is not complete. Consider an element that
	has an unrecognized element name. One cannot interpret the content of
	the element and so has to ignore it. One doesn't even know whether it
	contains binary or ascii information (this is what DICOM later refers
	to as "implicit representation". despite this, the length value allows
	one to skip to the next element and proceed.

	Over the years there has been much discussion amongst those who favour
	such implicit dictionary driven schemes, and those who prefer explicit
	representations, including explicit description of the element type
	(binary or ascii, etc.) and even the element description itself! Some
	would prefer the message to contain something like
	"RecognitionCode='ACR-NEMA 2.0';" for example. The nuclear medicine
	groups have adopted a de facto standard called Interfile that makes use
	of ACR/NEMA data elements, but uses such a descriptive representation.
	Their argument is that the data stream is much more readable which is
	true enough, and more readily extensible.

	The groups are organized as follows:

	    0000                    Command
	    0008                    Identifying
	    0010                    Patient
	    0018                    Acquisition
	    0020                    Relationship
	    0028                    Image Presentation
	    4000                    Text
	    6000-601E (even)        Overlay
	    7FE0                    Pixel Data

	Some of the more interesting elements are:

	    (nnnn,0000) BD S Group Length           # of bytes in group nnnn
	    (nnnn,4000) AT M Comments

	    (0008,0010) AT S Recognition Code       # ACR-NEMA 1.0 or 2.0
	    (0008,0020) AT S Study Date             # yyyy.mm.dd
	    (0008,0021) AT S Series Date            # yyyy.mm.dd
	    (0008,0022) AT S Acquisition Date       # yyyy.mm.dd
	    (0008,0023) AT S Image Date             # yyyy.mm.dd
	    (0008,0030) AT S Study Time             # hh.mm.ss.frac
	    (0008,0031) AT S Series Time            # hh.mm.ss.frac
	    (0008,0032) AT S Acquisition Time       # hh.mm.ss.frac
	    (0008,0033) AT S Image Time             # hh.mm.ss.frac
	    (0008,0060) AT S Modality               # CT,NM,MR,DS,DR,US,OT

	    (0010,0010) AT S Patient Name
	    (0010,0020) AT S Patient ID
	    (0010,0030) AT S Patient Birthdate      # yyyy.mm.dd
	    (0010,0040) AT S Patient Sex            # M, F, O for other
	    (0010,1010) AT S Patient Age            # xxxD or W or M or Y

	    (0018,0010) AT M Contrast/Bolus Agent   # or NONE
	    (0018,0030) AT M Radionuclide
	    (0018,0050) AN S Slice Thickness        # mm
	    (0018,0060) AN M KVP
	    (0018,0080) AN S Repetition Time        # ms
	    (0018,0081) AN S Echo Time              # ms
	    (0018,0082) AN S Inversion Time         # ms
	    (0018,1120) AN S Gantry Tilt            # degrees

	    (0020,1040) AT S Position Reference     # eg. iliac crest
	    (0020,1040) AN S Slice Location         # in mm (signed)

	    (0028,0010) BI S Rows
	    (0028,0011) BI S Columns
	    (0028,0030) AN M Pixel Size             # row\col in mm
	    (0028,0100) BI S Bits Allocated         # eg. 12 bit for CT
	    (0028,0101) BI S Bits Stored            # eg. 16 bit
	    (0028,0102) BI S High Bit               # eg. 11
	    (0028,0102) BI S Pixel Representation   # 1 signed, 0 unsigned

	    (7FE0,0010) BI M Pixel Data             # as described by grp 0028

	The way in which the pixel data is stored can vary tremendously, though
	thankfully most users and vendors use the simple unimaginative scheme
	that is shown above, ie. 1 12 bit pixel stored in the low order part of
	a 16 bit word with no attempt at packing more compactly. Following are
	some examples shown in
Appendix E of the standard. Note that when one adds the little/big endian
question the permutations mount!

	Bits Allocated = 16
	Bits Stored    = 12
	High Bit       = 11

			  |<------------------ pixel ----------------->|
	    ______________ ______________ ______________ ______________
	   |XXXXXXXXXXXXXX|              |              |              |
	   |______________|______________|______________|______________|
	    15          12 11           8 7            4 3            0

	---------------------------

	Bits Allocated = 16
	Bits Stored    = 12
	High Bit       = 15

	   |<------------------ pixel ----------------->|
	    ______________ ______________ ______________ ______________
	   |              |              |              |XXXXXXXXXXXXXX|
	   |______________|______________|______________|______________|
	    15          12 11           8 7            4 3            0

	---------------------------

	Bits Allocated = 12
	Bits Stored    = 12
	High Bit       = 11

	   ------ 2 ----->|<------------------ pixel 1 --------------->|
	    ______________ ______________ ______________ ______________
	   |              |              |              |              |
	   |______________|______________|______________|______________|
	    15          12 11           8 7            4 3            0

	   -------------- 3 ------------>|<------------ 2 --------------
	    ______________ ______________ ______________ ______________
	   |              |              |              |              |
	   |______________|______________|______________|______________|
	    15          12 11           8 7            4 3            0

	   |<------------------ pixel 4 --------------->|<----- 3 ------
	    ______________ ______________ ______________ ______________
	   |              |              |              |              |
	   |______________|______________|______________|______________|
	    15          12 11           8 7            4 3            0

	---------------------------

	And so on ... refer to the standard itself for more detail.

The next part is part2 - standard formats (continued).

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!munnari.OZ.AU!news.mel.connect.com.au!yarrina.connect.com.au!news.mira.net.au!Germany.EU.net!EU.net!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
From: dclunie@flash.us.com (David A. Clunie)
Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
Subject: Medical Image Format FAQ, Part 2/8
Followup-To: alt.image.medical
Date: 30 Jan 1996 16:03:48 -0500
Organization: Mollard Consultants
Lines: 439
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 28 Feb 1996 00:00:00 GMT
Message-ID: <4em13k$3b0@flash.ksapax>
Reply-To: dclunie@flash.us.com (David A. Clunie)
NNTP-Posting-Host: flash.ksapax
Summary: This posting contains answers to the most Frequently Asked
	 Question on alt.image.medical - how do I convert from image
	 format X from vendor Y to something I can use ? In addition
	 it contains information about various standard formats.
Xref: senator-bedfellow.mit.edu alt.image.medical:4242 comp.protocols.dicom:1425 sci.data.formats:1397 sci.med.informatics:5236 sci.med.radiology:4947 alt.answers:15293 comp.answers:16734 sci.answers:3816 news.answers:63379

Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

    2.2 ACR/NEMA DICOM 3.0

	ACR/NEMA Standards Publications

	    No. PS 3.1-1992   <- DICOM 3 - Introduction & Overview
	    No. PS 3.8-1992   <- DICOM 3 - Network Communication Support

	    No. PS 3.2-1993   <- DICOM 3 - Conformance
	    No. PS 3.3-1993   <- DICOM 3 - Information Object Definitions
	    No. PS 3.4-1993   <- DICOM 3 - Service Class Specifications
	    No. PS 3.5-1993   <- DICOM 3 - Data Structures & Encoding
	    No. PS 3.6-1993   <- DICOM 3 - Data Dictionary
	    No. PS 3.7-1993   <- DICOM 3 - Message Exchange
	    No. PS 3.9-1993   <- DICOM 3 - Point-to-Point Communication

	    No. PS 3.10-????  <- DICOM 3 - Media Storage & File Format
	    No. PS 3.11-????  <- DICOM 3 - Media Storage Application Profiles
	    No. PS 3.12-????  <- DICOM 3 - Media Formats & Physical Media

	DICOM (Digital Imaging and Communications in Medicine) standards are of
	course the hot topic at every radiological trade show. Unlike previous
	attempts at developing a standard, this one seems to have the potential
	to actually achieve its objective, which in a nutshell, is to allow
	vendors to produce a piece of equipment or software that has a high
	probability of communicating with devices from other vendors.

	Where DICOM differs substantially from other attempts, is in defining
	so called Service-Object Pairs. For instance if a vendor's MR DICOM
	conformance statement says that it supports an MR Storage Class as a
	Service Class Provider, and another vendor's workstation says that it
	supports an MR Storage Class as a Service Class User, and both can
	connect via TCP/IP over Ethernet, then the two devices will almost
	certainly be able to talk to each other once they are setup with each
	others network addresses and so on.

	The keys to the success of DICOM are the use of standard network
	facilities for interconnection (TCP/IP and ISO-OSI), a mechanism of
	association establishment that allows for negotiation of how messages
	are to be transferred, and an object-oriented specification of
	Information Objects (ie. data sets) and Service Classes.

	Of course all this makes for a huge and difficult to read standard, but
	once the basic concepts are grasped, the standard itself just provides
	a detailed reference. From the users' and equipment purchasers' points
	of view the important thing is to be able to read and match up the
	Conformance Statements from each vendor to see if two pieces of
	equipment will talk.

	Just being able to communicate and transfer information is of course
	not sufficient - these are only tools to help construct a total system
	with useful functionality. Because a workstation can pull an image off
	an MRI scanner doesn't mean it knows when to do it, when the image has
	become available, to which patient it belongs, and where it is
	subsequently archived, not to mention notifying the Radiology or
	Hospital Information System (RIS/HIS) when such a task has been
	performed. In other words DICOM Conformance does not guarantee
	functionality, it only facilitates connectivity.

	In otherwords, don't get too carried away with espousing the virtues of
	DICOM, demanding it from vendors, and expecting it to be the panacea to
	create a useful multi-vendor environment.

	Fred Prior (prior@xray.hmc.psu.edu) has come up with the concept of a
	User Conformance Statement to be generated by purchasers and to be
	satisfied by vendors. The idea is that one describes what one expects
	and hence gives the vendor a chance to realistically satisfy the buyer!
	Of course each such statement must be tailored to the user's needs, and
	simply stapling a copy of Fred's statement to a Request For Proposals
	is not going to achieve the desired objective. Caveat empor.

	To get more information about DICOM:

	   - Purchase the standards from NEMA.

	   - Ftp the final versions of the drafts in electronic form
	      one of the sites described below.

	   - Follow the Usenet group comp.protocols.dicom.

	   - Get a copy of "Understanding DICOM 3.0" $12.50 from Kodak.

	   - Insist that your existing and potential vendors supply you
	      with DICOM conformance statements before you upgrade or
	      purchase, and don't buy until you know what they mean. Don't
	      take no for an answer!!!!

	What is all this doing in an FAQ about medical image formats you ask ?
	Well first of all, in many ways DICOM 3.0 will solve future
	connectivity problems, if not provide functional solutions to common
	problems. Hence actually getting the images from point A to B is going
	to be easier if everyone conforms. Furthermore, for those of us with
	old equipment, interfacing it to new DICOM conforming equipment is
	going to be a problem. In otherwords old network solutions and file
	formats are going to have to be transformed if they are going to
	communicate unidirectionally or bidirectionally with DICOM 3.0 nodes.
	One is still faced with the same old questions of how does one move the
	data and how does one interpret it.

	 The specifics of the DICOM message format are very similar to the
	 previous versions of ACR/NEMA on which it is based. The data
	 dictionary is greatly extended, and certain data elements have been
	 "retired" but can be ignored gracefully if present. The message itself
	 can now be transmitted as a byte stream over networks, rather than
	 using a point-to-point paradigm excusively (though the old
	 point-to-point interface is available). This message can be encoded in
	 various different Transfer Syntaxes for transmission. When two devices
	 ("Application Entities" or AE) begin to establish an "Association",
	 they negotiate an appropriate transfer syntax. They may choose an
	 Explicit Big-Endian Transfer Syntax in which integers are encoded as
	 big-endian and where each data element includes a specific field that
	 says "I am an unsigned 16 bit integer" or "I am an ascii
	 floating-point number", or alternatively they can fall back on the
	 default transfer syntax which every AE must support, the Implicit
	 Little-Endian Tra

	This is all very well if you are using DICOM as it was originally
	envisaged - talking over a network, negotiating an association, and
	determining what Transfer Syntax to use. What if one wants to store a
	DICOM message in a file though ? Who is to say which transfer syntax
	one will use to encode it offline ? One approach, used for example by
	the Central Test Node software produced by Mallinkrodt and used in the
	RSNA Inforad demonstrations, is just to store it in the default
	little-endian implicit syntax and be done with it. This is obviously
	not good enough if one is going to be mailing tapes, floppies and
	optical disks between sites and vendors though, and hence the DICOM
	group decided to define a "Media Storage & File Format" part of the
	standard, the new Parts 10, 11 and 12 which have recently passed their
	ballot and shoul;d be available in final form from NEMA soon.

	Amongst other things, Part 10 defines a generic DICOM file format that
	contains a brief header, the "DICOM File Meta Information Header" which
	contains a 128 byte preamble (that the user can fill with anything), a
	4 byte DICOM prefix "DICM", then a short DICOM format message that
	contains newly defined elements of group 0002 in a specified Transfer
	Syntax, which uniquely identify the data set as well as specifying the
	Transfer Syntax for the rest of the file. The rest of the message must
	specify a single SOP instance. The length of the brief message in the
	Meta Header is specified in the first data element as usual, the group
	length.

Originally the draft of Part 10 specified the default Implicit Value
Representation Little Endian Transfer Syntax as the DICOM File Meta Information
Header Transfer Syntax, which is in keeping with the concept that it is the
default for all other parts of the standard. The final standard has changed
this to Explicit Value Representation Little Endian Transfer Syntax. This seems
like an extremely irritating change to me but I guess purists have prevailed.

	So what choices of Transfer Syntax does one have and why all the fuss ?
	Well the biggest distinction is between implicit and explicit value
	representation which allows for multiple possible representations for a
	single element, in theory at least, and perhaps allows one to make more
	of an unknown data element than one otherwise could perhaps. Some
	purists (and Interfile people) would argue that the element should be
	identified descriptively, and there is nothing to stop someone from
	defining their own private Transfer Syntax that does just that (what a
	heretical thought, wash my mouth out with soap). With regard to the
	little vs. big endian debate I can't see what the fuss is about, as it
	can't really be a serious performance issue.

	Perhaps more importantly in the long run, the Transfer Syntax mechanism
	provides a means for encapsulating compressed data streams, without
	having to deal with the vagaries and mechanics of compression in the
	standard itself. For example, if DICOM version 3.0, in addition to the
	"normal" Transfer Syntaxes, a series are defined to correspond to each
	of the Joint Photographic Experts Group (JPEG) processes. Each one of
	these Transfer Syntaxes encodes data elements in the normal way, except
	for the image pixel data, which is defined to be encoded as a valid and
	self-contained JPEG byte stream. Both reversible and irreversible
	processes of various types are provided for, without having to mess
	with the intricacies of encoding the various tables and parameters that
	JPEG processes require. Presumably a display application that supports
	such a Transfer Syntax will just chop out the byte stream, pass it to
	the relevant JPEG decode, and get an uncompressed image back. More
	importantly, an archive server can s

	Now one may not like the JPEG standard, but one cannot argue with the
	fact that the scheme is workable, and a readily available means of
	reversible compression has been incorporated painlessly. How effective
	a compression scheme this is remains to be determined, and whether or
	not the irreversible modes gain wide acceptance will be dictated by the
	usual medico-legal paranoia that prevails in the United States, but the
	option is there for those who want to take it up. There is of course no
	reason why private compression schemes cannot be readily incorporated
	using this "encapsulation" mechanism, and to preserve bandwidth this
	will undoubtedly occur. This will not compromise compatibility though,
	as one can always fall back to a default, uncompressed Transfer Syntax.
	The DICOM Working Group IV on compression will undoubtedly bring out
	new possibilities. Currently there is a lot of interest in RLE (Run
	Length Encoded) compression, particularly from the Ultrasound group.

	In order to identify all these various syntaxes, information objects,
	and so on, DICOM has adopted the ISO concept of the Unique Identifier
	(UID) which is a text string of numbers and periods with a unique root
	for each organization that is registered with ISO and various
	organizations that in turn register others in a hierarchical fashion.
	For example 1.2.840.10008.1.2 is defined as the Implicit VR Little
	Endian Transfer Syntax. The 1 identifies ISO, the 2 is the ISO member
	body branch, the 840 is the specific member body country code, in this
	case ANSI, and the 10008 is registered by ANSI to NEMA for DICOM.
	UID's are also used to uniqely identify non-DICOM specific things, such
	as information objects. These are constructed from a prefix registered
	to the supplier or vendor or site, and a unique suffix that may be
	generated from say a date and time stamp (which is not to be parsed).
	For example an instance of a CT information object might have a UID of
	1.2.840.123456.002.999999.940623.170717 where

	The other important new concept that DICOM introduced was the concept
	of Information Objects. In the previous ACR/NEMA standard, though
	modalities were identified by a specific data element, and though there
	were rules about which data elements were mandatory, conditional or
	optional in ceratin settings, the concept was relatively loosely
	defined. Presumably in order to provide a mechanism to allow
	conformance to be specified and hence ensure interoperability, various
	Information Objects are defined that are composed of sets of Modules,
	each module containing a specific set of data elements that are present
	or absent according to specific rules. For example, a CT Image
	Information Object contains amongst others, a Patient module, a General
	Equipment module, a CT Image module, and an Image Pixel module. An MR
	Image Information module would contain all of these except the CT Image
	module which would be replaced by an MR Image module. Clearly one needs
	descriptive information about a CT image that is di

	Hence, as described earlier, one can define pairs of Information
	Objects and Services that operate on such objects (Storage,
	Query/Retrieve, etc.) and one gets SOP classes and instances. All very
	object oriented and initially confusing perhaps, but it provides a
	mechanism for specifying conformance. From the point of view of an
	interpreters of a DICOM compatible data stream this means that for a
	certain instance of an Information Object, certain information is
	guaranteed to be in there, which is nice. As a creator of such a data
	stream, one must ensure that one follows all the rules to make sure
	that all the data elements from all the necessary modules are present.
	Having done so one then just throws all the data elements together,
	sorts them into ascending order by group and element order, and pumps
	them out. It is a shame that the data stream itself doesn't reflect the
	underlying order in the Information Objects, but I guess they had to
	maintain backward compatibility, hence this little bit of ugli

	At this point I am tempted to include more details of various different
	modules, data elements and transfer syntaxes, as well as the TCP/IP
	mechanism for connection. However all this information is in the
	standard itself, drafts of which are readily available electronically
	from ftp sites, and in the interests of brevity I will not succumb to
	temptation at this time.

    2.3 Papyrus

	Papyrus is an image file format based on ACR/NEMA version 2.0. It was
	developed by the Digital Imaging Unit of the University Hospital of
	Geneva for the European project on telemedicine (TELEMED project of the
	RACE program), under the leadership of Dr. Osman Ratib
	(osman@cih.hcuge.ch). The University Hospital of Geneva uses Papyrus
	for their hospital-wide PACS.

	The medical file format component of Papyrus version 2 extended the
	ACR/NEMA format, particularly in order to reference multiple images by
	placing folder information referencing ACR-NEMA data sets in a shadow
	(private) group. Contributing to the development of DICOM 3, the team
	are updating their format to be compatible with the offline file format
	provisions of the draft Part 10 of DICOM 3 in Papyrus version 3.

	The specifications, toolkit and image manipulation software that is
	Papyrus aware, Osiris, is available for the Mac, Windows, and
	Unix/X11/Motif by ftp from ftp://expasy.hcuge.ch/pub/Osiris.

See also Papyrus and Osiris ftp site.

	Further information is available in printed form. Contact
	yves@cih.hcuge.ch (Yves Ligier).

    2.4 Interfile V3.3

	Interfile is a "file format for the exchange of nuclear medicine image
	data" created I gather to satisfy the needs of the European COST B2
	Project for the transfer of images of quality control phantoms, and
	incorporates the AAPM (American Association of Physicists in Medicine)
	Report No. 10, and has been subsequently used for clinical work.

	It specifies a file format composed of ascii "key-value" pairs and a
	data dictionary of keys. The binary image data may be contained in the
	same file as the "administrative information", or in a separate file
	pointed to by a "name of data file" key. Image data may be binary
	integers, IEEE floating point values, or ascii and the byte order is
	specified by a key "imagedata byte order". The order of keys is defined
	by the Interfile syntax which is more sophisticated than a simple list
	of keys, allowing for groups, conditionals and loops to dictate the
	order of key-value pairs.

	Conformance to the Interfile standard is informally described in terms
	of which types of image data types, pixel types, multiple windows,
	special Interfile features including curves, and restriction to various
	maximum recommended limits.

	Interfile is specifically NOT a communications protocol and strictly
	deals with offline files. There are efforts to extend Interfile to
	include modalities other than nuclear medicine, as well as to keep
	ACR/NEMA and Interfile data dictionaries in some kind of harmony.

	A sample list of Interfile 3.3 key-value pairs is shown here to give
	you some idea of the flavor of the format. The example is culled from
	part of a Static study in the Interfile standard document and is not
	complete:

		!INTERFILE :=
		!imaging modality :=nucmed
		!version of keys :=3.3
		data description :=static
		patient name :=joe doe
		!patient ID  :=12345
		patient dob :=1968:08:21
		patient sex :=M
		!study ID :=test
		exam type :=test
		data compression :=none
		!image number :=1
		!matrix size [1] :=64
		!matrix size [2] :=64
		!number format :=signed integer
		!number of bytes per pixel :=2
		!image duration (sec) :=100
		image start time :=10:20: 0
		total counts :=8512
		!END OF INTERFILE :=

	One can see how easy such a format would be to extend, as well as how
	it is readable and almost useable without reference to any standard
	document or data dictionary.

	Undoubtedly ACR/NEMA DICOM 3.0 to Interfile translators will soon
	proliferate in view of the fact that many Nuclear Medicine vendors
	supply Interfile translators at present.

	To get hold of the Interfile 3.3 standard, see the Interfile sources,
	Interfile information contacts and Interfile mailing list described
	later in this document.

    2.5 Qsh

	Qsh is a family of programs for manipulating images, and it defines an
	intermediate file format. The following information was derived with
	the help of one of the authors maguire@it.kth.se(Chip Maguire):

	Uses an ASCII key-value-pair (KVP sic.) system, based on the AAPM
	Report #10 proposal. This format influenced both Interfile and ACR-NEMA
	(DICOM). The file format is referred to as "IMAGE" in some of their
	articles (see references). The header and the image data  are stored as
	two separate files with extensions *.qhd and *.qim respectively.

	Qsh is available by anonymous ftp from the Qsh ftp site. This is a
	seriously large tar file, including as it does some sample images, and
	lots of source code, as well as some post-script documents. Subtrees
	are available as separate tar files.

	QSH's Motif-based menu system (qmenu) will work with OpenWindows 3.0 if
	SUN patch number 100444-54 for SUNOS 4.1.3 rev. A is applied. The patch
	is available from ftp://sunsolve1.sun.com (192.9.9.24).

	The image access subroutines take the same parameters as the older
	/usr/image package from UNC, however, the actual subroutines support
	the qsh KVP and image data files.

	The frame buffer access subroutines take the same parameters as the
	Univ. of Utah software (of the mid.  1970s). The design is based on the
	use of a virtual frame buffer which is then implemented via a library
	for a specific frame buffer.  There exists a version of the the display
	routines for X11.

	Conversions are not supported any longer, instead there is a commercial
	product called InterFormat. InterFormat includes a qsh to Interfile
	conversion, along with DICOM to qsh, and many others. Information is
	available from reddy@nucmed.med.nyu.edu (David Reddy) (see InterFormat
	in the Sources section).

	[Editorial note: this seems a bit of a shame to me - the old
	distribution included lots of handy bits of information, particularly
	on driving tape drives. I am advised however that the conversion stuff
	was pulled out because people wanted it supported, the authors were
	worried they were disclosing things perhaps they ought not to be, and
	NYU had switched to using InterFormat themselves anyway. DAC.]

	The authors of the qsh package are:

	       - maguire@it.kth.se (Gerald Q. (Chip) Maguire)
	       - noz@nucmed.NYU.EDU (Marilyn E Noz)

	The following references are helpful in understanding the philosophy
	behind the file format, and are included in postscript form in the qsh
	ftp distribution:

	@Article[noz88b,
		Key=<noz88b>,
		Author=<M. E. Noz and G. Q. Maguire Jr.>,
		Title=<QSH: A Minimal but Highly Portable Image Display
		       and Processing Toolkit>,
		Journal=<Computer Methods and Programs in Biomedicine>,
		volume=<27>,
		month=<November>,
		Year=<1988>,
		Pages=<229-240>
	]
	@Article[maguire89e,
		Key=<maguire>,
		Author=<G.Q. Maguire Jr., and M.E. Noz>,
		Title=<Image Formats: Five Years after the AAPM Standard Format
		for Digital Image Interchange>,
		Journal=<Medical Physics>,
		volume=<16>,
		month=<September/October>,
		year=<1989>,
		pages=<818-823>,
		comment=<Also as CUCS-369-88>
	]

    2.6 DEFF

	DEFF (Data Exchange File Format) is a portable image file format
	designed for the exchange, printing and archiving of ultrasound images.
	It is written by John Bono of ATL from whom the specification may be
	obtained. The latest version is 2.5, March 25, 1994. It is based on the
	TIFF 5.0 specification, though a more recent version, TIFF 6.0 is
	available.

	Theorectically, any TIFF reader should be able to read the standard
	tags from a DEFF image, so long as only 8 bit images are in use, as in
	the Camera Ready class of DEFF images for instance. Additional support
	is provided for multi-frame images, and 9 to 16 bit images by extending
	the TIFF format. Because Aldus only allocates a small number of unique
	registered tags to each vendor, ATL have defined their own extensive
	set of additional tags, which are referenced by using one of the
	registered tags ExtendedTagsOffset. Hence these additional tags will
	not be visible to a conventional TIFF reader.

The next part is part3 -  proprietary CT formats.

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!news.mathworks.com!gatech!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
From: dclunie@flash.us.com (David A. Clunie)
Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
Subject: Medical Image Format FAQ, Part 3/8
Followup-To: alt.image.medical
Date: 30 Jan 1996 16:03:56 -0500
Organization: Mollard Consultants
Lines: 1121
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 28 Feb 1996 00:00:00 GMT
Message-ID: <4em13s$3bl@flash.ksapax>
Reply-To: dclunie@flash.us.com (David A. Clunie)
NNTP-Posting-Host: flash.ksapax
Summary: This posting contains answers to the most Frequently Asked
	 Question on alt.image.medical - how do I convert from image
	 format X from vendor Y to something I can use ? In addition
	 it contains information about various standard formats.
Xref: senator-bedfellow.mit.edu alt.image.medical:4246 comp.protocols.dicom:1430 sci.data.formats:1400 sci.med.informatics:5239 sci.med.radiology:4950 alt.answers:15296 comp.answers:16737 sci.answers:3819 news.answers:63382

Archive-name: medical-image-faq/part3
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

3.  Proprietary Formats

    3.1 Proprietary Formats - General Information

	3.1.1 SPI (Standard Product Interconnect)

	      Used for files exported from:

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

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

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

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

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

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

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

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

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

Element     Owner                 Name                  VR VM

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

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

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

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

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

    3.2 CT - Proprietary Formats

	3.2.1 General Electric CT

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

	      3.2.1.1 GE CT 9800

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

				- 46-021855 CT 9800 Image Data Format

		      3.2.1.1.1 GE CT 9800 Image data

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

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

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

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

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

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

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

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

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

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

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

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

	block 0 - global header

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

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

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

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

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

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

	block 0 - global header

	       word 17-23    - 7A2  - file name

	block 1 - exam header

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

	block 2 - image header

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

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

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

	seeeeeppdd.tt

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

	eg. B038500165.YP

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

		      3.2.1.1.2 GE CT 9800 Tape format

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

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

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

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

#!/bin/sh

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

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

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

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

		      3.2.1.1.2 GE CT 9800 Raw data MR

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

	      3.2.1.2 GE CT Advantage - Genesis

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

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

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

		      3.2.1.2.1 GE CT Advantage Image data

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

	image header - for CT (1020 bytes long):

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

		      3.2.1.2.2 GE CT Advantage Archive format

				See the GE MR Signa 5.x Archive format.

		      3.2.1.2.3 GE CT Advantage Raw data

				Again, unknown. Please fill in this space.

	      3.2.1.3 GE CT Pace

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

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

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

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

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

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

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

	bits 22-0       significand (f)

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

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

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

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

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

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

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

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

	Offset  Type    Length  Meaning       Units or values

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

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

	Offset  Type    Length  Meaning       Units or values

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

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

    For CT only:

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

    For MR only:

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

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

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

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

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

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

	      3.2.1.4 GE CT Sytec

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

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

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

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

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

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

      Offset   Type         Meaning               Units or values

	7      string       ModelNumber

	126    string       Organization
	204    string       PatientID
	217    string       PatientName

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

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

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

	1280   float32      SeriesStartLocation
	1288   float32      SeriesEndLocation

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

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

	2716   float32      XReconOffset            # mm
	2720   float32      YReconOffset            # mm

	3256   int32        BitsPerSample
	3264   int32        DefaultWindowWidth
	3268   int32        DefaultWindowLevel

	3.2.2 Siemens CT

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

	      3.2.1.1 Siemens Somatom DR

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

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

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

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

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

	- binary data block:

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

		72  - short       - matrix size (256 or 512)

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

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

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

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

		    0123456789012345678901234567890123456789

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

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

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

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

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

	      3.2.2.2 Siemens Somatom Plus

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

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

SPI private tags:

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

(0011,0010)                                      <SPI RELEASE 1>

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

Overlay descriptions (overlays already in image pixel data):

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

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

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

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

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

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

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

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

	      3.2.2.3 Siemens Somatom AR

	      Unknown.

	3.2.3 Philips CT - Big black hole

	3.2.4 Picker CT

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

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

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

The next part is part4 -  proprietary MR formats.

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!news.sol.net!uniserve!news.mindlink.net!van-bc!news.rmii.com!newsjunkie.ans.net!howland.reston.ans.net!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
From: dclunie@flash.us.com (David A. Clunie)
Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
Subject: Medical Image Format FAQ, Part 4/8
Followup-To: alt.image.medical
Date: 30 Jan 1996 16:04:05 -0500
Organization: Mollard Consultants
Lines: 1264
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 28 Feb 1996 00:00:00 GMT
Message-ID: <4em145$3c6@flash.ksapax>
Reply-To: dclunie@flash.us.com (David A. Clunie)
NNTP-Posting-Host: flash.ksapax
Summary: This posting contains answers to the most Frequently Asked
	 Question on alt.image.medical - how do I convert from image
	 format X from vendor Y to something I can use ? In addition
	 it contains information about various standard formats.
Xref: senator-bedfellow.mit.edu alt.image.medical:4251 comp.protocols.dicom:1434 sci.data.formats:1403 sci.med.informatics:5250 sci.med.radiology:4960 alt.answers:15302 comp.answers:16749 sci.answers:3823 news.answers:63416

Archive-name: medical-image-faq/part4
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

    3.3 MR - Proprietary Formats

	3.3.1 General Electric MR

	      3.3.1.1 GE MR Signa 3.x,4.x

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

				- 46-021858 MR Signa 4.x Mag Tape/Image Fmt

		      3.3.1.1.1 GE MR Signa 3.x,4.x Image data

				- "fixed format" header
				- image data is not compressed
				- image data fixed offset 14336 bytes
				- Data General host
				- AOS/VS

				The image files are of fixed layout, described
				here as a series of 256 by 16 bit word blocks
				(512 bytes), blocks numbered from 0. The
				headers start at the following block offsets:

	block 0  - length 4 blocks   - System configuration
	block 4  - length 2 blocks   - Site customization
	block 6  - length 2 blocks   - Study header
	block 8  - length 2 blocks   - Series header
	block 10 - length 2 blocks   - Image header
	block 12 - length 4 blocks   - Raw database header
	block 16 - length 10 blocks  - Pulse sequence description
	block 26 - length 2 blocks   - Pixel map (? not ever used)
	block 28 - length 256 blocks - Image data

				As decribed earlier, the header is a fixed
				length of 14336 bytes, after which the
				uncompressed image data starts.

				Some of the more important fields are described
				here. Integers are 16 bit words (big-endian),
				ascii strings are Fortran style specifications
				with length in bytes, and reals are 4 bytes
				long (see Host machines - Data General), word
				offsets are numbered from 0:

	block 6 - study header

	       word  32      - 5A   - Study number
	       word  39      - 9A   - Date of study (dd-mmm-yy)
	       word  47      - 8A   - Time of study (hh:mm:ss)
	       word  54      - 32A  - Patient name
	       word  70      - 12A  - Patient ID
	       word  78      - 3A   - Age xxx years or xxD or W or M or Y
	       word  80      - 1A   - Sex

	block 8 - series header

	       word  31      - 3A   - Series number
	       word  52      - 120A - Series description
	       word  112     - Int  - Series type (0=normal,1=screensave,
					  2=composite)
	       word  113     - Int  - Coil type (0=head,1=body,2=surface)
	       word  114     - 16A  - Coil name
	       word  122     - Int  - Contrast description
	       word  138     - Int  - Plane type (0=axial,1=sagittal,2=coronal,
					  3=oblique,4=screen save)
	       word  147     - Int  - Image mode (0=2D single,1=2D multiple,
					  2=3D volume,3=cine,4=spectroscopy)
	       word  148     - Int  - Field strength (gauss)
	       word  149     - Int  - Pulse sequence (0=memp,1=ir,2=ps,3=rm,
					  4=rmge,5=gre,6=vemp,7=mpgr,8=mpgrv,
					  9=mpirs,10=mpiri,11=3d/gre,
					  12=cine/gre,13=spgr,14=sspf,
					  15=cin/spgr,16=3d/spgr,17=fse,
					  18=fve,19=fspgr,20=fgr,21=fmpspgr,
					  22=fmpgr,23=fmpir,24=probe.s,
					  25=probe.p)
	       word  150     - Int  - Pulse sequence subtype (0=chopper)
	       word  151     - Real - Field of view mm
	       word  153     - Real - Center (3 values;R+L-,A+P-,S+I-)
	       word  159     - Int  - Orientation (0=supine,1=prone,2=Lt,3=Rt)
	       word  160     - Int  - Position (0=head first,1=feet first)
	       word  161     - 32A  - Longitudinal anatomical reference
	       word  177     - 32A  - Vertical anatomical reference
	       word  199     - Int  - Scan matrix X
	       word  200     - Int  - Scan matrix Y
	       word  201     - Int  - Image matrix

	block 10 - image header

	       word  44      - Int  - Image number
	       word  73      - Real - Image location
	       word  75      - Real - Table position
	       word  77      - Real - Image thickness
	       word  79      - Real - Image spacing
	       word  82      - Real - TR
	       word  86      - Real - TE
	       word  88      - Real - TI
	       word  98      - Int  - Number of echos
	       word  99      - Int  - Echo number
	       word  101     - Int  - NEX (if not fractional)
	       word  146     - Real - NEX
	       word  146     - Int  - Flip angle

		      3.3.1.1.2 GE MR Signa 3.x,4.x Tape format

		      3.3.1.1.3 GE MR Signa 3.x,4.x Raw data

	      3.3.1.2 GE MR Signa 5.x - 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 HighLite Advantage (HLA) and High Speed Advantage
		      (HSA) CT and Signa 5X MR family, referred to as Genesis.
		      The general details of this scheme will be discussed
		      here, as well as the description of the MR image header.
		      Specifics related to the CT modality are described
		      elsewhere.

		      3.3.1.2.1 GE MR Signa 5.x Image data

				Genesis is a system running under SunOS 3.5G
				(NOT Solaris) on, believe it or not, a sun3
				68000 architecture, not a sun4 sparc.

				It would appear that unlike in the previous
				Data General based system, the active database
				is stored as one large monolithic file in a raw
				partition, which doesn't make it very easy to
				extract single imgaes. Fortunately, GE have
				saved the day by kindly providing, and
				thoroughly documenting in the material that
				they send you when you ask for the image file
				format, an Image Extract Tool that lives in
				"/usr/g/insite/bin" and is called "ximg". To
				see what options are available just type "ximg
				-h" for help. Note that ximg's default is to
				strip out the patient's name and ID number
				which is annoying, so don't forget the "-s"
				flag. The default directory to put the
				extracted images in is "/usr/g/insite/tmp". The
				input names to select images in silent
				(non-menu) mode are of the following form:

		EeeeeeSsssIiii

		eeeee =  exam number   or "all"
		sss   =  series number or "all"
		iii   =  image number  or "all"

and the resultant filenames are the same with an extension of ".MR" or ".CT"
depending. For example:

		% /usr/g/insite/bin/ximg -i e673s1i1 -st
		% ls -l /usr/g/insite/tmp
		E673S1I1.MR

which extracts the selected image in silent mode (-i) without stripping the
identification (-s) in rectangular (-t) mode, ie. not compressed or packed.

				One nifty feature that allows you to keep up to
				date with the latest version header contents is
				the "-g" switch which invokes the GenIncl
				utility that produces a file called
				"imageFileOffsets.h" that lists the type and
				offsets of each field in the header !
				Remarkable, huh ?

				How does one get access to the operating system
				on the Signa ? Let me count the ways. First,
				from the Advantage console one can just call up
				a command shell from the Utilities menu, or one
				can invoke the Ftp option uner Networks and
				then use the "!" command to ftp, which like in
				many Unix tools, spawns a shell. Or from
				another workstation on the network one can just
				telnet or rsh across. If you are connected
				using an Advantage Windows workstation you can
				pull up a command shell by using the right menu
				button with the cursor on the desktop. Doing a
				few "cat /etc/hosts" around the place will let
				you know what all the machines are called.

One can also access the console directly from the plasma screen by toggling
"L1-B" on or off.

				Once you have extracted them, the Genesis file
				contains headers consisting of several
				components in common with CT and then a
				specific CT or MR header. The file is
				structured as a "block type" header with a
				brief "control header" of fixed size, followed
				by a bunch of optional headers, some of which
				reflect internal database structures and are of
				no interest, others (such as the
				suite/exam/series/image) headers that contain
				descriptive and identification information, and
				two that are of importance for deciphering the
				pixel data (unpack control & compression
				control). Some of the more important fields are
				described here:

	Sun3 Sun Data Types:

	   - short is 16 bits
	   - int is 32 bits
	   - float is 32 bits IEEE
	   - double is 64 bits IEEE
	   - byte offsets from 0 start of file
	   - length ==0 means header absent/empty

	control header (offset 0):

		0   - int      - magic number = 0x494d4746 = "IMGF"
		4   - int      - byte displacement to pixel data
		8   - int      - width
		12  - int      - height
		16  - int      - depth (bits)
		20  - int      - compression (0=asis,1=rectangular,2=packed,
				 3=compressed,4=compressed&packed)
		32  - int      - background shade to use for non-image
		54  - u_short  - 16 bit end_around_carry sum of pixels
		56  - int      - ptr to unique image identifier
		60  - int      - length of unique image identifier
		64  - int      - ptr to unpack header
		68  - int      - length of unpack header
		72  - int      - ptr to compression header
		76  - int      - length of compression header
		80  - int      - ptr to histogram header
		84  - int      - length of histogram header
		88  - int      - ptr to text plane
		92  - int      - length of text plane
		96  - int      - ptr to graphics plane
		100 - int      - length of graphics plane
		104 - int      - ptr to data base header
		108 - int      - length of data base header
		112 - int      - value to add to stored pixels
		116 - int      - ptr to user defined data
		120 - int      - length of user defined data
		124 - int      - ptr to suite header
		128 - int      - length of suite header
		132 - int      - ptr to exam header
		136 - int      - length of exam header
		140 - int      - ptr to series header
		144 - int      - length of series header
		148 - int      - ptr to image header
		152 - int      - length of image header

	unpack header:

		// used when compression is packed, or compressed & packed
		// contains perimeter encoding map ... cf. GE 9800

		struct {
			short pixels_to_left_of_line;
			short pixels_in_stored_line;
		} table [height_of_image];

	compression header:

		Not necessary for decompressing entire image ... rather it
		contains seeds for various "strips" of the image to allow
		jumping into the compressed pixel data ... see the GE docs.

	histogram header:

		Contains statistical information for determining optimum
		windowing ... see the GE docs and GenIncl produced header

	exam header:

		0   - char[4]  - suite ID
		8   - u_short  - exam number
		84  - char[13] - patient ID
		97  - char[25] - patient name
		122 - short    - patient age
		126 - short    - patient sex
		305 - char[3]  - exam type - "MR" or "CT"

	series header:

		10  - short    - series number
		84  - char[3]  - anatomical reference
		92  - char[25] - scan protocol name

	image header - for MR (1022 bytes long):

		12  - short    - image number
		26  - float    - slice thickness mm
		30  - short    - matrix size - X
		32  - short    - matrix size - Y
		34  - float    - display field of view - X (mm)
		38  - float    - display field of view - Y (mm)
		42  - float    - image dimension - X
		46  - float    - image dimension - Y
		50  - float    - pixel size - X
		54  - float    - pixel size - Y
		72  - char[17] - iv contrast agent
		89  - char[17] - oral contrast agent
		194 - int      - repetition time(usec)
		198 - int      - inversion time(usec)
		202 - int      - echo time(usec)
		210 - short    - number of echoes
		212 - short    - echo number
		218 - float    - NEX
		308 - char[33] - pulse sequence name
		362 - char[17] - coil name
		640 - short    - ETL for FSE

				So much for the headers. Now how does one deal
				with the image data ? The easiest way of course
				is to save it as "rectangular", that is not
				compressed and not packed. If you want to do it
				the hard way, then if the data is packed, then
				unpack it, then if it is compressed, uncompress
				it. The packing is a perimeter encoding method
				like the CT 9800, except that instead of using
				a map containing just the width of the stored
				data, both a left offset and a width are stored
				for each row, as described in the "unpack
				header". The compression scheme is DPCM again
				but with a difference ... three alternative
				encodings are possible ... a 7 bit difference
				(one byte), a 14 bit difference (two bytes), or
				a flag byte followed by a true 16 bit pixel
				value (three bytes). Presumably this scheme was
				devised to handle a greater dynamic range than
				in the CT 9800 scheme when necessary, but
				produce a similar degree of compression
				otherwise.

	     0  +/- <------ 6 bits ------->
	    _______________ _______________
	   |   |   |   |   |   |   |   |   |
	   |_______________|_______________|
	     7           4   3           0

    or

	     1   0  +/- <------------------ 13 bits ---------------------->
	    _______________ _______________ _______________ _______________
	   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
	   |_______________|_______________|_______________|_______________|
	    15           12 11           8   7           4   3           0

    or

	     1   1  <----- discarded ----->  Then two bytes for 16 bit word
	    _______________ _______________
	   |   |   |   |   |   |   |   |   |
	   |_______________|_______________|
	     7           4   3           0

				  The following piece of C++ code pulled out of
				  a Genesis to DICOM translator will give you
				  the general idea. Note that the perimeter
				  encoding map has already been read in
				  (map_left and map_wide). Note in particular
				  the need to deal with sign extension of the
				  difference values. Unlike the CT 9800 example
				  earlier, one has to use a separate loop for
				  the compressed data stream as all 16 bits are
				  potentially in use.

static void
copygenesisimage(ifstream& instream,DC3ofstream& outstream,
	Uint16 width,Uint16 height,Uint16 depth,Uint16 compress,
	Uint16 *map_left,Uint16 *map_wide)
{
	unsigned row;
	Int16 last_pixel=0;
	for (row=0; row<height; ++row) {
		unsigned j;
		unsigned start;
		unsigned end;

		if (compress == 2 || compress == 4) { // packed/compacked
			start=map_left[row];
			end=start+map_wide[row];
		}
		else {
			start=0;
			end=width;
		}
		// Pad the first "empty" part of the line ...
		for (j=0; j<start; j++) outstream.write16(0);

		if (compress == 3 || compress == 4) { // compressed/compacked
			while (start<end) {
				unsigned char byte;
				instream.read(&byte,1);
				if (!instream) return;
				if (byte & 0x80) {
					unsigned char byte2;
					instream.read(&byte2,1);
					if (!instream) return;
					if (byte & 0x40) {      // next word
						instream.read(&byte,1);
						if (!instream) return;
						last_pixel=
						    (((Uint16)byte2<<8)+byte);
					}
					else {                  // 14 bit delta
						if (byte & 0x20) byte|=0xe0;
						else byte&=0x1f;
						last_pixel+=
						    (((Int16)byte<<8)+byte2);
					}
				}
				else {                          // 7 bit delta
					if (byte & 0x40) byte|=0xc0;
					last_pixel+=(signed char)byte;
				}
				outstream.write16((Uint16)last_pixel);
				++start;
			}
		}
		else {
			while (start<end) {
				Uint16 u=readUint16(instream);
				if (!instream) return;
				outstream.write16(u);
				++start;
			}
		}

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

		      3.3.1.2.2 GE MR Signa 5.x Archive format

				GE supply both DAT tape and 5.25" write once
				and rewriteable optical disk drives.

				The optical drives are made by Pioneer. This is
				an unfortunate choice as the media format is
				incompatible with any other vendor so you need
				a Pioneer (DEC 702 ?) drive to read it. The
				person who made this choice tells me the
				fundamental technology seemed more sound on the
				Pioneer side than from the other companies, and
				there were also two sources for the Pioneer and
				no one was producing any other interchangeable
				systems. Interestingly Siemens made the same
				choice.

				As for the file system, there seem to be two
				methods in use. One is to use a monolithic file
				system on a raw partition. I haven't seen it
				but there is now apparently a document from GE
				available describing this format "direction
				46-021863 CT HLA/HSA MR Signa 5.x Optical Disk
				Raw Partition". See the GEMS image format
				information contacts section. This is what is
				used on the MOD.

				For the WORM, a different choice was made, to
				use a commericially available filesystem
				product that made the disk look like a unix
				filesystem with the ability to store and
				replace and update on a write once medium. It
				is available from DoroTech of France and called
				DoroFile. Because it is a commerical product,
				GE are restrained from disclosing the file
				structure.

				The formats have been reverse engineered by
				Jeffrey Siegel of Evergreen Technologies
				however, and he can supply you with software to
				read both GE and Siemens MOD and WORM formats,
				on a PC or Mac for $495. He can sell you the
				drive as well if necessary for $2800. It can
				run on a Mac or on a PC with an Adaptec card
				and driver. Some driver software for the
				Pioneer drive is also available from Corel.

				If you have an GE Advantage Windows
				workstation, there is an optional MOD/WORM
				drive and software for that.

				As far as the DAT format is concerned, this
				format is available though I don't have it
				(yet). Examining a tape reveals the following
				however:

	- One file used as a tape label (single 8192 byte record)
	- Tape mark
	- Series of image files separated by tape marks

				There does not seem to be a tape directory per
				se.

				Each image file is a modification of the format
				created by the ximg utility to extract images
				from the database.

				The ximg format is described as a file header
				beginning with the magic number "IMGF" and then
				a short header that contains byte offsets to
				the image data, and various suite, exam, series
				and image headers.

				The DAT images are NOT organized like this, but
				do use exactly the same headers and image data
				layout (and compression schemes). The
				difference is in the order of the header.

				The first record of the file is 3180 bytes long
				and contains:

	0-113      suite  header   (length 114)
	114-1137   exam   header   (length 1024)
	1138-2157  series header   (length 1020)
	2158-3079  image  header   (length 1022 for mr)
				   (length 1020 for ct)
	3080-3179  zero padding

				NB. this record DOES NOT begin with "IMGF" !

				The second record of the file is 5208 bytes
				long (in my case anyway) and followed by 8192
				byte records and a final record of whatever is
				left over.

				This 5208 byte record contains a "proper"
				header in the ximg output format and starts
				with "IMGF". The subsequent byte offsets to the
				image data, compression headers, histogram
				header etc. are correct and offset from the
				beginning of this second record and NOT the
				start of the file. Furthermore the pointers to
				those headers in the first record (suite, exam,
				series and image headers) are TOTALLY WRONG and
				must be ignored ... I don't know how their
				values are derived but it is not obvious.

				I presume that the files were reorganized this
				way in order to make it easy for simple
				utilities to access the demographic data to
				index the tape or something. Anyway it is easy
				to rewrite utilities that read the ximg format
				to take all this into account and extract the
				tags and the
images.

				The image data byte offset (eg. 5204) in the
				file header is 4 bytes too short, eg. 3180 +
				5204 + 4 -> 3188 which is where the image data
				starts.

				If you are not familiar with the Genesis ximg
				format, on a Signa at least, you can run
				"/usr/g/insite/bin/ximg -g" to extract a
				prototype C header file describing the file
				format.

		      3.3.1.2.3 GE MR Signa 5.x Raw data

	      3.3.1.3 GE MR Max

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

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

		      I do not have any MR Max images to try this on, but am
		      told that the format is essentially the same as the CT GE
		      CT Pace, with some different fields in the image header:

    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)

	      3.3.1.4 GE MR Vectra

		      Same comments as pertain to the Sytec/Pace entry in the
		      CT section. A few sample files on a floppy would be much
		      appreciated.

	3.3.2 Siemens MR

		It would seem that two formats are used on Siemens MR scanners,
		modern ones at least. There is a native format that is specific
		to each family of scanners, and an "exported" ACR/NEMA based
		SPI format. The earlier scanners define fewer useful elements
		in the exported format, and encapsulate parts of the native
		header in private elements, whereas the more recent forms are
		more complete implementations. The comments below are based on
		limited experience, and in most cases either the native or the
		exported format has been examined, but not both.

		A fairly common feature of all the native formats seems to be
		so-called "image text" portion of the header which contains a
		more or less exact replica of what is annotated on the film ...
		in the earlier models it is indeed an exact replica, being 24
		rows of 40 characters or whatever. This can be very helpful in
		deciphering un unknown format. Interestingly enough, though
		many values are repeated in string form from binary values in
		the header, patient identification information often occurs
		only in the text header and nowhere else !

	      3.3.2.1 Siemens Magnetom GBS/GBS II
		      3.3.2.1.1 Siemens Magnetom GBS/GBS II Native Format

			     Simply speaking the image data can be accessed in
			     most cases as:

				- files 133120 bytes
				- image pixel data 256*256*2 little endian
				- image pixel offset 4096 bytes

				In more detail, there is an initial brief fixed
				"Entry header" that contains pointers to
				subsequent headers, where pointers are offsets
				to 512 byte records, indexed from 1, and
				lengths are in 512 byte records, and binary
				values are Vax data types, including type F
				floats. The image data is usually uncompressed
				little endian two byte words, and it probably
				isn't worth going into details of the
				compression scheme here. I have never tested
				it. Only the more important header values are
				listed here:

    Entry header (first 128 bytes of first 512 byte record):

	0    short          Number of entries (==9)
	2    short          Entry length      (==2)
	4    short          Bytes per record  (==512)
	20   short          Installation header pointer (usually == 2)
	22   short          Installation header length  (usually == 1)
	24   short          Measurement header pointer  (usually == 3)
	26   short          Measurement header length   (usually == 2)
	28   short          Image text header pointer   (usually == 5)
	30   short          Image text header length    (usually == 2)
	32   short          Image data header pointer   (usually == 9)
	34   short          Image data header length    (usually == 256)

    Image header (last 394 bytes of first 512 byte record):

	0    short          Data code (-1=raw data,1=image data,...)
	10   short          Rows
	12   short          Columns
	24   short          Bit depth of image
	26   short          Bit depth of ROI
	28   short          Bit map of ROI in use
	54   short          Pixels per 10cm
	126  short          Archive code
			    (10/12=128 uncompressed/compressed,
			     20/22=256 uncompressed/compressed,
			     50/52=512 uncompressed/compressed)
	256  short          View direction (-1=caudal,1=cranial)
	258  short          Orientation (-1=head first,1=feet first)
	260  short          Orientation (1=supine,2=prone,
			     3=right lateral,4=left lateral)

    Installation header:

	64    char[32]      Serial number

    Measurement header:

	48    char[60]      Protocol name
	120   char[8]       Sequence name
	132   short         Measurement type
			    (100=SE,200=IR,500=FID,
			     502=FID,600=SEM,800=FW)
	138   short         Number of echoes
	140   short         Number of averages
	150   short         Rows in acquisition
	152   short         Columns in acquisition
	222   short         Echo number
	224   short         Slice number
	226   short         Number of slices
	228   short         Slice orientation (1=X,2=Y,3=Z)
	230   short         X angle
	232   short         Y angle
	234   short         Z angle
	236   short         3D resolution factor
	238   short         3D partition
	398   short         Acquisition number
	400   float_f       Slice thickness (3D partition thickness)
	440   short         NMR frequency Hz
	476   float_f       TR secs
	480   float_f       TI secs
	488   float_f[32]   TE[echo 1..32] mS
	756   float_f       Field strength Tesla
	772   float_f       Slice thickness mm
	776   float_f       Slice gap mm
	780   float_f[32]   Slice distance[slice 1..32] mm
	952   char[8]       Imaged nucleus
	972   short         Flip angle
	1004  float_f       Patient weight kg
	1020  float_f       Table position mm

    Image text header:

	0    char[9]       Installation name
	9    char[5]       Field strength <xxxx>T
	15   char[25]      Hospital name
	40   char[25]      Patient name
	66   char[1]       Trigger ('T'=ecg)
	67   char[1]       Gating ('H'=respiratory high,'L'=respiratory low)
	68   char[3]       Software version
	71   char[1]       Lookup table number
	72   char[1]       Measurement matrix size
			   ('A'=128*128,'B'=256*256,'C'=512*512,
			    'D'=128*256,'E'=128*512,'F'=256*512,
			    '*'=raw data set incomplete)
	73   char[1]       Reproduction matrix size
			   ('A'=128*128,'B'=256*256,'C'=512*512)
	74   char[4]       Number of acquisitions
	78   char[2]       Technique
			   ('SE'=spin echo,'SU'=spin echo summation,
			    'SM'=spin echo multiecho,
			    'IR'=inversion recovery,
			    'IS'=inversion recovery summation,
			    'FD'=free induction decay,
			    'PU'=phase image uncorrected,
			    'PC'=phase image corrected,
			    'W '=lipid separation water image,
			    'F '=lipid separation fat image,
			    '3D'=image from 3D data,
			    'T1'=longitudinal relaxation time,
			    '1R'=T1 weighted density,
			    'T2'=transverse relaxation time,
			    '2F'=T2 fit,'2R'=T2 weighted density,
			    'RH'=density,'SI'=synthetic image)
	80   char[12]      Patient ID
	113  char[2]       View direction ('CR'=cranial,'CU'=caudal)
	116  char[1]       View direction ('H'=head first,'F'=feet first)
	118  char[2]       View direction ('SP'=supine,'PR'=prone,
			    'RP'=right lateral posterior,
			    'LP'=left lateral posterior)
	120  char[2]       Date - DD
	123  char[3]       Date - MMM
	127  char[2]       Date - YY
	160  char[2]       Time - HH
	163  char[2]       Time - MM
	166  char[2]       Time - SS
	201  char[5]       Image number
	640  char[6]       Inversion time TI<xxxx> mSecs,
			    flip angle FI<xxxx>,FL<xxxx>,FA<xxxx>
	680  char[6]       Repetition time TR<xxxx> Secs
	680  char[6]       Echo time TE<xxxx> mSecs
	760  char[7]       Slice thickness SL<xxxxx> mm
	800  char[8]       Slice position  SP<xxxxx> mm
	880  char[7]       Slice orientation X  <xxxx>,Y  <xxxx>,Z  <xxxx>,
			    zoom factor ZF <xxxx>, field of view FOV <xxx>
	912  char[8]       Acquisition time TA<mmm:ss>
	920  char[6]       Trigger delay for ecg TD<xxxx>
	929  char[24]      Image comments

				A sample text header follows:

	MAGNETOM 1.5 T              HOSPITAL
	NONAME,JOHN 010199           D2 BB   2SE
	14802 F            FRONT         CU-H-SP
	04-FEB-94
	19:06:06
	>   74                              R
					    I
					    G
					    H
					    T

	TR .60
	TE  15
	SL  5.0
	SP -28.4
	Z   21
	FOV 210                         TA  5:10

		      3.3.2.1.2 Siemens Magnetom GBS/GBS II SPI Format

				Unknown, perhaps doesn't exist.

	      3.3.2.2 Siemens Magnetom SP
		      3.3.2.2.1 Siemens Magnetom SP Native Format

				Unknown.

		      3.3.2.2.2 Siemens Magnetom SP SPI Format

		      - ACR/NEMA data stream starts immediately
		      - big-endian byte order
		      - lots of private groups containing SPI & MR specific
			tags, but much useful information in standard tags
		      - 12 bit allocated data in 16 bits stored, high bit 11
		      - after ACR/NEMA data, trailing garbage

		      Similar story as for the Siemens Somatom Plus. 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 MR attributes have
		      been included in the SPI form, although SPI private tags
		      are available for lots of MR parameters. This is in
		      contrast to the Siemens Magnetom Impact which contains
		      more interesting SPI tags.

SPI private tags:

(0009,0010)                                      <SPI RELEASE 1>
(0009,0011)                                        <SIEMENS MED>
(0009,1010) SPI RELEASE 1   Comments        <SPI VERSION  01.00>
(0009,1015) SPI RELEASE 1   UID     <000S00MR001994122719161248>
(0009,1110) SIEMENS MED     RecognitionCode             <MR 2.0>
(0009,1130) SIEMENS MED     ByteOffsetOfOriginalHeader   [0x800]
(0009,1131) SIEMENS MED     LengthOfOriginalHeader      [0x1600]
(0009,1140) SIEMENS MED     ByteOffsetOfPixelmatrix     [0x2000]
(0009,1141) SIEMENS MED     LengthOfPixelmatrixInBytes [0x20000]

(0011,0010)                                      <SPI RELEASE 1>

(0021,0010)                                        <SIEMENS MED>
(0021,1010) SIEMENS MED     Zoom                          <01.0>
(0021,1011) SIEMENS MED     Target                            <>
(0021,1020) SIEMENS MED     ROIMask                     [0x0000]

Overlay descriptions (overlays already in image pixel data):

(6000,0010)                 OverlayRows                 [0x0100]
(6000,0011)                 OverlayColumns              [0x0100]
(6000,0040)                 ROI                              <R>
(6000,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6000,0060)                 OverlayCompressionCode        <NONE>
(6000,0100)                 OverlayBitsAllocated        [0x0010]
(6000,0102)                 OverlayBitPosition          [0x000c]
(6000,0110)                 OverlayFormat                 <RECT>
(6000,0200)                 OverlayLocation             [0x7fe0]

(6002,0010)                 OverlayRows                 [0x0100]
(6002,0011)                 OverlayColumns              [0x0100]
(6002,0040)                 ROI                              <R>
(6002,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6002,0060)                 OverlayCompressionCode        <NONE>
(6002,0100)                 OverlayBitsAllocated        [0x0010]
(6002,0102)                 OverlayBitPosition          [0x000d]
(6002,0110)                 OverlayFormat                 <RECT>
(6002,0200)                 OverlayLocation             [0x7fe0]

(6004,0010)                 OverlayRows                 [0x0100]
(6004,0011)                 OverlayColumns              [0x0100]
(6004,0040)                 ROI                              <R>
(6004,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6004,0060)                 OverlayCompressionCode        <NONE>
(6004,0100)                 OverlayBitsAllocated        [0x0010]
(6004,0102)                 OverlayBitPosition          [0x000e]
(6004,0110)                 OverlayFormat                 <RECT>
(6004,0200)                 OverlayLocation             [0x7fe0]

(6006,0010)                 OverlayRows                 [0x0100]
(6006,0011)                 OverlayColumns              [0x0100]
(6006,0040)                 ROI                              <R>
(6006,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6006,0060)                 OverlayCompressionCode        <NONE>
(6006,0100)                 OverlayBitsAllocated        [0x0010]
(6006,0102)                 OverlayBitPosition          [0x000f]
(6006,0110)                 OverlayFormat                 <RECT>
(6006,0200)                 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

NB. Siemens VR for OverlayOrigin seems to be wrong. ACR/NEMA says it should be
binary, but [0x5c31,0x2031] translates to a string <1\1> which seems more
plausible!

		      The models in this family include the SP (which the SPI
		      describes as a GBS 3 !), the SP/4000 which got a faster
		      Vax, and the new Vision. I have only examined the files
		      from the SP so far, but they are bog standard SPI with no
		      surprises, and I have no reason to doubt the same is true
		      of the later models.

		      The usual Vax VMS problems apply. Use the console serial
		      port on the back of the Vax. There is a C compiler
		      supplied so you can compile the more recent C version of
		      kermit ... although the old Bliss version works fine.
		      Unlike the Philips, there is no problem with CR delimited
		      file attributes being set on the binary files. Kermit
		      transfers are glacially slow as always.

	      3.3.2.3 Siemens Magnetom Impact
		      3.3.2.3.1 Siemens Magnetom Impact Native Format

				Unknown.

		      3.3.2.3.2 Siemens Magnetom Impact SPI Format

		      - skip the 1st 128 bytes to get to ACR/NEMA data stream
			   (may be artifact of transfer process though rather
			   than real)
		      - big-endian byte order
		      - lots of private groups containing SPI & MR specific
			tags, but much useful information in standard tags
		      - 12 bit allocated data in 16 bits stored, high bit 11
		      - after ACR/NEMA data, file is padded to 512 byte mark

		      Siemens version of SPI, containing the following private
		      data elements. More comprehensive attributes than the
		      Siemens Somatom Plus or Siemens Magnetom SP. There is no
		      overlayed data in the high four bytes of the image pixel
		      data, and that there is no padding in the middle or
		      "original header", or byte offsets and lengths described
		      in group 9. Only some of the more significant elements
		      are described here in the interest of brevity. Sources
		      for a more comprehensive dictionary are described under
		      SPI.

SPI private tags:

(0009,0010)                 PrivateCreator                <SPI RELEASE 1>
(0009,0012)                 PrivateCreator          <SIEMENS CM VA0  CMS>
(0009,0013)                 PrivateCreator          <SIEMENS CM VA0  LAB>
(0009,1010) SPI RELEASE 1   Comments                 <SPI VERSION  01.00>
(0009,1015) SPI RELEASE 1   UID              <000S00MR001994021614211710>
(0009,1040) SPI RELEASE 1   DataObjectSubtype                    [0x0000]
(0009,1041) SPI RELEASE 1   DataObjectSubtype                  <MRUPNONE>
(0009,1210) SIEMENS CM VA0  CMS  StorageMode                   <EXPANDED>
(0009,1212) SIEMENS CM VA0  CMS  EvaluationMask                  [0x0000]
(0009,1226) SIEMENS CM VA0  CMS  LastMoveDate                <1994.02.16>
(0009,1227) SIEMENS CM VA0  CMS  LastMoveTime              <13:41:52.000>
(0009,1320) SIEMENS CM VA0  LAB  HeaderVersion                      <VB6>

(0011,0011)                 PrivateCreator          <SIEMENS CM VA0  CMS>
(0011,1110) SIEMENS CM VA0  CMS RegistrationDate             <1994.02.16>
(0011,1111) SIEMENS CM VA0  CMS RegistrationTime          <113:43:49.000>
(0011,1123) SIEMENS CM VA0  CMS UsedPatientWeight                <000050>

(0019,0010)                 PrivateCreator          <SIEMENS CM VA0  CMS>
(0019,0012)                 PrivateCreator          <SIEMENS MR VA0  GEN>
(0019,0014)                 PrivateCreator         <SIEMENS MR VA0  COAD>
(0019,0015)                 PrivateCreator         <SIEMENS CM VA0  ACQU>
(0019,1060) SIEMENS CM VA0  CMS NumberOfDataBytes                <310127>
(0019,1220) SIEMENS MR VA0  GEN NominalNumberOfFourierLines      <000128>
(0019,1226) SIEMENS MR VA0  GEN NumberOfFourierLinesafterZero    <000063>
(0019,1228) SIEMENS MR VA0  GEN FirstMeasuredFourierLine         <-00064>
(0019,1230) SIEMENS MR VA0  GEN AcquisitionColumns               <000512>
(0019,1231) SIEMENS MR VA0  GEN ReconstructionColumns            <000512>
(0019,1250) SIEMENS MR VA0  GEN CurrentNumberOfAverages          <000010>
(0019,1260) SIEMENS MR VA0  GEN FlipAngle                <00.8000000+E00>
(0019,1290) SIEMENS MR VA0  GEN NumberOfSaturationRegions        <000000>
(0019,1294) SIEMENS MR VA0  GEN ImageRotationAngle       <00.0000000+E00>
(0019,1412) SIEMENS MR VA0  COAD MagneticFieldStrength   <009.500702E-01>
(0019,1456) SIEMENS MR VA0  COAD ReceiverFilterFrequency         <500000>

(0021,0010)                     PrivateCreator              <SIEMENS MED>
(0021,0011)                     PrivateCreator      <SIEMENS CM VA0  CMS>
(0021,0013)                     PrivateCreator      <SIEMENS MR VA0  GEN>
(0021,1010) SIEMENS MED Zoom                                           <>
(0021,1011) SIEMENS MED Target                                         <>
(0021,1020) SIEMENS MED ROIMask                                     [0x0]
(0021,1120) SIEMENS CM VA0  CMS FoV        <00.2050000+E200\.2050000+E20>
(0021,1122) SIEMENS CM VA0  CMS ImageMagnificationFactor <001.000000E+00>
(0021,1130) SIEMENS CM VA0  CMS ViewDirection                      <HEAD>
(0021,1132) SIEMENS CM VA0  CMS RestDirection                      <HEAD>
(0021,1160) SIEMENS CM VA0  CMS ImagePosition        <000.000000E+00\.\.>
(0021,1161) SIEMENS CM VA0  CMS ImageNormal          <-00.000000E+00\.\.>
(0021,1163) SIEMENS CM VA0  CMS ImageDistance            <002.787480E+01>
(0021,116a) SIEMENS CM VA0  CMS ImageRow             <001.000000E+00\.\.>
(0021,116b) SIEMENS CM VA0  CMS ImageColumn          <000.000000E+00\.\.>
(0021,1170) SIEMENS CM VA0  CMS PatientOrientationSet1          <R\AH\HP>
(0021,1171) SIEMENS CM VA0  CMS PatientOrientationSet2          <L\PF\FA>
(0021,1180) SIEMENS CM VA0  CMS StudyName    <routine_brain/6_opt3_mprag>
(0021,1182) SIEMENS CM VA0  CMS StudyType                           <MEA>
(0021,1334) SIEMENS MR VA0  GEN NumberOf3DImagePartitions        <000128>
(0021,1339) SIEMENS MR VA0  GEN SlabThickness            <001.800000E+02>
(0021,1342) SIEMENS MR VA0  GEN CurrentSliceNumber               <000001>
(0021,1343) SIEMENS MR VA0  GEN CurrentGroupNumber               <000001>
(0021,134f) SIEMENS MR VA0  GEN OrderofSlices                 <ASCENDING>
(0021,1370) SIEMENS MR VA0  GEN NumberOfEchoes                   <000001>

(0029,0011)                     PrivateCreator      <SIEMENS CM VA0  CMS>
(0029,1120) SIEMENS CM VA0  CMS PixelQualityCode         <NONE\NONE\NONE>

(0051,0010)                     PrivateCreator      <SIEMENS CM VA0  CMS>
(0051,1010) SIEMENS CM VA0  CMS ImageText                           <...>

	      3.3.2.4 Siemens Magnetom Vision
		      3.3.2.4.1 Siemens Magnetom Vision Native Format

				The exact details of the format are not known,
				but a little guess work has determined what
				follows. The data types are Sun, hence the byte
				order is big-endian and the all the floats I
				have found are doubles. Offsets here are in
				bytes from the start of the header. The
				uncompressed image data starts at offset 6144.

	0         u_int      SiemensStudyDateYYYY
	4         u_int      SiemensStudyDateMM
	8         u_int      SiemensStudyDateDD
	12        u_int      AcquisitionDateYYYY
	16        u_int      AcquisitionDateMM
	20        u_int      AcquisitionDateDD
	24        u_int      ImageDateYYYY
	28        u_int      ImageDateMM
	32        u_int      ImageDateDD
	36        u_int      SiemensStudyTimeHH
	40        u_int      SiemensStudyTimeMM
	44        u_int      SiemensStudyTimeSS
	52        u_int      AcquisitionTimeHH
	56        u_int      AcquisitionTimeMM
	60        u_int      AcquisitionTimeSS
	68        u_int      ImageTimeHH
	72        u_int      ImageTimeMM
	76        u_int      ImageTimeSS
	96        char[7]    Manufacturer
	105       char[25]   InstitutionName
	186       char[4]    Annotation
	281       char[15]   ModelName
	412       u_int      LastMoveDateYYYY
	416       u_int      LastMoveDateMM
	420       u_int      LastMoveDateDD
	424       u_int      LastMoveTimeHH
	428       u_int      LastMoveTimeMM
	432       u_int      LastMoveTimeSS
	768       char[25]   PatientName
	795       char[12]   PatientID
	808       u_int      DOBYYYY
	812       u_int      DOBMM
	816       u_int      DOBDD
	851       char[3]    PatientAge
	854       char       PatientAgeUnits      ('Y'=years)
	1052      u_int      RegistrationDateYYYY
	1056      u_int      RegistrationDateMM
	1060      u_int      RegistrationDateDD
	1064      u_int      RegistrationTimeHH
	1068      u_int      RegistrationTimeMM
	1072      u_int      RegistrationTimeSS
	1544      double     SliceThickness
	1560      double     RepetitionTime
	1568      double     EchoTime
	1592      double     FrequencyMHz
	1639      char[5]    Station
	1712      u_int      CalibrationDateYYYY
	1716      u_int      CalibrationDateMM
	1720      u_int      CalibrationDateDD
	1724      u_int      CalibrationTimeHH
	1728      u_int      CalibrationTimeMM
	1732      u_int      CalibrationTimeSS
	1767      char[16]   ReceivingCoil
	1828      char[4]    ImagedNucleus
	2112      double     FlipAngle
	2560      double     MagneticFieldStrength
	2864      u_int      DisplayMatrixSize
	2944      char[65]   SequencePrgName
	3009      char[65]   SequenceWkcName
	3074      char[9]    SequenceAuthor
	3083      char[8]    SequenceType
	3744      double     FOVRow
	3752      double     FOVColumn
	3768      double     CenterPointX
	3776      double     CenterPointY
	3784      double     CenterPointZ
	3792      double     NormalVectorX
	3800      double     NormalVectorY
	3808      double     NormalVectorZ
	3816      double     DistanceFromIsocenter
	3832      double     RowVectorX
	3840      double     RowVectorY
	3848      double     RowVectorZ
	3856      double     ColumnVectorX
	3864      double     ColumnVectorY
	3872      double     ColumnVectorZ
	3880      char[3]    OrientationSet1X
	3884      char[3]    OrientationSet1Y
	3888      char[3]    OrientationSet1Z
	3892      char[3]    OrientationSet2X
	3896      char[3]    OrientationSet2Y
	3900      char[3]    OrientationSet2Z
	3904      char[32]   SequenceName
	5000      double     PixelSizeRow
	5008      double     PixelSizeColumn

	5504      char[12]   TextPatientID
	5517      char       TextPatientSex
	5518      char[3]    TextPatientAge
	5521      char       TextPatientAgeUnits       ('Y'=years)
	5529      char[7]    TextPatientPosition
	5541      char[5]    TextImageNumberFlag       ('IMAGE'=image)
	5546      char[3]    TextImageNumber
	5559      char[2]    TextDateDD
	5562      char[3]    TextDateMM
	5566      char[4]    TextDateYYYY
	5571      char[2]    TextTimeHH
	5574      char[2]    TextTimeMM
	5577      char[2]    TextAcquisitionTimeFlag   ('TA'=acquisition time)
	5583      char[2]    TextAcquisitionTimeMM
	5586      char[2]    TextAcquisitionTimeSS
	5601      char[4]    TextAnnotation
	5655      char[25]   TextOrganization
	5682      char[5]    TextStation
	5695      char[3]    TextAcquisitionMatrixPhase
	5698      char       TextAcquisitionMatrixPhaseAxis  ('h'=horizontal,'
	'=vertical)
	5700      char[3]    TextAcquisitionMatrixFreq
	5703      char       TextAcquisitionMatrixFreqO      ('o'=o,' '=blank)
	5704      char       TextAcquisitionMatrixFreqS      ('s'=s,' '=blank)
	5706      char[8]    TextSequence
	5714      char[3]    TextFlipAngle
	5718      char[4]    TextScanNumberFlag        ('SCAN'=scan)
	5723      char[3]    TextScanNumberA
	5726      char[3]    TextScanNumberB
	5730      char[2]    TextRepetitionTimeFlag    ('TR'=tr)
	5734      char[7]    TextRepetitionTime
	5742      char[2]    TextEchoTimeFlag          ('TE'=te)
	5746      char[5]    TextEchoTime
	5752      char       TextEchoNumber
	5790      char[2]    TextSliceThicknessFlag    ('SL'=slice thickness)
	5794      char[7]    TextSliceThickness
	5802      char[2]    TextSlicePositionFlag     ('SP'=slice position)
	5806      char[7]    TextSlicePosition
	5814      char[3]    TextAngleFlag1
	('Sag'=sagittal,'Cor'=coronal,'Tra'=transverse)
	5817      char       TextAngleFlag2            ('>'=gt,'<'=lt)
	5818      char[3]    TextAngleFlag3
	('Sag'=sagittal,'Cor'=coronal,'Tra'=transverse)
	5821      char[4]    TextAngle
	5838      char[3]    TextFOVFlag               ('FoV'=field of view)
	5842      char[3]    TextFOVH
	5846      char[3]    TextFOVV
	5874      char[2]    TextTablePositionFlag     ('TP'=table position)
	5878      char[7]    TextTablePosition
	5938      char[5]    TextStudyNumberFlag       ('STUDY'=study)
	5943      char[2]    TextStudyNumber
	5956      char[2]    TextDOBDD
	5959      char[3]    TextDOBMM
	5963      char[4]    TextDOBYYYY
	5992      char[3]    TextStudyNumberFlag2      ('STU'=study)
	5996      char[3]    TextImageNumberFlag2      ('IMA'=study)
	5999      char[2]    TextStudyNumber2
	6002      char[2]    TextImageNumber2
	6013      char[5]    TextStudyImageNumber3
	6031      char[15]   TextModelName
	6058      char[25]   TextPatientName
	6085      char[2]    TextScanStartTimeHH
	6088      char[2]    TextScanStartTimeMM
	6091      char[2]    TextScanStartTimeSS

		      3.3.2.4.2 Siemens Magnetom Vision SPI Format

				Unknown.

	3.3.3 Philips MR

	      3.3.3.1 Philips Gyroscan S5

		      - can export as ACR/NEMA (actually SPI) files
		      - little endian byte order
		      - 12 bit packed data

		      This description pertains to "exported ACR/NEMA", not the
		      native image files, which I am not familiar with. In fact
		      I am not even sure in which directory they live.

		      Use the ADMIN menu on the operator's console to find the
		      import/export ACR/NEMA utility, with which you can select
		      an exam, series or image to export as an ACR/NEMA file.
		      The default directory is the GYROVIEW home directory,
		      which is already pretty cluttered so it is better to make
		      another subdirectory like "ANI" to keep exported files
		      in. The exported files have huge names composed of
		      identification information, but all have a ".ANI"
		      extension. For example:

	DIR SYS$SYSROOT:[GYROSCAN]*.ANI;*

	SMITH__FA02010801010001.ANI;1

		      These files are stored as, wait for it, fixed length 512
		      byte records, with the "carriage return carriage control"
		      record attributes set from some bizarre reason, which
		      totally messes up kermit which starts messing with adding
		      and changing CR/LF characters. See the Vax diatribe below
		      for a method of getting around this, by using DUMP as a
		      poor man's uuencode permitting ascii transfer.
		      Unfortunately the nature of fixed length records under
		      VMS means that the last record will be padded out to 512
		      bytes without any indication of the "real" end-of-file.
		      This means your ACR/NEMA reader has to cope with trailing
		      garbage gracefully.

		      Unlike the Siemens SPI files, the Philips ones are stored
		      in little-endian format. There is no fixed size header to
		      skip, just go straight into the ACR/NEMA data stream. For
		      the image pixel data four 12 bit words are packed without
		      padding into 16 bit words, without any compression sheme.
		      See the ACR/NEMA section for description of the packing
		      organization. Lots of private tags are defined, but these
		      can be ignored. Some of the identifying tags present are
		      as follows:

(0000x8,000x10) CS RecognitionCode       VR=<CS>   VL=<0xc>  <ACR-NEMA 1.0>
(0000x8,000x70) LO Manufacturer          VR=<LO>   VL=<0x8>  <Philips >
(0000x8,0x1090) LO ManufacturerModelName VR=<LO>   VL=<0x2>  <S5>
(0000x9,000x10) LT SPIComments   VR=<LT>   VL=<0xe>   <SPI Release 1 >
(000x19,000x10)                  VR=<LT>   VL=<0x14>  <PHILIPS MR R5.6/PART>

		      To get the files off, I plug a portable with a serial
		      cable into one of the spare serial ports inside one of
		      the Vax cabinets, at 9600 baud, and login as
		      "GYROVIEW/NOCOM" without any password needed. This dumps
		      you in the same directory as the files will be stored by
		      default. You will probably need to set local echo on on
		      your portable, or "SET TERMINAL/ECHO" on the Vax.
Kermit was already loaded on my system, accessed as "RUN [SYSEXE]KERMIT". See
the Vax section later for more help.

	      3.3.3.2 Philips Gyroscan ACS
	      3.3.3.3 Philips Gyroscan T5
	      3.3.3.4 Philips Gyroscan NT5 & NT15

	3.3.4 Picker MR - another black hole
	3.3.5 Toshiba MR - another black hole
	3.3.6 Hitachi MR - another black hole
	3.3.7 Shimadzu MR

	      No longer a black hole, as some information and sample files have
	      arrived. Watch this space.

	3.3.8 Elscint MR - another black hole

The next part is part5 -  proprietary other formats.

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!uhog.mit.edu!news.mathworks.com!gatech!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
From: dclunie@flash.us.com (David A. Clunie)
Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
Subject: Medical Image Format FAQ, Part 5/8
Followup-To: alt.image.medical
Date: 30 Jan 1996 16:04:11 -0500
Organization: Mollard Consultants
Lines: 651
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 28 Feb 1996 00:00:00 GMT
Message-ID: <4em14b$3cn@flash.ksapax>
Reply-To: dclunie@flash.us.com (David A. Clunie)
NNTP-Posting-Host: flash.ksapax
Summary: This posting contains answers to the most Frequently Asked
	 Question on alt.image.medical - how do I convert from image
	 format X from vendor Y to something I can use ? In addition
	 it contains information about various standard formats.
Xref: senator-bedfellow.mit.edu alt.image.medical:4253 comp.protocols.dicom:1435 sci.data.formats:1405 sci.med.informatics:5253 sci.med.radiology:4966 alt.answers:15306 comp.answers:16761 sci.answers:3830 news.answers:63444

Archive-name: medical-image-faq/part5
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

    3.4 Proprietary Workstations

	3.4.1 ISG Workstations

	      3.4.1.1 Gyroview

		      The Philips Gyroview workstation is a high-resolution
		      graphical workstation for MR images from Gyroscan
		      scanners, that can also handle CT images and other
		      modalities, and has an optional package for three
		      dimensional processing of images. It is based on a Sun
		      SPARC system with proprietary graphics hardware. The
		      software is actually written by ISG in Canada. The image
		      format is an ACR/NEMA based format with various private
		      tags defined, and a proprietary scheme of image
		      compression that has me stumped. I am told by some that
		      there is no means of telling the Gyroview not to compress
		      the images. I use compress in the sense that includes
		      packing four 12 bit words into three 16 bit big-endian
		      words, which appears to be part of the scheme in use.
		      Unfortunately, some form of perimeter encoding is also in
		      use, and I just can't figure it out :( Some people have
		      had more luck using "the export utility of the Gyroview"
		      to produce just 12 bit packed images without the
		      perimeter encoding. I don't kn

		      Despite prolonged exchanges of email it seems that the
		      formal decision is not to release the format. Customers
		      may contact ISG at harry@isgtec.com(Harry Visser) to
		      bitch about this and then give up and ask for information
		      on how to obtain a software package called the External
		      Developers Tool which contains a tool called xdimage
		      which can only be used on ISG's proprietary hardware.
		      This is free to customers. It does however only export to
		      (and import from) a flat file format and ascii
		      description, not an ACR/NEMA style file with uncompressed
		      pixel data :(.

		      I would still prefer to know the format, as people keep
		      asking (these machines were pretty popular I gather), and
		      if anyone has any hints about the data format, I would
		      appreciate them. Here follows part of a reply to one of
		      these people when I made an unsuccesful attempt to figure
		      this out:

Firstly, I presume this file is generated by a Philips Gyroview workstation
judging by ...

(0008,0070) LO Manufacturer  VR=<LO>  VL=<8>  <GYROVIEW>

The file says it is an MRI image ...

(0008,0060) CS Modality  VR=<CS>  VL=<2>  <MR>

and yet it is missing many of the mri attributes normally present. Also it
includes some CT specific attributes, notably ...

(0018,1120) DS GantryDetectorTilt  VR=<DS>  VL=<2>  < 0>

which is pretty weird. I presume that this format is generated by something
purely for the purposes of 3D reconstruction and only the attributes needed for
that have been preserved.

The image appears to be 512*512 ...

(0028,0010) US Rows     VR=<US>  VL=<2>  [200]
(0028,0011) US Columns  VR=<US>  VL=<2>  [200]

As far as the compression format is concerned ...

(0028,0060) CS CompressionCode  VR=<CS>  VL=<2>  < 2>

is not in itself a valid ACR/NEMA value, and hence some proprietary variation
is in use. The most important clue is ...

(0028,0040) CS ImageFormat  VR=<CS>  VL=<4>  <CIRC>

which is also not valid ACR/NEMA (only RECT is permitted). From this I conclude
that some sort of 'circular' perimeter encoding scheme is in use that only
sends the meaningful central pixels in each row and leaves out the background.
This is substantiated by the fact that the image pixel data seems to be
preceded by a table of 257 long words in ascending order, each value separated
by relatively low values (80-100 or so). I suspect that these are pointers into
the data to the start of each row...

% od -x I011_1_001 +1404 | more
0001404  0000 0202 0000 0252 0000 02a2 0000 02f2
0001424  0000 0342 0000 0392 0000 03e2 0000 0432
0001444  0000 0482 0000 04d2 0000 0522 0000 0572
0001464  0000 05c2 0000 0612 0000 0662 0000 06b3
0001504  0000 0705 0000 0757 0000 07ab 0000 0800
0001524  0000 0857 0000 08ae 0000 0905 0000 095e ...

[0000] 000514 -> 000514
[0001] 000594 -> 000080
[0002] 000674 -> 000080
[0003] 000754 -> 000080
[0004] 000834 -> 000080
[0005] 000914 -> 000080

 ...

[0155] 015322 -> 000103
[0156] 015425 -> 000103
[0157] 015527 -> 000102
[0158] 015629 -> 000102

 ...

[0254] 024484 -> 000080
[0255] 024564 -> 000080
[0256] 024564 -> 000000

The first of these values seems to be a pointer in two byte word units past the
table, the entries for a series of rows, then a final "257th" value that is the
same as the preceding with a difference of zero, possibly flagging the end of
the table.

What confuses me is the fact that there are 256 or so entries rather than 512
(number of rows), and that the difference values are relatively small for 512
columns. Perhaps each entry applies to two successive rows though this seems
rather peculiar.

Furthermore, if it is true that the units are two byte words, then the last
pointer value is much lower than the number of remaining bytes in the image
pixel data attribute, so what are all the other bytes for ?

The other thing that is going to make extraction difficult is the fact that the
data are supposed to be 12 bits packed into 16 bit words ...

(0028,0100) US BitsAllocated  VR=<US>  VL=<2>  [c]
(0028,0101) US BitsStored     VR=<US>  VL=<2>  [c]
(0028,0102) US HighBit        VR=<US>  VL=<2>  [b]

Hence 3 two byte words are used to store 4 12 bit pixels. It may not be easy to
figure out in what order this packing is performed. The ACR/NEMA standard has
an example of its intent in this case, but the byte order was never specified
for this standard, which had a 16 bit hardware data path and was not originally
intended for offline data storage in bytes, so there are a number of possible
permutations to deal with :(

Finally I don't know what to make of the "private" tags ...

Unrecognized (0029,0010)  VR=<LT>  VL=<a> <ISG shadow>
Unrecognized (0029,1070)  VR=<LT>  VL=<6> < 49128>
Unrecognized (0029,1080)  VR=<LT>  VL=<6> <123432>
Unrecognized (0029,1090)  VR=<LT>  VL=<2> < 0>

which presumably have some significance or they wouldn't be there !

    3.5 Other Proprietary Formats

	3.5.1 Analyze From Mayo

This very popular software package is produced by the Biomedical Imaging
Resource group at the Mayo Clinic/Foundation. I have always thought they should
give it away but they don't, it is moderately expensive, though less so than
some other alternatives. If you want to test or buy it try contacting Denny
Hanson dph@mayo.edu who is extremely helpful.

Anyway, importing images into Analyze is a drag and you have to convert your
files to their format, but it isn't very difficult. I hear that some other
programs also use their format but haven't encountered them myself. Anyway, the
package is sufficiently commonly used that it seems appropriate to include the
format here.

This information is included verbatim from what was sent to me by Ellis Workman
elw@mayo.edu and if you have problems I am sure he will be able to help. I
haven't tested it because I can't afford to buy a copy myself :( That's a hint,
Denny.

ANALYZE IMAGE FILE FORMAT

ANALYZE image file sets consist of at least 2 files:
	- an image file
	- a header file
	- a color lookup file   * optional

For the Analyze image file set "foo" there are two files:
	foo.img & foo.hdr  (optionally foo.lkup)

The ANALYZE programs refer to this file set as a single entity.

       The Image File (foo.img)

The format of the image file is very simple; containging usually
uncompressed voxel data for the images in one of the several
possible voxel formats:
	- 1 bit  packed binary (slices begin on byte boundaries)
	- 8 bit  (unsigned char) gray scale unless .lkup file present
	- 16 bit signed short
	- 32 bit signed integers or float
	- 24 bit RGB, 8 bits per channel

The header file is a 'C' structure which describes the dimensions
and properties of the voxel data.  This structure follows:

/*
 *
 * (c) Copyright, 1986-1995
 * Biomedical Imaging Resource
 * Mayo Foundation
 *
 * dbh.h
 *
 *
 * database sub-definitions
 */

struct header_key                       /*      header_key       */
    {                                           /* off + size*/
	int sizeof_hdr;                         /* 0 + 4     */
	char data_type[10];                     /* 4 + 10    */
	char db_name[18];                       /* 14 + 18   */
	int extents;                            /* 32 + 4    */
	short int session_error;                /* 36 + 2    */
	char regular;                           /* 38 + 1    */
	char hkey_un0;                          /* 39 + 1    */
    };                                          /* total=40  */

struct image_dimension                  /*      image_dimension  */
    {                                           /* off + size*/
	short int dim[8];                       /* 0 + 16    */
	char vox_units[4];                      /* 16 + 4    */
	char cal_units[8];                      /* 20 + 4    */
	short int unused1;                      /* 24 + 2    */
	short int datatype;                     /* 30 + 2    */
	short int bitpix;                       /* 32 + 2    */
	short int dim_un0;                      /* 34 + 2    */
	float pixdim[8];                        /* 36 + 32   */
			/*
				pixdim[] specifies the voxel dimensions:
				pixdim[1] - voxel width
				pixdim[2] - voxel height
				pixdim[3] - interslice distance
					..etc
			*/
	float vox_offset;                       /* 68 + 4    */
	float funused1;                         /* 72 + 4    */
	float funused2;                         /* 76 + 4    */
	float funused3;                         /* 80 + 4    */
	float cal_max;                          /* 84 + 4    */
	float cal_min;                          /* 88 + 4    */
	int compressed;                         /* 92 + 4    */
	int verified;                           /* 96 + 4    */
	int glmax, glmin;                       /* 100 + 8   */
    };                                          /* total=108 */

struct data_history                     /*      data_history     */
    {                                           /* off + size*/
	char descrip[80];                       /* 0 + 80    */
	char aux_file[24];                      /* 80 + 24   */
	char orient;                            /* 104 + 1   */
	char originator[10];                    /* 105 + 10  */
	char generated[10];                     /* 115 + 10  */
	char scannum[10];                       /* 125 + 10  */
	char patient_id[10];                    /* 135 + 10  */
	char exp_date[10];                      /* 145 + 10  */
	char exp_time[10];                      /* 155 + 10  */
	char hist_un0[3];                       /* 165 + 3   */
	int views;                              /* 168 + 4   */
	int vols_added;                         /* 172 + 4   */
	int start_field;                        /* 176 + 4   */
	int field_skip;                         /* 180 + 4   */
	int omax,omin;                          /* 184 + 8   */
	int smax,smin;                          /* 192 + 8   */
    };                                          /* total=200 */

struct dsr                              /*      dsr              */
    {                                           /* off + size*/
	struct header_key hk;                   /* 0 + 40    */
	struct image_dimension dime;            /* 40 + 108  */
	struct data_history hist;               /* 148 + 200 */
    };                                          /* total=348 */

Comments:
	struct header_key
		int sizeof_header   /* must indicate size of header file */
		int extants;        /* should be 16384 */
		char regular;       /* 'r' */

	struct image_dimension struct decribes the organization and
	side of images. These elements enable IO routines to reference
	images by volume and slice number.

		short int dim[]  /* array of image dimensions */
			dim[0]        /* number of dimensions; usually 4 */
			dim[1]        /* image width */
			dim[2]        /* image height */
			dim[3]        /* volume depth */
			dim[4]        /* volumes in file */

		char vox_units[4] /* labels voxerl spatial unit */
		char cal_units[4] /* labels voxel calibration unit */
		short int datatype /* Acceptable values are */

#define DT_NONE                         0
#define DT_UNKNOWN                      0
#define DT_BINARY                       1
#define DT_UNSIGNED_CHAR        2
#define DT_SIGNED_SHORT         4
#define DT_SIGNED_INT           8
#define DT_FLOAT                        16
#define DT_COMPLEX                      32
#define DT_DOUBLE                       64
#define DT_RGB                          128
#define DT_ALL                          255

		short int bitpix     /* bits per pixel */
		float pixdim[]  /* parallel array to dim giving voxel
		dimensions
				   in each dimension */
			 pixdim[1]  /* voxel width */
			 pixdim[2]  /* voxel height */
			 pixdim[3]  /* voxel depth or slice thickness */

		float vox_offset; /* byte offset in the .img file at which
				     voxels start. If value is negative
				     specifies that the absolute value
				     is applied for every image in the file. */

		float calibrated Max & Min /* specify range of calibration
		values */
		int glmax, glmin    /* the max and min values for entire data
		set */

The data_history substructure is not required, but the 'orient' element
is used to indicate individual slice orientation and determines whether
the ANALYZE 'Movie' program will attempt to flip the images before
displaying a movie sequence.
	orient:
			0 - transverse unflipped
			1 - coronal unflipped
			2 - sagittal unflipped
			3 - transverse flipped
			4 - coronal flipped
			5 - sagittal flipped

The following 'C' program creates an Analyze .hdr file.

/*
 * (c) Copyright, 1986-1994
 * Biomedical Imaging Resource
 * Mayo Foundation
 *
 *
 */

#include
#include "dbh.h"

main(argc,argv) /* file x y z t datatype max min */
int argc;
char **argv;
{
    int i;
    struct dsr hdr;
    FILE *fp;
    static char DataTypes[9][12] = {"UNKNOWN", "BINARY", "CHAR", "SHORT",
    "INT",
				    "FLOAT", "COMPLEX", "DOUBLE", "RGB"};

    static int DataTypeSizes[9] = {0,1,8,16,32,32,64,64,24};

    if(argc != 9)
    {
	usage();
	exit(0);
    }
    memset(&hdr,0, sizeof(struct dsr));
    for(i=0;i<8;i++)
	hdr.dime.pixdim[i]=0.0;

    hdr.dime.vox_offset = 0.0;
    hdr.dime.roi_scale   = 1.0;
    hdr.dime.funused1    = 0.0;
    hdr.dime.funused2    = 0.0;
    hdr.dime.cal_max     = 0.0;
    hdr.dime.cal_min     = 0.0;

    hdr.dime.datatype = -1;

    for(i=1;i<=8;i++)
	if(!strcmp(argv[6],DataTypes[i]))
	{
		hdr.dime.datatype = (1<<(i-1));
		hdr.dime.bitpix = DataTypeSizes[i];
		break;
	}

    if(hdr.dime.datatype <= 0)
    {
	printf(" is an unacceptable datatype \n\n", argv[6]);
	usage();
	exit(0);
    }

    if((fp=fopen(argv[1],"w"))==0)
    {
	printf("unable to create: %s\n",argv[1]);
	exit(0);
    }

    hdr.dime.dim[0] = 4;  /* all Analyze images are taken as 4 dimensional */
    hdr.hk.regular = 'r';
    hdr.hk.sizeof_hdr = sizeof(struct dsr);

    hdr.dime.dim[1] = atoi(argv[2]);  /* slice width  in pixels */
    hdr.dime.dim[2] = atoi(argv[3]);  /* slice height in pixels */
    hdr.dime.dim[3] = atoi(argv[4]);  /* volume depth in slices */
    hdr.dime.dim[4] = atoi(argv[5]);  /* number of volumes per file */

    hdr.dime.glmax  = atoi(argv[7]);  /* maximum voxel value  */
    hdr.dime.glmin  = atoi(argv[8]);  /* minimum voxel value */

/*      Set the voxel dimension fields:
       A value of 0.0 for these fields implies that the value is unknown.
	 Change these values to what is appropriate for your data
	 or pass additional command line arguments     */

    hdr.dime.pixdim[1] = 0.0; /* voxel x dimension */
    hdr.dime.pixdim[2] = 0.0; /* voxel y dimension */
    hdr.dime.pixdim[3] = 0.0; /* pixel z dimension, slice thickness */

/*   Assume zero offset in .img file, byte at which pixel
       data starts in the image file */

    hdr.dime.vox_offset = 0.0;

/*   Planar Orientation;    */
/*   Movie flag OFF: 0 = transverse, 1 = coronal, 2 = sagittal
     Movie flag ON:  3 = transverse, 4 = coronal, 5 = sagittal  */

    hdr.hist.orient     = 0;

/*   up to 3 characters for the voxels units label; i.e.
	mm., um., cm.               */

    strcpy(hdr.dime.vox_units," ");

/*   up to 7 characters for the calibration units label; i.e. HU */

    strcpy(hdr.dime.cal_units," ");

/*     Calibration maximum and minimum values;
       values of 0.0 for both fields imply that no
       calibration max and min values are used    */

    hdr.dime.cal_max = 0.0;
    hdr.dime.cal_min = 0.0;

    fwrite(&hdr,sizeof(struct dsr),1,fp);
    fclose(fp);
}

usage()
{
   printf("usage:  make_hdr name.hdr x y z t datatype max min \n\n");
   printf("  name.hdr = the name of the header file\n");
   printf("  x = width, y = height,  z = depth,  t = number of volumes\n");
   printf("  acceptable datatype values are: BINARY, CHAR, SHORT,\n");
   printf("                 INT, FLOAT, COMPLEX, DOUBLE, and RGB\n");
   printf("  max = maximum voxel value,  min = minimum voxel value\n");
}

The following program displays information in an Analyze header file.

#include
#include "dbh.h"

void ShowHdr(char *, struct dsr *);
void swap_long(unsigned char *);
void swap_short(unsigned char *);

main(argc,argv)
int argc;
char **argv;
    {
    struct dsr hdr;
    int size;
    double cmax, cmin;
    FILE *fp;

	if((fp=fopen(argv[1],"r"))==NULL)
    {
	fprintf(stderr,"Can't open:\n", argv[1]);
	exit(0);
    }
    fread(&hdr,1,sizeof(struct dsr),fp);

	if(hdr.dime.dim[0]  15)
		swap_hdr(&hdr);

     ShowHdr(argv[1], &hdr);

     }

void ShowHdr(fileName,hdr)
struct dsr *hdr;
char *fileName;
{
int i;
char string[128];
printf("Analyze Header Dump of:  \n", fileName);
/* Header Key */
printf("sizeof_hdr:  \n", hdr->hk.sizeof_hdr);
printf("data_type:   \n", hdr->hk.data_type);
printf("db_name:     \n", hdr->hk.db_name);
printf("extents:     \n", hdr->hk.extents);
printf("session_error:  \n", hdr->hk.session_error);
printf("regular:   \n", hdr->hk.regular);
printf("hkey_un0:  \n", hdr->hk.hkey_un0);

/* Image Dimension */
for(i=0;i<8;i++)
	printf("dim[%d]:  \n", i, hdr->dime.dim[i]);

	strncpy(string,hdr->dime.vox_units,4);
	printf("vox_units:   \n", string);

	strncpy(string,hdr->dime.cal_units,8);
	printf("cal_units:  \n", string);
	printf("unused1:    \n", hdr->dime.unused1);
	printf("datatype:   \n", hdr->dime.datatype);
	printf("bitpix:     \n", hdr->dime.bitpix);

for(i=0;i<8;i++)
	printf("pixdim[%d]:  \n",i, hdr->dime.pixdim[i]);

printf("vox_offset:  \n",  hdr->dime.vox_offset);
printf("funused1:    \n", hdr->dime.funused1);
printf("funused2:    \n", hdr->dime.funused2);
printf("funused3:    \n", hdr->dime.funused3);
printf("cal_max:     \n", hdr->dime.cal_max);
printf("cal_min:     \n", hdr->dime.cal_min);
printf("compressed:  \n", hdr->dime.compressed);
printf("verified:    \n", hdr->dime.verified);
printf("glmax:       \n", hdr->dime.glmax);
printf("glmin:       \n", hdr->dime.glmin);

/* Data History */
strncpy(string,hdr->hist.descrip,80);
printf("descrip:   \n", string);
strncpy(string,hdr->hist.aux_file,24);
printf("aux_file:  \n", string);
printf("orient:    \n", hdr->hist.orient);

strncpy(string,hdr->hist.originator,10);
printf("originator:  \n", string);

strncpy(string,hdr->hist.generated,10);
printf("generated:  \n", string);

strncpy(string,hdr->hist.scannum,10);
printf("scannum:  \n", string);

strncpy(string,hdr->hist.patient_id,10);
printf("patient_id:  \n", string);

strncpy(string,hdr->hist.exp_date,10);
printf("exp_date:  \n", string);

strncpy(string,hdr->hist.exp_time,10);
printf("exp_time:  \n", string);

strncpy(string,hdr->hist.hist_un0,10);
printf("hist_un0:  \n", string);

printf("views:       \n", hdr->hist.views);
printf("vols_added:  \n", hdr->hist.vols_added);
printf("start_field: \n", hdr->hist.start_field);
printf("field_skip:  \n", hdr->hist.field_skip);
printf("omax:  \n", hdr->hist.omax);
printf("omin:  \n", hdr->hist.omin);
printf("smin:  \n", hdr->hist.smax);
printf("smin:  \n", hdr->hist.smin);

}

swap_hdr(pntr)
struct dsr *pntr;
	{
	swap_long(&pntr->hk.sizeof_hdr) ;
	swap_long(&pntr->hk.extents) ;
	swap_short(&pntr->hk.session_error) ;
	swap_short(&pntr->dime.dim[0]) ;
	swap_short(&pntr->dime.dim[1]) ;
	swap_short(&pntr->dime.dim[2]) ;
	swap_short(&pntr->dime.dim[3]) ;
	swap_short(&pntr->dime.dim[4]) ;
	swap_short(&pntr->dime.dim[5]) ;
	swap_short(&pntr->dime.dim[6]) ;
	swap_short(&pntr->dime.dim[7]) ;
	swap_short(&pntr->dime.unused1) ;
	swap_short(&pntr->dime.datatype) ;
	swap_short(&pntr->dime.bitpix) ;
	swap_long(&pntr->dime.pixdim[0]) ;
	swap_long(&pntr->dime.pixdim[1]) ;
	swap_long(&pntr->dime.pixdim[2]) ;
	swap_long(&pntr->dime.pixdim[3]) ;
	swap_long(&pntr->dime.pixdim[4]) ;
	swap_long(&pntr->dime.pixdim[5]) ;
	swap_long(&pntr->dime.pixdim[6]) ;
	swap_long(&pntr->dime.pixdim[7]) ;
	swap_long(&pntr->dime.vox_offset) ;
	swap_long(&pntr->dime.funused1) ;
	swap_long(&pntr->dime.funused2) ;
	swap_long(&pntr->dime.cal_max) ;
	swap_long(&pntr->dime.cal_min) ;
	swap_long(&pntr->dime.compressed) ;
	swap_long(&pntr->dime.verified) ;
	swap_short(&pntr->dime.dim_un0) ;
	swap_long(&pntr->dime.glmax) ;
	swap_long(&pntr->dime.glmin) ;
	}

swap_long(pntr)
unsigned char *pntr;
	{
	unsigned char b0, b1, b2, b3;

	b0 = *pntr;
	b1 = *(pntr+1);
	b2 = *(pntr+2);
	b3 = *(pntr+3);

	*pntr = b3;
	*(pntr+1) = b2;
	*(pntr+2) = b1;
	*(pntr+3) = b0;
	}

swap_short(pntr)
unsigned char *pntr;
	{
	unsigned char b0, b1;

	b0 = *pntr;
	b1 = *(pntr+1);

	*pntr = b1;
	*(pntr+1) = b0;
	}

The next part is part6 -  hosts & compression.

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!munnari.OZ.AU!news.mel.connect.com.au!yarrina.connect.com.au!news.mira.net.au!Germany.EU.net!EU.net!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
From: dclunie@flash.us.com (David A. Clunie)
Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
Subject: Medical Image Format FAQ, Part 6/8
Followup-To: alt.image.medical
Date: 30 Jan 1996 16:04:16 -0500
Organization: Mollard Consultants
Lines: 675
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 28 Feb 1996 00:00:00 GMT
Message-ID: <4em14g$3d8@flash.ksapax>
Reply-To: dclunie@flash.us.com (David A. Clunie)
NNTP-Posting-Host: flash.ksapax
Summary: This posting contains answers to the most Frequently Asked
	 Question on alt.image.medical - how do I convert from image
	 format X from vendor Y to something I can use ? In addition
	 it contains information about various standard formats.
Xref: senator-bedfellow.mit.edu alt.image.medical:4243 comp.protocols.dicom:1428 sci.data.formats:1398 sci.med.informatics:5237 sci.med.radiology:4948 alt.answers:15294 comp.answers:16735 sci.answers:3817 news.answers:63380

Archive-name: medical-image-faq/part6
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

4.  Host Machines

    4.1 Data General

	4.1.1 Data General Data

	      4.1.1.1 Data General Integers

		      Integers are 16 bit two's complement and stored in
		      big-endian format as on Sun Sparc and opposite to the Dec
		      VAX.

	      4.1.1.2 Data General Floating Point

		      Single precision real values are 32 bits long, in
		      big-endian format. The high bit is the sign bit, followed
		      by a 7 bit excess 64 exponent (power to which 16 must be
		      raised) then a 24 bit hexadecimally normalized mantissa
		      with the decimal point to the left of the most
		      significant bit. Double precision values just have
		      another 32 bits tacked on the mantissa and the same
		      exponent format.

	    Sign
	   |<-->|<------ Exponent ------>|<--------- Mantissa -------->|
	    ______________ ______________ ______________ ______________
	   |              |              |              |              |
	   |______________|______________|______________|______________|
	    31          28 27          24 23          20 19          16
	   |<----------------------- Mantissa ------------------------>|
	    ______________ ______________ ______________ ______________
	   |              |              |              |              |
	   |______________|______________|______________|______________|
	    15          12 11           8 7            4 3            0

		      Here is a little piece of C++ code that should run on
		      anything and convert Data General floats to whatever the
		      host's floating point format is.

		double  value;
		unsigned char   sign;
		Uint16          exponent;
		Uint32          mantissa;

		typedef struct {
			unsigned        sign : 1;
			unsigned        exponent : 7;
			unsigned        mantissa : 24;
		} DG_FLOAT;

		DG_FLOAT number;

		unsigned char buffer[4];
		instream.read(buffer,4);
		if (instream) {
			// DataGeneral is a Big Endian machine
			memcpy ((char *)(&number),buffer,4);
			sign     = number.sign;
			exponent = number.exponent;
			mantissa = number.mantissa;

			value = (double) mantissa / (1 << 24) *
				pow (16.0, (long)(exponent) - 64);
			value = (sign == 0) ? value : -value;
		}
		else {
			cerr << "read failed\n" << flush;
			value=0;
		}

	4.1.2 Data General Operating System

	      4.1.2.1 Data General RDOS

		      Used on the GE CT 9800 family. Severely primitive but
		      then is running on an old machine that can only map 64Kb
		      of memory at a time after all. It is apparently
		      multitasking. Documentation may still be available from
		      Data General (try DG Direct) but is not supplied with the
		      scanner by GE. If anyone knows where I can find it at a
		      reasonable price let me know. Here is a brief command
		      summary culled from a nifty pocket book from GE for
		      SunOS/Genesis users that compares commands:

		 CHATR  - file attributes
		 CRAND  - create randomly organized file
		 CDIR   - create directory
		 DELETE - files or directories
		 DIR    - change directory
		 DISK   - free space
		 FILCOM - compare files
		 GDIR   - show working directory name
		 GTOD   - show date and time
		 LINK   - files (symbolic)
		 LIST   - directory contents
		 MOVE   - a file
		 RENAME - a file
		 SDAT   - set date
		 STOD   - set time
		 SDUMP  - write files to a device
		 SLOAD  - read dumped files
		 SPEED  - tex editor
		 TYPE   - contents of file
		 XFER   - copy a file

		 wildcards: '-' is series, '*' is single character

	      4.1.2.2 Data General AOS/VS

		      Used on the GE Signa 3X and 4X family. Quite a nice
		      operating system with multi-tasking and hierarchical
		      directories. Here is a brief command summary again culled
		      from a nifty pocket book from GE for SunOS/Genesis users
		      that compares commands:

		 ACL         - access control list (ownership)
		 BYE         - exit command process
		 COPY        - a file
		 CREATE      - a text file
		 CREATE/DIR  - a directory
		 CREATE/LINK - link files
		 DELETE      - files & directories
		 DIR         - display or change working directory
		 DUMP        - to peripheral
		 F/AS/S      - directory listing with file status
		 DATE        - show or set
		 HELP
		 LOAD        - DUMPed files
		 MOVE        - a file
		 RENAME      - a file
		 PATH        - show pathname of a file
		 PAUSE       - the command line interpreter
		 SUPERU ON   - enable superuser
		 SED         - text editor
		 TIME        - show or set
		 TYPE        - contents of text file
		 ?           - list processes running

		 wildcards: '+' is series, '*' is single character

		      Other useful hints include the use of "^" to refer to the
		      next directory up (like ".." in Unix) in DIR commands.
		      Command options follow the command name without any
		      spaces and are indicated by a slash. COPY operations
		      specify the destination name first and then the source
		      name. Devices like the mag tape are indicated by "@", for
		      example "@MTB0" is tape drive zero. Files on the tape can
		      be referred to as "@MTB0:nn" which is very handy. For
		      example to read a file off a CT 9800 tape under AOS/VS:

		COPY/V/IMTRSIZE=8192 B038040101.YP @MTB0:18

		      Perhaps most importantly, there is an extensive online
		      help system ... use the HELP command.

	4.1.3 Data General Network

	      If you have a GE Signa based on a DG then you can get the
	      so-called "High Speed Network" card and software from GE. From
	      memory it is pretty pricey, and there used to be a "slower"
	      network interface that was cheaper, but I don't think this is
	      available anymore.

	      If you have a CT 9800 based on the DG S/140 and you need to get
	      it connected there are a number of solutions:

	     - Talk to GE about there ID/LINK II product ... I gather this is a
	     device that hooks into the SCSI cable to the hard drive (you need
	     one of the Ace drives not the old Zebra drive), monitors disk
	     activity and snatches pieces of the conversation to make a copy of
	     the image data, stores it and makes it available via some network
	     protocol. Sound crazy ? Perhaps, but they tell me it works and the
	     price is reasonable, at least for something from GE anyway. Get
	     them to throw one in next time you buy something big.

	     - The do-it-yourself approach. Talk to John Clayton
	     (clayton@c-c.com) at Claflin and Clayton. They supply a complete
	     R-level solution by providing Ethernet hardware and TCP/IP
	     software for 16 bit DG OS including AOS and RDOS (specifically
	     including the GE CT version of RDOS). He tells me "you can expect
	     a file transfer rate of 25 kbytes/s for S/140 systems". The
	     package consists of:

	      $2,850 - EC-10 ethernet controller
	      $1,645 - RDOS TCP/IP software (telnet client,ftp client/server)

	      I have not personally tried either of these approaches, and I am
	      sure there are others (talk to Merge or DeJarnette), but I am
	      getting really tired of carrying 9-track tapes around so perhaps
	      I will bite the bullet soon (and upgrade to a HighSpeed Advantage
	      !).

    4.2 Vax

	4.2.1 Vax Data

	      4.2.1.1 Vax Integers

		      - little endian
		      - 8, 16, or 32 bits

	      4.2.1.2 Vax Floating Point

		      - little endian
		      - D_float

			- 8 bytes
			- sign bit 15
			- exponent bits 14-7 excess 128 binary
			- fraction MSB firstbits 6-0, 31-16, 47-32, 63-48
			- normalized bit is not represented (hidden)

		      - G_float

			- 8 bytes
			- like D, but
			- exponent is bits 14-4 excess 1024
			- fraction 3-0 and 63-16

		      - F_float

			- 4 bytes
			- like D, smaller fraction

		      - H_float

			- 16 bytes
			- like G, but
			- exponent is bits 14-0 excess 16384
			- fraction is bits 127-16

			  - same wierd order
			  - bit 112 least significant

	      4.2.1.3 Vax Strings

		      - 16 bits of length
		      - byte of type
		      - byte of class
		      - 32 bits of pointer

	4.2.2 Vax Operating System

	      4.2.2.1 Vax VMS

		      Truely one of the world's most irritating operating
		      systems to use, especially if you are a unix fan. Still
		      it works, has a great online help system that saves one's
		      butt almost often enough to be useful, and if you can
		      remember the directory where kermit is stored and the
		      weird command to invoke it one can get by (barely).

		      If you don't know VMS and the vendor doesn't supply the
		      manuals, get them from DEC ... you need them bad ... real
		      bad. If (like me) you throw them out everytime you move
		      then encounter another piece of archaic equipment, you
		      need the "vaxbook" which is available via ftp from
		      decoy.uoregon.edu, written by Joseph E St Sauver, which
		      summarizes commands, files and all sorts of application
		      specific stuff, though it is no substitute for the real
		      thing.

		      Recent VMS update: goddamn file formats ! Why can't VMS
		      behave like a real operating system and forget this file
		      format crap ! I have some Philips S5 MR images exported
		      in ACR/NEMA format and I can't get the things off the
		      hosts's Vax using Kermit, because though they have fixed
		      length 512 byte records, some cretinous program sets the
		      "carriage return carriage control" record attributes,
		      which causes kermit to send with all the '0A' characters
		      scrubbed out amongst other atrocities. I am getting
		      desperate and about to try using the Hex/Dehex utility
		      that came with Kermit to get the stuff off and then
		      decode the hex format ! Or perhaps even use "dump" to
		      make a textfile, transfer, and decipher that. (No I don't
		      have a C compiler for the Vax so I guess I can't use
		      uuencode unless someone wants to mail me a hex'ed
		      executable). Any hints, or instructions as to how to use
		      FDL and Convert, to change it to a normal format would be
		      appreciated. (Why can't they just have a "set file record
		      attrib

		      More recent VMS update: finally had an inspiration while
		      staring at hex dumps of these files - why not use the VMS
		      "DUMP" utility which produces hex dumps as a "poor man's
		      uuencode" by saving the dump to a file,  transferring it
		      as an ascii file, and then decoding it at the destination
		      ? Of course there are no nifty line checksums or
		      anything, but a transfer protocol such as kermit takes
		      care of this. The DUMP output defaults to 8 32 bit long
		      words separated by a space per line displayed as hex,
		      then an ascii string (32 bytes) and then a 24 bit word
		      hex address offset from the start of the fixed length
		      record. All the data containing lines start with a single
		      space, where as descriptions at the start of each record
		      begin in the first column, hence the data lines can be
		      easily selected out. By the way, the hex version of the
		      data is listed in reverse order ! VMS is so bizarre ! For
		      example, here is a fixed length 512 byte record file from
		      a Philips S5 MRI (some of the hex words elided to

Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ...
File ID (2419,301,0)   End of file block 198 / Allocated 200

Virtual block number 1 (00000001), 512 (0200) bytes

 0000000C 00100008 ... 00000008 .............................. 000000
 00083932 2E36302E ... 2D524341 ACR-NEMA 1.0.. .....1994.06.29.. 000020
 00600008 4D5F4553 ... 00000030 0.......@.........A.....SE_M..`. 000040
 494B0000 00100080 ... 00000002 ....MR..p.....Philips ........KI 000060

 00183148 00000002 ... 32200000 .. 2........63865375........H1.. 0001E0
^L
Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ...
File ID (2419,301,0)   End of file block 198 / Allocated 200

Virtual block number 2 (00000002), 512 (0200) bytes

 40000018 45424F52 ... 00161250 P.....AGACQ_PT_SURFACE_PROBE...@ 000000

And so on ... you get the idea. This ugly little C++ utility written quickly
during this moment of inspiration will take saved DUMP output and make it
binary again:

#include <fstream.h>

#include "MainCmd.h"

signed char
hextobin(char c)
{
	signed char r;
	switch (c) {
		case '0':       r=0; break;
		case '1':       r=1; break;
		case '2':       r=2; break;
		case '3':       r=3; break;
		case '4':       r=4; break;
		case '5':       r=5; break;
		case '6':       r=6; break;
		case '7':       r=7; break;
		case '8':       r=8; break;
		case '9':       r=9; break;
		case 'A':
		case 'a':       r=0xa; break;
		case 'B':
		case 'b':       r=0xb; break;
		case 'C':
		case 'c':       r=0xc; break;
		case 'D':
		case 'd':       r=0xd; break;
		case 'E':
		case 'e':       r=0xe; break;
		case 'F':
		case 'f':       r=0xf; break;
		default:        r=-1; break;
	}
	return r;
}

int
main(int argc,char **argv)
{
	CCOMMAND(argc,argv);

	while (1) {
		const linemax=132;              // only needs 113
		char line[linemax];
		cin.getline(line,linemax);
		if (!cin || cin.eof()) {
			// cerr << "Bad or eof\n" << flush;
			break;
		}
		unsigned count=cin.gcount();
		if (count == 0 || line[0] != ' ') continue;
		if (count != 113) {
			cerr << "Line length " << count << "\n" << flush;
			break;
		}
		unsigned i;
		char *ptr = line + 8*(1+8);
		// line is in reverse order ...
		for (i=0; i<8; ++i) {
			unsigned j;
			for (j=0; j<4; ++j) {
				// 2 hex bytes -> 1 byte
				char bytelo = *--ptr;
				char bytehi = *--ptr;
				unsigned char byte
					= (hextobin(bytehi)<<4)
					  + hextobin(bytelo);
				cout.put(byte);
			}
			--ptr;  // space between long words
		}
	}
	return 0;
}

		      Note that the nature of fixed length records under VMS
		      means that the last record will be padded out to 512
		      bytes without any indication of the "real" end-of-file.
		      This means you have to cope with trailing garbage
		      gracefully.

		      Hot VMS/Philips news: neelin@pet.mni.mcgill.ca (Peter
		      Neelin) tells me there is an extremely useful tool for
		      fiddling binary files called FILE from DECUS. It allows
		      you to change a file's header information without
		      modifying the content of the file. This then permits ftp,
		      kermit, etc. to do the right thing with Philips .ANI
		      files. It also permits wildcards and does not make a copy
		      of the file (so it is fast). He says also that someone
		      has told him that they succeeded in using convert to fix
		      these files, but his general experience with it is not
		      positive (it will often change the content of the file
		      and it doesn't allow wildcards, in addition to promoting
		      the use of the horrible fdl editor!). If you are
		      interested, you can get FILE through gopher from
		      decus.org (look for the DECUS software library archives,
		      under essential tools). The binary is provided in case
		      you don't have a compiler.

		      Some other useful hints:

		      - To log onto a serial terminal without executing the
		      login command file add "/NOCOM" to the username ... this
		      way you can use the operator console login which often
		      won't require a password.

		      - There is a kermit available for the Vax under VMS (file
		      prefix "vms" in area or tape b) ... I use the "obsolete"
		      version written in Bliss, because it comes from the
		      archives at columbia with a hex encoded executable which
		      can be uploaded just using an ordinary text capture into
		      a file, and doing the same with the short Macro hex
		      program that can then be assembled and used to make the
		      convert into the real executable. Look in places like
		      [SYSEXE] first though to be sure Kermit is not already
		      there. The generic C version of kermit runs under VMS
		      (file prefix "ck" in area or tape f), but not every
		      imaging machine comes with a VMS C compiler, whereas
		      Macro is always supposed to be there I gather. There is
		      however also a hex encoded executable of the C version in
		      the archives (ckvker.hex) which I haven't tried, and is
		      the one that is recommended in the kermit documentation.

		      - There is apparently a zmodem for VMS but I don't know
		      where it comes from or how to get it.

		      - Serial ports are almost always defaulted to 9600 baud.

		      - "SET TERMINAL/ECHO" often isn't set.

		      - Vax/VMS ftp conventions:

			UNIX FTP server     Vax/VMS FTP server

			cd dir                cd [.dir]
			cd dir/subdir         cd [.dir.subdir]
			cd ..                 cd [-]

	      4.2.2.2 ULTRIX
	      4.2.2.3 OSF

    4.3 Sun - Sun3 68000 and Sun4 Sparc

	4.3.1 Sun Data

	      The sun3 and sun4 architectures use much the same formats. Even
	      though the processors are different both are big-endian and the
	      float formats are IEEE. See the Sparc Architecture Manual -
	      Chapter 3 - Data Formats for more details.

	      4.3.1.1 Sun Integers

		      Integers are 8, 16, 32, or 64 bit unsigned or signed
		      two's complement and stored in big-endian format as on
		      Data General and opposite to the Dec VAX. Most C
		      compilers treat short as 16 bits, and int and long as 32
		      bits.

	      4.3.1.2 Sun Floating Point

		      Formats conform to IEEE 754-1985. Single precision real
		      values are 32 bits long, in big-endian format. The high
		      bit is the sign bit, followed by a 8 bit excess 127
		      exponent (power to which 2 must be raised) then a 23 bit
		      normalized mantissa with the decimal point to the left of
		      the most significant bit, from which 1.0 has been
		      subtracted. Double precision values have a 11 bit excess
		      1023 exponent and a 52 bit mantissa. Quad precision
		      values have a 15 bit excess 16383 exponent and a 112 bit
		      mantissa.

	    Sign
	   |<-->|<-------- Exponent -------->|<------- Mantissa ------>|
	    ______________ ______________ ______________ ______________
	   |              |              |              |              |
	   |______________|______________|______________|______________|
	    31          28 27          24 23          20 19          16
	   |<----------------------- Mantissa ------------------------>|
	    ______________ ______________ ______________ ______________
	   |              |              |              |              |
	   |______________|______________|______________|______________|
	    15          12 11           8 7            4 3            0

		      Here is a little piece of C++ code that should run on
		      anything and convert Sun IEEE floats to whatever the
		      host's floating point format is. It probably should take
		      into account a few special cases to be strictly correct:

		unsigned char buffer[4];
		instream.read(buffer,4);
		if (instream) {
#ifdef USESUN4NATIVEFLOAT
			float fvalue;
			memcpy ((char *)(&fvalue),buffer,4);
			value=fvalue;
#else  USESUN4NATIVEFLOAT
			unsigned char   sign;
			Uint16          exponent;
			Uint32          mantissa;

			typedef struct {
				unsigned        sign : 1;
				unsigned        exponent : 8;
				unsigned        mantissa : 23;
			} IEEE_FLOAT_SINGLE;

			IEEE_FLOAT_SINGLE number;
			// Sparc is a Big Endian machine
			memcpy ((char *)(&number),buffer,4);
			sign     = number.sign;
			exponent = number.exponent;
			mantissa = number.mantissa;

			if (exponent) {
				value = (1.0 + (double)mantissa / (1 << 23)) *
					pow (2.0, (long)(exponent) - 127);
			}
			else {
				if (mantissa) {
					value = (double)mantissa / (1 << 23) *
						pow (2.0, (long)(-126));
				}
				else {
					value=0;
				}
			}
			value = (sign == 0) ? value : -value;
#endif USESUN4NATIVEFLOAT
		}
		else {
			cerr << "read failed\n" << flush;
			value=0;
		}

	      4.3.1.3 Sun Strings

		      Strings obey the usual C convention of null terminated
		      strings without a length preamble.

	4.3.2 Sun Operating System

5.  Compression Schemes

    5.1 Reversible Compression
    5.2 Irreversible Compression
	5.2.1 Perimeter Encoding

6.  Getting Connected

    6.1 Tapes

	Nine-track half-inch tapes were the old medium of choice for archiving
	and image exchange and many older pieces of equipment will have these.
	Unfortunately most people don't have such a drive on their workstation
	or personal computer. There are several possibilities:

	  - Use another piece of equipment that has a more modern or
	   networked or serial-ported host and a nine-track drive, and
	   use it to do the extraction. I used to use a networked Signa 4X
	   to do this to extract GE 9800 CT tapes.

	  - Visit your MIS department, which almost certainly has an archaic
	   mainframe with a tape drive. Sometimes tough to get them to read
	   formats they aren't expecting though (the hosts not the people
	   I mean :) ).

	  - Buy a nine-track for your workstation. This may seem a ridiculous
	   idea given the price of new 6250 bpi drives are around $5,000, but
	   one can often pick up bargain primitive non-6250 or refurbished
	   drive that is adequate for the job.

	The Qualstar 1054 is one such drive, that attaches to a SCSI port, and
	works with the regular SunOS SCSI tape driver, once a few tables in the
	kernel have been updated as follows, and the kernel rebuilt:

{root}% pwd
/usr/kvm/sys/scsi/targets

{root}% diff -c stdef.h.prequalstar stdef.h
*** stdef.h.prequalstar Tue Aug 30 19:32:24 1994
--- stdef.h     Tue Aug 30 19:32:24 1994
***************
*** 43,48 ****
--- 43,49 ----
  #define       ST_TYPE_FUJI            0x21    /* Fujitsu - (not tested) */
  #define       ST_TYPE_KENNEDY         0x22    /* Kennedy */
  #define       ST_TYPE_HP              0x23    /* HP */
+ #define       ST_TYPE_QUALSTAR        0x24    /* Qualstar */
  #define       ST_TYPE_HIC             0x26    /* Generic 1/2" Cartridge */
  #define       ST_TYPE_REEL            0x27    /* Generic 1/2" Reel Tape */

{root}% diff -c st_conf.c.prequalstar st_conf.c
*** st_conf.c.prequalstar       Tue Aug 30 19:32:22 1994
--- st_conf.c   Tue Aug 30 19:32:22 1994
***************
*** 153,158 ****
--- 153,174 ----
   * so our best guess as to their capabilities is
   * included herein.
   */
+ /* Qualstar 1054 or 1260s scsi 9-track with 64KB buffer */
+ {
+       "Qualstar 1054/1260s 1/2\" Reel", 7, "NCR ADP-53", ST_TYPE_QUALSTAR,
10240,
+       (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
+       300, 300,
+       { 0x00, 0x02, 0x06, 0x03},
+       {  0, 0, 0, 0 }
+ },
+ /* Qualstar 1054 scsi 9-track with 256KB buffer */
+ {
+       "Qualstar 1054 1/2\" Reel", 10, "QUALSTAR10", ST_TYPE_QUALSTAR, 10240,
+       (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
+       300, 300,
+       { 0x00, 0x02, 0x06, 0x06},
+       {  0, 0, 0, 0 }
+ },
  /* Wangtek QIC-150 1/4" cartridge */ {
	"Wangtek QIC-150", 14, "WANGTEK 5150ES", ST_TYPE_WANGTEK, 512,
	(ST_QIC | ST_AUTODEN_OVERRIDE),

	I got my Qualstar 1054 from Bill Power at Power Computer Services for
	only $750 and have successfully read GE 9800 CT and Philips S15 MR
	tapes with it so far. See the "Sources" section for where to get one.

	Once you have such a tape connected to the SCSI port, one can either
	write simple programs to read files (easiest if the tape has variable
	length records) or use shell scripts and the "dd" command with whatever
	the correct block size is. See dd(1), mt(1), and mtio(3) for more
	information. Remember that the read(2) call reads one fixed or variable
	length record at a time, and returns 0 bytes read for a tape mark, and
	two tape marks in a row indicates the end of the tape (normally). If
	you encounter short files with a series of records 80 bytes long
	chances are you are dealing with header/end markers. This is what ANSI
	standard tapes off VAX VMS seem to look like.

	Anyone who has any further information about tape formats and handling,
	especially references to standard or on-line documents please let me
	know.

    6.2 Ethernet

    6.3 Serial Ports

The next part is part7 - information sources.

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsserver.pixel.kodak.com!news.sprintlink.net!gryphon.phoenix.net!academ!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
From: dclunie@flash.us.com (David A. Clunie)
Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
Subject: Medical Image Format FAQ, Part 7/8
Followup-To: alt.image.medical
Date: 30 Jan 1996 16:04:24 -0500
Organization: Mollard Consultants
Lines: 1508
Approved: news-answers-request@MIT.EDU
Distribution: world
Expires: 28 Feb 1996 00:00:00 GMT
Message-ID: <4em14o$3dp@flash.ksapax>
Reply-To: dclunie@flash.us.com (David A. Clunie)
NNTP-Posting-Host: flash.ksapax
Summary: This posting contains answers to the most Frequently Asked
	 Question on alt.image.medical - how do I convert from image
	 format X from vendor Y to something I can use ? In addition
	 it contains information about various standard formats.
Xref: senator-bedfellow.mit.edu alt.image.medical:4248 comp.protocols.dicom:1431 sci.data.formats:1401 sci.med.informatics:5243 sci.med.radiology:4956 alt.answers:15300 comp.answers:16741 sci.answers:3821 news.answers:63406

Archive-name: medical-image-faq/part7
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

7.  Sources of Information

    7.1 Vendor Contacts

       - ANSI - Getting a Registered Organization Number for a DICOM UID Root:

		ANSI Registration Coordinator
		Michelle Maas
		phone (212) 642-4900
		phone (212) 642-4884
		fax   (212) 398-0023
		e-mail mmaas@ansi.org
		www    http://www.ansi.org/

		numeric identifier costs $1000 and takes 10 days (needed for
		DICOM)
		organization name  costs $1500 and takes 90 days (not needed
		for DICOM)

       - ATL:

		Advanced Technology Laboratories
		22100 Bothell Everett Highway
		P.O. Box 3003
		Bothell, WA   98041-3003
		phone 206-487-7000
		phone 206-485-6080

		http://www.atl.com

       - COSIRA - Getting a Registered Organization Number for a DICOM UID
       Root:

		COSIRA - Canadian Open Systems Interconnection Registration
		Authority
		275 Slater Street, 19th Floor
		Ottawa Ontario K1P5H9
		phone (613) 236-7803
		fax   (613) 234-6934

		Attention: Louis Ferland, extension 427

		NumberForm object identifier costs $500 Canadian
		NameForm object identifier costs another $500 Canadian

       - DEFF Contact - TIFF based portable ultrasound format:

		- ATL
		- jbono@corp.atl.com John Bono

       - DICOM Registered Organization Number for a DICOM UID Root:

		ANSI Registration Coordinator
		COSIRA - Canadian Open Systems Interconnection Registration
		Authority

       - DICOM standard comments and working group information:

		David Snavely, Staff Executive
		NEMA
		1300 North 17th Street, Suite 1847
		Rosslyn VA 22209
		phone 703-841-3200 NEMA
		phone 703-841-3285 David Snavely
		phone 703-841-3217 Jean Brown (David's secretary)
		e-mail dav_snavely@nema.org

		Gordon Bass
		American College of Radiology
		1891 Preston White Drive
		Reston VA 22091
		phone (703) 648-8900

       - DICOM standard publications and ACR/NEMA standards:

		NEMA Publication Sales
		1300 North 17th Street, Suite 1847
		Rosslyn VA 22209
		phone 703-841-3200 NEMA

		Last price I have for Parts 1-10 was $USD235 plus SH
		More recent parts are STILL NOT AVAILABLE

       - FDA approval for PACS and Related Devices:

		Guidance for the Comment and Review of 510(k)
		Notifications for PACS and Related Devices

		FDA Small Manufacturers Assistance
		phone (800) 638-2041
		fax   (800) 899-0381 (flash system for document delivery)
		fax   (301) 827-0111 (flash system for document delivery)

       - FDA Regulatory Affairs site

		Regulatory Forum BBS - modem (919) 848-9461
		http://www.nando.net/ads/ckbus/RAinfo/reglink1.htm

       - FDA standards online

		Fedworld Gateway - modem (703) 321-8020
		telnet://fedworld.gov
		ftp://ftp.fedworld.gov
		http://www.fedworld.gov/

       - General Electric (not just GEMS):

		http://www.ge.com/

       - General Electric CRD (Corporate Research & Development):

		http://www.ge.com/crd/

       - General Electric, GEMS DICOM information contacts:

		Donald VanSyckle
		Senior Systems Analyst
		GE Medical Systems
		3200 N. Grandview Blvd.
		Waukesha WI 53188
		phone (414) 521-6262
		fax   (414) 521-6800
		email vansyckled@med.ge.com

       - GEMS image format information contacts:

		GE Format Documents currently available:

		- 46-021852 Technicare Magnetic Tape Image Fmt
		- 46-021853 CT 8800 Image Data Fmt
		- 46-021854 CT 9000 Image Data Fmt
		- 46-021855 CT 9800 Image Data Fmt
		- 46-021856 CT Pace Image Data Fmt
		- 46-021862 MR Max  Image Data Fmt
		- 46-021858 MR Signa 4.x Mag Tape and Image Data Fmt
		- 46-021861 CT HLA/HSA MR Signa 5.x Image Data Fmt
		- 46-021863 CT HLA/HSA MR Signa 5.x Optical Disk Raw Partition
		- 46-021864 CT HLA/HSA MR Signa 5.x Image Extract Tool
		- 46-021865 CT HLA/HSA MR Signa 5.x DAT Archive Fmt
		- 46-021866 PET 4096 Plus and 2048 Plus Image Fmt
		- 46-269546 IDNet v2.0 Implementation Profiles

		Field engineers are now supposedly well informed about these
		documents and can obtain them directly for you. They are
		freely distributable.

		You can try calling GE documentation direct at:

		phone (800) 558-2040
		phone (414) 548-2520

		If these approaches doesn't work, try one of these guys.

		John Meissner
		Networks Technical Leader
		GE Medical Systems
		N25 W23255 Paul Road
		Pewaukee WI 53072
		phone (414) 896-2707
		email meissnerj@med.ge.com

		Alan Cuellar-Amrod
		CT OnLine Support
		GE Medical Systems
		email cuellara@iscmed.med.ge.com

       - General Electric Medical Systems:

		ftp://ftp.med.ge.com/

       - General Electric, GEMS Ultrasound contact:

		Paul Mullen
		Radiology Product Manager
		email logiq@med.ge.com
		email mullenp@delphi.com (Paul Mullen)

       - Intech:

		http://www.dada.it/intech/welcome.html

       - General Electric, GEMS Ultrasound contact:

		Paul Mullen
		Radiology Product Manager
		email logiq@med.ge.com
		email mullenp@delphi.com (Paul Mullen)

       - Interfile information contacts:

		Trevor Cradduck cradduck@irus.rri.uwo.ca
		Andrew Todd-Pokropek a.todd@ucl.ac.uk

       - Images - digitized mammograms:

		- no FTP site
		- 50 each, normal and cancer mammograms
		- digitized at 200 micrometers and 8 bits
		- provide them with an appropriate tape
		- Contact:

		Maria Kallergi, PhD
		Department of Radiology
		University of South Florida
		12901 Bruce B. Downs Blvd., Box 17
		Tampa, FL   33612-4799
		phone (813) 975-7873
		fax   (813) 975-7831
		email kallergi@rad.usf.edu

       - ISG:

		ISG Technologies Inc
		6509 Airport Rd.
		Mississauga, ONT L4V 1S7
		Canada
		phone (905) 672-2100

		http://www.isgtec.com/

       - JPEG - Independent JPEG Group (IJG):

		Tom Lane jpeg-info@uunet.uu.net

       - Philips:

		http://www.philips.com

       - Philips Medical Systems:

		http://www.philips.com/ms
		http://www-eu.philips.com/ms European site
		http://www-us.philips.com/ms US mirror

       - Picker:

		http://www.picker.com

       - Siemens:

		http://www.siemens.de/

    7.2 Relevant FAQ's

       - Archive-name: compression-faq/part[1-3]
       - Archive-name: graphics/faq
       - Archive-name: graphics/resources-list/part[1-3]
       - Archive-name: image-processing/Macintosh
       - Archive-name: jpeg-faq
       - Archive-name: medical-image-faq/volume-visualization
       - Archive-name: medical-informatics-faq
       - Archive-name: pixutils-faq
       - Archive-name: sci-data-formats

       - DICOM FAQ

		  - http://www.xray.hmc.psu.edu/dicom/faq.html
		  - maintained by David Channin dsc@xray.hmc.psu.edu
		  - periodically posted to comp.protocols.dicom

       - FITS basics and information (periodic posting)

		- FITS (Flexible Image Transport System)
		- for astronomical data
		- periodically posted by
		      Barry Schlesinger bschlesinger@nssdca.gsfc.nasa.gov
		- in sci.astro.fits,sci.data.formats

       - Teleradiology FAQ

		  - maintained by Phillip Berman compumed@indirect.com
		  - periodically posted to various groups including

		       - alt.image.medical
		       - sci.med.informatics
		       - sci.med.radiology
		       - sci.med.telemedicine

    7.3 Source Code

	See under FTP/WWW Sites

    7.4 Commercial Offerings

       - Anatomical images on CDROM and other atlases:

		ADAM Software Inc
		1899 Powers Ferry Rd.
		Suite 460
		Marietta, GA 30067
		phone (800) 755-2326
		fax   (404) 955-3088
		phone (800) 408-ADAM Dept 502
		phone (800) 408-ADAM Dept 504
		phone (404) 980-0888

		BodyWorks
		Software Marketing Corp
		9830 South 51st St, Bldg. A-131
		Phoenix, AZ  85044
		phone (602) 893-3377

		Gold Standard Multimedia
		http://www.gate.net/~gsm

		Lifeart
		phone (800) 543-3278
		phone (216) 291-1922

		McKnight Associates
		Interactive Human and Radiologic Anatomy CDROMs
		Scott C. Howard
		Medical CD-ROM Sales Consultant
		242 S.W. 2nd Street
		Gainesville, FL  32601-6576
		phone (904) 378-7773
		phone (800) 378-7793
		fax   (904) 337-0760
		email  75521.2241@compuserve.com

		VoxelMan Atlas
		Springer-Verlag, Electronic Media
		175 Fifth Avenue
		New York, NY 10010
		phone  (212) 460-1682
		phone  (212) 533 5587
		email  blange@springer-ny.com

		See also:

		Visible Human Project
		Visible Human CDROM

       - Data General TCP/IP solution for RDOS & AOS:

		Claflin & Clayton
		203 Southwest Cutoff
		Northboro, MA 01532
		phone 508-393-7979
		fax   508-393-8788
		email clayton@c-c.com
		email 70262.3663@compuserve.com

       - Data General themselves:

		DG Direct
		phone 1-800-343-8842

       - DICOM to Information System integration contacts:

		Intech HiCube DICOM IS Integration.
		email lapus@intech.dada.it (Lapo Bertini) Director of Marketing
		http http://www.dada.it/intech/hicube/home.html

		Mitra DICOM IS Integration.
		email eric@mitra.com (Eric Peterson)
		http http://www.mitra.com/his-scp.html

		Philips Inturis.
		email R.A.vanGeuns@nl.cis.philips.com (Rob van Geuns)
		http http://www.philips.com/ms/connectivity/index_en.html

       - DICOM interface toolkits and solutions:

		Dejarnette Research Systems Inc.
		Wayne Dejarnette
		Suite 700
		401 Washington Avenue
		Towson, Maryland 21204
		USA
		phone 410-583-0680
		fax   410-583-0696
		email info@dejarnette.com

		Merge Technologies Inc.
		1126 S. 70th St, Suite N508B
		Milwaukee, Wisconsin 53214-34151
		phone 414-475-4300
		fax   414-475-3940
		email sales@merge.com (sales)
		email itk_support@merge.com (toolkit)

		http http://www.merge.com/

		Merge Technologies Europe.
		Molvense Erven 69
		5672 HJ Nuenen
		The Netherlands
		phone +31-40-838-948
		fax   +31-40-832-975

		Kodak Health Imaging Systems
		18325 Waterview Parkway
		Dallas TX 75252
		phone 214-994-1266
		fax   214-994-4180
		email cbs@khis.com (C.B.Stone)

		Mitra
		Eric Peterson
		115 Randall Drive
		Waterloo Ontario N2V 1C5
		Canada
		phone 519-746-2900
		email eric@mitra.com (Eric Peterson)

		http http://www.mitra.com/

       - DICOM to web gateways:

		Medwed.
		667 Folsom Street
		San Fransisco CA 94107
		phone 1-800-8MEDWEB
		phone 415-541-9980
		fax   415-541-9984
		email sales@medwed.net
		http  http://www.medweb.net/

		Passport Technologies.
		86 Orchard Street
		Hackensack NJ 07601
		phone 201-487-5885
		fax   201-487-7455
		email sbeer@ibm.net (Steve Beer) Director of RD,Marketing

       - Eight inch floppy solutions for PC's:

		Microtek Conversion Systems
		940 Industrial Ave
		Palo Alto, Ca. 94303
		phone (415) 424-1174
		fax   (415) 424-1176

		8" drive and controller $2,095
		Format software each package $595-$695

		Computer Peripherals Unlimited
		2355 N. Steves Blvd, Suite C
		Flagstaff AZ 86004
		phone (602) 526-2261
		fax   (602) 773-9183

		8" drive and controller $1,245
		Format software ? included

       - InterFormat - qsh to Interfile conversion, ACR/NEMA to qsh, et al.

		- http://nucmed.nyu.edu/qshtape.html
		- medical image format translation program
		- automatically identifies and translates heterogeneous files
		- Motif interface for user browsing & image selection
		- input formats:

			- GE 8800 CT, 9800 CT, Advantage CT & MR, Signa MR
			- Technicare 2000 CT
			- Positron PET
			- Philips 300 Series CT
			- Trionix Triad SPECT
			- Siemens Somatom CT, Siemens Magnetom MR, CTI PET
			- Varian CTSIM
			- ACR-NEMA 1.0, ACR-NEMA 2.0, and AAPM/qsh

		- output formats:

			- AAPM/qsh
			- Interfile
			- ADAC Interfile
			- Varian CTSIM
			- DICOM 3.0
			- Vital Images VoxelView
			- Vital Ximatron

		David Reddy                       <--- USA contact
		Radio Logic Inc.
		P.O. Box 9665
		New Haven CT 06536
		phone  (203) 624-8113
		email  reddy@nucmed.med.nyu.edu

		Bartec Medical Systems Ltd.       <--- UK, Europe & Mideast
		Impression House
		Invincible Road
		Farnborough Hampshire
		GU14 7NP England
		email  bob@bartec.demon.co.uk

       - Medical Image Networks - Commercial.

		- Medweb
		667 Folsom Street
		San Francisco CA 94107
		phone  (415) 541-9980
		fax    (415) 541-9984
		http://www.mednet.net
		email  jon@mednet.net

       - Network hardware for PACS/telemedicine/WAN.

		John A. Hansen
		Networks Northwest Inc.
		PO Box 40209
		Bellevue Wa 98015
		phone  (800) 835-9462
		phone  (206) 641-8779
		fax    (206) 641-8909
		email  jahansen@networksnw.com

       - Photoshop Plugins (Commercial) for proprietary, ACR/NEMA and DICOM
       import.

		- ImportACCESS

		http://www.desacc.com

		A commercial Photoshop plugin that works with the many other
		programs that support the plugin format. Reads fixed format
		proprietary formats, and extra modules for ACR-NEMA 2.0,
		DICOM 3.0, Interfile 3.3 files are available. Particularly
		good at multi-slice images and color images, and clearly has
		a nuclear medicine bias to it. Well documented. Recommended.
		Note of potential bias - I was a beta tester.

		Hugh Lyshkow
		DesAcc
		702 Wrightwood Ave.
		Chicago IL 60614
		phone  (312) 404-7888
		fax    (312) 472-8834
		email  daccess@interaccess.com (Hugh Lyshkow)

       - Proprietary format conversion, general:

		Phil Femano
		Medical Imaging Consultants
		phone (201) 812-1122

       - Proprietary format conversion, Nuclear Medicine:

		Medical Imaging Technology Associates
		Ray Deininger
		29 Main Street
		P.O. Box 197
		Mainland PA 19451
		phone (215) 513-0440
		fax   (215) 513-0442
		email  info@mita.com
		email  ray@mita.com

		Images can be read from floppies, tapes, or networks on a PC.
		Import formats include:

		- Elscint SBACK (5.25")
		- Elscint UST   (5.25, 3.5")
		- Elscint RECord (5.25")
		- Gamma11 (5.25")
		- Picker PCS (5.25")
		- GE Starcam/StarII (3.5")
		- GE Plink (5.25, 3.5")
		- NIC (5.35")
		- Interfile (5.25, 3.5")
		- Medasys Paragon (5.25")
		- Siemens Microdelta (5.25")
		- Sophy F83 (5.25, 3.5")
		- Sophy NXT (5.25, 3.5")
		- ADAC (5.25")

		Export formats include:

		- TARGA (.TGA)
		- GIF
		- TIF
		- PCX
		- WPG
		- PICT (MAC)
		- Medvision*
		- Interfile
		- GE Starcam
		- Elscint
		- Siemens
		- Sopha
		- Gamma11

		8" floppy formats (Microtek Conversion Systems include:

		- Technicare
		- GE Star
		- Starcam
		- StarII
		- MDS
		- Toshiba
		- Elscint F1
		- Scintronix
		- Siemens
		- Gamma11
		- NIC
		- Picker PCS

       - Proprietary format conversion, ACR/NEMA (MedVision for Mac and
       Windows):

		Evergreen Technologies
		Jeffrey Siegel
		Main Street, PO Box 795
		Castine  ME 04421
		phone 207-326-8300
		fax   207-326-8333
		email jsiegel@lunis.nucmed.luc.edu
		email 71035.3156@CompuServe.com

		Optical subsystems include:

		- GE Starcam
		- GE CT/MR
		- Siemens CT/MR

		Import formats include:

		- DEFF Ultrasound
		- DICOM
		- Elscint Nuclear
		- GE Starcam
		- GE CT 8800
		- GE CT 9800
		- GE CT HLA/HSA and MR Signa
		- Imatron CT
		- Interfile
		- Picker CT
		- Philips CT
		- Resonex MR
		- Siemens CT and MR
		- Siemens Icon Nuclear
		- Strichman Neuro 900 Nuclear
		- Toshiba Nuclear
		- Trionix Nuclear

		Export formats include:

		- Medvision format
		- ACR/NEMA

		Network capabilites include:

		- GE Starlink Agent
		- DICOM Agent (SCP)

       - Scanners for Xray films.

		Nathan Harris
		DBA Systems Inc.
		phone  (407) 727-0660
		email  nharris@dba-sys.com

		Lumisys

		Cobrascan

		Vidar

		XRS
		email xrs@netcom.com

       - Slides - 35mm - by Internet.

		Submit by ftp, receive by FedEx.

		Interlace Media
		Ernie Nathaniel
		phone  (204) 925-2330
		fax    (204) 261-6806
		email  ernie@interlace.mb.ca
		www    http://www.interlace.mb.ca/interlace/

       - Tape drive vendors - 9-track 1/2 inch.

		Power Computer Services           <--- $750 Qualstar 1054 SCSI
		Bill Power
		1132 Olympic Drive
		Corona CA 91719
		phone 800-323-0694
		phone 909-371-3992
		fax   909-371-1401
		email billp@powercomp.com (Bill Power)

		Bill is also working on an 9-track interface replacement
		to record on removable hard disk cartridges, to upgrade
		old equipment.

       - Tape drive emulators.

		Pertec 9-track interface to DAT, MOD, DICOM
		WORM emulator with MOD

		PBT Technologies
		Larry Martin
		2500 Meridian Parkway
		Suite 106
		Durham, NC  27713
		phone (919) 544-4142
		fax   (919) 544-4585
		email themrtns@ix.netcom.com (Larry Martin)

       - Teleradiology equipment vendors.

		CompuMed Inc.
		Cary Cole
		1200 No El Dorado Pl
		Suite C300
		Tucson AZ 85715
		phone 602-544-0544
		fax   602-722-9096
		email compumed@indirect.com

		Images-On-Call.
		email IOC@ix.netcom.com

       - Video capture vendors

		Precision Digital Images
		6742 185th Ave. NE
		Suite 100
		Redmond, WA  98052
		phone 206-882-0218
		fax   206-867-9177
		email info@precisionimages.com
		http  http://www.precisionimages.com/

       - Viewer vendors for Mac and/or Windows:

		Evergreen Technologies
		(see Proprietary format conversion, ACR/NEMA (MedVision for Mac
		and Windows))

		Includes DICOM C-STORE Provider support.

		MultiView for Macintosh
		Image Data Corp.
		Don Alvarez
		11550 IH-10 West
		San Antonio, TX 78230-1024
		phone (210) 641-8340
		fax   (210) 641-7428

		Alice
		Hayden Image Processing Group
		Boulder, Colorado, USA
		phone (303) 449-3433
		fax   (303) 449-3772
		email help@perceptive.com

		Imaging Solutions
		phone (908) 780-7836
		email mdinkes@delphi.com (Marc Dinkes)

		SiteView (Windows and SunOS 4.x)
		Joe Shapiro
		phone (617) 674-2199
		fax   (617) 674-2217
		email gbb@ConSolve.com
		email joe@ConSolve.com
		demo
		ftp://wuarchive.wustl.edu/graphics/graphics/demo-packages/SiteView
		demo ftp://ftp.cica.indiana.edu/pub/pc/win3/demo/

       - Visible Human CDROM

		Several vendors make various CDROM products containing
		sections from the Visible Human Project.

		- Research Systems Inc
		 email visible@rsinc.com
		 email peter@rsinc.com (Peter Hallett)
		 email denisef@rsinc.com (Denise Fields)

		 These CDs contain 1800+ axial images JPEG compressed,
		 as well as sagittal and coronal reconstructions. A
		 browser (specific to each platform Mac, Windows, Unix,
		 hence different disks) provides access to the images and
		 allows export in TIFF, PICT, GIF, Postscript, EPS,
		 and BMP formats. Each disk costs $495.

		- Expomed Inc
		 email expomed@interramp.com

		 The Visual Man CD contains over 1800 24 bit JPEG compressed
		 cryosection images and a Windows browser. $39.95

    7.5 FTP/WWW sites

       - 3D Reconstruction Sites:

		- http://biocomp.arc.nasa.gov/3dreconstruction

       - 3D Software Sites:

		- http://www.uni-hamburg.de/~medizin/imdm VoxelMan
		- http://www.dsi.unimi.it/Users/imaging/eva.html
		XEVA-VisualStudio
		- See also 3DVIEWNIX
		- See also volume-visualization FAQ

       - 3DVIEWNIX (University of Pennsylvania):

		NB. The new 1.1 version has a different distribution policy
		and complete binary software, rather than just a demo, is
		available from the ftp site.

		- ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/BINARIES
		- ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MPEG_MOVIES
		- ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/DATA
		- ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/PAPERS
		- ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MANUALS
		- ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/SRC
		- ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/TUTORIALS
		- http://mipgsun.mipg.upenn.edu

       - ACR Index of Radiologic Diagnoses (ascii text files):

		- ftp://ftp.xray.hmc.psu.edu/acr_codes
		- http://www.xray.hmc.psu.edu/acr_codes/acr_codes.html

       - AdobePhotoshop Plugins (Public Domain) for ACR/NEMA import (works with
       NIH Image also):

		- ftp://sumex-aim.stanford.edu/info-mac

			- /Graphic/Utility/photoshop-acr-nema.hqx

		- ftp://zippy.nimh.nih.gov/pub/nih-image

			- /plug-ins/ACRNema.hqx Frank Owen
			(owen@sgi.siemens.com)
			- /user-macros/import_ACR_NEMA.txt

       - Anatomy - interactive programs:

		- ftp://ftp.monash.edu.au/pub/medical

       - Anatomy - lung:

		-
		http://indy.radiology.uiowa.edu/Providers/Textbooks/rad/books/LungAnat/LungAnat.html

       - Angiography simulation:

		- ftp://ftp.comp.vuw.ac.nz/pub/graphics/peter/xras.tar.gz
		- http://www.comp.vuw.ac.nz/~peter/

       - Blood flow modelling:

		- georgef@server1.usa (George Foutrakis)
		- http://www.neuronet.pitt.edu/~georgef
		- http://www.pitt.edu/~gnfst1

       -  CT reconstruction software:

		- ftp://peipa.essex.ac.uk/ipa/src/process

			- ct.tar.Z
			- snark77.tar.Z

       - Dermatology sites:

		- http://www.rrze.uni-erlangen.de/

		    - /docs/FAU/fakultaet/med/kli/derma/

       - DICOM Conformance Statement sites:

		-  DICOM Conformance Statement - Applicare.
			http://www.applicare.nl/#DICOM

		-  DICOM Conformance Statement - ATL.
			Not yet available electronically
			jbono@corp.atl.com John Bono

		-  DICOM Conformance Statement - Duke University Image Server.
			ftp://louis1.mc.duke.edu/pub/dicom/doc

		-  DICOM Conformance Statement - General Electric.
			ftp://ftp.med.ge.com/pub/DICOM

			       - Tutorial
			       - Introduction
			       - Advantage Windows
			       - CT HighLight and HighSpeed Advantage
			       - CT Prospeed
			       - MR Signa
			       - MR Vectra

		-  DICOM Conformance Statement - Index.
			http://www.xray.hmc.psu.edu/dicom/dicom_home.html

		-  DICOM Conformance Statement - Intech - HiCube.
			http://www.dada.it/intech/hicube/diccons.html

		-  DICOM Conformance Statement - Intech - XFRAME.
			http://www.dada.it/intech/xframe/home.html

		-  DICOM Conformance Statement - ISG.
			http://www.isgtec.com/dicom.htm

		-  DICOM Conformance Statement - Loral.
			http://www.xray.hmc.psu.edu/dicom/loral_cs/loral_cs.html

		-  DICOM Conformance Statement - Philips.
			http://www.philips.com/ms/connectivity/index_en.html
			ftp://ftp.xray.hmc.psu.edu/dicom_docs/conformance_stmnts/philips
			dicom@ms.philips.nl

		-  DICOM Conformance Statement - Picker.

			http://www.picker.com/

			- NM Odyssey (HTML)
			- CT IQ and PQ scanners (Postscript)
			- Voxel Q/AqQSim 3.11 (Postscript)
			- Voxel Q/AqQSim 3.2 (Postscript)
			- MR Edge/Vista/Asset (HTML)
			- Vistar (HTML)

		-  DICOM Conformance Statement - Siemens.
			http://www.siemens.de/med/dicom/dicom.html
			dicom@ErlH.Siemens.DE

		-  DICOM Conformance Statement - Survey.
			http://www.rahul.net/dclunie/dicom-conformance/survey.html

		-  DICOM Conformance Statement - UCDMC.
			http://www-radiology.ucdmc.ucdavis.edu/pacs/MCONF.html

       - DICOM conversion tools (from proprietary formats) and utilities:

		- dicom3tools_*.tar.gz

			- ftp://ftp.rahul.net/pub/dclunie/dicom3tools/
			- http://www.rahul.net/dclunie/dicom3tools/

		- Tools and libraries for handling offline files.
		- Conversion from proprietary formats.
		- Can handle older ACR/NEMA format data.
		- Can handle SPI.
		- VERY limited X display capability.
		- No DICOM networking (yet).
		- Features.

			- Proprietary image conversions from ...

				- GE CT 9800
				- GE CT High Speed Advantage (Genesis)
				- GE MR Signa 3X/4X
				- GE MR Signa 5X (Genesis)
				- GE CT Sytec
				- GE CT Pace
				- GE MR Max
				- Siemens CT Somatom DR family
				- Siemens CT Somatom Plus family (SPI)
				- Siemens MR Magnetom Impact     (SPI)
				- Siemens MR Magnetom SP         (SPI)
				- Siemens MR Magnetom GBS/GBS2   (native)
				- Siemens MR Vision              (native)
				- Philips MR Gyroscan S5         (native,SPI)

			- Image format support ...

				- DICOM 3 offline file format (draft Part 10).
				- Parsing/validate DICOM modules and IODs.
				- Pbmplus extended 16 bit raw format.
				- Raw binary images.

			- Archive retrieval from ...

				- Generic extract 9-track and DAT.
				- GE CT 9800 9-track.
				- GE Genesis DAT.
				- Philips Gyroscan MR S5 ANSI tapes.

			- Miscellaneous image format utilities ...

				- Dump.
				- Patch.
				- Swap bytes.
				- Word to byte shift.
				- Extract 12 bit packed data.
				- Guess unknown image parameters.
				- Vax VMS DUMP output to binary.

       -  DICOM data dictionary:

		- From NIH ftp://zippy.nimh.nih.gov/pub/nih-image

			- /documents/dicom-dict.txt

		- In dicom3tools_*.tar.gz

			- ftp://ftp.rahul.net/pub/dclunie
			- http://www.rahul.net/dclunie

       - DICOM Directory of Resources:

	       - http://www.merge.com/subpage/DICOM.html

       - DICOM draft standards:

	       - ftp://ftp.xray.hmc.psu.edu/dicom_docs
	       - ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_docs

	- DICOM image samples:

	       - ftp://wuerlim.wustl.edu/pub/dicom/images/version3
	       - ftp://ftp.med.ge.com/pub/DICOM
	       - http://www.xray.hmc.psu.edu/public/med_img_dbs.html
	       - http://www.zki.uni-frankfurt.de/disc95/

       - DICOM Interfile Conversion Software - IDICON:

	       - http://www.inf.u-szeged.hu/~idicon/

       - DICOM Public Servers:

	       - UC Davis MC  Public PACS:

			- http://www-radiology.ucdmc.ucdavis.edu/pacs/PPP.html
			- information about the service
			- dicom://ppacs@mh_nt1.ucdmc.ucdavis.edu:104 - the
			server itself
			- Host is mh_nt1.ucdmc.ucdavis.edu (152.79.46.101)
			- Port is the standard well-known DICOM TCP port 104
			- Application Entity Title is "ppacs"
			- The server is promiscuous and will respond to any
			Calling AE Title,
			 but to target a C-Move you need to register your own
			 AE Title and
			 IP address and port number in order to receive images.
			 To do this
			 contact mhoskin@ucdavis.edu.
			- The UCDMC Public PACS acts as an SCP for the
			following SOP Classes:

				- Verification 1.2.840.10008.1.1
				- Study Root Retrieve/FIND
				1.2.840.10008.5.1.4.1.2.2.1
				- Study Root Retrieve/MOVE
				1.2.840.10008.5.1.4.1.2.2.2
				- Computed Radiography Storage
				1.2.840.100008.5.1.4.1.1
				- CT Image Storage 1.2.840.10008.5.1.4.1.1.2
				- Ultrasound Multi-frame Image Storage
				1.2.840.10008.5.1.4.1.1.3
				- MR Image Storage 1.2.840.10008.5.1.4.1.1.4
				- Nuclear Medicine Image Storage
				1.2.840.10008.5.1.4.1.1.5
				- Ultrasound Image Storage
				1.2.840.10008.5.1.4.1.1.6
				- Secondary Capture Image Storage
				1.2.840.10008.5.1.4.1.1.7

       - DICOM resources at Medx:

	       - http://topaz.sensor.com/work/fmt/dicom

       - DICOM resources in Chile:

		- http://www.dicom.cl

       - DICOM resources at Santel:

		- http://www.santel.lu/SANTEL/imgrel/imagproc.html

	- DICOM software - BMP conversion:

		- ftp://ftp.xray.hmc.psu.edu/dicom_software/dicombmp.zip

	- DICOM software - Cardiology:

		Lossless JPEG software for American College of Cardiology
		Digital Interchange Standards for Cardiology CD-R demo.
		From Brown University Institute for Medical Computing.

		- ftp://ftp.xray.hmc.psu.edu/dicom_software/Brown
		- Jonathan_Elion@brown.edu Jon Elion

	- DICOM software - Medx:

		DICOM dump utility.

		- http://topaz.sensor.com/links/mg/props/dicom

       - DICOM software - RSNA Central Test Node:

		 Contact  Steve Moore smm@wuerl.wustl.edu

		- ftp://wuerlim.wustl.edu/pub/dicom

		- ftp://ftp.xray.hmc.psu.edu/dicom_software

			- /Mallinckrodt
			 Mallinkrodt RSNA
			- /European
			 European CEN/TC251/WG4

		- ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_software

		- Linux port of Mallinckrodt CTN software

			- From ftp://ss10.numed.szote.u-szeged.hu/pub/MIR-CTN/

			    - Modified sources /Linux/CTN.Linux.tar.Z
			    - Compiled binaries /Linux/CTN.Linux.bin.tar.Z

			- Ported by boti@ss10.numed.szote.u-szeged.hu

	- DICOM software - UC Davis Medical Center:

		Binary libraries for Unix(various) and Windows/NT,
		written in C++, well documented, no royalties,
		supports Storage,Query/Retrieve for most objects.

		- ftp://imrad.ucdmc.ucdavis.edu/pub/dicom/UCDMC
		- http://www-radiology.ucdmc.ucdavis.edu/intro/radhome.html
		- http://www-radiology.ucdmc.ucdavis.edu/pacs/MCONF.html
		COnformance Statement
		- mhoskin@ucdavis.edu Mark Oskin
		- rlkennedy@ucdavis.edu R.L. Kennedy

       - DICOM Ultrasound/Echocardiography - ICMIT:

	       - International Consortium for Medical Imaging Technology
	       - http://dominica.ee.ic.ac.uk/ICMIT/ICMIT.html
	       - s.claesen@ic.ac.uk Stefan Claesen

       - DICOM WWW gateway:

	       - http://foyt.indyrad.iupui.edu/medres/iurad2.htmlSample gateway
	       - ftp://foyt.indyrad.iupui.edu/pubImplementation
	       - gcbrowni@foyt.indyrad.iupui.edu Grover Browning

       - Dr Razz - image viewer for MAC:

		- ftp://ftp.u.washington.edu/pub/user-supported/razz
		- ftp://ftp.u.washington.edu/public/razz
		- http://www.rad.washington.edu/

		The author (Thurman Gillespy tg3@u.washington.edu) writes:

		Dr Razz is a 16 bit medical image display and analysis
		program for Macintosh computers. Dr Razz can window and
		level on full 16 bit image data in near real time on any
		Macintosh color computer. Images can be viewed individually,
		or an image series can be viewed in an image stack. The
		program attempts to automatically open CT and MRI images,
		and can usually handle different header sizes and byte order.
		The program can directly read the headers of images created
		with the GE Image Extract Tool, and can automatically handle
		compressed images created with this utility. Dr Razz is not a
		DICOM viewer, although it can probably automatically open many
		CT/MRI DICOM images if they are not compressed. An option for
		manually entering image parameters for problem files is
		available. Images can be saved as PICT files, and TIFF support
		will be added.

       - FITS - Flexible Image Transport System - for astronomical data:

		- ftp://fits.cv.nrao.edu/fits
		- ftp://nssdca.gsfc.nasa.gov/FITS
		- http://hdf.ncsa.uiuc.edu:4321/fits/ FITS Browser

       - Graphics file formats (gif,tiff,etc.)

		- ftp://zamenhof.cs.rice.edu/pub/graphics.formats
		- http://sunsite.unc.edu/boutell/png.html Portable Network
		Graphics format (PNG)

       - Hierarchical Database Management System (astronomy images):

		- ftp://starlink-ftp.rl.ac.uk/pub/doc/star-docs/sun92.tex
		- http://star-www.rl.ac.uk/

       - Hospital News:

		- http://www.gate.net/hospital-news/

       - Image guided surgery:

		- http://igs.slu.edu/
		-
		http://www.cc.gatech.edu/gvu/medical_informatics/research/surg_sim.html
		- http://www.mni.mcgill.ca/demos/neurosurgery
		- http://cranium.unibe.ch/cas/

       - Image utilities - miscellaneous:

		- ftp://oak.oakland.edu/pub3/simtel/win3/graphics/IMA20A.ZIP

       - Images - digitized mammograms - sites:

		- miasdb@icr.ac.uk (J.Suckling) (Normal and abnormal)
		- ftp://ftp.xray.hmc.psu.edu/mammo (10 Normal)
		- http://www.xray.hmc.psu.edu/
		- http://cancer.med.upenn.edu/

       - Images - medical - sites (may be out of date):

		- ftp://fokus.uke.uni-hamburg.de/.voxelman.images
		- ftp://rwja.umdnj.edu/pub
		- gopher://gopher.austin.unimelb.edu.au/11/images/petimages/
		- ftp.nihon-u.ac.jp/pub/data/MRIMonkeyHead
		- http://ftp.nc.nihon-u.ac.jp/pub/data/MRIMonkeyHead
		- ftp://decaf.stanford.edu/pub/images/medical/mri
		- ftp://eedsp.gatech.edu/database/images/wchung/medical
		- ftp://omicron.cs.unc.edu/pub/softlab/CHVRTD
		- http://foyt.indyrad.iupui.edu/medres/iurad2.html
		- ftp://ccsun.unicamp.br
		- ftp://boris.umds.ac.uk/pub/images
		- http://www-ipg.umds.ac.uk/
		- http://www.stjosephs.london.on.ca/~jd
		- http://www.santel.lu/SANTEL/imgrel/imagproc.html
		- http://chaos.uh.cwru.edu/uhweb1.html
		- http://pss023.psi.ch/
		- http://visual-ra.swmed.edu
		- http://www.rad.upenn.edu/rundle/InteractiveKnee.html
		- http://www.ge.com/crd/ivl/three_dim_medical.html
		- ftp://ftp.med.ge.com/pub/DICOM/IMAGES
		- ftp://wuerlim.wustl.edu/pub/dicom/images/
		- gopher://mirage.umdnj.edu:70/1/Radiology_Images

       - Interfile sources -  see Nucmed ftp site at UWO.

       - JPEG Sources

	       - PVRG-JPEG CODEC:

		ftp://havefun.stanford.edu/pub/jpeg

			Supports

			  - sequential DCT baseline,
			  - lossless modes.

		- IJG:

		 ftp.uu.net/graphics/jpeg

			Supports

			  - sequential DCT baseline,
			  - 12 bit DCT modes.
			  - progressive modes.

       - Kermit distribution:

		- ftp://ftp.cc.columbia.edu/kermit

       - LUNIS - Loyola University Nuclear Medicine Information System

		- http://147.126.104.3/

		contact jhalama@lunis.nucmed.luc.edu (Jim Halama) for
		access, which is restricted ((708) 216-3777)

       - Magnetic Resonance Spectroscopy Resources:

		- http://members.aol.com/albrightmj
		- http://www.nmr.utmb.edu/#mrass

       - Medical Clip Art sites:

		- http://www.mindspring.com/~mperloe/gallery.html
		- ftp://goofy.cs.umd.edu/f/clipart/medical

       - Medical imaging research - University of Leeds:

		- http://agora.leeds.ac.uk/comir/comir.html

	- Medical imaging resources - Japanese site:

		- Images and tools, including DICOM, Osiris, NIH Image.
		- ftp://ftp.kurume-it.ac.jp/.kenchan/ftp/pub/

       - Medical Informatics standards, including HL7 standards:

		- ftp://dumccss.mc.duke.edu/standards

			- read-me.txt
			- HL7/pubs/version2.2/ballot1.zip

       - Medical Resources - Miscellaneous:

		-
		http://kuhttp.cc.ukans.edu/cwis/units/medcntr/Lee/HOMEPAGE.HTML
		Medical Matrix
		- http://golgi.harvard.edu/biopages/medicine.html Virtual
		Library of Medicine
		- http://critcare.vichosp.london.on.ca Critical Care
		- http://world-health.net/ World Health Net
		- http://www.li.net/~edhayes/ed.html
		- http://enuxsa.eas.asu.edu/~wilkins Radiology links
		- http://www.netins.net/showcase/eri/ Electronic Resources

       - Multimedia Medical Reference Library:

		- http://www.tiac.net/users/jtward/index.html

       - Neuroscience Resources List:

		- http://golgi.harvard.edu/biopages/neuro.html

       - NIH Image - Macintosh image processing software:

		- ftp://zippy.nimh.nih.gov/pub/nih-image

       - Nucmed ftp site at UWO (run by Trevor Cradduck (cradduck@uwo.ca)):

		- ftp://uwovax.uwo.ca/PUB:[000000.NUCMED]

       - Orthopaedic Biomechanics

		- http://cranium.unibe.ch/ Maurice E. Muller Institute

       - PACS - EurIPACS:

		- http://www.rad.unipi.it:7080/

		    - /works/imphone/presentation-imphone.html

       - Papyrus and Osiris ftp site:

		- ftp://expasy.hcuge.ch/pub/Osiris

			- Papyrus specifications for versions 2.1 and 3.
			- Osiris for Mac, PC and Unix (SunOS, Solaris, Dec).
			- Sample images for Dicom, Papyrus 2 and Papyrus 2.

		- http://expasy.hcuge.ch/www/UIN/UIN.html

       - Pathology sites:

		- http://www.uniud.it/drmm/drmmeng.html
		- http://www.uniud.it/drmm/anpat/gallery/pathpuzzle.html
		- http://www.osaka-med.ac.jp/omc-lib/path.html
		- http://www.med.uiuc.edu/titlePage.html
		- http://www.flightpath.com/Clients/Pisces/pdchome.htm
		- http://www.med.nagoya-u.ac.jp/pathy/pathy.html
		- http://www.bocklabs.wisc.edu/
		- http://www.derby.ac.uk
		- http://www.ets.bris.ac.uk/mru.htm
		- http://www.bgsm.wfu.edu/
		- http://www-medlib.med.utah.edu/sol.htm
		- http://www-medlib.med.utah.edu/WebPath/webpath.html
		- http://pandoras-box.bgsm.edu/
		- http://rmc-www.lbl.gov/
		- http://bsd.meddean.luc.edu/lumen/
		-
		gopher://caldmed.med.miami.edu:70/11/.gopher/discipline/Discipline-Specific
		Sources/Pathology
		- gopher://gopher.med.cornell.edu:70/1/Medical College/Images
		-
		gopher://gopher.rz.uni-karlsruhe.de:70/7waissrc:/zent/rz/netz/spez/WAIS/r/RPMS-pathology.src
		- gopher://mirage.umdnj.edu:70/1/Pathology_Images
		- http://128.196.106.42/ahsc-res.html
		- http://192.93.247.18/
		- http://count51.med.harvard.edu/AANLIB/home.html
		- http://count51.med.harvard.edu/BWH/BRADHome.html
		- http://indy.radiology.uiowa.edu/VirtualHospital.html
		- http://info.med.yale.edu/caim/C_HOME.HTML

       - Penn State Radiology Web Server:

		- http://www.xray.hmc.psu.edu/

       - PET Sites:

		- http://www-ipg.umds.ac.uk/pet/petcen.html
		- http://members.aol.com/albrightmj
		- http://www.nuc.ucla.edu/html_docs/crump/lpp.html
		- http://www.nucmed.buffalo.edu/cpethm.htm

       - Physics Sites:

		- http://www.physics.mcgill.ca/physics-services/
		- http://tph.tuwien.ac.at/physics-services/

       - Qsh ftp site:

		- ftp://nucmed.med.nyu.edu/pub

			- /dist
				 compressed tar
			- /qsh
				 source

       - Radiological Society of North America - On-Line Sources:

		 This site is strongly recommended and has more points
		 to jump to than you could possibly imagine !!!

		- http://www.rsna.org
		- http://www.rsna.org/edu/internet.html

       - Radiology History:

		- http://www.fh-wuerzburg.de/roentgen/

       - Teaching File - Index:

		- http://www.xray.hmc.psu.edu/public/tf.html

       - Teaching File - University of Washington:

		Run by mrich@u.washington.edu

		- http://www.rad.washington.edu/

		1.  Radiology Teaching File (CME credit)
		2.  Anatomy Teaching Modules
		3.  Radiology Exhibits from UW
		4.  Information on UW radiology residency/fellowship programs
		5.  Image processing software written by UW faculty

       - Teaching File - University of Western Ontario:

		- http://johns.largnet.uwo.ca

       - Telemedicine - DOD server

		- http://ftdetrck-matmoweb.army.mil/

       - TIFF Specification Source- Tagged Image File Format:

		-
		gopher://palimpsest.stanford.edu:70/00/ByTopic/standards/tiff.5.0.txt
		TIFF 5.0
		- ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.Z TIFF 6.0
		- http://www.adobe.com/PDFs/TN/TIFF6.pdf
		- http://www-mipl.jpl.nasa.gov/~ndr/tiff/index.html Unofficial
		TIFF Home Page

       - University of North Carolina SoftLab /usr/image package:

		- ftp://ftp.cs.unc.edu/pub/projects/softlab/image/product/

       - Vax help - "The Vax Book" by Joseph E St Sauver, U of Oregon:

		- ftp://decoy.uoregon.edu/pub/vaxbook/

       - Virtual Hospital - University Of Iowa:

		-
		http://indy.radiology.uiowa.edu/Providers/ProviderDept/InfoByDept.Rad.html
		radiology
		- http://everest.radiology.uiowa.edu/image.html imaging
		resource links

       - Visible Human Project

		- http://www.nlm.nih.gov/

		    - /factsheets.dir/visible_human.html
		    - /extramural_research.dir/visible_gallery.html

		Dr. Michael J. Ackerman
		Project Officer, Visible Human Project
		National Library of Medicine
		8600 Rockville Pike
		Bethesda, MD 20894

		Need to sign an agreement with the NLM before one can
		transfer the 15 GB of data or buy tapes.

		Tape can be purchased from NTIS (301) 402-4100 in Unix
		tar format for $1000.

		See also Visible Human CDROM

       - Visible Human Project - Experiments

		- http://www.ge.com/crd/ivl/vm/vm.html CT 3D Visible Man
		- http://aperture.stanford.edu/~lorensen/vw/vw.html CT 3D
		Visible Woman

       - Wavelet compression software:

		- ftp://pascal.math.yale.edu/pub/wavelets

       - Web Delivered Telemedicine and PACS:

		- http://www.mco.edu/iarc/telemed.html

       -  Window level software (12/16 bits ->8):

		- ftp://alvin.ach.uams.edu/pub/winlev.tar.Z (Includes images)
		- ftp://alvin.ach.uams.edu/pub/winlev-noimages.tar.gz

       - Wxwin software:

		- ftp://skye.aiai.ed.ac.uk/pub/wxwin

       - Xsee - X-windows based display program for raw images:

		- available from Stefan Thurnhofer thurn@amadeus.ece.ucsb.edu

The next part is part8 - information sources (continued).


Archive-name: medical-image-faq/part8
Posting-Frequency: monthly
Last-modified: Tue Jan 30 15:51:53 1996
Version: 2.11

    7.6 Mailservers

	- FAQ about email access to internet services:

		To find out more, fetch the relevant FAQ from the mailserver
		at "mail-server@rtfm.mit.edu" with a message body:

			send
			usenet/news.answers/internet-services/access-via-email

		Or ftp it from
		"ftp://rtfm.mit.edu/pub/news.answers/internet-services/access-via-email"

      - Ftpmail:

		Ftpmail is a service provided by some extremely generous
		sites that allow you to send ftp commands to them by email
		and the server executes the commands and sends the results
		back. Very few sites offer this because of the huge load
		and potential for abuse. I only mention it here because a
		lot of medical imaging people don't seem to have anonymous
		ftp access.

		To find out more, fetch the relevant FAQ from the mailserver
		at "mail-server@rtfm.mit.edu" with a message body:

			send usenet/news.answers/ftp-list/faq

		The most commonly used site is "ftpmail@decwrl.dec.com" (send
		"help" (no quotes) in the message body).

       - HSPNET-L Hospital Computer Network Discussion Group and Data Base:

		Run by Don Parsons dfp10%albnydh2.bitnet@uacsc2.albany.edu.

		- To subscribe:

			To: listserv%albnydh2.bitnet@uacsc2.albany.edu
			Subject:
			SUBSCRIBE HSPNET-L your_full_name

		- For the monthly digest:

			To: listserv%albnydh2.bitnet@uacsc2.albany.edu
			Subject:
			AFD ADD HSP* DIGEST HSPNET-L

		- To contribute (if subscribed):

			To: hspnet-l%albnydh2.bitnet@uacsc2.albany.edu

		- To download from the LISTSERV Database:

			To: listserv%albnydh2.bitnet@uacsc2.albany.edu
			Subject:
			INDEX HSPNET-L
			GET <filename> <filetype>

		HSPNET-L is mirrored by "sci.med.telemedicine" Usenet
		newsgroup.

       - Interfile mailing list:

		Don't know much about this list, but I am sure that
		atoddpok@medphys.ucl.ac.uk (Andrew Todd-Pokropek) would
		be able to fill you in on this.

       - ldicom mailing list for dicom3tools users:

		- to subscribe:          ldicom-subscribe@flash.us.com
		- to unsubscribe, etc.:  ldicom-unsubscribe@flash.us.com
		- to send to list:       ldicom@flash.us.com
		- the relevant human:    ldicom-admin@flash.us.com

       - Nucmed mailing list for medical physicists:

		- to subscribe:          nucmed-request@irus.rri.uwo.ca
		- to unsubscribe, etc.:  nucmed-owner@irus.rri.uwo.ca
		- to send to list:       nucmed@uwo.ca
		- the relevant human:    cradduck@uwo.ca (Trevor Cradduck)

		This list is not actually gated to "sci.med.physics",
		though Trevor often reposts significant items.

		See also Nucmed ftp site at UWO.

       - Radiation Safety Distribution list - RADSAFE:

		For Health Physicists, Medical Physicists, Radiological
		Engineers and others who have a professional interest in
		matters related to Radiation Protection.

		pet_mail-REQUEST@ncbapsun2.pet.wfu.edu

		Put request key word (help, subscribe, unsubscribe) in the
		body of the message, not the subject line.

       - PET Mail mailing list - Positron Emission Tomography:

		For Health Physicists, Medical Physicists, Radiological
		Engineers and others who have a professional interest in
		matters related to Radiation Protection.

		RADSAFE@romulus.ehs.uiuc.edu

       - Radiologic Science Discussion Group - Radsci-L:

		 Discussion may choose to center around radiologic science
		 education, medical radiography, CT (computerized scanning),
		 MRI (magnetic resonance scanning), sonography, nuclear
		 medicine, radiation oncology, veterinary medicine, industrial
		 applications, radiologic patient care, etc.

		- command address:   mailserv@western.tec.wi.us
		- commands:          in message body not subject
		- list name:         Radsci-L
		- to subscribe:      subscribe Radsci-L firstname lastname
				    (NB. not your email address, that is
				     derived from the 'From ' header line)

       - sci.med.radiology gateway:

		sci.med.radiology@news.cs.indiana.edu

    7.7 References

       - DICOM Publications - General:

		Kodak "Understanding DICOM 3.0" catalog # 1787928, $US 15.00

		Ed Weaver
		Kodak Health Imaging Systems
		18325 Waterview Parkway
		Dallas TX 75252
		phone 1-800-767-3448
		phone 1-214-454-1506
		email eweaver@khis.kodak.com

		Kodak Distribution Center (credit cards)
		phone 1-800-233-1650

       - DICOM Publications - Implementation:

		"Implementation of the DICOM 3.0 Standard - A Pragmatic
		Handbook"
		Robert Hindel, Editor

		RH Consulting
		483 Ridge Road
		Orange CT 06477-2830
		phone 203-799-2258
		fax   203-795-8640
		email 73030.1366@compuserve.com (Robert Hindel)

		Radiological Society of North America
		2021 Spring Road Suite 600
		Oak Brook IL 60521

       - DICOM Publications - Resource Directories:

		"DICOM Tools for End User Applications and System Integration"
		Presented at EuroPACS'94 Geneva Switzerland
		Dwight Simon

		Merge Technologies Inc.
		1126 S. 70th St. Suite N508B
		Milwaukee, Wisconsin 53214-3151
		phone 414-475-4300
		fax   414-475-3940
		email dwight@merge.com (Dwight Simon)

       - PACS Publications:

		Understanding PACS:Picture Archiving & Communications Systems

		available for $5 from SCAR - Society for Computer Applications
		in Radiology:

       - Telemedicine Publications:

		Rural TeleHealth:Telemedicine,Distance Education &
		Informatics for Rural Health Care, A Report of the Office
		of Rural Health Policy Health Resources and Services
		Administration, DHSS (Nov,1993)

		available for $8 from:

			WICHE Publications
			Western Interstate Commission for Higher Education
			P.O. Drawer P
			Boulder, CO  80301-9752
			phone (303) 541-0290
			fax   (303) 541-0291

       - Wavelet compression publications:

		Press, et al. Numerical Recipes in C.
		Chapter 13.10. Wavelet Transforms.

		Cody,MA. The Wavelet Packet Transform.
		Dr. Dobb's Journal, April '94

    7.8 Organizations, Societies and Journals

       - Association of Students of the Radiologic Sciences

		http://enuxsa.eas.asu.edu/~wilkins/asrs.html

       - IEEE Transactions on Medical Imaging

		Mike Vannier
		Mallinckrodt Institute of Radiology
		Washington University Medical Center
		510 South Kingshighway Blvd.
		St. Louis, MO 63110

       - SCAR - Society for Computer Applications in Radiology

		4750 Lindle Road,
		P.O. Box 8800
		Harrisburg, PA 17105-8800
		phone 717-561-5266
		fax   717-561-5360
		email 73531.1173@compuserve.com
		email tg3@u.washington.edu (Thurman Gillespy).

	       - Web server is at http://www.scar.rad.washington.edu/

	       - Official journal is the "Journal of Digital Imaging".

	       - Last meeting was S/CAR'94 held in Winston-Salem,
		North Carolina during June 1994.

	       - (membership is considered mandatory for FAQ readers :) )

    7.9 Usenet Newsgroups

       - alt.graphics.pixutils
       - alt.image.medical
       - alt.med.equipment
       - comp.graphics
       - comp.graphics.algorithms
       - comp.graphics.pixutils
       - comp.graphics.research
       - comp.protocols.dicom
       - sci.data.formats
       - sci.med.emergency
       - sci.med.informatics
       - sci.med.physics
       - sci.med.radiology
       - sci.med.telemedicine
       - sci.med.vision

8.  Acknowledgements

    Thanks to the many people for contributions, general help, interesting
    postings or mail whose contents have found there way in here, or just plain
    old moral support. They used to be listed by name and email address here,
    but the list was getting so long and difficult to update that it got out of
    hand and has been retired !

The next part is index by keyword.

