Subject: Medical Image Format FAQ, Part 2/2 Followup-To: alt.image.medical Date: 8 Jul 199

---
Master Index Current Directory Index Go to SkepticTank Go to Human Rights activist Keith Henson Go to Scientology cult

Skeptic Tank!

Path: bloom-beacon.mit.edu!hookup!swrinde!sgiblab!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,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 2/2 Followup-To: alt.image.medical Date: 8 Jul 1994 10:50:36 +0300 Organization: Her Master's Voice Lines: 1856 Approved: news-answers-request@MIT.EDU Distribution: world Message-ID: <2vj0gc$69b@britt.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: britt.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: bloom-beacon.mit.edu alt.image.medical:1163 comp.protocols.dicom:248 sci.data.formats:536 alt.answers:3509 comp.answers:6215 sci.answers:1358 news.answers:22233 Archive-name: medical-image-faq/part2 Posting-Frequency: monthly Last-modified: Fri Jul 8 10:48:34 GMT+0300 1994 Version: 1.01 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 information about proprietary formats & hosts Changes this issue: Changed archive name to 'medical-image-faq/partn' at request of mit. Added qsh information. Sparc floating point code bug fixed. Data General network hardware/software. Using the Vax/VMS DUMP utility to encode for ascii transfer. More Siemens information. Philips S5 MRI image data format. Added lunis information. Added mailserver section: ftpmail, interfile, medimagex, nucmed. Changes last issue: Split into two parts. GE Genesis information extended. GE Signa 3X/4X image data format included. Siemens GBS II, Impact, DR information (limited). Picker IQ/PQ CT information (limited). Vax data layout description. More anti-VMS vitriol added. Sparc data layout description. 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. Note: this FAQ has been formatted as a digest. Many newsreaders can skip to each of the major subsections by pressing ^G. Please direct comments or questions and especially contributions to "dclunie@flash.us.com" or reply to this article. START OF PART 2 -------- Subject: Proprietary Formats 3. Proprietary Formats 3.1 General 3.1.1 SPI (Standard Product Interconnect) Used on: - Siemens MRI Impact - Philips MRI S5 - ? what else ? SPI is a standard based on the old ACR/NEMA 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). Needless to say this section needs expanding dramatically so please send more information ! 3.2 CT 3.2.1 General Electric 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 contact 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 CT 9800 3.2.1.1.1 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 _______________ _______________ | | | | | | | | | |_______________|_______________| 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 VL=<0xc> (0000x8,000x70) LO Manufacturer VR= VL=<0x8> (0000x8,0x1090) LO ManufacturerModelName VR= VL=<0x2> (0000x9,000x10) LT SPIComments VR= VL=<0xe> (000x19,000x10) VR= VL=<0x14> 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 ACS 3.3.3.3 T5 3.3.3.4 NT5 & NT15 3.3.4 Picker - another black hole 3.3.5 Toshiba - another black hole 3.3.6 Hitachi - another black hole 3.3.7 Shimadzu - another black hole 3.3.8 Elscint - another black hole -------- Subject: Host Machines 4. Host Machines 4.1 Data General 4.1.1 Data 4.1.1.1 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 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 Operating System 4.1.2.1 RDOS Used on the GE CT 9800 family. Severely primitive and not 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 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 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 Data 4.2.1.1 Integers - little endian - 8, 16, or 32 bits 4.2.1.2 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 Strings - 16 bits of length - byte of type - byte of class - 32 bits of pointer 4.2.2 Operating System 4.2.2.1 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 attribute xxx" command like all the other millions of set commands ? Grrrr.). 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 make the line fit on the page): 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 #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. 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. 4.2.2.2 ULTRIX 4.2.2.3 OSF 4.3 Sun4 - Sparc 4.2.1 Data See the Sparc Architecture Manual - Chapter 3 - Data Formats for more details. 4.2.1.1 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.2.1.2 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 4 Sparc 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.2.1.3 Strings 4.2.2 Operating System -------- Subject: Compression Schemes 5. Compression Schemes 5.1 Reversible 5.2 Irreversible 5.2.1 Perimeter Encoding -------- Subject: Getting Connected 6. Getting Connected 6.1 Tapes 6.2 Ethernet 6.3 Serial Ports -------- Subject: Sources of Information 7. Sources of Information 7.1 Vendor Contacts DICOM and ACR/NEMA standards: NEMA Publication Sales 2101 L St. NW, Suite 300 Washington DC 20037-1526 phone (202) 457-8474 DICOM standards comments and working group information: David Snavely, Staff Executive NEMA 2101 L St. NW, Suite 300 Washington DC 20037-1526 phone (202) 457-1965 Gordon Bass American College of Radiology 1891 Preston White Drive Reston VA 22091 phone (703) 648-8900 General Electric, for image format information: John Meissner Networks Technical Leader GE Medical Systems N25 W23255 Paul Road Pewaukee WI 53072 phone (414) 896-2707 email "meissnerj@med.ge.com" Kodak "Understanding DICOM 3.0" for $US 12.50 (no credit cards): Angie Helms Kodak Health Imaging Systems 18325 Waterview Parkway Dallas TX 75252 phone 1-800-767-3448 Independent JPEG Group (IJG): Tom Lane (tgl@netcom.com) Interfile: Trevor Cradduck (cradduck@irus.rri.uwo.ca) Andrew Todd-Pokropek (a.todd@ucl.ac.uk) 7.2 Relevant FAQ's Archive-name: graphics/resources-list/part[1-3] Archive-name: graphics/faq Archive-name: pixutils-faq Archive-name: image-processing/Macintosh Archive-name: sci-data-formats DICOM FAQ - maintained by dsc@xray.hmc.psu.edu (David S. Channin) - periodically posted to comp.protocols.dicom med.volviz.faq - maintained by mhaveri@phoenix.oulu.fi (Matti Haveri) - occasionally posted to alt.image.medical - discussed medical volume visualization FITS basics and information (periodic posting) - FITS (Flexible Image Transport System) - for astronomical data - periodically posted by bschlesinger@nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) - in sci.astro.fits,sci.data.formats 7.3 Source Code 7.3.X JPEG PVRG-JPEG CODEC: havefun.stanford.edu[36.2.0.35]:/pub/jpeg/JPEGv1.2.tar.Z Supports - sequential DCT baseline, - lossless modes. IJG: ftp.uu.net[137.39.1.9]:/graphics/jpeg/jpegsrc.v4.tar.Z Supports - sequential DCT baseline, - 12 bit DCT modes. 7.4 Commercial Offerings Data General RDOS & AOS TCP/IP solution: Claflin & Clayton 203 Southwest Cutoff Northboro, MA 01532 phone 508-393-7979 fax 508-393-8788 email "clayton@c-c.com" compuserve 70262,3663 Data General themselves: DG Direct phone 1-800-343-8842 Interfaces between vendors equipment, DICOM 3.0, etc.: DeJarnette Research Systems Inc. Suite 700 401 Washington Avenue Towson, Maryland 21204 USA phone 410-583-0694 email "71107.3237@compuserve.com" Merge Technologies, Inc. 1126 S. 70th St Milwaukee, Wisconsin 53214-3151 phone 414-475-4300 fax 414-475-3940 email "Merge.Tech@mixcom.com" Interformat - qsh to Interfile conversion, DICOM to qsh, et al. David Reddy Radio Logic, Inc. P.O. Box 9665 New Haven CT 06536 phone (203) 624-8113 email reddy@nucmed.med.nyu.edu 7.5 FTP sites 3DVIEWNIX (University of Pennsylvania): ftp:mipgsun.mipg.upenn.edu:/3DVIEWNIX1.0/BINARIES http://mipgsun.mipg.upenn.edu ACR/NEMA (dicom) viewer for MAC (haven't tried this yet): ftp.u.washington.edu:/public/razz CT reconstruction software: peipa.essex.ac.uk:/ipa/src/process /ipa/src/process/ct.tar.Z /ipa/src/process/snark77.tar.Z DICOM draft standards and demonstration software: ftp.xray.hmc.psu.edu:/dicom_docs /dicom_docs/dicom_3.0/postcript postscript /dicom_docs/dicom_3.0/frame FrameMaker /dicom_docs/dicom_3.0/word_hqx Microsoft Word ftp.xray.hmc.psu.edu:/dicom_software /dicom_software/Mallinckrodt Mallinkrodt RSNA '93 /dicom_software/European European CEN/TC251/WG4 rsna.org wuerlim.wustl.edu:/pub/dicom /pub/dicom/images/version3 sample images ftp.uni-oldenburg.de:/pub/dicom /pub/dicom/dicom_docs /pub/dicom/dicom_software FITS (Flexible Image Transport System) for astronomical data: ftp:fits.cv.nrao.edu:/fits ftp:nssdca.gsfc.nasa.gov:/FITS Interfile - see nucmed ftp site at UWO. Kermit distribution: ftp:ftp.cc.columbia.edu:/kermit LUNIS - Loyola University Nuclear Medicine Information System http://147.126.104.3/ contact Jim Halama (jhalama@lunis.nucmed.luc.edu) Medical Informatics standards, including HL7: ftp:dumccss.mc.duke.edu:/standards /standards/read-me.txt /standards/HL7/pubs/version2.2/ballot1.zip Nucmed ftp site (run by Trevor Cradduck (cradduck@uwo.ca)): ftp:uwovax.uwo.ca[129.100.2.13]:PUB:[000000.NUCMED] Qsh: ftp:nucmed.med.nyu.edu[128.122.156.10]:/pub /pub/dist compressed tar /pub/qsh source Sample medical images (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/ Vax help - "The Vax Book" by Joseph E St Sauver, U of Oregon: ftp:decoy.uoregon.edu: ? what directory 7.6 Mailservers 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 best site used to be "ftpmail@decwrl.dec.com" (send "help" (no quotes) in the message body) but it has not been responding lately Interfile 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. Medimagex list for medical image format discussions: Precursor to alt.image.medical usenet news group. Now essentially defunct. Was gated to the group, but is currently gated one way (mail->news) only for some reason. Maybe useful is you don't have usenet access. command address: listserver@cs.columbia.edu commands: in message body not subject list name: MEDIMAGEX to get help: HELP and/or HELP LISTSERV to subscribe: SUBSCRIBE MEDIMAGEX firstname lastname (NB. not your email address, that is derived from the 'From ' header line) to unsubscribe: UNSUBSCRIBE MEDIMAGEX to send to list: medimagex@cs.columbia.edu 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: Trevor Cradduck (cradduck@uwo.ca) This list may or may not be gated to "sci.med.physics". See also Nucmed ftp site at UWO. 7.7 References -------- Subject: Acknowledgements 8. Acknowledgements Thanks to the following people for contributions, general help, interesting postings or mail whose contents have found there way in here, or just plain old moral support. If I have inadvertently omitted anyone, sorry ! Allen Rueter (allen@wuerl.WUstl.EDU) Trevor Cradduck (cradduck@irus.rri.uwo.ca) Andrew Todd-Pokropek (a.todd@ucl.ac.uk) John Meissner (meissnerj@med.ge.com) Tom Lane (tgl@netcom.com) Jeff Paynowski (paynowsk@ct.picker.com) James Harrison (james@hplb.hpl.hp.com) David S. Channin (dsc@xray.hmc.psu.edu) Fred W. Prior (prior@xray.hmc.psu.edu) Jeff Wade (wade@kegs.saic.com) Michael P. McIntyre (mikey@lobby.ti.com) Andy Hewett (Andy.Hewett@informatik.uni-oldenburg.de) Varun Mitroo (mitroo@magnus.acs.ohio-state.edu) Rafael Pous (pous@gaig.upc.es) Martin Liversage (operator@iris.kth.dk) John Clayton (clayton@c-c.com) Gerald Q. Maguire (maguire@it.kth.se) ? Chip on holiday :) Marilyn E Noz (noz@nucmed.NYU.EDU) Bud Wendt (rwendt@bcm.tmc.edu) END OF PART 2 -- David A. Clunie (dclunie@flash.us.com) In sunny Riyadh, Saudi Arabia. "I must see your DICOM 3 conformance statement before I buy."

---

E-Mail Fredric L. Rice / The Skeptic Tank