ftp.pasteur.org/FAQ/

home *** CD-ROM | disk | FTP | other *** search

/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / medical-image-faq / part4 < prev next >

Wrap

Internet Message Format | 2003-12-22 | 51.9 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.rediris.es!irazu.switch.ch!switch.ch!tiscali!newsfeed1.ip.tiscali.net!newshosting.com!news-xfer1.atl.newshosting.com!diablo.voicenet.com!news2.epix.net!news1.epix.net!dclunie.com Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,alt.answers,comp.answers,sci.answers,news.answers Message-ID: <20031221091625.3015.4@dclunie.com> Expires: 21 Jan 2004 00:00:00 GMT Subject: Medical Image Format FAQ, Part 4/8 From: dclunie@dclunie.com (David A. Clunie) Followup-To: alt.image.medical Reply-To: dclunie@dclunie.com (David A. Clunie) Approved: news-answers-request@MIT.EDU 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. Lines: 1248 Date: Sun, 21 Dec 2003 14:16:42 GMT NNTP-Posting-Host: 216.37.230.197 X-Complaints-To: abuse@epix.net X-Trace: news1.epix.net 1072016202 216.37.230.197 (Sun, 21 Dec 2003 09:16:42 EST) NNTP-Posting-Date: Sun, 21 Dec 2003 09:16:42 EST Xref: senator-bedfellow.mit.edu alt.image.medical:12457 comp.protocols.dicom:11713 sci.data.formats:3062 alt.answers:70771 comp.answers:55776 sci.answers:15697 news.answers:263502 Archive-name: medical-image-faq/part4 Posting-Frequency: monthly Last-modified: Sun Dec 21 09:16:41 EST 2003 Version: 4.26 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 - 3A - 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 uS word 86 - Real - TE uS word 88 - Real - TI uS word 98 - Int - Number of echos word 99 - Int - Echo number word 101 - Int - NEX (if not fractional) word 146 - Real - NEX word 175 - 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 -s -t % 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 - common to CT and MR: 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 58 - char[14] - pixel data ID 72 - char[17] - iv contrast agent 89 - char[17] - oral contrast agent 126 - float - image location 130 - float - image centre R mm (ie. X +ve to right) 134 - float - image centre A mm (ie. Y +ve to anterior) 138 - float - image centre S mm (ie. Z +ve to superior) 154 - float - image TLHC R mm (ie. X +ve to right) 158 - float - image TLHC A mm (ie. Y +ve to anterior) 162 - float - image TLHC S mm (ie. Z +ve to superior) 166 - float - image TRHC R mm (ie. X +ve to right) 170 - float - image TRHC A mm (ie. Y +ve to anterior) 174 - float - image TRHC S mm (ie. Z +ve to superior) 178 - float - image BRHC R mm (ie. X +ve to right) 182 - float - image BRHC A mm (ie. Y +ve to anterior) 186 - float - image BRHC S mm (ie. Z +ve to superior) image header - for MR (1022 bytes long): 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] OrientationSet1Top 3884 char[3] OrientationSet1Left 3888 char[3] OrientationSet1Back 3892 char[3] OrientationSet2Down 3896 char[3] OrientationSet2Right 3900 char[3] OrientationSet2Front 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 The following information pertains to Revision 3 of the Shimadzu MRI format. The new Revision 4 doesn't change this apparently. - words are big endian - fixed layout header - standard 512 bytes - extended 2048 bytes (1st 512 same) - extended indicated by high byte of ZHREV non-zero - 16 bit uncompressed image pixel data - starting block of image pixel data is ZIBLKA (from 1) - multiple images per file, number specified in ZIMAGE - offset to image pixel data specified by index after header - each index entry is 48 bytes for standard - each index entry is 256 bytes for extended - starting block for image added to ZIBLKA is - int16 at byte 30 (from 0) of entry (standard) - int16 at byte 50 + (int16 at byte 52 << 16) (extended) (NB. Not the same at big-endian int32 at byte 50) - physical location of each slice is encoded in - ZSLOC slice Location - ZSLOC int16 at byte offset 8 (from 0) of index entry - ZSLOC is relative to isocenter (same units as ZCLOC) - elapsed time of each slice is encoded in - ZPTIM1 int16 at byte offset 6 (from 0) of index entry - ZPTIM1 units are seconds since first slice - field of view - ZVIEW give the real field of view in mm*10 units - better than the mnemonic code in the ZAAREA field The following information pertains to Revision 3 of the Shimadzu MRI format. The new Revision 4 doesn't change this apparently. The offsets are specified in both bytes from 0 and words from 1 (the Shimadzu convention). Standard Header or 1st 512 bytes of Extended Header: Offset Offset Type Keyword Description Units Example (Bytes) (Words) 0 1 char 8 ZASYSID SYS-ID 8 5 char 16 ZANAME NAME 24 13 char 12 ZAID ID 36 19 char 2 ZASEX SEX "M ","F " 38 20 char 4 ZAAGE AGE years 42 22 char 20 ZACOMM COMMENT 62 32 char 18 ZAHOSP HOSPITAL 80 41 char 8 ZADATW DATE "YY-MM-DD" 88 45 char 8 ZATIME TIME "HH:MM:SS" 96 49 char 8 ZAAREA Zoom Size/NSlices "1.0 S/10" ES = 100mm VS = 150mm SS = 200mm S = 250mm M = 300mm L = 350mm LL = 400mm 104 53 char 8 ZASEQ TYPE/MODE "IR/256" where 256 is Max(Nx,Ny) IR = Inversion Recovery SE = Spin Echo FE = Field Echo 112 57 char 8 ZATR TR mS "TR=1500" 120 61 char 8 ZATE TE mS "TE=150" 128 65 char 8 ZATI TI mS "TI=200" 136 69 char 8 ZALOK LOCATION MM "OM+125","CN+50" 144 73 char 8 ZAECG ECG ? "ECG=100" 152 77 char 6 ZADIRL Left side of image "RIGHT","LEFT","ANTR","POSTR","HEAD","FEET" 158 80 char 6 ZADIRB Bottom side of image "RIGHT","LEFT","ANTR","POSTR","HEAD","FEET" 164 83 char 4 ZATCS "TRN","COR",'SAG" 168 85 char 8 ZAMTE Interslice rest ms "MTE=50" 176 89 char 6 ZAPIT Interslice skip mm "PT=10" 182 92 char 8 ZAFLIP FLIP ANGLE DEGREES "FLIP=90" 190 96 char 8 ZAENCD ENCODE % "ECD=80%" 198 100 char 6 ZADIREP "(P,F)" OR "(F,P)" 204 103 char 8 ZANSEQ Sequence Name 212 107 char 8 ZAMATER1 SYSTEM-ID 1 220 111 char 8 ZAMATER2 SYSTEM-ID 2 228 115 char 8 ZAMATER3 SYSTEM-ID 3 236 119 char 2 ZASITE 238 120 char 8 AVERAGE "NEX=2" 246 124 char 2 ZADIRL2 Left direction "RT","LT","HD","FT","DO","AN" 248 125 char 2 ZADIRB2 Down direction "RT","LT","HD","FT","DO","AN" 250 126 char 6 SCAN (?) 256 129 int16 ZMAGN 5000 258 130 int16 ZSCSW 1-199 260 131 int16 ZIMAGE Images in series 262 132 int16 ZSLICE 264 133 int16 ZECHO 1,2,4 266 134 int16 ZXSIZE columns 268 135 int16 ZYSIZE rows 270 136 int16 ZTBLK 272 137 int16 ZNEGSW Even line DC neg 0=No,1=Yes 274 138 int16 ZFTYPE 0,1,2,3=1+2 276 139 int16 ZCALB Max 0=No,1=Yes 278 140 int16 ZLBLK 280 141 int16 ZRBLK 282 142 int16 ZIBLKA 284 143 int16 ZCOIL 286 144 int16 ZDTYPE 288 145 int16 ZETYPE 290 146 int16 ZKRNL 292 147 int16 ZPTOR1 0=head first,1=feet first 294 148 int16 ZPTOR2 0=supine,1=prone,2=right side down,3=left side down,4=other 296 149 int16 ZLRVS 0=Up,1=Down 298 150 int16 ? 300 151 int16 ZRCDMODE Mode 302 152 int16 ZVDBAND 304 153 int16 ZYSTL 306 154 int16 ZPWGHT 308 155 int16 ZPFUSE RF power ratio % 310 156 char 2 ZSATON "P","H","Na" 312 157 int16 ZSFREQ 10kHz 314 158 int16 ZIMFLT 0=No 316 159 int16 ZSLANT2 192 2 318 160 int16 ZROTPHS Recon 320 161 int16 ZWIDE Slice width *10mm 322 162 int16 ZPITCH Interslice skip *10mm 324 163 int16 ZCLOC Center location *10mm (offset from isocenter in ZDIR direction (SAG L+,COR A+,TRN F+) FOR CENTER OF SERIES) 326 164 int16 ZMAG *100 328 165 int16 ZCNTX X mm 330 166 int16 ZCNTY Y mm 332 167 int16 ZVIEW Actual FOV mm*10 334 168 int16 ZDIR Orientation 1=Trn,2=Cor,3=Sag,6=Non,7=Point 336 169 int16 ZANG1 Alpha *10 degrees (tilt angle of vertical, up-to-down direction relative to base plane (C,S,T)) 338 170 int16 ZANG2 Beta *10 degrees (tilt angle of horizontal, left-to-right direction) 340 171 char 8 ZPSID1 348 175 char 2 ZPSIM1 350 176 char 2 ZPSCR1 352 177 char 8 ZPSID2 360 181 char 2 ZPSIM2 362 182 char 2 ZPSCR2 364 183 int16 ZANG3S system *10 degrees 366 184 int16 ZANG3U user *10 degrees 368 185 int16 ZTILTSW TILT 1=?,2=?,3=Trn,4=Cor 370 186 int16 ZPSOR1 location +/-512 372 187 int16 ZPSOA1 location *10 degrees 374 188 int16 ZPSOR2 location +/-512 376 189 int16 ZPSOA2 location *10 degrees 378 190 int16 ZPSOD1 loc 0-100mm 380 191 int16 ZPSOD2 loc 0-100mm 382 192 int16 ZSLANT orthog=10000 384 193 char 2 ZPMOD IR,SE,FE 386 194 int16 ZTR TR ms 388 195 int16 ZTE TE ms 390 196 int16 ZTI TI ms 392 197 int16 ZNX X Encode 394 198 int16 ZNY Y Encode 396 199 int16 ZXAV X NEX 398 200 int16 ZYAV Y NEX 400 201 int16 ZEAV Echo 402 202 int16 ZSTIM 404 203 char 2 ZCONST 2D,3D 406 204 int16 ZFLIP degrees 408 205 int16 ZRESP 0=No,1=Yes 410 206 int16 ZECG 0=No,1=Yes 412 207 int16 ZDIXON CH-SHFT *10ppm 414 208 int16 ZMTE Interslice rest 416 209 int16 ZHALF 418 210 int16 ZSGNSW 420 211 int16 ZCINE 422 212 int16 ZPKZ 424 213 int16 ZTEALN TE ALIGN 0=In phase,1=Opposed 426 214 int16 ZCSSW Chemical Shift Switch 428 215 int16 ZIMDIR 430 216 int16 ZPSSP1 432 217 int16 ZPSSP2 434 218 int16 ZXWD X Dimension *10mm 436 219 int16 ZXLOC1 *10mm 438 220 int16 ZXLOC2 *10mm 440 221 int16 ZYWD Y Dimension *10mm 442 222 int16 ZYLOC1 *10mm 444 223 int16 ZYLOC2 *10mm 446 224 int16 ZHREV Header Revision 448 225 int16 ZSYSMAG 450 226 int16 ZSCOPT Optional Control 452 227 int16 ZANGIO 0=No,1=Yes 454 228 int16 ? 456 229 int16 ? 458 230 int16 ? 460 231 int16 ZSXADR blk# 462 232 int16 ZSPMOD KSPM 3.3.8 Elscint MR - another black hole The next part is part5 - proprietary other formats.