From dclunie@flash.us.com Tue Aug 2 09:30:58 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["48230" "" "29" "July" "1994" "11:32:20" "+0300" "David A. Clunie" "dclunie@flash.us.com" "<31aeqk$m3v@britt.ksapax>" "942" "Medical Image Format FAQ, Part 1/2" "^From:" nil nil "7" "1994072908:32:20" "Medical Image Format FAQ, Part 1/2" (number " " mark " David A. Clunie Jul 29 942/48230 " thread-indent "\"Medical Image Format FAQ, Part 1/2\"\n") nil] nil) X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" X-VM-Labels: nil X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil X-VM-Bookmark: 2 Xref: saips.cv.nrao.edu alt.image.medical:1249 comp.protocols.dicom:253 sci.data.formats:526 alt.answers:3738 comp.answers:6475 sci.answers:1362 news.answers:25729 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!saimiri.primate.wisc.edu!ames!hookup!usc!howland.reston.ans.net!spool.mu.edu!sgiblab!a2i!flash.us.com!flash.us.com!not-for-mail Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,alt.answers,comp.answers,sci.answers,news.answers Followup-To: alt.image.medical Organization: Her Master's Voice Lines: 942 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 29 Aug 1994 00:00:00 GMT Message-ID: <31aeqk$m3v@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. From: dclunie@flash.us.com (David A. Clunie) Subject: Medical Image Format FAQ, Part 1/2 Date: 29 Jul 1994 11:32:20 +0300 Archive-name: medical-image-faq/part1 Posting-Frequency: monthly Last-modified: Fri Jul 29 11:06:27 GMT+0300 1994 Version: 1.03 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: Clarified the origins of Interfile. More on qsh & file conversion. Updated InterFormat description Updated Data General RDOS comments. The Decus FILE utility for fixing crazy Philips Vax/VMS files. FTP for NIH Image and Image/Adobe Photoshop ACR/NEMA plug-in. DICOM conversion tools V0.04 posted to alt.sources. Ftp site for window level software. Fixed some typographical errors. Changes last 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. 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 1 -------- Subject: Index 1. Introduction 1.1 Objective 1.2 Types of Formats 1.3 In Desperation - Quick & Dirty Tricks 2. Standard Formats 2.1 ACR/NEMA 1.0 and 2.0 2.2 ACR/NEMA DICOM 3.0 2.3 Papyrus 2.4 Interfile V3.3 2.5 Qsh 3. Proprietary Formats 3.1 General 3.1.1 SPI (Standard Product Interconnect) 3.2 CT 3.2.1 General Electric 3.2.1.1 CT 9800 3.2.1.1.1 Image data 3.2.1.1.2 Tape format 3.2.1.1.3 Raw data 3.2.1.2 CT Advantage - Genesis 3.2.1.2.1 Image data 3.2.1.2.2 Archive format 3.2.1.2.3 Raw data 3.2.1.3 Scitec/Pace 3.2.2 Siemens 3.2.2.1 Somatom DR 3.2.2.2 Somatom Plus 3.2.2.3 Somatom AR 3.2.3 Philips 3.2.4 Picker 3.2.5 Toshiba 3.2.6 Hitachi 3.2.7 Shimadzu 3.2.8 Elscint 3.3 MR 3.3.1 General Electric 3.3.1.1 Signa 3X and 4X 3.3.1.1.1 Image data 3.3.1.1.2 Tape format 3.3.1.1.3 Raw data 3.3.1.2 Signa 5X - Genesis 3.3.1.2.1 Image data 3.3.1.2.2 Tape format 3.3.1.2.3 Raw data 3.3.1.3 Vectra 3.3.2 Siemens 3.3.2.1 GBS II 3.3.2.2 SP/Vision 3.3.2.3 Impact 3.3.3 Philips 3.3.3.1 S5 3.3.3.2 ACS 3.3.3.3 T5 3.3.3.4 NT5 & NT15 3.3.4 Picker 3.3.5 Toshiba 3.3.6 Hitachi 3.3.7 Shimadzu 3.3.8 Elscint 4. Host Machines 4.1 Data General 4.1.1 Data 4.1.1.1 Integers 4.1.1.2 Floating Point 4.1.2 Operating System 4.1.2.1 RDOS 4.1.2.2 AOS/VS 4.1.3 Network 4.2 Vax 4.2.1 Data 4.2.1.1 Integers 4.2.1.2 Floating Point 4.2.2 Operating System 4.2.2.1 VMS 4.2.2.2 ULTRIX 4.2.2.3 OSF 4.3 Sun4 - Sparc 4.2.1 Data 4.2.1.1 Integers 4.2.1.2 Floating Point 4.2.2 Operating System 5. Compression Schemes 5.1 Reversible 5.2 Irreversible 5.2.1 Perimeter Encoding 6. Getting Connected 6.1 Tapes 6.2 Ethernet 6.3 Serial Ports 7. Sources of Information 7.1 Vendor Contacts 7.2 Relevant FAQ's 7.3 Source Code 7.4 Commercial Offerings 7.5 FTP sites 7.6 Mailservers 7.7 References 8. Acknowledgements -------- Subject: Introduction 1. Introduction 1.1 Objective The goal of this FAQ is to facilitate access to medical images stored on digital imaging modalities such as CT and MR scanners, and their accompanying descriptive information. The document is designed particularly for those who do not have access to the necessary proprietary tools or descriptions, particularly in those moments when inspiration strikes and one just can't wait for the local sales person to track down the necessary authority and go through the cycle of correspondence necessary to get a non-disclosure agreement in place, by which time interest in the project has usually faded, and another great research opportunity has passed ! It may also be helpful for those keen to experiment with home-grown PACS-like systems using their existing equipment, and also for those who still have equipment that is still useful but so old even the host computer vendor doesn't support it any more ! There is of course no substitute for the genuine tools or descriptions >from the equipment vendors themselves, and pointers to helpful individuals in various organizations, as well as names and catalog numbers of various useful documents, are included here where known. In addition there are several small companies that specialize in such connectivity problems that have a good reputation and are well known. Contact information is provided for them, though I personally have no experience with their products and am not endorsing them. Finally, great care has been taken not to include any information that has been released under non-disclosure agreements. What is included here is the result of either information freely released by vendors, handy hints from others working in the field, or in many cases close scrutiny of hex dumps and experimentation with scanner parameters and study of the effects on the image files. The intent is to spread hard-earned knowledge gained over many years amongst those new to the field or a particular piece of equipment, not to threaten anyone's proprietary interests, or to substitute for the technical support available from vendors that ranges from free to extortionate, and excellent to abysmal, depending on who your are dealing with and where in the world you are located ! Please use this information in the spirit in which is intended, and where possible contribute whatever you know in order to expand the information to cover more vendors and equipment. 1.2 Types of Formats Later sections will deal with the problems of getting the image files >from the modality to the workstation, but for the moment assume the files are there and need to be deciphered. Four types of information are generally present in these files: - image data, which may be unmodified or compressed, - patient identification and demographics, - technique information about the exam, series, and slice/image. Extracting the image information alone is usually straightforward and is described in 1.3. Dealing with the descriptive information, for example to make use of the data for dissemination in a PACS environment, or to extract geometry details in order to combine images into 3D datasets, is more difficult and requires deeper understanding of how the files are constructed. There are three basis families of formats that are in popular use: - fixed format, where layout is identical in each file, - block format, where the header contains pointers to information, - tag based format, where each item contains its own length. The block format is one of the most popular, though in most cases, the early part of the header contains only a limited number of pointers to large blocks, the blocks are almost always in the same place and a constant length, for standard rather than reformatted images at least, and if one doesn't know the specifics of the layout one can get by assumming a fixed format. I presume this reflects the intent of the designers to handle future expansion and revision of the format. The example par excellence of the tag based format is the ACR/NEMA style of data stream, which, though never intended as a file format per se has proven useful as model. See for example the sections dealing with the ACR/NEMA standards as well as DICOM (whose creators are about to vote on a media interchange format after all this time) and Papyrus. ACR/NEMA style tags are described in more detail elsewhere, but each is self-contained and self-describing (at least if you have the appropriate data dictionary) and contains its own length, so if you can't interpret it you can skip it ! Very convenient. Most file formats based on this scheme are just concatenated series of tags, and apart from having to guess the byte order, which is not specified (unlike TIFF which is a similar deal for those in the "real" imaging world), and sometimes skip a fixed length but short header, are dead easy to handle. To identify such a file just do a "strings | ______________ ______________ ______________ ______________ |XXXXXXXXXXXXXX| | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 --------------------------- Bits Allocated = 16 Bits Stored = 12 High Bit = 15 |<------------------ pixel ----------------->| ______________ ______________ ______________ ______________ | | | |XXXXXXXXXXXXXX| |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 --------------------------- Bits Allocated = 12 Bits Stored = 12 High Bit = 11 ------ 2 ----->|<------------------ pixel 1 --------------->| ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 -------------- 3 ------------>|<------------ 2 -------------- ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 |<------------------ pixel 4 --------------->|<----- 3 ------ ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 --------------------------- And so on ... refer to the standard itself for more detail. 2.2 ACR/NEMA DICOM 3.0 ACR/NEMA Standards Publications No. PS 3.1-1992 <- DICOM 3 - Introduction & Overview No. PS 3.8-1992 <- DICOM 3 - Network Communication Support No. PS 3.2-1993 <- DICOM 3 - Conformance No. PS 3.3-1993 <- DICOM 3 - Information Object Definitions No. PS 3.4-1993 <- DICOM 3 - Service Class Specifications No. PS 3.5-1993 <- DICOM 3 - Data Structures & Encoding No. PS 3.6-1993 <- DICOM 3 - Data Dictionary No. PS 3.7-1993 <- DICOM 3 - Message Exchange No. PS 3.9-1993 <- DICOM 3 - Point-to-Point Communication No. PS 3.10-???? <- DICOM 3 - Media Storage & File Format No. PS 3.11-???? <- DICOM 3 - Media Storage Application Profiles No. PS 3.12-???? <- DICOM 3 - Media Formats & Physical Media DICOM (Digital Imaging and Communications in Medicine) standards are of course the hot topic at every radiological trade show. Unlike previous attempts at developing a standard, this one seems to have the potential to actually achieve its objective, which in a nutshell, is to allow vendors to produce a piece of equipment or software that has a high probability of communicating with devices from other vendors. Where DICOM differs substantially from other attempts, is in defining so called Service-Object Pairs. For instance if a vendor's MR DICOM conformance statement says that it supports an MR Storage Class as a Service Class Provider, and another vendor's workstation says that it supports an MR Storage Class as a Service Class User, and both can connect via TCP/IP over Ethernet, then the two devices will almost certainly be able to talk to each other once they are setup with each others network addresses and so on. The keys to the success of DICOM are the use of standard network facilities for interconnection (TCP/IP and ISO-OSI), a mechanism of association establishment that allows for negotiation of how messages are to be transferred, and an object-oriented specification of Information Objects (ie. data sets) and Service Classes. Of course all this makes for a huge and difficult to read standard, but once the basic concepts are grasped, the standard itself just provides a detailed reference. From the users' and equipment purchasers' points of view the important thing is to be able to read and match up the Conformance Statements from each vendor to see if two pieces of equipment will talk. Just being able to communicate and transfer information is of course not sufficient - these are only tools to help construct a total system with useful functionality. Because a workstation can pull an image off an MRI scanner doesn't mean it knows when to do it, when the image has become available, to which patient it belongs, and where it is subsequently archived, not to mention notifying the Radiology or Hospital Information System (RIS/HIS) when such a task has been performed. In other words DICOM Conformance does not guarantee functionality, it only facilitates connectivity. In otherwords, don't get too carried away with espousing the virtues of DICOM, demanding it from vendors, and expecting it to be the panacea to create a useful multi-vendor environment. Fred Prior (prior@xray.hmc.psu.edu) has come up with the concept of a User Conformance Statement to be generated by purchasers and to be satisfied by vendors. The idea is that one describes what one expects and hence gives the vendor a chance to realistically satisfy the buyer ! Of course each such statement must be tailored to the user's needs, and simply stapling a copy of Fred's statement to a Request For Proposals is not going to achieve the desired objective. Caveat empor. To get more information about DICOM: - Purchase the standards from NEMA (address below) when they become available around July 1994. - Ftp the final versions of the drafts in electronic form one of the sites described below. - Follow the Usenet group comp.protocols.dicom. - Get a copy of "Understanding DICOM 3.0" $12.50 from Kodak. - Insist that your existing and potential vendors supply you with DICOM conformance statements before you upgrade or purchase, and don't buy until you know what they mean. Don't take no for an answer !!!! What is all this doing in an FAQ about medical image formats you ask ? Well first of all, in many ways DICOM 3.0 will solve future connectivity problems, if not provide functional solutions to common problems. Hence actually getting the images from point A to B is going to be easier if everyone conforms. Furthermore, for those of us with old equipment, interfacing it to new DICOM conforming equipment is going to be a problem. In otherwords old network solutions and file formats are going to have to be transformed if they are going to communicate unidirectionally or bidirectionally with DICOM 3.0 nodes. One is still faced with the same old questions of how does one move the data and how does one interpret it. The specifics of the DICOM message format are very similar to the previous versions of ACR/NEMA on which it is based. The data dictionary is greatly extended, and certain data elements have been "retired" but can be ignored gracefully if present. The message itself can now be transmitted as a byte stream over networks, rather than using a point-to-point paradigm excusively (though the old point-to-point interface is available). This message can be encoded in various different Transfer Syntaxes for transmission. When two devices ("Application Entities" or AE) begin to establish an "Association", they negotiate an appropriate transfer syntax. They may choose an Explicit Big-Endian Transfer Syntax in which integers are encoded as big-endian and where each data element includes a specific field that says "I am an unsigned 16 bit integer" or "I am an ascii floating-point number", or alternatively they can fall back on the default transfer syntax which every AE must support, the Implicit Little-Endian Transfer Syntax which is just the same as an old ACR/NEMA message with the byte order defined once and for all. This is all very well if you are using DICOM as it was originally envisaged - talking over a network, negotiating an association, and determining what Transfer Syntax to use. What if one wants to store a DICOM message in a file though ? Who is to say which transfer syntax one will use to encode it offline ? One approach, used for example by the Central Test Node software produced by Mallinkrodt and used in the RSNA Inforad demonstrations, is just to store it in the default little-endian implicit syntax and be done with it. This is obviously not good enough if one is going to be mailing tapes, floppies and optical disks between sites and vendors though, and hence the DICOM group decided to define a "Media Storage & File Format" part of the standard, the new Chapter 10 which is about to be or has just been voted on. Amongst other things, this new part defines a generic DICOM file format that contains a brief header, the "DICOM File Meta Information Header" which contains a 128 byte preamble (that the user can fill with anything), a 4 byte DICOM prefix "DICM", then a short DICOM format message that contains newly defined elements of group 0002 in the default Implicit Little Endian Transfer Syntax, which uniquely identify the data set as well as specifying the Transfer Syntax for the rest of the file. The rest of the message must specify a single SOP instance which can of course contain multiple images as folders if necessary. The length of the brief message in the Meta Header is specified in the first data element as usual, the group length. So what choices of Transfer Syntax does one have and why all the fuss ? Well the biggest distinction is between implicit and explicit representation which allows for multiple possible representations for a single element, in theory at least, and perhaps allows one to make more of an unknown data element than one otherwise could perhaps. Some purists (and Interfile people) would argue that the element should be identified descriptively, and there is nothing to stop someone from defining their own private Transfer Syntax that does just that (what a heretical thought, wash my mouth out with soap). With regard to the little vs. big endian debate I can't see what the fuss is about, as it can't really be a serious performance issue. Perhaps more importantly in the long run, the Transfer Syntax mechanism provides a means for encapsulating compressed data streams, without having to deal with the vagaries and mechanics of compression in the standard itself. For example, if DICOM version 3.0, in addition to the "normal" Transfer Syntaxes, a series are defined to correspond to each of the Joint Photographic Experts Group (JPEG) processes. Each one of these Transfer Syntaxes encodes data elements in the normal way, except for the image pixel data, which is defined to be encoded as a valid and self-contained JPEG byte stream. Both reversible and irreversible processes of various types are provided for, without having to mess with the intricacies of encoding the various tables and parameters that JPEG processes require. Presumably a display application that supports such a Transfer Syntax will just chop out the byte stream, pass it to the relevant JPEG decode, and get an uncompressed image back. More importantly, an archive server can store the image and retrieve it without ever having to know anything about how the image pixel data is encoded. Contrast this approach with that taken by those defining the TIFF (Tagged Image File Format) for general imaging and page layout applications. In their version 6.0 standard they attempted to disassemble the JPEG stream into its various components and assign each to a specific tag. Unfortunately this proved to be unworkable after the standard was disseminated and they have gone back to the drawing board. Now one may not like the JPEG standard, but one cannot argue with the fact that the scheme is workable, and a readily available means of reversible compression has been incorporated painlessly. How effective a compression scheme this is remains to be determined, and whether or not the irreversible modes gain wide acceptance will be dictated by the usual medico-legal paranoia that prevails in the United States, but the option is there for those who want to take it up. There is of course no reason why private compression schemes cannot be readily incorporated using this "encapsulation" mechanism, and to preserve bandwidth this will undoubtedly occur. This will not compromise compatibility though, as one can always fall back to a default, uncompressed Transfer Syntax. The DICOM Working Group on compression will undoubtedly bring out new possibilities. In order to identify all these various syntaxes, information objects, and so on, DICOM has adopted the ISO concept of the Unique Identifier (UID) which is a text string of numbers and periods with a unique root for each organization that is registered with ISO and various organizations that in turn register others in a hierarchical fashion. For example 1.2.840.10008.1.2 is defined as the Implicit VR Little Endian Transfer Syntax. The 1 identifies ISO, the 2 is the ISO member body branch, the 840 is the specific member body country code, in this case ANSI, and the 10008 is registered by ANSI to NEMA for DICOM. UID's are also used to uniqely identify non-DICOM specific things, such as information objects. These are constructed from a prefix registered to the supplier or vendor or site, and a unique suffix that may be generated from say a date and time stamp (which is not to be parsed). For example an instance of a CT information object might have a UID of 1.2.840.123456.002.999999.940623.170717 where a (presumably US) vendor registered 123456, and the modality generated a unique suffix based on its device number, patient hospital id, date and time, which have no other significance other than to create a unique suffix. The other important new concept that DICOM introduced was the concept of Information Objects. In the previous ACR/NEMA standard, though modalities were identified by a specific data element, and though there were rules about which data elements were mandatory, conditional or optional in ceratin settings, the concept was relatively loosely defined. Presumably in order to provide a mechanism to allow conformance to be specified and hence ensure interoperability, various Information Objects are defined that are composed of sets of Modules, each module containing a specific set of data elements that are present or absent according to specific rules. For example, a CT Image Information Object contains amongst others, a Patient module, a General Equipment module, a CT Image module, and an Image Pixel module. An MR Image Information module would contain all of these except the CT Image module which would be replaced by an MR Image module. Clearly one needs descriptive information about a CT image that is different from an MR image, yet the commonality of the image pixel data and the patient information is recognized by this model. Hence, as described earlier, one can define pairs of Information Objects and Services that operate on such objects (Storage, Query/Retrieve, etc.) and one gets SOP classes and instances. All very object oriented and initially confusing perhaps, but it provides a mechanism for specifying conformance. From the point of view of an interpreters of a DICOM compatible data stream this means that for a certain instance of an Information Object, certain information is guaranteed to be in there, which is nice. As a creator of such a data stream, one must ensure that one follows all the rules to make sure that all the data elements from all the necessary modules are present. Having done so one then just throws all the data elements together, sorts them into ascending order by group and element order, and pumps them out. It is a shame that the data stream itself doesn't reflect the underlying order in the Information Objects, but I guess they had to maintain backward compatibility, hence this little bit of ugliness. This gets worse when one considers how to put more than one object in a folder inside another object. At this point I am tempted to include more details of various different modules, data elements and transfer syntaxes, as well as the TCP/IP mechanism for connection. However all this information is in the standard itself which is readily available electronically from the ftp sites, and in the interests of brevity I will not succumb to temptation at this time. 2.3 Papyrus Papyrus is an image file format based on ACR/NEMA version 2.0. I don't have much information about it yet, but what I do know, gleaned from Usenet and a presentation at SCAR 94 is: - it is from Switzerland, - there is a library of tools available for handling it, - it allows multiple images/file, - it has something to do with the European RACE Telemed project, - it stores 16 bit integers as big-endian, and that is all for the moment ! Someone is sending me more information Real Soon Now so stay tuned. 2.4 Interfile V3.3 Interfile is a "file format for the exchange of nuclear medicine image data" created I gather to satisfy the needs of the European COST B2 Project for the transfer of images of quality control phantoms, and incorporates the AAPM (American Association of Physicists in Medicine) Report No. 10, and has been subsequently used for clinical work. It specifies a file format composed of ascii "key-value" pairs and a data dictionary of keys. The binary image data may be contained in the same file as the "administrative information", or in a separate file pointed to by a "name of data file" key. Image data may be binary integers, IEEE floating point values, or ascii and the byte order is specified by a key "imagedata byte order". The order of keys is defined by the Interfile syntax which is more sophisticated than a simple list of keys, allowing for groups, conditionals and loops to dictate the order of key-value pairs. Conformance to the Interfile standard is informally described in terms of which types of image data types, pixel types, multiple windows, special Interfile features including curves, and restriction to various maximum recommended limits. Interfile is specifically NOT a communications protocol and strictly deals with offline files. There are efforts to extend Interfile to include modalities other than nuclear medicine, as well as to keep ACR/NEMA and Interfile data dictionaries in some kind of harmony. A sample list of Interfile 3.3 key-value pairs is shown here to give you some idea of the flavor of the format. The example is culled from part of a Static study in the Interfile standard document and is not complete: !INTERFILE := !imaging modality :=nucmed !version of keys :=3.3 data description :=static patient name :=joe doe !patient ID :=12345 patient dob :=1968:08:21 patient sex :=M !study ID :=test exam type :=test data compression :=none !image number :=1 !matrix size [1] :=64 !matrix size [2] :=64 !number format :=signed integer !number of bytes per pixel :=2 !image duration (sec) :=100 image start time :=10:20: 0 total counts :=8512 !END OF INTERFILE := One can see how easy such a format would be to extend, as well as how it is readable and almost useable without reference to any standard document or data dictionary. Undoubtedly ACR/NEMA DICOM 3.0 to Interfile translators will soon proliferate in view of the fact that many Nuclear Medicine vendors supply Interfile translators at present. To get hold of the Interfile 3.3 standard by ftp, see the sources and contacts listed later in this document. 2.5 Qsh Qsh is a family of programs for manipulating images, and it defines an intermediate file format. The following information was derived with the help of one of the authors (Chip Maguire ): Uses an ASCII key-value-pair (KVP sic.) system, based on the AAPM Report #10 proposal. This format influenced both Interfile and ACR-NEMA (DICOM). The file format is referred to as "IMAGE" in some of their articles (see references). The header and the image data are stored as two separate files with extensions *.qhd and *.qim respectively. Qsh is available by anonymous ftp (see Sources section). This is a seriously large tar file, including as it does some sample images, and lots of source code, as well as some post-script documents. Subtrees are available as separate tar files. QSH's Motif-based menu system (qmenu) will work with OpenWindows 3.0 if SUN patch number 100444-54 for SUNOS 4.1.3 rev. A is applied. The patch is available from sunsolve1.sun.com (192.9.9.24). The image access subroutines take the same parameters as the older /usr/image package from UNC, however, the actual subroutines support the qsh KVP and image data files. The frame buffer access subroutines take the same parameters as the Univ. of Utah software (of the mid. 1970s). The design is based on the use of a virtual frame buffer which is then implemented via a library for a specific frame buffer. There exists a version of the the display routines for X11. Conversions are not supported any longer, instead there is a commercial product called InterFormat. InterFormat includes a qsh to Interfile conversion, along with DICOM to qsh, and many others. Information is available from David Reddy (reddy@nucmed.med.nyu.edu) (see Sources section). [Editorial note: this seems a bit of a shame to me - the old distribution included lots of handy bits of information, particularly on driving tape drives. I am advised however that the conversion stuff was pulled out because people wanted it supported, the authors were worried they were disclosing things perhaps they ought not to be, and NYU had switched to using InterFormat themselves anyway. DAC.] The authors of the qsh package are: Gerald Q. (Chip) Maguire (maguire@it.kth.se) Marilyn E Noz (noz@nucmed.NYU.EDU) The following references are helpful in understanding the philosophy behind the file format, and are included in postscript form in the qsh ftp distribution: @Article[noz88b, Key=, Author=, Title=, Journal=, volume=<27>, month=, Year=<1988>, Pages=<229-240> ] @Article[maguire89e, Key=, Author=, Title=, Journal=, volume=<16>, month=, year=<1989>, pages=<818-823>, comment= ] END OF PART 1 -- David A. Clunie (dclunie@flash.us.com) In sunny Riyadh, Saudi Arabia. "I must see your DICOM 3 conformance statement before I buy." From dclunie@flash.us.com Tue Aug 2 14:11:41 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["80326" "" "29" "July" "1994" "11:32:26" "+0300" "David A. Clunie" "dclunie@flash.us.com" "<31aeqq$m43@britt.ksapax>" "1946" "Medical Image Format FAQ, Part 2/2" "^From:" nil nil "7" "1994072908:32:26" "Medical Image Format FAQ, Part 2/2" (number " " mark " David A. Clunie Jul 29 1946/80326 " thread-indent "\"Medical Image Format FAQ, Part 2/2\"\n") nil] nil) Xref: saips.cv.nrao.edu alt.image.medical:1253 comp.protocols.dicom:254 sci.data.formats:527 alt.answers:3743 comp.answers:6485 sci.answers:1363 news.answers:25764 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!malgudi.oar.net!cedarnet!calvin!gumby!newsxfer.itd.umich.edu!gatech!howland.reston.ans.net!spool.mu.edu!sgiblab!a2i!flash.us.com!flash.us.com!not-for-mail Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,alt.answers,comp.answers,sci.answers,news.answers Followup-To: alt.image.medical Organization: Her Master's Voice Lines: 1946 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 29 Aug 1994 00:00:00 GMT Message-ID: <31aeqq$m43@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. From: dclunie@flash.us.com (David A. Clunie) Subject: Medical Image Format FAQ, Part 2/2 Date: 29 Jul 1994 11:32:26 +0300 Archive-name: medical-image-faq/part2 Posting-Frequency: monthly Last-modified: Fri Jul 29 11:06:27 GMT+0300 1994 Version: 1.03 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: Clarified the origins of Interfile. More on qsh & file conversion. Updated InterFormat description Updated Data General RDOS comments. The Decus FILE utility for fixing crazy Philips Vax/VMS files. Ftp site for NIH Image and Image/Adobe Photoshop ACR/NEMA plug-in. DICOM conversion tools V0.04 posted to alt.sources. Ftp site for window level software. Fixed some typographical errors. Changes last 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. 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; ifrom one's own workstation. All the same I will fill in this gap if anyone has any useful information. 3.2.1.2.3 Raw data Again, unknown. Please fill in this space. 3.2.1.3 Scitec/Pace I don't have one of these, but the documents describing the format are in the mail. Anyone who can send me a few sample files on a floppy or something, please let me know. 3.2.2 Siemens 3.2.1.1 Somatom DR - NOT in SPI format - fixed format - files 133120 bytes - image pixel data 256*256*2 little endian - image pixel offset 2048 bytes - same for axial images and topograms (scouts) This description pertains to the DR family, and possibly also earlier Siemens CT models, but I have no files from these to test. The files are in fixed format (cf. the early Magnetom format which is similar, but has block pointers) with three major blocks of entries: - binary data - offset 0 - 512 bytes - text overlay - offset 512 - 960 bytes plus 676 bytes free - image pixel data - offset 2048 - 131072 bytes The binary data block is filled with the usual cryptic enumerated values and useful parameters. Some of the more interesting ones are: - binary data block: 134 - short - scan time - secs 136 - short - kv 138 - short - dose - maS 140 - short - slice thickness - mm 142 - short - gantry tilt - degrees 144 - short - table position - mm 146 - short - table height - mm 148 - short - scan mode (1=standard(360), 2=quickscan(240),4=topogram) Unfortunately, the patient identification information is NOT stored in the binary data block, rather one has to extract it from the image text overlay block, which consists of 960 characters (24 lines of 40 characters WITHOUT carriage control characters) in a fixed format. This is where what you see overlayed on the filmed images is stored. Some of these values are duplicates of what is in the binary data block, but things like the patient name and so on are here and nowhere else :( 0123456789012345678901234567890123456789 0 SOMATOM DR2 ST. ELSEWHERE GEN HOSP 40 999999-9999 JOHN DOE EF2 80 01-JAN-90 FRONT 35B 120 13:31:22 H/SP 160 200 SCAN 60 L 240 E 280 F 320 T 360 400 440 480 520 560 600 640 680 720 TI 5 760 KV 125 800 AS .35 840 SL 2 880 GT 0 920 TP 144 - text overlay block: (some of this is guess work) 0 - char[14] - product 15 - char[25] - hospital name 40 - char[12] - patient number 53 - char[22] - patient name 80 - char[2] - date - dd 83 - char[3] - date - mmm 87 - char[2] - date - yy 120 - char[2] - time - hh 123 - char[2] - time - mm 126 - char[2] - time - ss 156 - char[1] - H=head first,F=feet first 158 - char[2] - SP=supine,PR=prone, RP=right lateral decubitus, LP=left lateral decubitus 205 - char[4] - slice number 723 - char[4] - scan time - secs 763 - char[4] - kv 803 - char[4] - dose - AmpS 843 - char[4] - slice thickness - mm 883 - char[4] - gantry tilt - degrees 923 - char[4] - table position - mm If anyone knows what "EF2" and "35B" stand for I would love to know - I presume they are something like the filter used, or field of view or something ? So far the images I have are all 256*256 ... I haven't yet figured out where if anywhere, this fact is stored in the header, or if any other choice is available with this family of machines. I also haven't seen any kind of compression being used on the image pixel data. Also the DR family don't seem to be aware of the concept of a hierarchy of examination/study and series numbering, which makes it annoying to try to import them into PACS systems :( Correct me if I am wrong but they just seem to keep bumping up the slice number for each patient as each group of scans is done. 3.2.2.2 Somatom Plus - unknown 3.2.2.3 Somatom AR - unknown 3.2.3 Philips - Big black hole 3.2.4 Picker Grey hole perhaps. This information probably pertains to the IQ and PQ CT models, though I have no sample images to experiment with yet. I am told that: - axial images are 512x512 - pilot images are 1024x1024 - uncompressed images are 12 bits stored in 16 bits - don't know how to handle compression scheme - raster order is as usual, by row, TLHC first - 8k header to be skipped 3.2.5 Toshiba - another black hole 3.2.6 Hitachi - another black hole 3.2.7 Shimadzu - another black hole 3.2.8 Elscint - another black hole 3.3 MR 3.3.1 General Electric 3.3.1.1 Signa 3X and 4X 3.3.1.1.1 Image data - "fixed format" header - image data is not compressed - image data fixed offset 14336 bytes - Data General host - AOS/VS The image files are of fixed layout, described here as a series of 256 by 16 bit word blocks (512 bytes), blocks numbered from 0. The headers start at the following block offsets: block 0 - length 4 blocks - System configuration block 4 - length 2 blocks - Site customization block 6 - length 2 blocks - Study header block 8 - length 2 blocks - Series header block 10 - length 2 blocks - Image header block 12 - length 4 blocks - Raw database header block 16 - length 10 blocks - Pulse sequence description block 26 - length 2 blocks - Pixel map (? not ever used) block 28 - length 256 blocks - Image data As decribed earlier, the header is a fixed length of 14336 bytes, after which the uncompressed image data starts. Some of the more important fields are described here. Integers are 16 bit words (big-endian), ascii strings are Fortran style specifications with length in bytes, and reals are 4 bytes long (see Host machines - Data General), word offsets are numbered from 0: block 6 - study header word 32 - 5A - Study number word 39 - 9A - Date of study (dd-mmm-yy) word 47 - 8A - Time of study (hh:mm:ss) word 54 - 32A - Patient name word 70 - 12A - Patient ID word 78 - 3A - Age xxx years or xxD or W or M or Y word 80 - 1A - Sex block 8 - series header word 31 - 3A - Series number word 52 - 120A - Series description word 112 - Int - Series type (0=normal,1=screensave, 2=composite) word 113 - Int - Coil type (0=head,1=body,2=surface) word 114 - 16A - Coil name word 122 - Int - Contrast description word 138 - Int - Plane type (0=axial,1=sagittal,2=coronal, 3=oblique,4=screen save) word 147 - Int - Image mode (0=2D single,1=2D multiple, 2=3D volume,3=cine,4=spectroscopy) word 148 - Int - Field strength (gauss) word 149 - Int - Pulse sequence (0=memp,1=ir,2=ps,3=rm, 4=rmge,5=gre,6=vemp,7=mpgr,8=mpgrv, 9=mpirs,10=mpiri,11=3d/gre, 12=cine/gre,13=spgr,14=sspf, 15=cin/spgr,16=3d/spgr,17=fse, 18=fve,19=fspgr,20=fgr,21=fmpspgr, 22=fmpgr,23=fmpir,24=probe.s, 25=probe.p) word 150 - Int - Pulse sequence subtype (0=chopper) word 151 - Real - Field of view mm word 153 - Real - Center (3 values;R+L-,A+P-,S+I-) word 159 - Int - Orientation (0=supine,1=prone,2=Lt,3=Rt) word 160 - Int - Position (0=head first,1=feet first) word 161 - 32A - Longitudinal anatomical reference word 177 - 32A - Vertical anatomical reference word 199 - Int - Scan matrix X word 200 - Int - Scan matrix Y word 201 - Int - Image matrix block 10 - image header word 44 - Int - Image number word 73 - Real - Image location word 75 - Real - Table position word 77 - Real - Image thickness word 79 - Real - Image spacing word 82 - Real - TR word 86 - Real - TE word 88 - Real - TI word 98 - Int - Number of echos word 99 - Int - Echo number word 101 - Int - NEX (if not fractional) word 146 - Real - NEX word 146 - Int - Flip angle 3.3.1.1.2 Tape format 3.3.1.1.3 Raw data 3.3.1.2 Signa 5X - Genesis General Electric now uses the same architecture for its Advantage 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 Image data Genesis is system running on the Sun Sparc processor under SunOS 4.1.X (NOT Solaris). It would appear that unlike in the previous Data General based system, the active database is stored as one large monolithic file (? /usr/g/genesis_Data) which doesn't make it very easy to extract single imgaes. Fortunately, GE have saved the day by kindly providing, and thoroughly documenting in the material that they send you when you ask for the image file format, an Image Extract Tool that lives in "/usr/g/insite/bin" and is called "ximg". To see what options are available just type "ximg -h" for help. Note that ximg's default is to strip out the patient's name and ID number which is annoying, so don't forget the "-s" flag. The default directory to put the extracted images in is "/usr/g/insite/tmp". The input names to select images in silent (non-menu) mode are of the following form: EeeeeeSsssIiii eeeee = exam number or "all" sss = series number or "all" iii = image number or "all" and the resultant filenames are the same with an extension of ".MR" or ".CT" depending. For example: % /usr/g/insite/bin/ximg -i e673s1i1 -st % ls -l /usr/g/insite/tmp E673S1I1.MR which extracts the selected image in silent mode (-i) without stripping the identification (-s) in rectangular (-t) mode, ie. not compressed or packed. One nifty feature that allows you to keep up to date with the latest version header contents is the "-g" switch which invokes the GenIncl utility that produces a file called "imageFileOffsets.h" that lists the type and offsets of each field in the header ! Remarkable, huh ? How does one get access to the operating system on the Signa ? Let me count the ways. First, from the Advantage console one can just call up a command shell from the Utilities menu, or one can invoke the Ftp option uner Networks and then use the "!" command to ftp, which like in many Unix tools, spawns a shell. Or from another workstation on the network one can just telnet or rsh across. If you are connected using an Advantage Windows workstation you can pull up a command shell by using the right menu button with the cursor on the desktop. Doing a few "cat /etc/hosts" around the place will let you know what all the machines are called. 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: sun4 sparc data types: short is 16 bits int is 32 bits float is 32 bits IEEE double is 64 bits IEEE byte offsets from 0 start of file length ==0 means header absent/empty control header (offset 0): 0 - int - magic number = 0x494d4746 = "IMGF" 4 - int - byte displacement to pixel data 8 - int - width 12 - int - height 16 - int - depth (bits) 20 - int - compression (0=asis,1=rectangular,2=packed, 3=compressed,4=compressed&packed) 32 - int - background shade to use for non-image 54 - u_short - 16 bit end_around_carry sum of pixels 56 - int - ptr to unique image identifier 60 - int - length of unique image identifier 64 - int - ptr to unpack header 68 - int - length of unpack header 72 - int - ptr to compression header 76 - int - length of compression header 80 - int - ptr to histogram header 84 - int - length of histogram header 88 - int - ptr to text plane 92 - int - length of text plane 96 - int - ptr to graphics plane 100 - int - length of graphics plane 104 - int - ptr to data base header 108 - int - length of data base header 112 - int - value to add to stored pixels 116 - int - ptr to user defined data 120 - int - length of user defined data 124 - int - ptr to suite header 128 - int - length of suite header 132 - int - ptr to exam header 136 - int - length of exam header 140 - int - ptr to series header 144 - int - length of series header 148 - int - ptr to image header 152 - int - length of image header unpack header: // used when compression is packed, or compressed & packed // contains perimeter encoding map ... cf. GE 9800 struct { short pixels_to_left_of_line; short pixels_in_stored_line; } table [height_of_image]; compression header: Not necessary for decompressing entire image ... rather it contains seeds for various "strips" of the image to allow jumping into the compressed pixel data ... see the GE docs. histogram header: Contains statistical information for determining optimum windowing ... see the GE docs and GenIncl produced header exam header: 0 - char[4] - suite ID 8 - u_short - exam number 84 - char[13] - patient ID 97 - char[25] - patient name 122 - short - patient age 126 - short - patient sex 305 - char[3] - exam type - "MR" or "CT" series header: 10 - short - series number 84 - char[3] - anatomical reference 92 - char[25] - scan protocol name image header - for MR (1022 bytes long): 12 - short - image number 26 - float - slice thickness mm 30 - short - matrix size - X 32 - short - matrix size - Y 34 - float - display field of view - X (mm) 38 - float - display field of view - Y (mm) 42 - float - image dimension - X 46 - float - image dimension - Y 50 - float - pixel size - X 54 - float - pixel size - Y 72 - char[17] - iv contrast agent 89 - char[17] - oral contrast agent 194 - int - repetition time(usec) 198 - int - inversion time(usec) 202 - int - echo time(usec) 210 - short - number of echoes 212 - short - echo number 218 - float - NEX 308 - char[33] - pulse sequence name 362 - char[17] - coil name 640 - short - ETL for FSE So much for the headers. Now how does one deal with the image data ? The easiest way of course is to save it as "retangular", 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; rowfrom 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= 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 but then is running on an old machine that can only map 64Kb of memory at a time after all. It is apparently multitasking. Documentation may still be available >from Data General (try DG Direct) but is not supplied with the scanner by GE. If anyone knows where I can find it at a reasonable price let me know. Here is a brief command summary culled from a nifty pocket book from GE for SunOS/Genesis users that compares commands: CHATR - file attributes CRAND - create randomly organized file CDIR - create directory DELETE - files or directories DIR - change directory DISK - free space FILCOM - compare files GDIR - show working directory name GTOD - show date and time LINK - files (symbolic) LIST - directory contents MOVE - a file RENAME - a file SDAT - set date STOD - set time SDUMP - write files to a device SLOAD - read dumped files SPEED - tex editor TYPE - contents of file XFER - copy a file wildcards: '-' is series, '*' is single character 4.1.2.2 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. Hot VMS/Philips news: neelin@pet.mni.mcgill.ca (Peter Neelin) tells me there is an extremely useful tool for fiddling binary files called FILE from DECUS. It allows you to change a file's header information without modifying the content of the file. This then permits ftp, kermit, etc. to do the right thing with Philips .ANI files. It also permits wildcards and does not make a copy of the file (so it is fast). He says also that someone has told him that they succeeded in using convert to fix these files, but his general experience with it is not positive (it will often change the content of the file and it doesn't allow wildcards, in addition to promoting the use of the horrible fdl editor!). If you are interested, you can get FILE through gopher from decus.org (look for the DECUS software library archives, under essential tools). The binary is provided in case you don't have a compiler. Some other useful hints: - To log onto a serial terminal without executing the login command file add "/NOCOM" to the username ... this way you can use the operator console login which often won't require a password. - There is a kermit available for the Vax under VMS (file prefix "vms" in area or tape b) ... I use the "obsolete" version written in Bliss, because it comes from the archives at columbia with a hex encoded executable which can be uploaded just using an ordinary text capture into a file, and doing the same with the short Macro hex program that can then be assembled and used to make the convert into the real executable. Look in places like [SYSEXE] first though to be sure Kermit is not already there. The generic C version of kermit runs under VMS (file prefix "ck" in area or tape f), but not every imaging machine comes with a VMS C compiler, whereas Macro is always supposed to be there I gather. There is however also a hex encoded executable of the C version in the archives (ckvker.hex) which I haven't tried, and is the one that is recommended in the kermit documentation. - There is apparently a zmodem for VMS but I don't know where it comes from or how to get it. - Serial ports are almost always defaulted to 9600 baud. - "SET TERMINAL/ECHO" often isn't set. 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, ACR/NEMA to qsh, et al. - medical image format translation program - automatically identifies and translates heterogeneous files - Motif interface for user browsing & image selection - input formats: - GE 8800 CT, 9800 CT, Advantage CT & MR, Signa MR - Technicare 2000 CT - Positron PET - Philips 300 Series CT - Trionix Triad SPECT - Siemens Somatom CT, Siemens Magnetom MR, CTI PET - Varian CTSIM - ACR-NEMA 1.0, ACR-NEMA 2.0, and AAPM/qsh - output formats: - AAPM/qsh - Interfile - ADAC Interfile - Varian CTSIM - other formats planned, including DICOM 3 David Reddy <--- USA contact Radio Logic, Inc. P.O. Box 9665 New Haven CT 06536 phone (203) 624-8113 email reddy@nucmed.med.nyu.edu Bartec Medical Systems Ltd. <--- UK, Europe & Mideast Impression House Invincible Road Farnborough Hampshire GU14 7NP England email bob@bartec.demon.co.uk 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:ftp.u.washington.edu:/public/razz ACR/NEMA plugin for Adobe Photoshop (works with NIH Image also): ftp:sumex-aim.stanford.edu: /info-mac/Graphic/Utility/photoshop-acr-nema.hqx CT reconstruction software: ftp:peipa.essex.ac.uk:/ipa/src/process /ipa/src/process/ct.tar.Z /ipa/src/process/snark77.tar.Z DICOM conversion tools V0.04: Just posted to alt.sources - should be available by ftp soon (try the alt.sources archives at wustl). DICOM draft standards and demonstration software: ftp: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:ftp.xray.hmc.psu.edu:/dicom_software /dicom_software/Mallinckrodt Mallinkrodt RSNA '93 /dicom_software/European European CEN/TC251/WG4 ftp:rsna.org ftp:wuerlim.wustl.edu:/pub/dicom /pub/dicom/images/version3 sample images ftp:ftp.uni-oldenburg.de:/pub/dicom /pub/dicom/dicom_docs /pub/dicom/dicom_software In the Mallinckrodt software, there are a few sample images ... look in: apps/simple_storage/D19051502.9 apps/simple_storage/D19051513.9 (contain images, but are ACR/NEMA 2 and missing lots of required type 1 and 2 attributes) same in: apps/send_image apps/move_image also: apps/displays/TEST_IMAGES/baby.color.img (contains image, but is not legal DICOM 3 (no UID's)) apps/displays/TEST_IMAGES/ct1.1 (valid DICOM 3 CT IOD (passes Mallinckrodt dcm_verify)) 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 NIH Image - Macintosh image processing software: ftp:zippy.nimh.nih.gov:/pub/nih-image 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 Window level software (12/16 bits ->8): ftp:alvin.ach.uams.edu /pub/winlev.tar.Z Includes images /pub/winlev-noimages.tar.gz 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