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