Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!canyon.sr.hp.com!col.hp.com!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!news.mathworks.com!gatech!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail From: dclunie@flash.us.com (David A. Clunie) Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 1/8 Followup-To: alt.image.medical Date: 30 Jan 1996 16:03:40 -0500 Organization: Mollard Consultants Lines: 677 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 28 Feb 1996 00:00:00 GMT Message-ID: <4em13c$3ae@flash.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: flash.ksapax Summary: This posting contains answers to the most Frequently Asked Question on alt.image.medical - how do I convert from image format X from vendor Y to something I can use ? In addition it contains information about various standard formats. Xref: senator-bedfellow.mit.edu alt.image.medical:4245 comp.protocols.dicom:1429 sci.data.formats:1399 sci.med.informatics:5238 sci.med.radiology:4949 alt.answers:15295 comp.answers:16736 sci.answers:3818 news.answers:63381 Archive-name: medical-image-faq/part1 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 This message is automatically posted once a month to help readers looking for information about medical image formats. If you don't want to see this posting every month, please add the subject line to your kill file. Contents: part1 - contains index, general information & standard formats part2 - contains standard formats (continued) part3 - contains information about proprietary CT formats part4 - contains information about proprietary MR formats part5 - contains information about proprietary other formats part6 - contains information about hosts & compression part7 - contains information sources part8 - contains information sources (continued) Tools that describe and convert many of the formats described in this document are available in the dicom3tools package from "ftp://ftp.rahul.net/pub/dclunie/". A Mosaic browsable version of this FAQ is available at: "http://www.rahul.net/dclunie/medical-image-faq/html/". Html, postscript and text forms of the FAQ are available at: "ftp://ftp.rahul.net/pub/dclunie/medical-image-faq/". Many FAQs, including this Listing, are available on the archive site rtfm.mit.edu in the directory pub/usenet/news.answers. The name under which a FAQ is archived appears in the Archive-name line at the top of the article. There's a mail server on that machine. You send a e-mail message to mail-server@rtfm.mit.edu containing the keyword "help" (without quotes!) in the message body. To fetch this particular FAQ send a message with the following body: send usenet/news.answers/medical-image-faq/part1 ... send usenet/news.answers/medical-image-faq/part8 Please direct comments or questions and especially contributions to "dclunie@flash.us.com" or reply to this article. All unknown formats and test images gratefully accepted, but please don't email them, rather contact me and we can arrange to exchange documents or disks or tapes by snail mail. Changes this issue Add "impending" Shimadzu MR format. Add UCDMC publically accessible DICOM server site. Add Loral DICOM CS site. Add DICOM IS integration entry for Philips Inturis,Mitra.Intech HiCube. Add DICOM to web gateways from Medweb,Passport. Add Mitra web site. Clean up Picker Conformance Statement links. Add UCDMC Conformance Statement link. Update DesAcc phone number. Add FITS Browser web page. Changes last issue New FDA fax number. Add PET Mail list. Add DICOM to BMP software site. Add Medweb html site. Add Designed Access html site. Add Interformat html site. Add Applicare DICOM conformance site. More medical image sites. Add DICOM Santel web site. Add DICOM Chile web site. Add Medx web site and DICOM dump utility. Add Merge web site and DICOM resource directory. Add Philips entries. The next part is table of contents. Subject: Contents 1. Introduction 1.1 Objective 1.2 Types of Formats 1.3 In Desperation - Quick & Dirty Tricks 2. Standard Formats 2.1 ACR/NEMA 1.0 and 2.0 2.2 ACR/NEMA DICOM 3.0 2.3 Papyrus 2.4 Interfile V3.3 2.5 Qsh 2.6 DEFF 3. Proprietary Formats 3.1 Proprietary Formats - General Information 3.1.1 SPI (Standard Product Interconnect) 3.2 CT - Proprietary Formats 3.2.1 General Electric CT 3.2.1.1 GE CT 9800 3.2.1.1.1 GE CT 9800 Image data 3.2.1.1.2 GE CT 9800 Tape format 3.2.1.1.3 GE CT 9800 Raw data MR 3.2.1.2 GE CT Advantage - Genesis 3.2.1.2.1 GE CT Advantage Image data 3.2.1.2.2 GE CT Advantage Archive format 3.2.1.2.3 GE CT Advantage Raw data 3.2.1.3 GE CT Pace 3.2.1.4 GE CT Sytec 3.2.2 Siemens CT 3.2.2.1 Siemens Somatom DR 3.2.2.2 Siemens Somatom Plus 3.2.2.3 Siemens Somatom AR 3.2.3 Philips CT 3.2.4 Picker CT 3.2.5 Toshiba CT 3.2.6 Hitachi CT 3.2.7 Shimadzu CT 3.2.8 Elscint CT 3.3 MR - Proprietary Formats 3.3.1 General Electric MR 3.3.1.1 GE MR Signa 3.x,4.x 3.3.1.1.1 GE MR Signa 3.x,4.x Image data 3.3.1.1.2 GE MR Signa 3.x,4.x Tape format 3.3.1.1.3 GE MR Signa 3.x,4.x Raw data 3.3.1.2 GE MR Signa 5.x - Genesis 3.3.1.2.1 GE MR Signa 5.x Image data 3.3.1.2.2 GE MR Signa 5.x Archive format 3.3.1.2.3 GE MR Signa 5.x Raw data 3.3.1.3 GE MR Max 3.3.1.4 GE MR Vectra 3.3.2 Siemens MR 3.3.2.1 Siemens Magnetom GBS/GBS II 3.3.2.1.1 Siemens Magnetom GBS/GBS II Native Format 3.3.2.1.2 Siemens Magnetom GBS/GBS II SPI Format 3.3.2.2 Siemens Magnetom SP 3.3.2.2.1 Siemens Magnetom SP Native Format 3.3.2.2.2 Siemens Magnetom SP SPI Format 3.3.2.3 Siemens Magnetom Impact 3.3.2.3.1 Siemens Magnetom Impact Native Format 3.3.2.3.2 Siemens Magnetom Impact SPI Format 3.3.2.4 Siemens Magnetom Vision 3.3.2.4.1 Siemens Magnetom Vision Native Format 3.3.2.4.2 Siemens Magnetom Vision SPI Format 3.3.3 Philips MR 3.3.3.1 Philips Gyroscan S5 3.3.3.2 Philips Gyroscan ACS 3.3.3.3 Philips Gyroscan T5 3.3.3.4 Philips Gyroscan NT5 & NT15 3.3.4 Picker MR 3.3.5 Toshiba MR 3.3.6 Hitachi MR 3.3.7 Shimadzu MR 3.3.8 Elscint MR 3.4 Proprietary Workstations 3.4.1 ISG Workstations 3.4.1.1 Gyroview 3.5 Other Proprietary Formats 3.5.1 Analyze From Mayo 4. Host Machines 4.1 Data General 4.1.1 Data General Data 4.1.1.1 Data General Integers 4.1.1.2 Data General Floating Point 4.1.2 Data General Operating System 4.1.2.1 Data General RDOS 4.1.2.2 Data General AOS/VS 4.1.3 Data General Network 4.2 Vax 4.2.1 Vax Data 4.2.1.1 Vax Integers 4.2.1.2 Vax Floating Point 4.2.1.3 Vax Strings 4.2.2 Vax Operating System 4.2.2.1 Vax VMS 4.2.2.2 ULTRIX 4.2.2.3 OSF 4.3 Sun - Sun3 68000 and Sun4 Sparc 4.3.1 Sun Data 4.3.1.1 Sun Integers 4.3.1.2 Sun Floating Point 4.3.1.3 Sun Strings 4.3.2 Sun Operating System 5. Compression Schemes 5.1 Reversible Compression 5.2 Irreversible Compression 5.2.1 Perimeter Encoding 6. Getting Connected 6.1 Tapes 6.2 Ethernet 6.3 Serial Ports 7. Sources of Information 7.1 Vendor Contacts 7.2 Relevant FAQ's 7.3 Source Code 7.4 Commercial Offerings 7.5 FTP/WWW sites 7.6 Mailservers 7.7 References 7.8 Organizations and Societies 7.9 Usenet Newsgroups 8. Acknowledgements The next part is part1 - general information & standard formats. 1. Introduction 1.1 Objective The goal of this FAQ is to facilitate access to medical images stored on digital imaging modalities such as CT and MR scanners, and their accompanying descriptive information. The document is designed particularly for those who do not have access to the necessary proprietary tools or descriptions, particularly in those moments when inspiration strikes and one just can't wait for the local sales person to track down the necessary authority and go through the cycle of correspondence necessary to get a non-disclosure agreement in place, by which time interest in the project has usually faded, and another great research opportunity has passed! It may also be helpful for those keen to experiment with home-grown PACS-like systems using their existing equipment, and also for those who still have equipment that is still useful but so old even the host computer vendor doesn't support it any more! There is of course no substitute for the genuine tools or descriptions from the equipment vendors themselves, and pointers to helpful individuals in various organizations, as well as names and catalog numbers of various useful documents, are included here where known. In addition there are several small companies that specialize in such connectivity problems that have a good reputation and are well known. Contact information is provided for them, though I personally have no experience with their products and am not endorsing them. Finally, great care has been taken not to include any information that has been released under non-disclosure agreements. What is included here is the result of either information freely released by vendors, handy hints from others working in the field, or in many cases close scrutiny of hex dumps and experimentation with scanner parameters and study of the effects on the image files. The intent is to spread hard-earned knowledge gained over many years amongst those new to the field or a particular piece of equipment, not to threaten anyone's proprietary interests, or to substitute for the technical support available from vendors that ranges from free to extortionate, and excellent to abysmal, depending on who your are dealing with and where in the world you are located! Please use this information in the spirit in which is intended, and where possible contribute whatever you know in order to expand the information to cover more vendors and equipment. 1.2 Types of Formats Later sections will deal with the problems of getting the image files from the modality to the workstation, but for the moment assume the files are there and need to be deciphered. Four types of information are generally present in these files: - image data, which may be unmodified or compressed, - patient identification and demographics, - technique information about the exam, series, and slice/image. Extracting the image information alone is usually straightforward and is described in 1.3. Dealing with the descriptive information, for example to make use of the data for dissemination in a PACS environment, or to extract geometry details in order to combine images into 3D datasets, is more difficult and requires deeper understanding of how the files are constructed. There are three basis families of formats that are in popular use: - fixed format, where layout is identical in each file, - block format, where the header contains pointers to information, - tag based format, where each item contains its own length. The block format is one of the most popular, though in most cases, the early part of the header contains only a limited number of pointers to large blocks, the blocks are almost always in the same place and a constant length, for standard rather than reformatted images at least, and if one doesn't know the specifics of the layout one can get by assumming a fixed format. I presume this reflects the intent of the designers to handle future expansion and revision of the format. The example par excellence of the tag based format is the ACR/NEMA style of data stream, which, though never intended as a file format per se has proven useful as model. See for example the sections dealing with the ACR/NEMA standards as well as DICOM (whose creators are about to vote on a media interchange format after all this time) and Papyrus. ACR/NEMA style tags are described in more detail elsewhere, but each is self-contained and self-describing (at least if you have the appropriate data dictionary) and contains its own length, so if you can't interpret it you can skip it! Very convenient. Most file formats based on this scheme are just concatenated series of tags, and apart from having to guess the byte order, which is not specified (unlike TIFF which is a similar deal for those in the "real" imaging world), and sometimes skip a fixed length but short header, are dead easy to handle. To identify such a file just do a "strings | ______________ ______________ ______________ ______________ |XXXXXXXXXXXXXX| | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 --------------------------- Bits Allocated = 16 Bits Stored = 12 High Bit = 15 |<------------------ pixel ----------------->| ______________ ______________ ______________ ______________ | | | |XXXXXXXXXXXXXX| |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 --------------------------- Bits Allocated = 12 Bits Stored = 12 High Bit = 11 ------ 2 ----->|<------------------ pixel 1 --------------->| ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 -------------- 3 ------------>|<------------ 2 -------------- ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 |<------------------ pixel 4 --------------->|<----- 3 ------ ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 --------------------------- And so on ... refer to the standard itself for more detail. The next part is part2 - standard formats (continued). Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!munnari.OZ.AU!news.mel.connect.com.au!yarrina.connect.com.au!news.mira.net.au!Germany.EU.net!EU.net!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail From: dclunie@flash.us.com (David A. Clunie) Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 2/8 Followup-To: alt.image.medical Date: 30 Jan 1996 16:03:48 -0500 Organization: Mollard Consultants Lines: 439 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 28 Feb 1996 00:00:00 GMT Message-ID: <4em13k$3b0@flash.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: flash.ksapax Summary: This posting contains answers to the most Frequently Asked Question on alt.image.medical - how do I convert from image format X from vendor Y to something I can use ? In addition it contains information about various standard formats. Xref: senator-bedfellow.mit.edu alt.image.medical:4242 comp.protocols.dicom:1425 sci.data.formats:1397 sci.med.informatics:5236 sci.med.radiology:4947 alt.answers:15293 comp.answers:16734 sci.answers:3816 news.answers:63379 Archive-name: medical-image-faq/part2 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 2.2 ACR/NEMA DICOM 3.0 ACR/NEMA Standards Publications No. PS 3.1-1992 <- DICOM 3 - Introduction & Overview No. PS 3.8-1992 <- DICOM 3 - Network Communication Support No. PS 3.2-1993 <- DICOM 3 - Conformance No. PS 3.3-1993 <- DICOM 3 - Information Object Definitions No. PS 3.4-1993 <- DICOM 3 - Service Class Specifications No. PS 3.5-1993 <- DICOM 3 - Data Structures & Encoding No. PS 3.6-1993 <- DICOM 3 - Data Dictionary No. PS 3.7-1993 <- DICOM 3 - Message Exchange No. PS 3.9-1993 <- DICOM 3 - Point-to-Point Communication No. PS 3.10-???? <- DICOM 3 - Media Storage & File Format No. PS 3.11-???? <- DICOM 3 - Media Storage Application Profiles No. PS 3.12-???? <- DICOM 3 - Media Formats & Physical Media DICOM (Digital Imaging and Communications in Medicine) standards are of course the hot topic at every radiological trade show. Unlike previous attempts at developing a standard, this one seems to have the potential to actually achieve its objective, which in a nutshell, is to allow vendors to produce a piece of equipment or software that has a high probability of communicating with devices from other vendors. Where DICOM differs substantially from other attempts, is in defining so called Service-Object Pairs. For instance if a vendor's MR DICOM conformance statement says that it supports an MR Storage Class as a Service Class Provider, and another vendor's workstation says that it supports an MR Storage Class as a Service Class User, and both can connect via TCP/IP over Ethernet, then the two devices will almost certainly be able to talk to each other once they are setup with each others network addresses and so on. The keys to the success of DICOM are the use of standard network facilities for interconnection (TCP/IP and ISO-OSI), a mechanism of association establishment that allows for negotiation of how messages are to be transferred, and an object-oriented specification of Information Objects (ie. data sets) and Service Classes. Of course all this makes for a huge and difficult to read standard, but once the basic concepts are grasped, the standard itself just provides a detailed reference. From the users' and equipment purchasers' points of view the important thing is to be able to read and match up the Conformance Statements from each vendor to see if two pieces of equipment will talk. Just being able to communicate and transfer information is of course not sufficient - these are only tools to help construct a total system with useful functionality. Because a workstation can pull an image off an MRI scanner doesn't mean it knows when to do it, when the image has become available, to which patient it belongs, and where it is subsequently archived, not to mention notifying the Radiology or Hospital Information System (RIS/HIS) when such a task has been performed. In other words DICOM Conformance does not guarantee functionality, it only facilitates connectivity. In otherwords, don't get too carried away with espousing the virtues of DICOM, demanding it from vendors, and expecting it to be the panacea to create a useful multi-vendor environment. Fred Prior (prior@xray.hmc.psu.edu) has come up with the concept of a User Conformance Statement to be generated by purchasers and to be satisfied by vendors. The idea is that one describes what one expects and hence gives the vendor a chance to realistically satisfy the buyer! Of course each such statement must be tailored to the user's needs, and simply stapling a copy of Fred's statement to a Request For Proposals is not going to achieve the desired objective. Caveat empor. To get more information about DICOM: - Purchase the standards from NEMA. - Ftp the final versions of the drafts in electronic form one of the sites described below. - Follow the Usenet group comp.protocols.dicom. - Get a copy of "Understanding DICOM 3.0" $12.50 from Kodak. - Insist that your existing and potential vendors supply you with DICOM conformance statements before you upgrade or purchase, and don't buy until you know what they mean. Don't take no for an answer!!!! What is all this doing in an FAQ about medical image formats you ask ? Well first of all, in many ways DICOM 3.0 will solve future connectivity problems, if not provide functional solutions to common problems. Hence actually getting the images from point A to B is going to be easier if everyone conforms. Furthermore, for those of us with old equipment, interfacing it to new DICOM conforming equipment is going to be a problem. In otherwords old network solutions and file formats are going to have to be transformed if they are going to communicate unidirectionally or bidirectionally with DICOM 3.0 nodes. One is still faced with the same old questions of how does one move the data and how does one interpret it. The specifics of the DICOM message format are very similar to the previous versions of ACR/NEMA on which it is based. The data dictionary is greatly extended, and certain data elements have been "retired" but can be ignored gracefully if present. The message itself can now be transmitted as a byte stream over networks, rather than using a point-to-point paradigm excusively (though the old point-to-point interface is available). This message can be encoded in various different Transfer Syntaxes for transmission. When two devices ("Application Entities" or AE) begin to establish an "Association", they negotiate an appropriate transfer syntax. They may choose an Explicit Big-Endian Transfer Syntax in which integers are encoded as big-endian and where each data element includes a specific field that says "I am an unsigned 16 bit integer" or "I am an ascii floating-point number", or alternatively they can fall back on the default transfer syntax which every AE must support, the Implicit Little-Endian Tra This is all very well if you are using DICOM as it was originally envisaged - talking over a network, negotiating an association, and determining what Transfer Syntax to use. What if one wants to store a DICOM message in a file though ? Who is to say which transfer syntax one will use to encode it offline ? One approach, used for example by the Central Test Node software produced by Mallinkrodt and used in the RSNA Inforad demonstrations, is just to store it in the default little-endian implicit syntax and be done with it. This is obviously not good enough if one is going to be mailing tapes, floppies and optical disks between sites and vendors though, and hence the DICOM group decided to define a "Media Storage & File Format" part of the standard, the new Parts 10, 11 and 12 which have recently passed their ballot and shoul;d be available in final form from NEMA soon. Amongst other things, Part 10 defines a generic DICOM file format that contains a brief header, the "DICOM File Meta Information Header" which contains a 128 byte preamble (that the user can fill with anything), a 4 byte DICOM prefix "DICM", then a short DICOM format message that contains newly defined elements of group 0002 in a specified Transfer Syntax, which uniquely identify the data set as well as specifying the Transfer Syntax for the rest of the file. The rest of the message must specify a single SOP instance. The length of the brief message in the Meta Header is specified in the first data element as usual, the group length. Originally the draft of Part 10 specified the default Implicit Value Representation Little Endian Transfer Syntax as the DICOM File Meta Information Header Transfer Syntax, which is in keeping with the concept that it is the default for all other parts of the standard. The final standard has changed this to Explicit Value Representation Little Endian Transfer Syntax. This seems like an extremely irritating change to me but I guess purists have prevailed. So what choices of Transfer Syntax does one have and why all the fuss ? Well the biggest distinction is between implicit and explicit value representation which allows for multiple possible representations for a single element, in theory at least, and perhaps allows one to make more of an unknown data element than one otherwise could perhaps. Some purists (and Interfile people) would argue that the element should be identified descriptively, and there is nothing to stop someone from defining their own private Transfer Syntax that does just that (what a heretical thought, wash my mouth out with soap). With regard to the little vs. big endian debate I can't see what the fuss is about, as it can't really be a serious performance issue. Perhaps more importantly in the long run, the Transfer Syntax mechanism provides a means for encapsulating compressed data streams, without having to deal with the vagaries and mechanics of compression in the standard itself. For example, if DICOM version 3.0, in addition to the "normal" Transfer Syntaxes, a series are defined to correspond to each of the Joint Photographic Experts Group (JPEG) processes. Each one of these Transfer Syntaxes encodes data elements in the normal way, except for the image pixel data, which is defined to be encoded as a valid and self-contained JPEG byte stream. Both reversible and irreversible processes of various types are provided for, without having to mess with the intricacies of encoding the various tables and parameters that JPEG processes require. Presumably a display application that supports such a Transfer Syntax will just chop out the byte stream, pass it to the relevant JPEG decode, and get an uncompressed image back. More importantly, an archive server can s Now one may not like the JPEG standard, but one cannot argue with the fact that the scheme is workable, and a readily available means of reversible compression has been incorporated painlessly. How effective a compression scheme this is remains to be determined, and whether or not the irreversible modes gain wide acceptance will be dictated by the usual medico-legal paranoia that prevails in the United States, but the option is there for those who want to take it up. There is of course no reason why private compression schemes cannot be readily incorporated using this "encapsulation" mechanism, and to preserve bandwidth this will undoubtedly occur. This will not compromise compatibility though, as one can always fall back to a default, uncompressed Transfer Syntax. The DICOM Working Group IV on compression will undoubtedly bring out new possibilities. Currently there is a lot of interest in RLE (Run Length Encoded) compression, particularly from the Ultrasound group. In order to identify all these various syntaxes, information objects, and so on, DICOM has adopted the ISO concept of the Unique Identifier (UID) which is a text string of numbers and periods with a unique root for each organization that is registered with ISO and various organizations that in turn register others in a hierarchical fashion. For example 1.2.840.10008.1.2 is defined as the Implicit VR Little Endian Transfer Syntax. The 1 identifies ISO, the 2 is the ISO member body branch, the 840 is the specific member body country code, in this case ANSI, and the 10008 is registered by ANSI to NEMA for DICOM. UID's are also used to uniqely identify non-DICOM specific things, such as information objects. These are constructed from a prefix registered to the supplier or vendor or site, and a unique suffix that may be generated from say a date and time stamp (which is not to be parsed). For example an instance of a CT information object might have a UID of 1.2.840.123456.002.999999.940623.170717 where The other important new concept that DICOM introduced was the concept of Information Objects. In the previous ACR/NEMA standard, though modalities were identified by a specific data element, and though there were rules about which data elements were mandatory, conditional or optional in ceratin settings, the concept was relatively loosely defined. Presumably in order to provide a mechanism to allow conformance to be specified and hence ensure interoperability, various Information Objects are defined that are composed of sets of Modules, each module containing a specific set of data elements that are present or absent according to specific rules. For example, a CT Image Information Object contains amongst others, a Patient module, a General Equipment module, a CT Image module, and an Image Pixel module. An MR Image Information module would contain all of these except the CT Image module which would be replaced by an MR Image module. Clearly one needs descriptive information about a CT image that is di Hence, as described earlier, one can define pairs of Information Objects and Services that operate on such objects (Storage, Query/Retrieve, etc.) and one gets SOP classes and instances. All very object oriented and initially confusing perhaps, but it provides a mechanism for specifying conformance. From the point of view of an interpreters of a DICOM compatible data stream this means that for a certain instance of an Information Object, certain information is guaranteed to be in there, which is nice. As a creator of such a data stream, one must ensure that one follows all the rules to make sure that all the data elements from all the necessary modules are present. Having done so one then just throws all the data elements together, sorts them into ascending order by group and element order, and pumps them out. It is a shame that the data stream itself doesn't reflect the underlying order in the Information Objects, but I guess they had to maintain backward compatibility, hence this little bit of ugli At this point I am tempted to include more details of various different modules, data elements and transfer syntaxes, as well as the TCP/IP mechanism for connection. However all this information is in the standard itself, drafts of which are readily available electronically from ftp sites, and in the interests of brevity I will not succumb to temptation at this time. 2.3 Papyrus Papyrus is an image file format based on ACR/NEMA version 2.0. It was developed by the Digital Imaging Unit of the University Hospital of Geneva for the European project on telemedicine (TELEMED project of the RACE program), under the leadership of Dr. Osman Ratib (osman@cih.hcuge.ch). The University Hospital of Geneva uses Papyrus for their hospital-wide PACS. The medical file format component of Papyrus version 2 extended the ACR/NEMA format, particularly in order to reference multiple images by placing folder information referencing ACR-NEMA data sets in a shadow (private) group. Contributing to the development of DICOM 3, the team are updating their format to be compatible with the offline file format provisions of the draft Part 10 of DICOM 3 in Papyrus version 3. The specifications, toolkit and image manipulation software that is Papyrus aware, Osiris, is available for the Mac, Windows, and Unix/X11/Motif by ftp from ftp://expasy.hcuge.ch/pub/Osiris. See also Papyrus and Osiris ftp site. Further information is available in printed form. Contact yves@cih.hcuge.ch (Yves Ligier). 2.4 Interfile V3.3 Interfile is a "file format for the exchange of nuclear medicine image data" created I gather to satisfy the needs of the European COST B2 Project for the transfer of images of quality control phantoms, and incorporates the AAPM (American Association of Physicists in Medicine) Report No. 10, and has been subsequently used for clinical work. It specifies a file format composed of ascii "key-value" pairs and a data dictionary of keys. The binary image data may be contained in the same file as the "administrative information", or in a separate file pointed to by a "name of data file" key. Image data may be binary integers, IEEE floating point values, or ascii and the byte order is specified by a key "imagedata byte order". The order of keys is defined by the Interfile syntax which is more sophisticated than a simple list of keys, allowing for groups, conditionals and loops to dictate the order of key-value pairs. Conformance to the Interfile standard is informally described in terms of which types of image data types, pixel types, multiple windows, special Interfile features including curves, and restriction to various maximum recommended limits. Interfile is specifically NOT a communications protocol and strictly deals with offline files. There are efforts to extend Interfile to include modalities other than nuclear medicine, as well as to keep ACR/NEMA and Interfile data dictionaries in some kind of harmony. A sample list of Interfile 3.3 key-value pairs is shown here to give you some idea of the flavor of the format. The example is culled from part of a Static study in the Interfile standard document and is not complete: !INTERFILE := !imaging modality :=nucmed !version of keys :=3.3 data description :=static patient name :=joe doe !patient ID :=12345 patient dob :=1968:08:21 patient sex :=M !study ID :=test exam type :=test data compression :=none !image number :=1 !matrix size [1] :=64 !matrix size [2] :=64 !number format :=signed integer !number of bytes per pixel :=2 !image duration (sec) :=100 image start time :=10:20: 0 total counts :=8512 !END OF INTERFILE := One can see how easy such a format would be to extend, as well as how it is readable and almost useable without reference to any standard document or data dictionary. Undoubtedly ACR/NEMA DICOM 3.0 to Interfile translators will soon proliferate in view of the fact that many Nuclear Medicine vendors supply Interfile translators at present. To get hold of the Interfile 3.3 standard, see the Interfile sources, Interfile information contacts and Interfile mailing list described later in this document. 2.5 Qsh Qsh is a family of programs for manipulating images, and it defines an intermediate file format. The following information was derived with the help of one of the authors maguire@it.kth.se(Chip Maguire): Uses an ASCII key-value-pair (KVP sic.) system, based on the AAPM Report #10 proposal. This format influenced both Interfile and ACR-NEMA (DICOM). The file format is referred to as "IMAGE" in some of their articles (see references). The header and the image data are stored as two separate files with extensions *.qhd and *.qim respectively. Qsh is available by anonymous ftp from the Qsh ftp site. This is a seriously large tar file, including as it does some sample images, and lots of source code, as well as some post-script documents. Subtrees are available as separate tar files. QSH's Motif-based menu system (qmenu) will work with OpenWindows 3.0 if SUN patch number 100444-54 for SUNOS 4.1.3 rev. A is applied. The patch is available from ftp://sunsolve1.sun.com (192.9.9.24). The image access subroutines take the same parameters as the older /usr/image package from UNC, however, the actual subroutines support the qsh KVP and image data files. The frame buffer access subroutines take the same parameters as the Univ. of Utah software (of the mid. 1970s). The design is based on the use of a virtual frame buffer which is then implemented via a library for a specific frame buffer. There exists a version of the the display routines for X11. Conversions are not supported any longer, instead there is a commercial product called InterFormat. InterFormat includes a qsh to Interfile conversion, along with DICOM to qsh, and many others. Information is available from reddy@nucmed.med.nyu.edu (David Reddy) (see InterFormat in the Sources section). [Editorial note: this seems a bit of a shame to me - the old distribution included lots of handy bits of information, particularly on driving tape drives. I am advised however that the conversion stuff was pulled out because people wanted it supported, the authors were worried they were disclosing things perhaps they ought not to be, and NYU had switched to using InterFormat themselves anyway. DAC.] The authors of the qsh package are: - maguire@it.kth.se (Gerald Q. (Chip) Maguire) - noz@nucmed.NYU.EDU (Marilyn E Noz) The following references are helpful in understanding the philosophy behind the file format, and are included in postscript form in the qsh ftp distribution: @Article[noz88b, Key=, 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= ] 2.6 DEFF DEFF (Data Exchange File Format) is a portable image file format designed for the exchange, printing and archiving of ultrasound images. It is written by John Bono of ATL from whom the specification may be obtained. The latest version is 2.5, March 25, 1994. It is based on the TIFF 5.0 specification, though a more recent version, TIFF 6.0 is available. Theorectically, any TIFF reader should be able to read the standard tags from a DEFF image, so long as only 8 bit images are in use, as in the Camera Ready class of DEFF images for instance. Additional support is provided for multi-frame images, and 9 to 16 bit images by extending the TIFF format. Because Aldus only allocates a small number of unique registered tags to each vendor, ATL have defined their own extensive set of additional tags, which are referenced by using one of the registered tags ExtendedTagsOffset. Hence these additional tags will not be visible to a conventional TIFF reader. The next part is part3 - proprietary CT formats. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!news.mathworks.com!gatech!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail From: dclunie@flash.us.com (David A. Clunie) Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 3/8 Followup-To: alt.image.medical Date: 30 Jan 1996 16:03:56 -0500 Organization: Mollard Consultants Lines: 1121 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 28 Feb 1996 00:00:00 GMT Message-ID: <4em13s$3bl@flash.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: flash.ksapax Summary: This posting contains answers to the most Frequently Asked Question on alt.image.medical - how do I convert from image format X from vendor Y to something I can use ? In addition it contains information about various standard formats. Xref: senator-bedfellow.mit.edu alt.image.medical:4246 comp.protocols.dicom:1430 sci.data.formats:1400 sci.med.informatics:5239 sci.med.radiology:4950 alt.answers:15296 comp.answers:16737 sci.answers:3819 news.answers:63382 Archive-name: medical-image-faq/part3 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 3. Proprietary Formats 3.1 Proprietary Formats - General Information 3.1.1 SPI (Standard Product Interconnect) Used for files exported from: - Siemens Somatom Plus - Siemens Magnetom Impact - Siemens Magnetom SP - Siemens Magnetom Vision - Philips Gyroscan S5 - ? what else ? SPI is a standard based on the old ACR/NEMA 1 standard, devised I gather by Siemens and Philips, for use in a PACS environment. Who currently maintains it and whether or not Sienet PACS systems are based on it, I am not certain. Many machines in the workplace use it in some shape or form, or can export files in SPI format. I gather it has been around since 1987 or so, but I do not yet have access to the reference documents, nor permission to disclose their contents, so much of the following is guess work or hearsay from Usenet. Like the ACR/NEMA standard, SPI is designed to define interconnections between pieces of equipment from the physical level through to the application level. Where appropriate it utilized relevant parts of ACR/NEMA. Unlike ACR/NEMA, I gather that SPI is aware of the concept of networks, objects containing information, the need to uniquely identify instances of objects, and defines an offline file format. Thus in many ways it sounds like the missing link between ACR/NEMA 2.0 and DICOM 3.0. SPI makes use of ACR/NEMA data elements and groups, and in addition provides "shadow" private odd-numbered groups as dictated by the ACR/NEMA standard for the purpose of storing additional items of information, including a means of uniquely identifying objects, as well as allowing for enumerated values for elements beyond those defined by ACR/NEMA. SPI also defines a byte order for offline storage of data streams. Integers are stored in little endian format (least significant byte first). The private groups mechanism works as follows. For each odd numbered group (other than 0x0001,0x0003,0x0005,0x0007 and 0xffff), the elements 0x00nn in the range 0x0010 through 0x00ff contain a single valued string identification code that identifies the creator of the range of elements 0xnn00 through 0xnnff. Neat eh ? For example: (0x0009,0x0010) PrivateCreatorDataElement (0x0009,0x0011) PrivateCreatorDataElement ... (0x0009,0x1000) DavidElement1 (0x0009,0x1001) DavidElement2 ... (0x0009,0x1100) HarryElement1 (0x0009,0x1101) HarryElement2 You get the idea. The nice thing about this scheme is that each creator dictionary considers its elements numbered from 0x0000, but these will be remapped to a block of elements depending on exactly which PrivateCreatorDataElement is used in the particular data set. Hence multiple groups from different creators can co-exist happily in the same data set, and vary in position between data sets. Note that the group number IS taken into consideration ... a private element with the same element offset and the same creator will have a different meaning depending on which group it is in. SPI uses this concept extensively and defines a large dictionary with different creators with convoluted names for different modalities and PACS operations. A few sample elements are described here. Particularly important are those elements for purposes that were not envisaged when ACR/NEMA 1 was written, but are necessary to create valid DICOM 3 data sets. Such things as FlipAngle for MR scans for example. Note that the SPI UID is not the same as a DICOM UID, but presumably it is unique ! Note also that the creator of "SPI RELEASE 1" is the same as "SPI Release 1" and "SPI" ... presumably someone messed up between machines or modalities or manufacturers. For a more extensive SPI data dictionary see the DICOM conversion tools. The value representation fields are shown here using the modern DICOM equivalents rather than the older, less specific ACR/NEMA names. The "owner" is what is used as the string value of the PrivateCreatorDataElement when a range of elements in a group is claimed. Element Owner Name VR VM (0009,0010) SPI Comments LO 1 (0009,0015) SPI UID LO 1 (0009,0010) SIEMENS MED RecognitionCode LO 1 (0011,0010) SPI RELEASE 1 Organ LO 1 (0011,0015) SPI RELEASE 1 AllergyIndication LO 1 (0011,0020) SPI RELEASE 1 Pregnancy LO 1 (0011,0010) SIEMENS CM VA0 CMS RegistrationDate DA 1 (0011,0011) SIEMENS CM VA0 CMS RegistrationTime TM 1 (0011,0023) SIEMENS CM VA0 CMS UsedPatientWeight IS 1 (0013,0020) SIEMENS CM VA0 CMS PatientName LO 1 (0013,0022) SIEMENS CM VA0 CMS PatientId LO 1 (0013,0030) SIEMENS CM VA0 CMS PatientBirthdate LO 1 (0013,0031) SIEMENS CM VA0 CMS PatientWeight DS 1 (0013,0035) SIEMENS CM VA0 CMS PatientSex LO 1 (0013,0040) SIEMENS CM VA0 CMS ProcedureDescription LO 1 (0013,0042) SIEMENS CM VA0 CMS RestDirection LO 1 (0013,0044) SIEMENS CM VA0 CMS PatientPosition LO 1 (0019,0010) SIEMENS CM VA0 CMS NetFrequency DS 1 (0019,0011) SIEMENS CM VA0 ACQU SequenceFileName LO 1 (0019,0021) SIEMENS CT VA0 GEN Exposure DS 1 (0019,0026) SIEMENS CT VA0 GEN GeneratorVoltage DS 1 (0019,0050) SIEMENS MR VA0 GEN NumberOfAverages IS 1 (0019,0060) SIEMENS MR VA0 GEN FlipAngle DS 1 (0019,0012) SIEMENS MR VA0 COAD MagneticFieldStrength DS 1 (0021,0010) SIEMENS MED Zoom DS 1 (0021,0011) SIEMENS MED Target DS 2 (0021,0020) SIEMENS CM VA0 CMS FoV DS 2 (0021,0060) SIEMENS CM VA0 CMS ImagePosition DS 3 (0021,0061) SIEMENS CM VA0 CMS ImageNormal DS 3 (0021,006a) SIEMENS CM VA0 CMS ImageRow DS 3 (0021,006b) SIEMENS CM VA0 CMS ImageColumn DS 3 (0021,0039) SIEMENS MR VA0 GEN SlabThickness DS 1 (0021,0070) SIEMENS MR VA0 GEN NumberOfEchoes IS 1 3.2 CT - Proprietary Formats 3.2.1 General Electric CT Now we get to the meaty part. After years of being faced with the problem of either a) hours of detective work, or b) tediously tracking down the name of the responsible person and exercising a non-disclosure agreement, General Electric (or Generous Electric as I heard them described the other day) now really are being generous, as well as sensible, and are making their image format description documents freely available. For details see the GEMS image format information contacts section later on. In the meantime, both for historical completeness, educational purposes, and for those who can't wait for document to come in the mail, a summary of the relevant formats and decompression algorithms is provided here. 3.2.1.1 GE CT 9800 References (see the GEMS image format information contacts section): - 46-021855 CT 9800 Image Data Format 3.2.1.1.1 GE CT 9800 Image data - "block format" header - perimeter encoding - optional DPCM compression - Data General host (various) - RDOS (yuck !) Almost everyone in this field has at some stage encountered the dreaded CT 9800 format. The world is divided into two groups of people ... those who have seen the documents or the critical piece of code in another program or have been given a handy hint, and those who will never figure out the format themselves. Essentially the format fits into the "block format" described earlier, with pointers to each of the major header components. Rarely, if ever, does one encounter a file that doesn't have the same size blocks in the same place, so most people treat it as a fixed layout. I believe that reformatted images may have another header stored in there, but I have never tested for it. The data itself is stored in one of two forms depending on whether compression is selected or not during archival. In the uncompressed form, a type of perimeter encoding is used (see later section) in which for an essentially circular object, the outer parts of a rectangular image are discarded (and expected to be filled in with a background pixel value during reconstitution of the image). In the case of the CT9800 then, the image pixel data is interpreted using a map, which contains an entry for each row of the image (either 256, 320 or 512 entries) which specifies the length of the row that is actually stored, centered about the midline of the image. This obviously saves a lot of space. If compression is selected on one of the later model machines, then a form of Differential Pulse Code Modulation is used, in which advantage is taken of the fact that not all the bits of a 16 bit word are need to store a CT value. I gather only 12 bits of data are actually significant, but one can theoretically represent 15 using this scheme. Essentially, the first 16 bit word is read and used as is. Then another byte is read. If its most significant bit is set, then the remaining 7 bits represent a signed difference value relative to the previous pixel. If its most significant bit is not set, then the difference must have exceeded the range of 7 bits, and hence the next byte is read to complete a valid 16 bit word (15 bits really) which is the actual pixel value. The really neat thing about this scheme is that the same algorithm can be used for compressed or uncompressed data as an uncompressed stream of words will never have the most significant bit set ! The following piece of C++ code pulled out of a CT9800 to DICOM translator will give you the general idea. Note that the perimeter encoding map has already been read in. Note in particular the need to deal with sign extension of the difference value. Also note that the code doesn't handle the first pixel specially because its high bit will not be set. static void copy9800image(ifstream& instream,DC3ofstream& outstream, Uint16 resolution,Uint16 *map) { unsigned i; Int16 last_pixel; last_pixel=0; for (i=0; i/dev/null` if [ -z "$name" ]; then break; fi mv tape.tmp $name echo "Extracted $name" done echo "Rewinding" mt -f /dev/nrst1 rewind echo "Finished" 3.2.1.1.2 GE CT 9800 Raw data MR No idea about this one ... I have never had the need or seen any documention. Anyone who does or has please fill in this space. 3.2.1.2 GE CT Advantage - Genesis References (see the GEMS image format information contacts section): - 46-021861 Image Data Format - 46-021863 Optical Disk Raw Partition - 46-021864 Image Extract Tool - 46-021865 DAT Archive Format General Electric now uses the same Sun based architecture for its Advantage CT and Signa 5X MR family, referred to as Genesis, and hence the general details of this scheme will be discussed under the GE MR Signa 5.x - Genesis section. Specifics related to the CT modality will be described here. 3.2.1.2.1 GE CT Advantage Image data The Image Extract Tool is used in the same way as on the Signa to extract an image from the database into a single file, either asis or using the requested compression and packing mode. The Genesis file contains headers consisting of several components in common with MR and then a specific CT or MR header. Theroetically, one should be able to use "/usr/g/insite/bin/ximg -g" to extract a prototype C header file describing the file format, as on the Signa, though last time I tried this on a High Speed Advantage this didn't work. Some of the more interesting fields in the CT image header include: image header - for CT (1020 bytes long): 26 - float - slice thickness (mm) 30 - short - image matrix size - X 32 - short - image matrix size - Y 34 - float - display field of view - X 38 - float - display field of view - Y 42 - float - image dimension - X 46 - float - image dimension - Y 50 - float - pixel size - X 54 - float - pixel size - Y 58 - char[14] - pixel data ID 72 - char[17] - iv contrast agent 89 - char[17] - oral contrast agent 194 - float - table start Location 198 - float - table end Location 202 - float - table speed (mm/sec) 206 - float - table height 224 - float - gantry tilt (degrees) 3.2.1.2.2 GE CT Advantage Archive format See the GE MR Signa 5.x Archive format. 3.2.1.2.3 GE CT Advantage Raw data Again, unknown. Please fill in this space. 3.2.1.3 GE CT Pace References (see the GEMS image format information contacts section): - 46-021856 CT Pace Image Data Format - 46-021862 MR Max Image Data Format The Pace is a CT scanner made by Yokogawa Medical Systems(YMS) in Japan. The format documents I have for it are partially in Japanese and partially in English, but they get the job done. I have only tested the following on a few images that were extracted off a nine-track tape, so the offsets to the image header fields may not be correct in other cases, but here are "eye-catcher" fields at the start of each header which should be easy to find. The format seems to be shared with the GE MR Max family. The images described in the documents have a 512 byte study header that begins with "!STD" and an image header of 1024 bytes that begins with "!IMG". In the image that I had to play with, there was a 256 byte header that I am not familiar with tacked on the front, presumambly something to do with being a mag tape rather than a disk image. Anyway this meant that the offset to the study header was 256 bytes, the image header was 768 bytes, and the compressed image data began at 1792 bytes. I don't know what kind of host is used on the Pace though I have seen some cryptic references to "DOS-68K" in the documents. Regardless, the integers are 16 or 32 bit big-endian. The image data is stored as SIGNED not unsigned 16 bit values, same as on the Sytec and presumably all the YMS systems. Most of the useful dates and times are provided as string values, however there are some dates and times that are 32 bit binary integers. Though not specified in the docs it seems that the dates are days since an epoch of "0 Jan 1980" and the times are in milliseconds. Floats are 32 bit IEEE format, dfined in the Pace documentation as follows: bit 31 sign (s) (0 is +ve) bits 30-23 exponent (e) - unsigned integer - e == 0 for denormalized numbers - 0 < e < 255 for normalized numbers - e == 255 for other reserved operands bits 22-0 significand (f) Normalized numbers: Exponent: - bias 127 - range 0 < e < 255 Significand: - interpreted as 1.f - range 1.0 <= f < 2.0 (-1)^s * 2^(e-127) * 1.f Denormalized numbers: Exponent: - e == 0 - bias 126 Significand: - interpreted as 0.f - range f != 0 (-1)^s * 2^(-126) * 0.f Signed Infinities: - e == 255 - f == 0 Not-a-numbers: - e == 255 - f != 0 The image header has a chunk in the middle where different values are defined for CT and MR. One can use the first byte of the model number field to distinuish the two modalities. Some of the more important study and image header values are: Study header (offset 256 bytes, length 512 bytes): Offset Type Length Meaning Units or values 0x0 string 4 Eyecatcher !STD 0x6 byte 1 Modality 1=CT,2=MR 0xa string 5 Study Number 0x10 datestring Study Date yyyy/mm/dd 0x1a timestring Study Time hh/mm/ss.xxx 0x26 string 12 Patient ID 0x36 string 12 Patient Name 0x50 string 6 Patient Age yyy;mm 0x5c string 2 PatientSex" 'M ','F ' 0xbc string 4 Contrast media 'NO C','+C ' Image header (offset 768 bytes, length 1024 bytes): Offset Type Length Meaning Units or values 0x0 string 4 Eyecatcher !IMG 0x6 byte 1 Modality 1=CT,2=MR 0xa string 5 Study Number 0x10 string 2 Series Number 0x12 string 2 Acquisition Number 0x14 string 2 Image Number 0x20 datestring Image Date yyyy/mm/dd 0x2a timestring Image Time hh/mm/ss.xxx 0x40 string 2 'H '=Head First,'F '=Feet First 0x42 string 2 'SP'=Supine,'PR'=Prone, 'LL'=Left Lateral Decubitus, 'RL'=Right Lateral Decubitus,'OT'=Other 0x44 string 6 Anatomic location 0x50 string 4 'AX '=Axial,'SAG '=Sagittal,'COR '=Coronal 0x54 float32 Slice position by body coords HF mm 0x58 float32 Slice position by body coords AP mm 0x5c float32 Slice position by body coords LR mm 0x6c string 4 Scan fov cm 0x70 string 4 Scan thickness mm 0xa0 string 4 Contrast media 'NO C','+C ' 0x188 float32 Recon center X mm 0x18c float32 Recon center Y mm 0x190 string 4 Recon FOV cm [xx.x] 0x1a0 u_int16 Pixels in X-axis 0x1a2 u_int16 Pixels in Y-axis 0x1a4 float32 Pixel size mm 0x1b0 float32 Mag center X mm 0x1b4 float32 Mag center Y mm 0x1b8 float32 Mag factor For CT only: 0xc8 string 5 Gantry tilt machine coords degrees 0xe0 string 5 Exposure time ms 0xe6 string 3 Tube current mA 0xea string 5 Exposure mAS 0xf0 string 3 KVP 0xf4 string 2 'CW'=Clockwise,'CC'=CounterClockwise For MR only: 0xc0 string 5 Tilt ordered by user Axis+/-Angle [xx+/-xx] 0x100 string 2 Echo number 0x102 string 2 Number of echoes 0x104 string 2 Slice number 0x106 string 2 Number of slices 0x108 string 2 Number of excitations 0x10a string 5 Repetition time ms 0x110 string 5 Inversion time ms 0x115 string 5 Echo time ms 0x130 string 4 Magnetic flux density (T) Unlike the Sytec sample images I had, compression was used in the Pace images I received. This is a neat scheme that uses both Run Length Encoding and Differential Pulse Code Modulation. Essentially, each byte may be a flag value 0x81 which indicates the next byte is a run length of the current pixel, or a flag value 0x80 which indicates that the current mode should be toggled between "reference" mode, in which the subsequent 16 bit words are new pixel values, or "difference" mode, in which case subsequent bytes are signed differences added to the current pixel value. The initial mode is "reference" mode. Runs do extended across horizontal line boundaries. I am not totally clear from the documentation or the sample images where in the header is the flag to say compression is in use or not. It is probably bit 5 of the Image Attribute field in offset 0x1ac in the image header, where a false value specifies DPCM and a true value specifies uncompressed or "Original" encoding. The docs say this is for optical disk only, but the compressed image from tape I have has this bit false, which is correct. The following piece of code will decode such a compressed image: static void copypaceimage(istream& instream,ostream& outstream, Uint16 width,Uint16 height) { // NB. the exclusive or with 0x8000 makes the signed Pace values unsigned // which is what the PGM convention is ... just omit the ^0x8000 // everywhere if you want the data left signed. unsigned i; Int16 pixel=0; enum Mode { Difference, Reference } mode = Reference; for (i=0; i (0009,0011) (0009,1011) SPI RELEASE 1 UID <049S03CT031995011712072452> (0009,1040) SPI RELEASE 1 DataObjectSubtype [0x0000] (0009,1041) SPI RELEASE 1 DataObjectSubtype (0009,1110) SIEMENS MED RecognitionCode (0009,1130) SIEMENS MED ByteOffsetOfOriginalHeader (0009,1131) SIEMENS MED LengthOfOriginalHeader (0009,1140) SIEMENS MED ByteOffsetOfPixelmatrix (0009,1141) SIEMENS MED LengthOfPixelmatrixInBytes (0011,0010) (0021,0010) (0021,1010) SIEMENS MED Zoom <01.0> (0021,1011) SIEMENS MED Target <000.000\00.000> (0021,1012) SIEMENS MED TubeAngle <0270> (0021,1020) SIEMENS MED ROIMask [0xf000] Overlay descriptions (overlays already in image pixel data): (6000,0040) ROI (6000,0102) BitPosition [0x000c] (6000,0102) OverlayLocation [0x7fe0] (6002,0040) ROI (6002,0102) BitPosition [0x000d] (6002,0102) OverlayLocation [0x7fe0] (6004,0040) ROI (6004,0102) BitPosition [0x000e] (6004,0102) OverlayLocation [0x7fe0] (6006,0040) ROI (6006,0102) BitPosition [0x000f] (6006,0102) OverlayLocation [0x7fe0] More SPI private stuff ... padding and original header ... (7001,0010) (7001,1010) SIEMENS MED Dummy (7003,0010) (7003,1010) SIEMENS MED Header (7005,0010) (7005,1010) SIEMENS MED Dummy 3.2.2.3 Siemens Somatom AR Unknown. 3.2.3 Philips CT - Big black hole 3.2.4 Picker CT Grey hole perhaps. This information probably pertains to the IQ and PQ CT models, though I have no sample images to experiment with yet. I am told that: - axial images are 512x512 - pilot images are 1024x1024 - uncompressed images are 12 bits stored in 16 bits - don't know how to handle compression scheme - raster order is as usual, by row, TLHC first - 8k header to be skipped 3.2.5 Toshiba CT - another black hole 3.2.6 Hitachi CT - another black hole 3.2.7 Shimadzu CT - another black hole 3.2.8 Elscint CT - another black hole The next part is part4 - proprietary MR formats. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!news.sol.net!uniserve!news.mindlink.net!van-bc!news.rmii.com!newsjunkie.ans.net!howland.reston.ans.net!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail From: dclunie@flash.us.com (David A. Clunie) Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 4/8 Followup-To: alt.image.medical Date: 30 Jan 1996 16:04:05 -0500 Organization: Mollard Consultants Lines: 1264 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 28 Feb 1996 00:00:00 GMT Message-ID: <4em145$3c6@flash.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: flash.ksapax Summary: This posting contains answers to the most Frequently Asked Question on alt.image.medical - how do I convert from image format X from vendor Y to something I can use ? In addition it contains information about various standard formats. Xref: senator-bedfellow.mit.edu alt.image.medical:4251 comp.protocols.dicom:1434 sci.data.formats:1403 sci.med.informatics:5250 sci.med.radiology:4960 alt.answers:15302 comp.answers:16749 sci.answers:3823 news.answers:63416 Archive-name: medical-image-faq/part4 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 3.3 MR - Proprietary Formats 3.3.1 General Electric MR 3.3.1.1 GE MR Signa 3.x,4.x References (see the GEMS image format information contacts section): - 46-021858 MR Signa 4.x Mag Tape/Image Fmt 3.3.1.1.1 GE MR Signa 3.x,4.x Image data - "fixed format" header - image data is not compressed - image data fixed offset 14336 bytes - Data General host - AOS/VS The image files are of fixed layout, described here as a series of 256 by 16 bit word blocks (512 bytes), blocks numbered from 0. The headers start at the following block offsets: block 0 - length 4 blocks - System configuration block 4 - length 2 blocks - Site customization block 6 - length 2 blocks - Study header block 8 - length 2 blocks - Series header block 10 - length 2 blocks - Image header block 12 - length 4 blocks - Raw database header block 16 - length 10 blocks - Pulse sequence description block 26 - length 2 blocks - Pixel map (? not ever used) block 28 - length 256 blocks - Image data As decribed earlier, the header is a fixed length of 14336 bytes, after which the uncompressed image data starts. Some of the more important fields are described here. Integers are 16 bit words (big-endian), ascii strings are Fortran style specifications with length in bytes, and reals are 4 bytes long (see Host machines - Data General), word offsets are numbered from 0: block 6 - study header word 32 - 5A - Study number word 39 - 9A - Date of study (dd-mmm-yy) word 47 - 8A - Time of study (hh:mm:ss) word 54 - 32A - Patient name word 70 - 12A - Patient ID word 78 - 3A - Age xxx years or xxD or W or M or Y word 80 - 1A - Sex block 8 - series header word 31 - 3A - Series number word 52 - 120A - Series description word 112 - Int - Series type (0=normal,1=screensave, 2=composite) word 113 - Int - Coil type (0=head,1=body,2=surface) word 114 - 16A - Coil name word 122 - Int - Contrast description word 138 - Int - Plane type (0=axial,1=sagittal,2=coronal, 3=oblique,4=screen save) word 147 - Int - Image mode (0=2D single,1=2D multiple, 2=3D volume,3=cine,4=spectroscopy) word 148 - Int - Field strength (gauss) word 149 - Int - Pulse sequence (0=memp,1=ir,2=ps,3=rm, 4=rmge,5=gre,6=vemp,7=mpgr,8=mpgrv, 9=mpirs,10=mpiri,11=3d/gre, 12=cine/gre,13=spgr,14=sspf, 15=cin/spgr,16=3d/spgr,17=fse, 18=fve,19=fspgr,20=fgr,21=fmpspgr, 22=fmpgr,23=fmpir,24=probe.s, 25=probe.p) word 150 - Int - Pulse sequence subtype (0=chopper) word 151 - Real - Field of view mm word 153 - Real - Center (3 values;R+L-,A+P-,S+I-) word 159 - Int - Orientation (0=supine,1=prone,2=Lt,3=Rt) word 160 - Int - Position (0=head first,1=feet first) word 161 - 32A - Longitudinal anatomical reference word 177 - 32A - Vertical anatomical reference word 199 - Int - Scan matrix X word 200 - Int - Scan matrix Y word 201 - Int - Image matrix block 10 - image header word 44 - Int - Image number word 73 - Real - Image location word 75 - Real - Table position word 77 - Real - Image thickness word 79 - Real - Image spacing word 82 - Real - TR word 86 - Real - TE word 88 - Real - TI word 98 - Int - Number of echos word 99 - Int - Echo number word 101 - Int - NEX (if not fractional) word 146 - Real - NEX word 146 - Int - Flip angle 3.3.1.1.2 GE MR Signa 3.x,4.x Tape format 3.3.1.1.3 GE MR Signa 3.x,4.x Raw data 3.3.1.2 GE MR Signa 5.x - Genesis References (see the GEMS image format information contacts section): - 46-021861 Image Data Format - 46-021863 Optical Disk Raw Partition - 46-021864 Image Extract Tool - 46-021865 DAT Archive Format General Electric now uses the same Sun based architecture for its HighLite Advantage (HLA) and High Speed Advantage (HSA) CT and Signa 5X MR family, referred to as Genesis. The general details of this scheme will be discussed here, as well as the description of the MR image header. Specifics related to the CT modality are described elsewhere. 3.3.1.2.1 GE MR Signa 5.x Image data Genesis is a system running under SunOS 3.5G (NOT Solaris) on, believe it or not, a sun3 68000 architecture, not a sun4 sparc. It would appear that unlike in the previous Data General based system, the active database is stored as one large monolithic file in a raw partition, which doesn't make it very easy to extract single imgaes. Fortunately, GE have saved the day by kindly providing, and thoroughly documenting in the material that they send you when you ask for the image file format, an Image Extract Tool that lives in "/usr/g/insite/bin" and is called "ximg". To see what options are available just type "ximg -h" for help. Note that ximg's default is to strip out the patient's name and ID number which is annoying, so don't forget the "-s" flag. The default directory to put the extracted images in is "/usr/g/insite/tmp". The input names to select images in silent (non-menu) mode are of the following form: EeeeeeSsssIiii eeeee = exam number or "all" sss = series number or "all" iii = image number or "all" and the resultant filenames are the same with an extension of ".MR" or ".CT" depending. For example: % /usr/g/insite/bin/ximg -i e673s1i1 -st % ls -l /usr/g/insite/tmp E673S1I1.MR which extracts the selected image in silent mode (-i) without stripping the identification (-s) in rectangular (-t) mode, ie. not compressed or packed. One nifty feature that allows you to keep up to date with the latest version header contents is the "-g" switch which invokes the GenIncl utility that produces a file called "imageFileOffsets.h" that lists the type and offsets of each field in the header ! Remarkable, huh ? How does one get access to the operating system on the Signa ? Let me count the ways. First, from the Advantage console one can just call up a command shell from the Utilities menu, or one can invoke the Ftp option uner Networks and then use the "!" command to ftp, which like in many Unix tools, spawns a shell. Or from another workstation on the network one can just telnet or rsh across. If you are connected using an Advantage Windows workstation you can pull up a command shell by using the right menu button with the cursor on the desktop. Doing a few "cat /etc/hosts" around the place will let you know what all the machines are called. One can also access the console directly from the plasma screen by toggling "L1-B" on or off. Once you have extracted them, the Genesis file contains headers consisting of several components in common with CT and then a specific CT or MR header. The file is structured as a "block type" header with a brief "control header" of fixed size, followed by a bunch of optional headers, some of which reflect internal database structures and are of no interest, others (such as the suite/exam/series/image) headers that contain descriptive and identification information, and two that are of importance for deciphering the pixel data (unpack control & compression control). Some of the more important fields are described here: Sun3 Sun Data Types: - short is 16 bits - int is 32 bits - float is 32 bits IEEE - double is 64 bits IEEE - byte offsets from 0 start of file - length ==0 means header absent/empty control header (offset 0): 0 - int - magic number = 0x494d4746 = "IMGF" 4 - int - byte displacement to pixel data 8 - int - width 12 - int - height 16 - int - depth (bits) 20 - int - compression (0=asis,1=rectangular,2=packed, 3=compressed,4=compressed&packed) 32 - int - background shade to use for non-image 54 - u_short - 16 bit end_around_carry sum of pixels 56 - int - ptr to unique image identifier 60 - int - length of unique image identifier 64 - int - ptr to unpack header 68 - int - length of unpack header 72 - int - ptr to compression header 76 - int - length of compression header 80 - int - ptr to histogram header 84 - int - length of histogram header 88 - int - ptr to text plane 92 - int - length of text plane 96 - int - ptr to graphics plane 100 - int - length of graphics plane 104 - int - ptr to data base header 108 - int - length of data base header 112 - int - value to add to stored pixels 116 - int - ptr to user defined data 120 - int - length of user defined data 124 - int - ptr to suite header 128 - int - length of suite header 132 - int - ptr to exam header 136 - int - length of exam header 140 - int - ptr to series header 144 - int - length of series header 148 - int - ptr to image header 152 - int - length of image header unpack header: // used when compression is packed, or compressed & packed // contains perimeter encoding map ... cf. GE 9800 struct { short pixels_to_left_of_line; short pixels_in_stored_line; } table [height_of_image]; compression header: Not necessary for decompressing entire image ... rather it contains seeds for various "strips" of the image to allow jumping into the compressed pixel data ... see the GE docs. histogram header: Contains statistical information for determining optimum windowing ... see the GE docs and GenIncl produced header exam header: 0 - char[4] - suite ID 8 - u_short - exam number 84 - char[13] - patient ID 97 - char[25] - patient name 122 - short - patient age 126 - short - patient sex 305 - char[3] - exam type - "MR" or "CT" series header: 10 - short - series number 84 - char[3] - anatomical reference 92 - char[25] - scan protocol name image header - for MR (1022 bytes long): 12 - short - image number 26 - float - slice thickness mm 30 - short - matrix size - X 32 - short - matrix size - Y 34 - float - display field of view - X (mm) 38 - float - display field of view - Y (mm) 42 - float - image dimension - X 46 - float - image dimension - Y 50 - float - pixel size - X 54 - float - pixel size - Y 72 - char[17] - iv contrast agent 89 - char[17] - oral contrast agent 194 - int - repetition time(usec) 198 - int - inversion time(usec) 202 - int - echo time(usec) 210 - short - number of echoes 212 - short - echo number 218 - float - NEX 308 - char[33] - pulse sequence name 362 - char[17] - coil name 640 - short - ETL for FSE So much for the headers. Now how does one deal with the image data ? The easiest way of course is to save it as "rectangular", that is not compressed and not packed. If you want to do it the hard way, then if the data is packed, then unpack it, then if it is compressed, uncompress it. The packing is a perimeter encoding method like the CT 9800, except that instead of using a map containing just the width of the stored data, both a left offset and a width are stored for each row, as described in the "unpack header". The compression scheme is DPCM again but with a difference ... three alternative encodings are possible ... a 7 bit difference (one byte), a 14 bit difference (two bytes), or a flag byte followed by a true 16 bit pixel value (three bytes). Presumably this scheme was devised to handle a greater dynamic range than in the CT 9800 scheme when necessary, but produce a similar degree of compression otherwise. 0 +/- <------ 6 bits -------> _______________ _______________ | | | | | | | | | |_______________|_______________| 7 4 3 0 or 1 0 +/- <------------------ 13 bits ----------------------> _______________ _______________ _______________ _______________ | | | | | | | | | | | | | | | | | |_______________|_______________|_______________|_______________| 15 12 11 8 7 4 3 0 or 1 1 <----- discarded -----> Then two bytes for 16 bit word _______________ _______________ | | | | | | | | | |_______________|_______________| 7 4 3 0 The following piece of C++ code pulled out of a Genesis to DICOM translator will give you the general idea. Note that the perimeter encoding map has already been read in (map_left and map_wide). Note in particular the need to deal with sign extension of the difference values. Unlike the CT 9800 example earlier, one has to use a separate loop for the compressed data stream as all 16 bits are potentially in use. static void copygenesisimage(ifstream& instream,DC3ofstream& outstream, Uint16 width,Uint16 height,Uint16 depth,Uint16 compress, Uint16 *map_left,Uint16 *map_wide) { unsigned row; Int16 last_pixel=0; for (row=0; row 3188 which is where the image data starts. If you are not familiar with the Genesis ximg format, on a Signa at least, you can run "/usr/g/insite/bin/ximg -g" to extract a prototype C header file describing the file format. 3.3.1.2.3 GE MR Signa 5.x Raw data 3.3.1.3 GE MR Max References (see the GEMS image format information contacts section): - 46-021856 CT Pace Image Data Format - 46-021862 MR Max Image Data Format I do not have any MR Max images to try this on, but am told that the format is essentially the same as the CT GE CT Pace, with some different fields in the image header: For MR only: 0xc0 string 5 Tilt ordered by user Axis+/-Angle [xx+/-xx] 0x100 string 2 Echo number 0x102 string 2 Number of echoes 0x104 string 2 Slice number 0x106 string 2 Number of slices 0x108 string 2 Number of excitations 0x10a string 5 Repetition time ms 0x110 string 5 Inversion time ms 0x115 string 5 Echo time ms 0x130 string 4 Magnetic flux density (T) 3.3.1.4 GE MR Vectra Same comments as pertain to the Sytec/Pace entry in the CT section. A few sample files on a floppy would be much appreciated. 3.3.2 Siemens MR It would seem that two formats are used on Siemens MR scanners, modern ones at least. There is a native format that is specific to each family of scanners, and an "exported" ACR/NEMA based SPI format. The earlier scanners define fewer useful elements in the exported format, and encapsulate parts of the native header in private elements, whereas the more recent forms are more complete implementations. The comments below are based on limited experience, and in most cases either the native or the exported format has been examined, but not both. A fairly common feature of all the native formats seems to be so-called "image text" portion of the header which contains a more or less exact replica of what is annotated on the film ... in the earlier models it is indeed an exact replica, being 24 rows of 40 characters or whatever. This can be very helpful in deciphering un unknown format. Interestingly enough, though many values are repeated in string form from binary values in the header, patient identification information often occurs only in the text header and nowhere else ! 3.3.2.1 Siemens Magnetom GBS/GBS II 3.3.2.1.1 Siemens Magnetom GBS/GBS II Native Format Simply speaking the image data can be accessed in most cases as: - files 133120 bytes - image pixel data 256*256*2 little endian - image pixel offset 4096 bytes In more detail, there is an initial brief fixed "Entry header" that contains pointers to subsequent headers, where pointers are offsets to 512 byte records, indexed from 1, and lengths are in 512 byte records, and binary values are Vax data types, including type F floats. The image data is usually uncompressed little endian two byte words, and it probably isn't worth going into details of the compression scheme here. I have never tested it. Only the more important header values are listed here: Entry header (first 128 bytes of first 512 byte record): 0 short Number of entries (==9) 2 short Entry length (==2) 4 short Bytes per record (==512) 20 short Installation header pointer (usually == 2) 22 short Installation header length (usually == 1) 24 short Measurement header pointer (usually == 3) 26 short Measurement header length (usually == 2) 28 short Image text header pointer (usually == 5) 30 short Image text header length (usually == 2) 32 short Image data header pointer (usually == 9) 34 short Image data header length (usually == 256) Image header (last 394 bytes of first 512 byte record): 0 short Data code (-1=raw data,1=image data,...) 10 short Rows 12 short Columns 24 short Bit depth of image 26 short Bit depth of ROI 28 short Bit map of ROI in use 54 short Pixels per 10cm 126 short Archive code (10/12=128 uncompressed/compressed, 20/22=256 uncompressed/compressed, 50/52=512 uncompressed/compressed) 256 short View direction (-1=caudal,1=cranial) 258 short Orientation (-1=head first,1=feet first) 260 short Orientation (1=supine,2=prone, 3=right lateral,4=left lateral) Installation header: 64 char[32] Serial number Measurement header: 48 char[60] Protocol name 120 char[8] Sequence name 132 short Measurement type (100=SE,200=IR,500=FID, 502=FID,600=SEM,800=FW) 138 short Number of echoes 140 short Number of averages 150 short Rows in acquisition 152 short Columns in acquisition 222 short Echo number 224 short Slice number 226 short Number of slices 228 short Slice orientation (1=X,2=Y,3=Z) 230 short X angle 232 short Y angle 234 short Z angle 236 short 3D resolution factor 238 short 3D partition 398 short Acquisition number 400 float_f Slice thickness (3D partition thickness) 440 short NMR frequency Hz 476 float_f TR secs 480 float_f TI secs 488 float_f[32] TE[echo 1..32] mS 756 float_f Field strength Tesla 772 float_f Slice thickness mm 776 float_f Slice gap mm 780 float_f[32] Slice distance[slice 1..32] mm 952 char[8] Imaged nucleus 972 short Flip angle 1004 float_f Patient weight kg 1020 float_f Table position mm Image text header: 0 char[9] Installation name 9 char[5] Field strength T 15 char[25] Hospital name 40 char[25] Patient name 66 char[1] Trigger ('T'=ecg) 67 char[1] Gating ('H'=respiratory high,'L'=respiratory low) 68 char[3] Software version 71 char[1] Lookup table number 72 char[1] Measurement matrix size ('A'=128*128,'B'=256*256,'C'=512*512, 'D'=128*256,'E'=128*512,'F'=256*512, '*'=raw data set incomplete) 73 char[1] Reproduction matrix size ('A'=128*128,'B'=256*256,'C'=512*512) 74 char[4] Number of acquisitions 78 char[2] Technique ('SE'=spin echo,'SU'=spin echo summation, 'SM'=spin echo multiecho, 'IR'=inversion recovery, 'IS'=inversion recovery summation, 'FD'=free induction decay, 'PU'=phase image uncorrected, 'PC'=phase image corrected, 'W '=lipid separation water image, 'F '=lipid separation fat image, '3D'=image from 3D data, 'T1'=longitudinal relaxation time, '1R'=T1 weighted density, 'T2'=transverse relaxation time, '2F'=T2 fit,'2R'=T2 weighted density, 'RH'=density,'SI'=synthetic image) 80 char[12] Patient ID 113 char[2] View direction ('CR'=cranial,'CU'=caudal) 116 char[1] View direction ('H'=head first,'F'=feet first) 118 char[2] View direction ('SP'=supine,'PR'=prone, 'RP'=right lateral posterior, 'LP'=left lateral posterior) 120 char[2] Date - DD 123 char[3] Date - MMM 127 char[2] Date - YY 160 char[2] Time - HH 163 char[2] Time - MM 166 char[2] Time - SS 201 char[5] Image number 640 char[6] Inversion time TI mSecs, flip angle FI,FL,FA 680 char[6] Repetition time TR Secs 680 char[6] Echo time TE mSecs 760 char[7] Slice thickness SL mm 800 char[8] Slice position SP mm 880 char[7] Slice orientation X ,Y ,Z , zoom factor ZF , field of view FOV 912 char[8] Acquisition time TA 920 char[6] Trigger delay for ecg TD 929 char[24] Image comments A sample text header follows: MAGNETOM 1.5 T HOSPITAL NONAME,JOHN 010199 D2 BB 2SE 14802 F FRONT CU-H-SP 04-FEB-94 19:06:06 > 74 R I G H T TR .60 TE 15 SL 5.0 SP -28.4 Z 21 FOV 210 TA 5:10 3.3.2.1.2 Siemens Magnetom GBS/GBS II SPI Format Unknown, perhaps doesn't exist. 3.3.2.2 Siemens Magnetom SP 3.3.2.2.1 Siemens Magnetom SP Native Format Unknown. 3.3.2.2.2 Siemens Magnetom SP SPI Format - ACR/NEMA data stream starts immediately - big-endian byte order - lots of private groups containing SPI & MR specific tags, but much useful information in standard tags - 12 bit allocated data in 16 bits stored, high bit 11 - after ACR/NEMA data, trailing garbage Similar story as for the Siemens Somatom Plus. Siemens version of SPI, containing the following private data elements. Note that there is overlayed data in the high four bytes of the image pixel data, and that there seems to be a bunch of padding in the middle. The intent seems to be to store the "original header" and the image pixel data at accessible, presumably standard locations, presumably indexed by the byte offsets and lengths described in group 9. This is a shame because it seems that none of the really interesting MR attributes have been included in the SPI form, although SPI private tags are available for lots of MR parameters. This is in contrast to the Siemens Magnetom Impact which contains more interesting SPI tags. SPI private tags: (0009,0010) (0009,0011) (0009,1010) SPI RELEASE 1 Comments (0009,1015) SPI RELEASE 1 UID <000S00MR001994122719161248> (0009,1110) SIEMENS MED RecognitionCode (0009,1130) SIEMENS MED ByteOffsetOfOriginalHeader [0x800] (0009,1131) SIEMENS MED LengthOfOriginalHeader [0x1600] (0009,1140) SIEMENS MED ByteOffsetOfPixelmatrix [0x2000] (0009,1141) SIEMENS MED LengthOfPixelmatrixInBytes [0x20000] (0011,0010) (0021,0010) (0021,1010) SIEMENS MED Zoom <01.0> (0021,1011) SIEMENS MED Target <> (0021,1020) SIEMENS MED ROIMask [0x0000] Overlay descriptions (overlays already in image pixel data): (6000,0010) OverlayRows [0x0100] (6000,0011) OverlayColumns [0x0100] (6000,0040) ROI (6000,0050) OverlayOrigin [0x5c31,0x2031] (6000,0060) OverlayCompressionCode (6000,0100) OverlayBitsAllocated [0x0010] (6000,0102) OverlayBitPosition [0x000c] (6000,0110) OverlayFormat (6000,0200) OverlayLocation [0x7fe0] (6002,0010) OverlayRows [0x0100] (6002,0011) OverlayColumns [0x0100] (6002,0040) ROI (6002,0050) OverlayOrigin [0x5c31,0x2031] (6002,0060) OverlayCompressionCode (6002,0100) OverlayBitsAllocated [0x0010] (6002,0102) OverlayBitPosition [0x000d] (6002,0110) OverlayFormat (6002,0200) OverlayLocation [0x7fe0] (6004,0010) OverlayRows [0x0100] (6004,0011) OverlayColumns [0x0100] (6004,0040) ROI (6004,0050) OverlayOrigin [0x5c31,0x2031] (6004,0060) OverlayCompressionCode (6004,0100) OverlayBitsAllocated [0x0010] (6004,0102) OverlayBitPosition [0x000e] (6004,0110) OverlayFormat (6004,0200) OverlayLocation [0x7fe0] (6006,0010) OverlayRows [0x0100] (6006,0011) OverlayColumns [0x0100] (6006,0040) ROI (6006,0050) OverlayOrigin [0x5c31,0x2031] (6006,0060) OverlayCompressionCode (6006,0100) OverlayBitsAllocated [0x0010] (6006,0102) OverlayBitPosition [0x000f] (6006,0110) OverlayFormat (6006,0200) OverlayLocation [0x7fe0] More SPI private stuff ... padding and original header ... (7001,0010) (7001,1010) SIEMENS MED Dummy (7003,0010) (7003,1010) SIEMENS MED Header (7005,0010) (7005,1010) SIEMENS MED Dummy NB. Siemens VR for OverlayOrigin seems to be wrong. ACR/NEMA says it should be binary, but [0x5c31,0x2031] translates to a string <1\1> which seems more plausible! The models in this family include the SP (which the SPI describes as a GBS 3 !), the SP/4000 which got a faster Vax, and the new Vision. I have only examined the files from the SP so far, but they are bog standard SPI with no surprises, and I have no reason to doubt the same is true of the later models. The usual Vax VMS problems apply. Use the console serial port on the back of the Vax. There is a C compiler supplied so you can compile the more recent C version of kermit ... although the old Bliss version works fine. Unlike the Philips, there is no problem with CR delimited file attributes being set on the binary files. Kermit transfers are glacially slow as always. 3.3.2.3 Siemens Magnetom Impact 3.3.2.3.1 Siemens Magnetom Impact Native Format Unknown. 3.3.2.3.2 Siemens Magnetom Impact SPI Format - skip the 1st 128 bytes to get to ACR/NEMA data stream (may be artifact of transfer process though rather than real) - big-endian byte order - lots of private groups containing SPI & MR specific tags, but much useful information in standard tags - 12 bit allocated data in 16 bits stored, high bit 11 - after ACR/NEMA data, file is padded to 512 byte mark Siemens version of SPI, containing the following private data elements. More comprehensive attributes than the Siemens Somatom Plus or Siemens Magnetom SP. There is no overlayed data in the high four bytes of the image pixel data, and that there is no padding in the middle or "original header", or byte offsets and lengths described in group 9. Only some of the more significant elements are described here in the interest of brevity. Sources for a more comprehensive dictionary are described under SPI. SPI private tags: (0009,0010) PrivateCreator (0009,0012) PrivateCreator (0009,0013) PrivateCreator (0009,1010) SPI RELEASE 1 Comments (0009,1015) SPI RELEASE 1 UID <000S00MR001994021614211710> (0009,1040) SPI RELEASE 1 DataObjectSubtype [0x0000] (0009,1041) SPI RELEASE 1 DataObjectSubtype (0009,1210) SIEMENS CM VA0 CMS StorageMode (0009,1212) SIEMENS CM VA0 CMS EvaluationMask [0x0000] (0009,1226) SIEMENS CM VA0 CMS LastMoveDate <1994.02.16> (0009,1227) SIEMENS CM VA0 CMS LastMoveTime <13:41:52.000> (0009,1320) SIEMENS CM VA0 LAB HeaderVersion (0011,0011) PrivateCreator (0011,1110) SIEMENS CM VA0 CMS RegistrationDate <1994.02.16> (0011,1111) SIEMENS CM VA0 CMS RegistrationTime <113:43:49.000> (0011,1123) SIEMENS CM VA0 CMS UsedPatientWeight <000050> (0019,0010) PrivateCreator (0019,0012) PrivateCreator (0019,0014) PrivateCreator (0019,0015) PrivateCreator (0019,1060) SIEMENS CM VA0 CMS NumberOfDataBytes <310127> (0019,1220) SIEMENS MR VA0 GEN NominalNumberOfFourierLines <000128> (0019,1226) SIEMENS MR VA0 GEN NumberOfFourierLinesafterZero <000063> (0019,1228) SIEMENS MR VA0 GEN FirstMeasuredFourierLine <-00064> (0019,1230) SIEMENS MR VA0 GEN AcquisitionColumns <000512> (0019,1231) SIEMENS MR VA0 GEN ReconstructionColumns <000512> (0019,1250) SIEMENS MR VA0 GEN CurrentNumberOfAverages <000010> (0019,1260) SIEMENS MR VA0 GEN FlipAngle <00.8000000+E00> (0019,1290) SIEMENS MR VA0 GEN NumberOfSaturationRegions <000000> (0019,1294) SIEMENS MR VA0 GEN ImageRotationAngle <00.0000000+E00> (0019,1412) SIEMENS MR VA0 COAD MagneticFieldStrength <009.500702E-01> (0019,1456) SIEMENS MR VA0 COAD ReceiverFilterFrequency <500000> (0021,0010) PrivateCreator (0021,0011) PrivateCreator (0021,0013) PrivateCreator (0021,1010) SIEMENS MED Zoom <> (0021,1011) SIEMENS MED Target <> (0021,1020) SIEMENS MED ROIMask [0x0] (0021,1120) SIEMENS CM VA0 CMS FoV <00.2050000+E200\.2050000+E20> (0021,1122) SIEMENS CM VA0 CMS ImageMagnificationFactor <001.000000E+00> (0021,1130) SIEMENS CM VA0 CMS ViewDirection (0021,1132) SIEMENS CM VA0 CMS RestDirection (0021,1160) SIEMENS CM VA0 CMS ImagePosition <000.000000E+00\.\.> (0021,1161) SIEMENS CM VA0 CMS ImageNormal <-00.000000E+00\.\.> (0021,1163) SIEMENS CM VA0 CMS ImageDistance <002.787480E+01> (0021,116a) SIEMENS CM VA0 CMS ImageRow <001.000000E+00\.\.> (0021,116b) SIEMENS CM VA0 CMS ImageColumn <000.000000E+00\.\.> (0021,1170) SIEMENS CM VA0 CMS PatientOrientationSet1 (0021,1171) SIEMENS CM VA0 CMS PatientOrientationSet2 (0021,1180) SIEMENS CM VA0 CMS StudyName (0021,1182) SIEMENS CM VA0 CMS StudyType (0021,1334) SIEMENS MR VA0 GEN NumberOf3DImagePartitions <000128> (0021,1339) SIEMENS MR VA0 GEN SlabThickness <001.800000E+02> (0021,1342) SIEMENS MR VA0 GEN CurrentSliceNumber <000001> (0021,1343) SIEMENS MR VA0 GEN CurrentGroupNumber <000001> (0021,134f) SIEMENS MR VA0 GEN OrderofSlices (0021,1370) SIEMENS MR VA0 GEN NumberOfEchoes <000001> (0029,0011) PrivateCreator (0029,1120) SIEMENS CM VA0 CMS PixelQualityCode (0051,0010) PrivateCreator (0051,1010) SIEMENS CM VA0 CMS ImageText <...> 3.3.2.4 Siemens Magnetom Vision 3.3.2.4.1 Siemens Magnetom Vision Native Format The exact details of the format are not known, but a little guess work has determined what follows. The data types are Sun, hence the byte order is big-endian and the all the floats I have found are doubles. Offsets here are in bytes from the start of the header. The uncompressed image data starts at offset 6144. 0 u_int SiemensStudyDateYYYY 4 u_int SiemensStudyDateMM 8 u_int SiemensStudyDateDD 12 u_int AcquisitionDateYYYY 16 u_int AcquisitionDateMM 20 u_int AcquisitionDateDD 24 u_int ImageDateYYYY 28 u_int ImageDateMM 32 u_int ImageDateDD 36 u_int SiemensStudyTimeHH 40 u_int SiemensStudyTimeMM 44 u_int SiemensStudyTimeSS 52 u_int AcquisitionTimeHH 56 u_int AcquisitionTimeMM 60 u_int AcquisitionTimeSS 68 u_int ImageTimeHH 72 u_int ImageTimeMM 76 u_int ImageTimeSS 96 char[7] Manufacturer 105 char[25] InstitutionName 186 char[4] Annotation 281 char[15] ModelName 412 u_int LastMoveDateYYYY 416 u_int LastMoveDateMM 420 u_int LastMoveDateDD 424 u_int LastMoveTimeHH 428 u_int LastMoveTimeMM 432 u_int LastMoveTimeSS 768 char[25] PatientName 795 char[12] PatientID 808 u_int DOBYYYY 812 u_int DOBMM 816 u_int DOBDD 851 char[3] PatientAge 854 char PatientAgeUnits ('Y'=years) 1052 u_int RegistrationDateYYYY 1056 u_int RegistrationDateMM 1060 u_int RegistrationDateDD 1064 u_int RegistrationTimeHH 1068 u_int RegistrationTimeMM 1072 u_int RegistrationTimeSS 1544 double SliceThickness 1560 double RepetitionTime 1568 double EchoTime 1592 double FrequencyMHz 1639 char[5] Station 1712 u_int CalibrationDateYYYY 1716 u_int CalibrationDateMM 1720 u_int CalibrationDateDD 1724 u_int CalibrationTimeHH 1728 u_int CalibrationTimeMM 1732 u_int CalibrationTimeSS 1767 char[16] ReceivingCoil 1828 char[4] ImagedNucleus 2112 double FlipAngle 2560 double MagneticFieldStrength 2864 u_int DisplayMatrixSize 2944 char[65] SequencePrgName 3009 char[65] SequenceWkcName 3074 char[9] SequenceAuthor 3083 char[8] SequenceType 3744 double FOVRow 3752 double FOVColumn 3768 double CenterPointX 3776 double CenterPointY 3784 double CenterPointZ 3792 double NormalVectorX 3800 double NormalVectorY 3808 double NormalVectorZ 3816 double DistanceFromIsocenter 3832 double RowVectorX 3840 double RowVectorY 3848 double RowVectorZ 3856 double ColumnVectorX 3864 double ColumnVectorY 3872 double ColumnVectorZ 3880 char[3] OrientationSet1X 3884 char[3] OrientationSet1Y 3888 char[3] OrientationSet1Z 3892 char[3] OrientationSet2X 3896 char[3] OrientationSet2Y 3900 char[3] OrientationSet2Z 3904 char[32] SequenceName 5000 double PixelSizeRow 5008 double PixelSizeColumn 5504 char[12] TextPatientID 5517 char TextPatientSex 5518 char[3] TextPatientAge 5521 char TextPatientAgeUnits ('Y'=years) 5529 char[7] TextPatientPosition 5541 char[5] TextImageNumberFlag ('IMAGE'=image) 5546 char[3] TextImageNumber 5559 char[2] TextDateDD 5562 char[3] TextDateMM 5566 char[4] TextDateYYYY 5571 char[2] TextTimeHH 5574 char[2] TextTimeMM 5577 char[2] TextAcquisitionTimeFlag ('TA'=acquisition time) 5583 char[2] TextAcquisitionTimeMM 5586 char[2] TextAcquisitionTimeSS 5601 char[4] TextAnnotation 5655 char[25] TextOrganization 5682 char[5] TextStation 5695 char[3] TextAcquisitionMatrixPhase 5698 char TextAcquisitionMatrixPhaseAxis ('h'=horizontal,' '=vertical) 5700 char[3] TextAcquisitionMatrixFreq 5703 char TextAcquisitionMatrixFreqO ('o'=o,' '=blank) 5704 char TextAcquisitionMatrixFreqS ('s'=s,' '=blank) 5706 char[8] TextSequence 5714 char[3] TextFlipAngle 5718 char[4] TextScanNumberFlag ('SCAN'=scan) 5723 char[3] TextScanNumberA 5726 char[3] TextScanNumberB 5730 char[2] TextRepetitionTimeFlag ('TR'=tr) 5734 char[7] TextRepetitionTime 5742 char[2] TextEchoTimeFlag ('TE'=te) 5746 char[5] TextEchoTime 5752 char TextEchoNumber 5790 char[2] TextSliceThicknessFlag ('SL'=slice thickness) 5794 char[7] TextSliceThickness 5802 char[2] TextSlicePositionFlag ('SP'=slice position) 5806 char[7] TextSlicePosition 5814 char[3] TextAngleFlag1 ('Sag'=sagittal,'Cor'=coronal,'Tra'=transverse) 5817 char TextAngleFlag2 ('>'=gt,'<'=lt) 5818 char[3] TextAngleFlag3 ('Sag'=sagittal,'Cor'=coronal,'Tra'=transverse) 5821 char[4] TextAngle 5838 char[3] TextFOVFlag ('FoV'=field of view) 5842 char[3] TextFOVH 5846 char[3] TextFOVV 5874 char[2] TextTablePositionFlag ('TP'=table position) 5878 char[7] TextTablePosition 5938 char[5] TextStudyNumberFlag ('STUDY'=study) 5943 char[2] TextStudyNumber 5956 char[2] TextDOBDD 5959 char[3] TextDOBMM 5963 char[4] TextDOBYYYY 5992 char[3] TextStudyNumberFlag2 ('STU'=study) 5996 char[3] TextImageNumberFlag2 ('IMA'=study) 5999 char[2] TextStudyNumber2 6002 char[2] TextImageNumber2 6013 char[5] TextStudyImageNumber3 6031 char[15] TextModelName 6058 char[25] TextPatientName 6085 char[2] TextScanStartTimeHH 6088 char[2] TextScanStartTimeMM 6091 char[2] TextScanStartTimeSS 3.3.2.4.2 Siemens Magnetom Vision SPI Format Unknown. 3.3.3 Philips MR 3.3.3.1 Philips Gyroscan S5 - can export as ACR/NEMA (actually SPI) files - little endian byte order - 12 bit packed data This description pertains to "exported ACR/NEMA", not the native image files, which I am not familiar with. In fact I am not even sure in which directory they live. Use the ADMIN menu on the operator's console to find the import/export ACR/NEMA utility, with which you can select an exam, series or image to export as an ACR/NEMA file. The default directory is the GYROVIEW home directory, which is already pretty cluttered so it is better to make another subdirectory like "ANI" to keep exported files in. The exported files have huge names composed of identification information, but all have a ".ANI" extension. For example: DIR SYS$SYSROOT:[GYROSCAN]*.ANI;* SMITH__FA02010801010001.ANI;1 These files are stored as, wait for it, fixed length 512 byte records, with the "carriage return carriage control" record attributes set from some bizarre reason, which totally messes up kermit which starts messing with adding and changing CR/LF characters. See the Vax diatribe below for a method of getting around this, by using DUMP as a poor man's uuencode permitting ascii transfer. Unfortunately the nature of fixed length records under VMS means that the last record will be padded out to 512 bytes without any indication of the "real" end-of-file. This means your ACR/NEMA reader has to cope with trailing garbage gracefully. Unlike the Siemens SPI files, the Philips ones are stored in little-endian format. There is no fixed size header to skip, just go straight into the ACR/NEMA data stream. For the image pixel data four 12 bit words are packed without padding into 16 bit words, without any compression sheme. See the ACR/NEMA section for description of the packing organization. Lots of private tags are defined, but these can be ignored. Some of the identifying tags present are as follows: (0000x8,000x10) CS RecognitionCode VR= 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 Philips Gyroscan ACS 3.3.3.3 Philips Gyroscan T5 3.3.3.4 Philips Gyroscan NT5 & NT15 3.3.4 Picker MR - another black hole 3.3.5 Toshiba MR - another black hole 3.3.6 Hitachi MR - another black hole 3.3.7 Shimadzu MR No longer a black hole, as some information and sample files have arrived. Watch this space. 3.3.8 Elscint MR - another black hole The next part is part5 - proprietary other formats. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!uhog.mit.edu!news.mathworks.com!gatech!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail From: dclunie@flash.us.com (David A. Clunie) Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 5/8 Followup-To: alt.image.medical Date: 30 Jan 1996 16:04:11 -0500 Organization: Mollard Consultants Lines: 651 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 28 Feb 1996 00:00:00 GMT Message-ID: <4em14b$3cn@flash.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: flash.ksapax Summary: This posting contains answers to the most Frequently Asked Question on alt.image.medical - how do I convert from image format X from vendor Y to something I can use ? In addition it contains information about various standard formats. Xref: senator-bedfellow.mit.edu alt.image.medical:4253 comp.protocols.dicom:1435 sci.data.formats:1405 sci.med.informatics:5253 sci.med.radiology:4966 alt.answers:15306 comp.answers:16761 sci.answers:3830 news.answers:63444 Archive-name: medical-image-faq/part5 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 3.4 Proprietary Workstations 3.4.1 ISG Workstations 3.4.1.1 Gyroview The Philips Gyroview workstation is a high-resolution graphical workstation for MR images from Gyroscan scanners, that can also handle CT images and other modalities, and has an optional package for three dimensional processing of images. It is based on a Sun SPARC system with proprietary graphics hardware. The software is actually written by ISG in Canada. The image format is an ACR/NEMA based format with various private tags defined, and a proprietary scheme of image compression that has me stumped. I am told by some that there is no means of telling the Gyroview not to compress the images. I use compress in the sense that includes packing four 12 bit words into three 16 bit big-endian words, which appears to be part of the scheme in use. Unfortunately, some form of perimeter encoding is also in use, and I just can't figure it out :( Some people have had more luck using "the export utility of the Gyroview" to produce just 12 bit packed images without the perimeter encoding. I don't kn Despite prolonged exchanges of email it seems that the formal decision is not to release the format. Customers may contact ISG at harry@isgtec.com(Harry Visser) to bitch about this and then give up and ask for information on how to obtain a software package called the External Developers Tool which contains a tool called xdimage which can only be used on ISG's proprietary hardware. This is free to customers. It does however only export to (and import from) a flat file format and ascii description, not an ACR/NEMA style file with uncompressed pixel data :(. I would still prefer to know the format, as people keep asking (these machines were pretty popular I gather), and if anyone has any hints about the data format, I would appreciate them. Here follows part of a reply to one of these people when I made an unsuccesful attempt to figure this out: Firstly, I presume this file is generated by a Philips Gyroview workstation judging by ... (0008,0070) LO Manufacturer VR= VL=<8> The file says it is an MRI image ... (0008,0060) CS Modality VR= VL=<2> and yet it is missing many of the mri attributes normally present. Also it includes some CT specific attributes, notably ... (0018,1120) DS GantryDetectorTilt VR= VL=<2> < 0> which is pretty weird. I presume that this format is generated by something purely for the purposes of 3D reconstruction and only the attributes needed for that have been preserved. The image appears to be 512*512 ... (0028,0010) US Rows VR= VL=<2> [200] (0028,0011) US Columns VR= VL=<2> [200] As far as the compression format is concerned ... (0028,0060) CS CompressionCode VR= VL=<2> < 2> is not in itself a valid ACR/NEMA value, and hence some proprietary variation is in use. The most important clue is ... (0028,0040) CS ImageFormat VR= VL=<4> which is also not valid ACR/NEMA (only RECT is permitted). From this I conclude that some sort of 'circular' perimeter encoding scheme is in use that only sends the meaningful central pixels in each row and leaves out the background. This is substantiated by the fact that the image pixel data seems to be preceded by a table of 257 long words in ascending order, each value separated by relatively low values (80-100 or so). I suspect that these are pointers into the data to the start of each row... % od -x I011_1_001 +1404 | more 0001404 0000 0202 0000 0252 0000 02a2 0000 02f2 0001424 0000 0342 0000 0392 0000 03e2 0000 0432 0001444 0000 0482 0000 04d2 0000 0522 0000 0572 0001464 0000 05c2 0000 0612 0000 0662 0000 06b3 0001504 0000 0705 0000 0757 0000 07ab 0000 0800 0001524 0000 0857 0000 08ae 0000 0905 0000 095e ... [0000] 000514 -> 000514 [0001] 000594 -> 000080 [0002] 000674 -> 000080 [0003] 000754 -> 000080 [0004] 000834 -> 000080 [0005] 000914 -> 000080 ... [0155] 015322 -> 000103 [0156] 015425 -> 000103 [0157] 015527 -> 000102 [0158] 015629 -> 000102 ... [0254] 024484 -> 000080 [0255] 024564 -> 000080 [0256] 024564 -> 000000 The first of these values seems to be a pointer in two byte word units past the table, the entries for a series of rows, then a final "257th" value that is the same as the preceding with a difference of zero, possibly flagging the end of the table. What confuses me is the fact that there are 256 or so entries rather than 512 (number of rows), and that the difference values are relatively small for 512 columns. Perhaps each entry applies to two successive rows though this seems rather peculiar. Furthermore, if it is true that the units are two byte words, then the last pointer value is much lower than the number of remaining bytes in the image pixel data attribute, so what are all the other bytes for ? The other thing that is going to make extraction difficult is the fact that the data are supposed to be 12 bits packed into 16 bit words ... (0028,0100) US BitsAllocated VR= VL=<2> [c] (0028,0101) US BitsStored VR= VL=<2> [c] (0028,0102) US HighBit VR= VL=<2> [b] Hence 3 two byte words are used to store 4 12 bit pixels. It may not be easy to figure out in what order this packing is performed. The ACR/NEMA standard has an example of its intent in this case, but the byte order was never specified for this standard, which had a 16 bit hardware data path and was not originally intended for offline data storage in bytes, so there are a number of possible permutations to deal with :( Finally I don't know what to make of the "private" tags ... Unrecognized (0029,0010) VR= VL= Unrecognized (0029,1070) VR= VL=<6> < 49128> Unrecognized (0029,1080) VR= VL=<6> <123432> Unrecognized (0029,1090) VR= VL=<2> < 0> which presumably have some significance or they wouldn't be there ! 3.5 Other Proprietary Formats 3.5.1 Analyze From Mayo This very popular software package is produced by the Biomedical Imaging Resource group at the Mayo Clinic/Foundation. I have always thought they should give it away but they don't, it is moderately expensive, though less so than some other alternatives. If you want to test or buy it try contacting Denny Hanson dph@mayo.edu who is extremely helpful. Anyway, importing images into Analyze is a drag and you have to convert your files to their format, but it isn't very difficult. I hear that some other programs also use their format but haven't encountered them myself. Anyway, the package is sufficiently commonly used that it seems appropriate to include the format here. This information is included verbatim from what was sent to me by Ellis Workman elw@mayo.edu and if you have problems I am sure he will be able to help. I haven't tested it because I can't afford to buy a copy myself :( That's a hint, Denny. ANALYZE IMAGE FILE FORMAT ANALYZE image file sets consist of at least 2 files: - an image file - a header file - a color lookup file * optional For the Analyze image file set "foo" there are two files: foo.img & foo.hdr (optionally foo.lkup) The ANALYZE programs refer to this file set as a single entity. The Image File (foo.img) The format of the image file is very simple; containging usually uncompressed voxel data for the images in one of the several possible voxel formats: - 1 bit packed binary (slices begin on byte boundaries) - 8 bit (unsigned char) gray scale unless .lkup file present - 16 bit signed short - 32 bit signed integers or float - 24 bit RGB, 8 bits per channel The header file is a 'C' structure which describes the dimensions and properties of the voxel data. This structure follows: /* * * (c) Copyright, 1986-1995 * Biomedical Imaging Resource * Mayo Foundation * * dbh.h * * * database sub-definitions */ struct header_key /* header_key */ { /* off + size*/ int sizeof_hdr; /* 0 + 4 */ char data_type[10]; /* 4 + 10 */ char db_name[18]; /* 14 + 18 */ int extents; /* 32 + 4 */ short int session_error; /* 36 + 2 */ char regular; /* 38 + 1 */ char hkey_un0; /* 39 + 1 */ }; /* total=40 */ struct image_dimension /* image_dimension */ { /* off + size*/ short int dim[8]; /* 0 + 16 */ char vox_units[4]; /* 16 + 4 */ char cal_units[8]; /* 20 + 4 */ short int unused1; /* 24 + 2 */ short int datatype; /* 30 + 2 */ short int bitpix; /* 32 + 2 */ short int dim_un0; /* 34 + 2 */ float pixdim[8]; /* 36 + 32 */ /* pixdim[] specifies the voxel dimensions: pixdim[1] - voxel width pixdim[2] - voxel height pixdim[3] - interslice distance ..etc */ float vox_offset; /* 68 + 4 */ float funused1; /* 72 + 4 */ float funused2; /* 76 + 4 */ float funused3; /* 80 + 4 */ float cal_max; /* 84 + 4 */ float cal_min; /* 88 + 4 */ int compressed; /* 92 + 4 */ int verified; /* 96 + 4 */ int glmax, glmin; /* 100 + 8 */ }; /* total=108 */ struct data_history /* data_history */ { /* off + size*/ char descrip[80]; /* 0 + 80 */ char aux_file[24]; /* 80 + 24 */ char orient; /* 104 + 1 */ char originator[10]; /* 105 + 10 */ char generated[10]; /* 115 + 10 */ char scannum[10]; /* 125 + 10 */ char patient_id[10]; /* 135 + 10 */ char exp_date[10]; /* 145 + 10 */ char exp_time[10]; /* 155 + 10 */ char hist_un0[3]; /* 165 + 3 */ int views; /* 168 + 4 */ int vols_added; /* 172 + 4 */ int start_field; /* 176 + 4 */ int field_skip; /* 180 + 4 */ int omax,omin; /* 184 + 8 */ int smax,smin; /* 192 + 8 */ }; /* total=200 */ struct dsr /* dsr */ { /* off + size*/ struct header_key hk; /* 0 + 40 */ struct image_dimension dime; /* 40 + 108 */ struct data_history hist; /* 148 + 200 */ }; /* total=348 */ Comments: struct header_key int sizeof_header /* must indicate size of header file */ int extants; /* should be 16384 */ char regular; /* 'r' */ struct image_dimension struct decribes the organization and side of images. These elements enable IO routines to reference images by volume and slice number. short int dim[] /* array of image dimensions */ dim[0] /* number of dimensions; usually 4 */ dim[1] /* image width */ dim[2] /* image height */ dim[3] /* volume depth */ dim[4] /* volumes in file */ char vox_units[4] /* labels voxerl spatial unit */ char cal_units[4] /* labels voxel calibration unit */ short int datatype /* Acceptable values are */ #define DT_NONE 0 #define DT_UNKNOWN 0 #define DT_BINARY 1 #define DT_UNSIGNED_CHAR 2 #define DT_SIGNED_SHORT 4 #define DT_SIGNED_INT 8 #define DT_FLOAT 16 #define DT_COMPLEX 32 #define DT_DOUBLE 64 #define DT_RGB 128 #define DT_ALL 255 short int bitpix /* bits per pixel */ float pixdim[] /* parallel array to dim giving voxel dimensions in each dimension */ pixdim[1] /* voxel width */ pixdim[2] /* voxel height */ pixdim[3] /* voxel depth or slice thickness */ float vox_offset; /* byte offset in the .img file at which voxels start. If value is negative specifies that the absolute value is applied for every image in the file. */ float calibrated Max & Min /* specify range of calibration values */ int glmax, glmin /* the max and min values for entire data set */ The data_history substructure is not required, but the 'orient' element is used to indicate individual slice orientation and determines whether the ANALYZE 'Movie' program will attempt to flip the images before displaying a movie sequence. orient: 0 - transverse unflipped 1 - coronal unflipped 2 - sagittal unflipped 3 - transverse flipped 4 - coronal flipped 5 - sagittal flipped The following 'C' program creates an Analyze .hdr file. /* * (c) Copyright, 1986-1994 * Biomedical Imaging Resource * Mayo Foundation * * */ #include #include "dbh.h" main(argc,argv) /* file x y z t datatype max min */ int argc; char **argv; { int i; struct dsr hdr; FILE *fp; static char DataTypes[9][12] = {"UNKNOWN", "BINARY", "CHAR", "SHORT", "INT", "FLOAT", "COMPLEX", "DOUBLE", "RGB"}; static int DataTypeSizes[9] = {0,1,8,16,32,32,64,64,24}; if(argc != 9) { usage(); exit(0); } memset(&hdr,0, sizeof(struct dsr)); for(i=0;i<8;i++) hdr.dime.pixdim[i]=0.0; hdr.dime.vox_offset = 0.0; hdr.dime.roi_scale = 1.0; hdr.dime.funused1 = 0.0; hdr.dime.funused2 = 0.0; hdr.dime.cal_max = 0.0; hdr.dime.cal_min = 0.0; hdr.dime.datatype = -1; for(i=1;i<=8;i++) if(!strcmp(argv[6],DataTypes[i])) { hdr.dime.datatype = (1<<(i-1)); hdr.dime.bitpix = DataTypeSizes[i]; break; } if(hdr.dime.datatype <= 0) { printf(" is an unacceptable datatype \n\n", argv[6]); usage(); exit(0); } if((fp=fopen(argv[1],"w"))==0) { printf("unable to create: %s\n",argv[1]); exit(0); } hdr.dime.dim[0] = 4; /* all Analyze images are taken as 4 dimensional */ hdr.hk.regular = 'r'; hdr.hk.sizeof_hdr = sizeof(struct dsr); hdr.dime.dim[1] = atoi(argv[2]); /* slice width in pixels */ hdr.dime.dim[2] = atoi(argv[3]); /* slice height in pixels */ hdr.dime.dim[3] = atoi(argv[4]); /* volume depth in slices */ hdr.dime.dim[4] = atoi(argv[5]); /* number of volumes per file */ hdr.dime.glmax = atoi(argv[7]); /* maximum voxel value */ hdr.dime.glmin = atoi(argv[8]); /* minimum voxel value */ /* Set the voxel dimension fields: A value of 0.0 for these fields implies that the value is unknown. Change these values to what is appropriate for your data or pass additional command line arguments */ hdr.dime.pixdim[1] = 0.0; /* voxel x dimension */ hdr.dime.pixdim[2] = 0.0; /* voxel y dimension */ hdr.dime.pixdim[3] = 0.0; /* pixel z dimension, slice thickness */ /* Assume zero offset in .img file, byte at which pixel data starts in the image file */ hdr.dime.vox_offset = 0.0; /* Planar Orientation; */ /* Movie flag OFF: 0 = transverse, 1 = coronal, 2 = sagittal Movie flag ON: 3 = transverse, 4 = coronal, 5 = sagittal */ hdr.hist.orient = 0; /* up to 3 characters for the voxels units label; i.e. mm., um., cm. */ strcpy(hdr.dime.vox_units," "); /* up to 7 characters for the calibration units label; i.e. HU */ strcpy(hdr.dime.cal_units," "); /* Calibration maximum and minimum values; values of 0.0 for both fields imply that no calibration max and min values are used */ hdr.dime.cal_max = 0.0; hdr.dime.cal_min = 0.0; fwrite(&hdr,sizeof(struct dsr),1,fp); fclose(fp); } usage() { printf("usage: make_hdr name.hdr x y z t datatype max min \n\n"); printf(" name.hdr = the name of the header file\n"); printf(" x = width, y = height, z = depth, t = number of volumes\n"); printf(" acceptable datatype values are: BINARY, CHAR, SHORT,\n"); printf(" INT, FLOAT, COMPLEX, DOUBLE, and RGB\n"); printf(" max = maximum voxel value, min = minimum voxel value\n"); } The following program displays information in an Analyze header file. #include #include "dbh.h" void ShowHdr(char *, struct dsr *); void swap_long(unsigned char *); void swap_short(unsigned char *); main(argc,argv) int argc; char **argv; { struct dsr hdr; int size; double cmax, cmin; FILE *fp; if((fp=fopen(argv[1],"r"))==NULL) { fprintf(stderr,"Can't open:\n", argv[1]); exit(0); } fread(&hdr,1,sizeof(struct dsr),fp); if(hdr.dime.dim[0] 15) swap_hdr(&hdr); ShowHdr(argv[1], &hdr); } void ShowHdr(fileName,hdr) struct dsr *hdr; char *fileName; { int i; char string[128]; printf("Analyze Header Dump of: \n", fileName); /* Header Key */ printf("sizeof_hdr: \n", hdr->hk.sizeof_hdr); printf("data_type: \n", hdr->hk.data_type); printf("db_name: \n", hdr->hk.db_name); printf("extents: \n", hdr->hk.extents); printf("session_error: \n", hdr->hk.session_error); printf("regular: \n", hdr->hk.regular); printf("hkey_un0: \n", hdr->hk.hkey_un0); /* Image Dimension */ for(i=0;i<8;i++) printf("dim[%d]: \n", i, hdr->dime.dim[i]); strncpy(string,hdr->dime.vox_units,4); printf("vox_units: \n", string); strncpy(string,hdr->dime.cal_units,8); printf("cal_units: \n", string); printf("unused1: \n", hdr->dime.unused1); printf("datatype: \n", hdr->dime.datatype); printf("bitpix: \n", hdr->dime.bitpix); for(i=0;i<8;i++) printf("pixdim[%d]: \n",i, hdr->dime.pixdim[i]); printf("vox_offset: \n", hdr->dime.vox_offset); printf("funused1: \n", hdr->dime.funused1); printf("funused2: \n", hdr->dime.funused2); printf("funused3: \n", hdr->dime.funused3); printf("cal_max: \n", hdr->dime.cal_max); printf("cal_min: \n", hdr->dime.cal_min); printf("compressed: \n", hdr->dime.compressed); printf("verified: \n", hdr->dime.verified); printf("glmax: \n", hdr->dime.glmax); printf("glmin: \n", hdr->dime.glmin); /* Data History */ strncpy(string,hdr->hist.descrip,80); printf("descrip: \n", string); strncpy(string,hdr->hist.aux_file,24); printf("aux_file: \n", string); printf("orient: \n", hdr->hist.orient); strncpy(string,hdr->hist.originator,10); printf("originator: \n", string); strncpy(string,hdr->hist.generated,10); printf("generated: \n", string); strncpy(string,hdr->hist.scannum,10); printf("scannum: \n", string); strncpy(string,hdr->hist.patient_id,10); printf("patient_id: \n", string); strncpy(string,hdr->hist.exp_date,10); printf("exp_date: \n", string); strncpy(string,hdr->hist.exp_time,10); printf("exp_time: \n", string); strncpy(string,hdr->hist.hist_un0,10); printf("hist_un0: \n", string); printf("views: \n", hdr->hist.views); printf("vols_added: \n", hdr->hist.vols_added); printf("start_field: \n", hdr->hist.start_field); printf("field_skip: \n", hdr->hist.field_skip); printf("omax: \n", hdr->hist.omax); printf("omin: \n", hdr->hist.omin); printf("smin: \n", hdr->hist.smax); printf("smin: \n", hdr->hist.smin); } swap_hdr(pntr) struct dsr *pntr; { swap_long(&pntr->hk.sizeof_hdr) ; swap_long(&pntr->hk.extents) ; swap_short(&pntr->hk.session_error) ; swap_short(&pntr->dime.dim[0]) ; swap_short(&pntr->dime.dim[1]) ; swap_short(&pntr->dime.dim[2]) ; swap_short(&pntr->dime.dim[3]) ; swap_short(&pntr->dime.dim[4]) ; swap_short(&pntr->dime.dim[5]) ; swap_short(&pntr->dime.dim[6]) ; swap_short(&pntr->dime.dim[7]) ; swap_short(&pntr->dime.unused1) ; swap_short(&pntr->dime.datatype) ; swap_short(&pntr->dime.bitpix) ; swap_long(&pntr->dime.pixdim[0]) ; swap_long(&pntr->dime.pixdim[1]) ; swap_long(&pntr->dime.pixdim[2]) ; swap_long(&pntr->dime.pixdim[3]) ; swap_long(&pntr->dime.pixdim[4]) ; swap_long(&pntr->dime.pixdim[5]) ; swap_long(&pntr->dime.pixdim[6]) ; swap_long(&pntr->dime.pixdim[7]) ; swap_long(&pntr->dime.vox_offset) ; swap_long(&pntr->dime.funused1) ; swap_long(&pntr->dime.funused2) ; swap_long(&pntr->dime.cal_max) ; swap_long(&pntr->dime.cal_min) ; swap_long(&pntr->dime.compressed) ; swap_long(&pntr->dime.verified) ; swap_short(&pntr->dime.dim_un0) ; swap_long(&pntr->dime.glmax) ; swap_long(&pntr->dime.glmin) ; } swap_long(pntr) unsigned char *pntr; { unsigned char b0, b1, b2, b3; b0 = *pntr; b1 = *(pntr+1); b2 = *(pntr+2); b3 = *(pntr+3); *pntr = b3; *(pntr+1) = b2; *(pntr+2) = b1; *(pntr+3) = b0; } swap_short(pntr) unsigned char *pntr; { unsigned char b0, b1; b0 = *pntr; b1 = *(pntr+1); *pntr = b1; *(pntr+1) = b0; } The next part is part6 - hosts & compression. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!munnari.OZ.AU!news.mel.connect.com.au!yarrina.connect.com.au!news.mira.net.au!Germany.EU.net!EU.net!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail From: dclunie@flash.us.com (David A. Clunie) Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 6/8 Followup-To: alt.image.medical Date: 30 Jan 1996 16:04:16 -0500 Organization: Mollard Consultants Lines: 675 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 28 Feb 1996 00:00:00 GMT Message-ID: <4em14g$3d8@flash.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: flash.ksapax Summary: This posting contains answers to the most Frequently Asked Question on alt.image.medical - how do I convert from image format X from vendor Y to something I can use ? In addition it contains information about various standard formats. Xref: senator-bedfellow.mit.edu alt.image.medical:4243 comp.protocols.dicom:1428 sci.data.formats:1398 sci.med.informatics:5237 sci.med.radiology:4948 alt.answers:15294 comp.answers:16735 sci.answers:3817 news.answers:63380 Archive-name: medical-image-faq/part6 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 4. Host Machines 4.1 Data General 4.1.1 Data General Data 4.1.1.1 Data General Integers Integers are 16 bit two's complement and stored in big-endian format as on Sun Sparc and opposite to the Dec VAX. 4.1.1.2 Data General Floating Point Single precision real values are 32 bits long, in big-endian format. The high bit is the sign bit, followed by a 7 bit excess 64 exponent (power to which 16 must be raised) then a 24 bit hexadecimally normalized mantissa with the decimal point to the left of the most significant bit. Double precision values just have another 32 bits tacked on the mantissa and the same exponent format. Sign |<-->|<------ Exponent ------>|<--------- Mantissa -------->| ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 31 28 27 24 23 20 19 16 |<----------------------- Mantissa ------------------------>| ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 Here is a little piece of C++ code that should run on anything and convert Data General floats to whatever the host's floating point format is. double value; unsigned char sign; Uint16 exponent; Uint32 mantissa; typedef struct { unsigned sign : 1; unsigned exponent : 7; unsigned mantissa : 24; } DG_FLOAT; DG_FLOAT number; unsigned char buffer[4]; instream.read(buffer,4); if (instream) { // DataGeneral is a Big Endian machine memcpy ((char *)(&number),buffer,4); sign = number.sign; exponent = number.exponent; mantissa = number.mantissa; value = (double) mantissa / (1 << 24) * pow (16.0, (long)(exponent) - 64); value = (sign == 0) ? value : -value; } else { cerr << "read failed\n" << flush; value=0; } 4.1.2 Data General Operating System 4.1.2.1 Data General RDOS Used on the GE CT 9800 family. Severely primitive but then is running on an old machine that can only map 64Kb of memory at a time after all. It is apparently multitasking. Documentation may still be available from Data General (try DG Direct) but is not supplied with the scanner by GE. If anyone knows where I can find it at a reasonable price let me know. Here is a brief command summary culled from a nifty pocket book from GE for SunOS/Genesis users that compares commands: CHATR - file attributes CRAND - create randomly organized file CDIR - create directory DELETE - files or directories DIR - change directory DISK - free space FILCOM - compare files GDIR - show working directory name GTOD - show date and time LINK - files (symbolic) LIST - directory contents MOVE - a file RENAME - a file SDAT - set date STOD - set time SDUMP - write files to a device SLOAD - read dumped files SPEED - tex editor TYPE - contents of file XFER - copy a file wildcards: '-' is series, '*' is single character 4.1.2.2 Data General AOS/VS Used on the GE Signa 3X and 4X family. Quite a nice operating system with multi-tasking and hierarchical directories. Here is a brief command summary again culled from a nifty pocket book from GE for SunOS/Genesis users that compares commands: ACL - access control list (ownership) BYE - exit command process COPY - a file CREATE - a text file CREATE/DIR - a directory CREATE/LINK - link files DELETE - files & directories DIR - display or change working directory DUMP - to peripheral F/AS/S - directory listing with file status DATE - show or set HELP LOAD - DUMPed files MOVE - a file RENAME - a file PATH - show pathname of a file PAUSE - the command line interpreter SUPERU ON - enable superuser SED - text editor TIME - show or set TYPE - contents of text file ? - list processes running wildcards: '+' is series, '*' is single character Other useful hints include the use of "^" to refer to the next directory up (like ".." in Unix) in DIR commands. Command options follow the command name without any spaces and are indicated by a slash. COPY operations specify the destination name first and then the source name. Devices like the mag tape are indicated by "@", for example "@MTB0" is tape drive zero. Files on the tape can be referred to as "@MTB0:nn" which is very handy. For example to read a file off a CT 9800 tape under AOS/VS: COPY/V/IMTRSIZE=8192 B038040101.YP @MTB0:18 Perhaps most importantly, there is an extensive online help system ... use the HELP command. 4.1.3 Data General Network If you have a GE Signa based on a DG then you can get the so-called "High Speed Network" card and software from GE. From memory it is pretty pricey, and there used to be a "slower" network interface that was cheaper, but I don't think this is available anymore. If you have a CT 9800 based on the DG S/140 and you need to get it connected there are a number of solutions: - Talk to GE about there ID/LINK II product ... I gather this is a device that hooks into the SCSI cable to the hard drive (you need one of the Ace drives not the old Zebra drive), monitors disk activity and snatches pieces of the conversation to make a copy of the image data, stores it and makes it available via some network protocol. Sound crazy ? Perhaps, but they tell me it works and the price is reasonable, at least for something from GE anyway. Get them to throw one in next time you buy something big. - The do-it-yourself approach. Talk to John Clayton (clayton@c-c.com) at Claflin and Clayton. They supply a complete R-level solution by providing Ethernet hardware and TCP/IP software for 16 bit DG OS including AOS and RDOS (specifically including the GE CT version of RDOS). He tells me "you can expect a file transfer rate of 25 kbytes/s for S/140 systems". The package consists of: $2,850 - EC-10 ethernet controller $1,645 - RDOS TCP/IP software (telnet client,ftp client/server) I have not personally tried either of these approaches, and I am sure there are others (talk to Merge or DeJarnette), but I am getting really tired of carrying 9-track tapes around so perhaps I will bite the bullet soon (and upgrade to a HighSpeed Advantage !). 4.2 Vax 4.2.1 Vax Data 4.2.1.1 Vax Integers - little endian - 8, 16, or 32 bits 4.2.1.2 Vax Floating Point - little endian - D_float - 8 bytes - sign bit 15 - exponent bits 14-7 excess 128 binary - fraction MSB firstbits 6-0, 31-16, 47-32, 63-48 - normalized bit is not represented (hidden) - G_float - 8 bytes - like D, but - exponent is bits 14-4 excess 1024 - fraction 3-0 and 63-16 - F_float - 4 bytes - like D, smaller fraction - H_float - 16 bytes - like G, but - exponent is bits 14-0 excess 16384 - fraction is bits 127-16 - same wierd order - bit 112 least significant 4.2.1.3 Vax Strings - 16 bits of length - byte of type - byte of class - 32 bits of pointer 4.2.2 Vax Operating System 4.2.2.1 Vax VMS Truely one of the world's most irritating operating systems to use, especially if you are a unix fan. Still it works, has a great online help system that saves one's butt almost often enough to be useful, and if you can remember the directory where kermit is stored and the weird command to invoke it one can get by (barely). If you don't know VMS and the vendor doesn't supply the manuals, get them from DEC ... you need them bad ... real bad. If (like me) you throw them out everytime you move then encounter another piece of archaic equipment, you need the "vaxbook" which is available via ftp from decoy.uoregon.edu, written by Joseph E St Sauver, which summarizes commands, files and all sorts of application specific stuff, though it is no substitute for the real thing. Recent VMS update: goddamn file formats ! Why can't VMS behave like a real operating system and forget this file format crap ! I have some Philips S5 MR images exported in ACR/NEMA format and I can't get the things off the hosts's Vax using Kermit, because though they have fixed length 512 byte records, some cretinous program sets the "carriage return carriage control" record attributes, which causes kermit to send with all the '0A' characters scrubbed out amongst other atrocities. I am getting desperate and about to try using the Hex/Dehex utility that came with Kermit to get the stuff off and then decode the hex format ! Or perhaps even use "dump" to make a textfile, transfer, and decipher that. (No I don't have a C compiler for the Vax so I guess I can't use uuencode unless someone wants to mail me a hex'ed executable). Any hints, or instructions as to how to use FDL and Convert, to change it to a normal format would be appreciated. (Why can't they just have a "set file record attrib More recent VMS update: finally had an inspiration while staring at hex dumps of these files - why not use the VMS "DUMP" utility which produces hex dumps as a "poor man's uuencode" by saving the dump to a file, transferring it as an ascii file, and then decoding it at the destination ? Of course there are no nifty line checksums or anything, but a transfer protocol such as kermit takes care of this. The DUMP output defaults to 8 32 bit long words separated by a space per line displayed as hex, then an ascii string (32 bytes) and then a 24 bit word hex address offset from the start of the fixed length record. All the data containing lines start with a single space, where as descriptions at the start of each record begin in the first column, hence the data lines can be easily selected out. By the way, the hex version of the data is listed in reverse order ! VMS is so bizarre ! For example, here is a fixed length 512 byte record file from a Philips S5 MRI (some of the hex words elided to Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ... File ID (2419,301,0) End of file block 198 / Allocated 200 Virtual block number 1 (00000001), 512 (0200) bytes 0000000C 00100008 ... 00000008 .............................. 000000 00083932 2E36302E ... 2D524341 ACR-NEMA 1.0.. .....1994.06.29.. 000020 00600008 4D5F4553 ... 00000030 0.......@.........A.....SE_M..`. 000040 494B0000 00100080 ... 00000002 ....MR..p.....Philips ........KI 000060 00183148 00000002 ... 32200000 .. 2........63865375........H1.. 0001E0 ^L Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ... File ID (2419,301,0) End of file block 198 / Allocated 200 Virtual block number 2 (00000002), 512 (0200) bytes 40000018 45424F52 ... 00161250 P.....AGACQ_PT_SURFACE_PROBE...@ 000000 And so on ... you get the idea. This ugly little C++ utility written quickly during this moment of inspiration will take saved DUMP output and make it binary again: #include #include "MainCmd.h" signed char hextobin(char c) { signed char r; switch (c) { case '0': r=0; break; case '1': r=1; break; case '2': r=2; break; case '3': r=3; break; case '4': r=4; break; case '5': r=5; break; case '6': r=6; break; case '7': r=7; break; case '8': r=8; break; case '9': r=9; break; case 'A': case 'a': r=0xa; break; case 'B': case 'b': r=0xb; break; case 'C': case 'c': r=0xc; break; case 'D': case 'd': r=0xd; break; case 'E': case 'e': r=0xe; break; case 'F': case 'f': r=0xf; break; default: r=-1; break; } return r; } int main(int argc,char **argv) { CCOMMAND(argc,argv); while (1) { const linemax=132; // only needs 113 char line[linemax]; cin.getline(line,linemax); if (!cin || cin.eof()) { // cerr << "Bad or eof\n" << flush; break; } unsigned count=cin.gcount(); if (count == 0 || line[0] != ' ') continue; if (count != 113) { cerr << "Line length " << count << "\n" << flush; break; } unsigned i; char *ptr = line + 8*(1+8); // line is in reverse order ... for (i=0; i<8; ++i) { unsigned j; for (j=0; j<4; ++j) { // 2 hex bytes -> 1 byte char bytelo = *--ptr; char bytehi = *--ptr; unsigned char byte = (hextobin(bytehi)<<4) + hextobin(bytelo); cout.put(byte); } --ptr; // space between long words } } return 0; } Note that the nature of fixed length records under VMS means that the last record will be padded out to 512 bytes without any indication of the "real" end-of-file. This means you have to cope with trailing garbage gracefully. Hot VMS/Philips news: neelin@pet.mni.mcgill.ca (Peter Neelin) tells me there is an extremely useful tool for fiddling binary files called FILE from DECUS. It allows you to change a file's header information without modifying the content of the file. This then permits ftp, kermit, etc. to do the right thing with Philips .ANI files. It also permits wildcards and does not make a copy of the file (so it is fast). He says also that someone has told him that they succeeded in using convert to fix these files, but his general experience with it is not positive (it will often change the content of the file and it doesn't allow wildcards, in addition to promoting the use of the horrible fdl editor!). If you are interested, you can get FILE through gopher from decus.org (look for the DECUS software library archives, under essential tools). The binary is provided in case you don't have a compiler. Some other useful hints: - To log onto a serial terminal without executing the login command file add "/NOCOM" to the username ... this way you can use the operator console login which often won't require a password. - There is a kermit available for the Vax under VMS (file prefix "vms" in area or tape b) ... I use the "obsolete" version written in Bliss, because it comes from the archives at columbia with a hex encoded executable which can be uploaded just using an ordinary text capture into a file, and doing the same with the short Macro hex program that can then be assembled and used to make the convert into the real executable. Look in places like [SYSEXE] first though to be sure Kermit is not already there. The generic C version of kermit runs under VMS (file prefix "ck" in area or tape f), but not every imaging machine comes with a VMS C compiler, whereas Macro is always supposed to be there I gather. There is however also a hex encoded executable of the C version in the archives (ckvker.hex) which I haven't tried, and is the one that is recommended in the kermit documentation. - There is apparently a zmodem for VMS but I don't know where it comes from or how to get it. - Serial ports are almost always defaulted to 9600 baud. - "SET TERMINAL/ECHO" often isn't set. - Vax/VMS ftp conventions: UNIX FTP server Vax/VMS FTP server cd dir cd [.dir] cd dir/subdir cd [.dir.subdir] cd .. cd [-] 4.2.2.2 ULTRIX 4.2.2.3 OSF 4.3 Sun - Sun3 68000 and Sun4 Sparc 4.3.1 Sun Data The sun3 and sun4 architectures use much the same formats. Even though the processors are different both are big-endian and the float formats are IEEE. See the Sparc Architecture Manual - Chapter 3 - Data Formats for more details. 4.3.1.1 Sun Integers Integers are 8, 16, 32, or 64 bit unsigned or signed two's complement and stored in big-endian format as on Data General and opposite to the Dec VAX. Most C compilers treat short as 16 bits, and int and long as 32 bits. 4.3.1.2 Sun Floating Point Formats conform to IEEE 754-1985. Single precision real values are 32 bits long, in big-endian format. The high bit is the sign bit, followed by a 8 bit excess 127 exponent (power to which 2 must be raised) then a 23 bit normalized mantissa with the decimal point to the left of the most significant bit, from which 1.0 has been subtracted. Double precision values have a 11 bit excess 1023 exponent and a 52 bit mantissa. Quad precision values have a 15 bit excess 16383 exponent and a 112 bit mantissa. Sign |<-->|<-------- Exponent -------->|<------- Mantissa ------>| ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 31 28 27 24 23 20 19 16 |<----------------------- Mantissa ------------------------>| ______________ ______________ ______________ ______________ | | | | | |______________|______________|______________|______________| 15 12 11 8 7 4 3 0 Here is a little piece of C++ code that should run on anything and convert Sun IEEE floats to whatever the host's floating point format is. It probably should take into account a few special cases to be strictly correct: unsigned char buffer[4]; instream.read(buffer,4); if (instream) { #ifdef USESUN4NATIVEFLOAT float fvalue; memcpy ((char *)(&fvalue),buffer,4); value=fvalue; #else USESUN4NATIVEFLOAT unsigned char sign; Uint16 exponent; Uint32 mantissa; typedef struct { unsigned sign : 1; unsigned exponent : 8; unsigned mantissa : 23; } IEEE_FLOAT_SINGLE; IEEE_FLOAT_SINGLE number; // Sparc is a Big Endian machine memcpy ((char *)(&number),buffer,4); sign = number.sign; exponent = number.exponent; mantissa = number.mantissa; if (exponent) { value = (1.0 + (double)mantissa / (1 << 23)) * pow (2.0, (long)(exponent) - 127); } else { if (mantissa) { value = (double)mantissa / (1 << 23) * pow (2.0, (long)(-126)); } else { value=0; } } value = (sign == 0) ? value : -value; #endif USESUN4NATIVEFLOAT } else { cerr << "read failed\n" << flush; value=0; } 4.3.1.3 Sun Strings Strings obey the usual C convention of null terminated strings without a length preamble. 4.3.2 Sun Operating System 5. Compression Schemes 5.1 Reversible Compression 5.2 Irreversible Compression 5.2.1 Perimeter Encoding 6. Getting Connected 6.1 Tapes Nine-track half-inch tapes were the old medium of choice for archiving and image exchange and many older pieces of equipment will have these. Unfortunately most people don't have such a drive on their workstation or personal computer. There are several possibilities: - Use another piece of equipment that has a more modern or networked or serial-ported host and a nine-track drive, and use it to do the extraction. I used to use a networked Signa 4X to do this to extract GE 9800 CT tapes. - Visit your MIS department, which almost certainly has an archaic mainframe with a tape drive. Sometimes tough to get them to read formats they aren't expecting though (the hosts not the people I mean :) ). - Buy a nine-track for your workstation. This may seem a ridiculous idea given the price of new 6250 bpi drives are around $5,000, but one can often pick up bargain primitive non-6250 or refurbished drive that is adequate for the job. The Qualstar 1054 is one such drive, that attaches to a SCSI port, and works with the regular SunOS SCSI tape driver, once a few tables in the kernel have been updated as follows, and the kernel rebuilt: {root}% pwd /usr/kvm/sys/scsi/targets {root}% diff -c stdef.h.prequalstar stdef.h *** stdef.h.prequalstar Tue Aug 30 19:32:24 1994 --- stdef.h Tue Aug 30 19:32:24 1994 *************** *** 43,48 **** --- 43,49 ---- #define ST_TYPE_FUJI 0x21 /* Fujitsu - (not tested) */ #define ST_TYPE_KENNEDY 0x22 /* Kennedy */ #define ST_TYPE_HP 0x23 /* HP */ + #define ST_TYPE_QUALSTAR 0x24 /* Qualstar */ #define ST_TYPE_HIC 0x26 /* Generic 1/2" Cartridge */ #define ST_TYPE_REEL 0x27 /* Generic 1/2" Reel Tape */ {root}% diff -c st_conf.c.prequalstar st_conf.c *** st_conf.c.prequalstar Tue Aug 30 19:32:22 1994 --- st_conf.c Tue Aug 30 19:32:22 1994 *************** *** 153,158 **** --- 153,174 ---- * so our best guess as to their capabilities is * included herein. */ + /* Qualstar 1054 or 1260s scsi 9-track with 64KB buffer */ + { + "Qualstar 1054/1260s 1/2\" Reel", 7, "NCR ADP-53", ST_TYPE_QUALSTAR, 10240, + (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR), + 300, 300, + { 0x00, 0x02, 0x06, 0x03}, + { 0, 0, 0, 0 } + }, + /* Qualstar 1054 scsi 9-track with 256KB buffer */ + { + "Qualstar 1054 1/2\" Reel", 10, "QUALSTAR10", ST_TYPE_QUALSTAR, 10240, + (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR), + 300, 300, + { 0x00, 0x02, 0x06, 0x06}, + { 0, 0, 0, 0 } + }, /* Wangtek QIC-150 1/4" cartridge */ { "Wangtek QIC-150", 14, "WANGTEK 5150ES", ST_TYPE_WANGTEK, 512, (ST_QIC | ST_AUTODEN_OVERRIDE), I got my Qualstar 1054 from Bill Power at Power Computer Services for only $750 and have successfully read GE 9800 CT and Philips S15 MR tapes with it so far. See the "Sources" section for where to get one. Once you have such a tape connected to the SCSI port, one can either write simple programs to read files (easiest if the tape has variable length records) or use shell scripts and the "dd" command with whatever the correct block size is. See dd(1), mt(1), and mtio(3) for more information. Remember that the read(2) call reads one fixed or variable length record at a time, and returns 0 bytes read for a tape mark, and two tape marks in a row indicates the end of the tape (normally). If you encounter short files with a series of records 80 bytes long chances are you are dealing with header/end markers. This is what ANSI standard tapes off VAX VMS seem to look like. Anyone who has any further information about tape formats and handling, especially references to standard or on-line documents please let me know. 6.2 Ethernet 6.3 Serial Ports The next part is part7 - information sources. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsserver.pixel.kodak.com!news.sprintlink.net!gryphon.phoenix.net!academ!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!swrinde!sgigate.sgi.com!sgiblab!news.spies.com!genmagic!bug.rahul.net!a2i!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail From: dclunie@flash.us.com (David A. Clunie) Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers Subject: Medical Image Format FAQ, Part 7/8 Followup-To: alt.image.medical Date: 30 Jan 1996 16:04:24 -0500 Organization: Mollard Consultants Lines: 1508 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 28 Feb 1996 00:00:00 GMT Message-ID: <4em14o$3dp@flash.ksapax> Reply-To: dclunie@flash.us.com (David A. Clunie) NNTP-Posting-Host: flash.ksapax Summary: This posting contains answers to the most Frequently Asked Question on alt.image.medical - how do I convert from image format X from vendor Y to something I can use ? In addition it contains information about various standard formats. Xref: senator-bedfellow.mit.edu alt.image.medical:4248 comp.protocols.dicom:1431 sci.data.formats:1401 sci.med.informatics:5243 sci.med.radiology:4956 alt.answers:15300 comp.answers:16741 sci.answers:3821 news.answers:63406 Archive-name: medical-image-faq/part7 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 7. Sources of Information 7.1 Vendor Contacts - ANSI - Getting a Registered Organization Number for a DICOM UID Root: ANSI Registration Coordinator Michelle Maas phone (212) 642-4900 phone (212) 642-4884 fax (212) 398-0023 e-mail mmaas@ansi.org www http://www.ansi.org/ numeric identifier costs $1000 and takes 10 days (needed for DICOM) organization name costs $1500 and takes 90 days (not needed for DICOM) - ATL: Advanced Technology Laboratories 22100 Bothell Everett Highway P.O. Box 3003 Bothell, WA 98041-3003 phone 206-487-7000 phone 206-485-6080 http://www.atl.com - COSIRA - Getting a Registered Organization Number for a DICOM UID Root: COSIRA - Canadian Open Systems Interconnection Registration Authority 275 Slater Street, 19th Floor Ottawa Ontario K1P5H9 phone (613) 236-7803 fax (613) 234-6934 Attention: Louis Ferland, extension 427 NumberForm object identifier costs $500 Canadian NameForm object identifier costs another $500 Canadian - DEFF Contact - TIFF based portable ultrasound format: - ATL - jbono@corp.atl.com John Bono - DICOM Registered Organization Number for a DICOM UID Root: ANSI Registration Coordinator COSIRA - Canadian Open Systems Interconnection Registration Authority - DICOM standard comments and working group information: David Snavely, Staff Executive NEMA 1300 North 17th Street, Suite 1847 Rosslyn VA 22209 phone 703-841-3200 NEMA phone 703-841-3285 David Snavely phone 703-841-3217 Jean Brown (David's secretary) e-mail dav_snavely@nema.org Gordon Bass American College of Radiology 1891 Preston White Drive Reston VA 22091 phone (703) 648-8900 - DICOM standard publications and ACR/NEMA standards: NEMA Publication Sales 1300 North 17th Street, Suite 1847 Rosslyn VA 22209 phone 703-841-3200 NEMA Last price I have for Parts 1-10 was $USD235 plus SH More recent parts are STILL NOT AVAILABLE - FDA approval for PACS and Related Devices: Guidance for the Comment and Review of 510(k) Notifications for PACS and Related Devices FDA Small Manufacturers Assistance phone (800) 638-2041 fax (800) 899-0381 (flash system for document delivery) fax (301) 827-0111 (flash system for document delivery) - FDA Regulatory Affairs site Regulatory Forum BBS - modem (919) 848-9461 http://www.nando.net/ads/ckbus/RAinfo/reglink1.htm - FDA standards online Fedworld Gateway - modem (703) 321-8020 telnet://fedworld.gov ftp://ftp.fedworld.gov http://www.fedworld.gov/ - General Electric (not just GEMS): http://www.ge.com/ - General Electric CRD (Corporate Research & Development): http://www.ge.com/crd/ - General Electric, GEMS DICOM information contacts: Donald VanSyckle Senior Systems Analyst GE Medical Systems 3200 N. Grandview Blvd. Waukesha WI 53188 phone (414) 521-6262 fax (414) 521-6800 email vansyckled@med.ge.com - GEMS image format information contacts: GE Format Documents currently available: - 46-021852 Technicare Magnetic Tape Image Fmt - 46-021853 CT 8800 Image Data Fmt - 46-021854 CT 9000 Image Data Fmt - 46-021855 CT 9800 Image Data Fmt - 46-021856 CT Pace Image Data Fmt - 46-021862 MR Max Image Data Fmt - 46-021858 MR Signa 4.x Mag Tape and Image Data Fmt - 46-021861 CT HLA/HSA MR Signa 5.x Image Data Fmt - 46-021863 CT HLA/HSA MR Signa 5.x Optical Disk Raw Partition - 46-021864 CT HLA/HSA MR Signa 5.x Image Extract Tool - 46-021865 CT HLA/HSA MR Signa 5.x DAT Archive Fmt - 46-021866 PET 4096 Plus and 2048 Plus Image Fmt - 46-269546 IDNet v2.0 Implementation Profiles Field engineers are now supposedly well informed about these documents and can obtain them directly for you. They are freely distributable. You can try calling GE documentation direct at: phone (800) 558-2040 phone (414) 548-2520 If these approaches doesn't work, try one of these guys. John Meissner Networks Technical Leader GE Medical Systems N25 W23255 Paul Road Pewaukee WI 53072 phone (414) 896-2707 email meissnerj@med.ge.com Alan Cuellar-Amrod CT OnLine Support GE Medical Systems email cuellara@iscmed.med.ge.com - General Electric Medical Systems: ftp://ftp.med.ge.com/ - General Electric, GEMS Ultrasound contact: Paul Mullen Radiology Product Manager email logiq@med.ge.com email mullenp@delphi.com (Paul Mullen) - Intech: http://www.dada.it/intech/welcome.html - General Electric, GEMS Ultrasound contact: Paul Mullen Radiology Product Manager email logiq@med.ge.com email mullenp@delphi.com (Paul Mullen) - Interfile information contacts: Trevor Cradduck cradduck@irus.rri.uwo.ca Andrew Todd-Pokropek a.todd@ucl.ac.uk - Images - digitized mammograms: - no FTP site - 50 each, normal and cancer mammograms - digitized at 200 micrometers and 8 bits - provide them with an appropriate tape - Contact: Maria Kallergi, PhD Department of Radiology University of South Florida 12901 Bruce B. Downs Blvd., Box 17 Tampa, FL 33612-4799 phone (813) 975-7873 fax (813) 975-7831 email kallergi@rad.usf.edu - ISG: ISG Technologies Inc 6509 Airport Rd. Mississauga, ONT L4V 1S7 Canada phone (905) 672-2100 http://www.isgtec.com/ - JPEG - Independent JPEG Group (IJG): Tom Lane jpeg-info@uunet.uu.net - Philips: http://www.philips.com - Philips Medical Systems: http://www.philips.com/ms http://www-eu.philips.com/ms European site http://www-us.philips.com/ms US mirror - Picker: http://www.picker.com - Siemens: http://www.siemens.de/ 7.2 Relevant FAQ's - Archive-name: compression-faq/part[1-3] - Archive-name: graphics/faq - Archive-name: graphics/resources-list/part[1-3] - Archive-name: image-processing/Macintosh - Archive-name: jpeg-faq - Archive-name: medical-image-faq/volume-visualization - Archive-name: medical-informatics-faq - Archive-name: pixutils-faq - Archive-name: sci-data-formats - DICOM FAQ - http://www.xray.hmc.psu.edu/dicom/faq.html - maintained by David Channin dsc@xray.hmc.psu.edu - periodically posted to comp.protocols.dicom - FITS basics and information (periodic posting) - FITS (Flexible Image Transport System) - for astronomical data - periodically posted by Barry Schlesinger bschlesinger@nssdca.gsfc.nasa.gov - in sci.astro.fits,sci.data.formats - Teleradiology FAQ - maintained by Phillip Berman compumed@indirect.com - periodically posted to various groups including - alt.image.medical - sci.med.informatics - sci.med.radiology - sci.med.telemedicine 7.3 Source Code See under FTP/WWW Sites 7.4 Commercial Offerings - Anatomical images on CDROM and other atlases: ADAM Software Inc 1899 Powers Ferry Rd. Suite 460 Marietta, GA 30067 phone (800) 755-2326 fax (404) 955-3088 phone (800) 408-ADAM Dept 502 phone (800) 408-ADAM Dept 504 phone (404) 980-0888 BodyWorks Software Marketing Corp 9830 South 51st St, Bldg. A-131 Phoenix, AZ 85044 phone (602) 893-3377 Gold Standard Multimedia http://www.gate.net/~gsm Lifeart phone (800) 543-3278 phone (216) 291-1922 McKnight Associates Interactive Human and Radiologic Anatomy CDROMs Scott C. Howard Medical CD-ROM Sales Consultant 242 S.W. 2nd Street Gainesville, FL 32601-6576 phone (904) 378-7773 phone (800) 378-7793 fax (904) 337-0760 email 75521.2241@compuserve.com VoxelMan Atlas Springer-Verlag, Electronic Media 175 Fifth Avenue New York, NY 10010 phone (212) 460-1682 phone (212) 533 5587 email blange@springer-ny.com See also: Visible Human Project Visible Human CDROM - Data General TCP/IP solution for RDOS & AOS: Claflin & Clayton 203 Southwest Cutoff Northboro, MA 01532 phone 508-393-7979 fax 508-393-8788 email clayton@c-c.com email 70262.3663@compuserve.com - Data General themselves: DG Direct phone 1-800-343-8842 - DICOM to Information System integration contacts: Intech HiCube DICOM IS Integration. email lapus@intech.dada.it (Lapo Bertini) Director of Marketing http http://www.dada.it/intech/hicube/home.html Mitra DICOM IS Integration. email eric@mitra.com (Eric Peterson) http http://www.mitra.com/his-scp.html Philips Inturis. email R.A.vanGeuns@nl.cis.philips.com (Rob van Geuns) http http://www.philips.com/ms/connectivity/index_en.html - DICOM interface toolkits and solutions: Dejarnette Research Systems Inc. Wayne Dejarnette Suite 700 401 Washington Avenue Towson, Maryland 21204 USA phone 410-583-0680 fax 410-583-0696 email info@dejarnette.com Merge Technologies Inc. 1126 S. 70th St, Suite N508B Milwaukee, Wisconsin 53214-34151 phone 414-475-4300 fax 414-475-3940 email sales@merge.com (sales) email itk_support@merge.com (toolkit) http http://www.merge.com/ Merge Technologies Europe. Molvense Erven 69 5672 HJ Nuenen The Netherlands phone +31-40-838-948 fax +31-40-832-975 Kodak Health Imaging Systems 18325 Waterview Parkway Dallas TX 75252 phone 214-994-1266 fax 214-994-4180 email cbs@khis.com (C.B.Stone) Mitra Eric Peterson 115 Randall Drive Waterloo Ontario N2V 1C5 Canada phone 519-746-2900 email eric@mitra.com (Eric Peterson) http http://www.mitra.com/ - DICOM to web gateways: Medwed. 667 Folsom Street San Fransisco CA 94107 phone 1-800-8MEDWEB phone 415-541-9980 fax 415-541-9984 email sales@medwed.net http http://www.medweb.net/ Passport Technologies. 86 Orchard Street Hackensack NJ 07601 phone 201-487-5885 fax 201-487-7455 email sbeer@ibm.net (Steve Beer) Director of RD,Marketing - Eight inch floppy solutions for PC's: Microtek Conversion Systems 940 Industrial Ave Palo Alto, Ca. 94303 phone (415) 424-1174 fax (415) 424-1176 8" drive and controller $2,095 Format software each package $595-$695 Computer Peripherals Unlimited 2355 N. Steves Blvd, Suite C Flagstaff AZ 86004 phone (602) 526-2261 fax (602) 773-9183 8" drive and controller $1,245 Format software ? included - InterFormat - qsh to Interfile conversion, ACR/NEMA to qsh, et al. - http://nucmed.nyu.edu/qshtape.html - medical image format translation program - automatically identifies and translates heterogeneous files - Motif interface for user browsing & image selection - input formats: - GE 8800 CT, 9800 CT, Advantage CT & MR, Signa MR - Technicare 2000 CT - Positron PET - Philips 300 Series CT - Trionix Triad SPECT - Siemens Somatom CT, Siemens Magnetom MR, CTI PET - Varian CTSIM - ACR-NEMA 1.0, ACR-NEMA 2.0, and AAPM/qsh - output formats: - AAPM/qsh - Interfile - ADAC Interfile - Varian CTSIM - DICOM 3.0 - Vital Images VoxelView - Vital Ximatron David Reddy <--- USA contact Radio Logic Inc. P.O. Box 9665 New Haven CT 06536 phone (203) 624-8113 email reddy@nucmed.med.nyu.edu Bartec Medical Systems Ltd. <--- UK, Europe & Mideast Impression House Invincible Road Farnborough Hampshire GU14 7NP England email bob@bartec.demon.co.uk - Medical Image Networks - Commercial. - Medweb 667 Folsom Street San Francisco CA 94107 phone (415) 541-9980 fax (415) 541-9984 http://www.mednet.net email jon@mednet.net - Network hardware for PACS/telemedicine/WAN. John A. Hansen Networks Northwest Inc. PO Box 40209 Bellevue Wa 98015 phone (800) 835-9462 phone (206) 641-8779 fax (206) 641-8909 email jahansen@networksnw.com - Photoshop Plugins (Commercial) for proprietary, ACR/NEMA and DICOM import. - ImportACCESS http://www.desacc.com A commercial Photoshop plugin that works with the many other programs that support the plugin format. Reads fixed format proprietary formats, and extra modules for ACR-NEMA 2.0, DICOM 3.0, Interfile 3.3 files are available. Particularly good at multi-slice images and color images, and clearly has a nuclear medicine bias to it. Well documented. Recommended. Note of potential bias - I was a beta tester. Hugh Lyshkow DesAcc 702 Wrightwood Ave. Chicago IL 60614 phone (312) 404-7888 fax (312) 472-8834 email daccess@interaccess.com (Hugh Lyshkow) - Proprietary format conversion, general: Phil Femano Medical Imaging Consultants phone (201) 812-1122 - Proprietary format conversion, Nuclear Medicine: Medical Imaging Technology Associates Ray Deininger 29 Main Street P.O. Box 197 Mainland PA 19451 phone (215) 513-0440 fax (215) 513-0442 email info@mita.com email ray@mita.com Images can be read from floppies, tapes, or networks on a PC. Import formats include: - Elscint SBACK (5.25") - Elscint UST (5.25, 3.5") - Elscint RECord (5.25") - Gamma11 (5.25") - Picker PCS (5.25") - GE Starcam/StarII (3.5") - GE Plink (5.25, 3.5") - NIC (5.35") - Interfile (5.25, 3.5") - Medasys Paragon (5.25") - Siemens Microdelta (5.25") - Sophy F83 (5.25, 3.5") - Sophy NXT (5.25, 3.5") - ADAC (5.25") Export formats include: - TARGA (.TGA) - GIF - TIF - PCX - WPG - PICT (MAC) - Medvision* - Interfile - GE Starcam - Elscint - Siemens - Sopha - Gamma11 8" floppy formats (Microtek Conversion Systems include: - Technicare - GE Star - Starcam - StarII - MDS - Toshiba - Elscint F1 - Scintronix - Siemens - Gamma11 - NIC - Picker PCS - Proprietary format conversion, ACR/NEMA (MedVision for Mac and Windows): Evergreen Technologies Jeffrey Siegel Main Street, PO Box 795 Castine ME 04421 phone 207-326-8300 fax 207-326-8333 email jsiegel@lunis.nucmed.luc.edu email 71035.3156@CompuServe.com Optical subsystems include: - GE Starcam - GE CT/MR - Siemens CT/MR Import formats include: - DEFF Ultrasound - DICOM - Elscint Nuclear - GE Starcam - GE CT 8800 - GE CT 9800 - GE CT HLA/HSA and MR Signa - Imatron CT - Interfile - Picker CT - Philips CT - Resonex MR - Siemens CT and MR - Siemens Icon Nuclear - Strichman Neuro 900 Nuclear - Toshiba Nuclear - Trionix Nuclear Export formats include: - Medvision format - ACR/NEMA Network capabilites include: - GE Starlink Agent - DICOM Agent (SCP) - Scanners for Xray films. Nathan Harris DBA Systems Inc. phone (407) 727-0660 email nharris@dba-sys.com Lumisys Cobrascan Vidar XRS email xrs@netcom.com - Slides - 35mm - by Internet. Submit by ftp, receive by FedEx. Interlace Media Ernie Nathaniel phone (204) 925-2330 fax (204) 261-6806 email ernie@interlace.mb.ca www http://www.interlace.mb.ca/interlace/ - Tape drive vendors - 9-track 1/2 inch. Power Computer Services <--- $750 Qualstar 1054 SCSI Bill Power 1132 Olympic Drive Corona CA 91719 phone 800-323-0694 phone 909-371-3992 fax 909-371-1401 email billp@powercomp.com (Bill Power) Bill is also working on an 9-track interface replacement to record on removable hard disk cartridges, to upgrade old equipment. - Tape drive emulators. Pertec 9-track interface to DAT, MOD, DICOM WORM emulator with MOD PBT Technologies Larry Martin 2500 Meridian Parkway Suite 106 Durham, NC 27713 phone (919) 544-4142 fax (919) 544-4585 email themrtns@ix.netcom.com (Larry Martin) - Teleradiology equipment vendors. CompuMed Inc. Cary Cole 1200 No El Dorado Pl Suite C300 Tucson AZ 85715 phone 602-544-0544 fax 602-722-9096 email compumed@indirect.com Images-On-Call. email IOC@ix.netcom.com - Video capture vendors Precision Digital Images 6742 185th Ave. NE Suite 100 Redmond, WA 98052 phone 206-882-0218 fax 206-867-9177 email info@precisionimages.com http http://www.precisionimages.com/ - Viewer vendors for Mac and/or Windows: Evergreen Technologies (see Proprietary format conversion, ACR/NEMA (MedVision for Mac and Windows)) Includes DICOM C-STORE Provider support. MultiView for Macintosh Image Data Corp. Don Alvarez 11550 IH-10 West San Antonio, TX 78230-1024 phone (210) 641-8340 fax (210) 641-7428 Alice Hayden Image Processing Group Boulder, Colorado, USA phone (303) 449-3433 fax (303) 449-3772 email help@perceptive.com Imaging Solutions phone (908) 780-7836 email mdinkes@delphi.com (Marc Dinkes) SiteView (Windows and SunOS 4.x) Joe Shapiro phone (617) 674-2199 fax (617) 674-2217 email gbb@ConSolve.com email joe@ConSolve.com demo ftp://wuarchive.wustl.edu/graphics/graphics/demo-packages/SiteView demo ftp://ftp.cica.indiana.edu/pub/pc/win3/demo/ - Visible Human CDROM Several vendors make various CDROM products containing sections from the Visible Human Project. - Research Systems Inc email visible@rsinc.com email peter@rsinc.com (Peter Hallett) email denisef@rsinc.com (Denise Fields) These CDs contain 1800+ axial images JPEG compressed, as well as sagittal and coronal reconstructions. A browser (specific to each platform Mac, Windows, Unix, hence different disks) provides access to the images and allows export in TIFF, PICT, GIF, Postscript, EPS, and BMP formats. Each disk costs $495. - Expomed Inc email expomed@interramp.com The Visual Man CD contains over 1800 24 bit JPEG compressed cryosection images and a Windows browser. $39.95 7.5 FTP/WWW sites - 3D Reconstruction Sites: - http://biocomp.arc.nasa.gov/3dreconstruction - 3D Software Sites: - http://www.uni-hamburg.de/~medizin/imdm VoxelMan - http://www.dsi.unimi.it/Users/imaging/eva.html XEVA-VisualStudio - See also 3DVIEWNIX - See also volume-visualization FAQ - 3DVIEWNIX (University of Pennsylvania): NB. The new 1.1 version has a different distribution policy and complete binary software, rather than just a demo, is available from the ftp site. - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/BINARIES - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MPEG_MOVIES - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/DATA - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/PAPERS - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MANUALS - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/SRC - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/TUTORIALS - http://mipgsun.mipg.upenn.edu - ACR Index of Radiologic Diagnoses (ascii text files): - ftp://ftp.xray.hmc.psu.edu/acr_codes - http://www.xray.hmc.psu.edu/acr_codes/acr_codes.html - AdobePhotoshop Plugins (Public Domain) for ACR/NEMA import (works with NIH Image also): - ftp://sumex-aim.stanford.edu/info-mac - /Graphic/Utility/photoshop-acr-nema.hqx - ftp://zippy.nimh.nih.gov/pub/nih-image - /plug-ins/ACRNema.hqx Frank Owen (owen@sgi.siemens.com) - /user-macros/import_ACR_NEMA.txt - Anatomy - interactive programs: - ftp://ftp.monash.edu.au/pub/medical - Anatomy - lung: - http://indy.radiology.uiowa.edu/Providers/Textbooks/rad/books/LungAnat/LungAnat.html - Angiography simulation: - ftp://ftp.comp.vuw.ac.nz/pub/graphics/peter/xras.tar.gz - http://www.comp.vuw.ac.nz/~peter/ - Blood flow modelling: - georgef@server1.usa (George Foutrakis) - http://www.neuronet.pitt.edu/~georgef - http://www.pitt.edu/~gnfst1 - CT reconstruction software: - ftp://peipa.essex.ac.uk/ipa/src/process - ct.tar.Z - snark77.tar.Z - Dermatology sites: - http://www.rrze.uni-erlangen.de/ - /docs/FAU/fakultaet/med/kli/derma/ - DICOM Conformance Statement sites: - DICOM Conformance Statement - Applicare. http://www.applicare.nl/#DICOM - DICOM Conformance Statement - ATL. Not yet available electronically jbono@corp.atl.com John Bono - DICOM Conformance Statement - Duke University Image Server. ftp://louis1.mc.duke.edu/pub/dicom/doc - DICOM Conformance Statement - General Electric. ftp://ftp.med.ge.com/pub/DICOM - Tutorial - Introduction - Advantage Windows - CT HighLight and HighSpeed Advantage - CT Prospeed - MR Signa - MR Vectra - DICOM Conformance Statement - Index. http://www.xray.hmc.psu.edu/dicom/dicom_home.html - DICOM Conformance Statement - Intech - HiCube. http://www.dada.it/intech/hicube/diccons.html - DICOM Conformance Statement - Intech - XFRAME. http://www.dada.it/intech/xframe/home.html - DICOM Conformance Statement - ISG. http://www.isgtec.com/dicom.htm - DICOM Conformance Statement - Loral. http://www.xray.hmc.psu.edu/dicom/loral_cs/loral_cs.html - DICOM Conformance Statement - Philips. http://www.philips.com/ms/connectivity/index_en.html ftp://ftp.xray.hmc.psu.edu/dicom_docs/conformance_stmnts/philips dicom@ms.philips.nl - DICOM Conformance Statement - Picker. http://www.picker.com/ - NM Odyssey (HTML) - CT IQ and PQ scanners (Postscript) - Voxel Q/AqQSim 3.11 (Postscript) - Voxel Q/AqQSim 3.2 (Postscript) - MR Edge/Vista/Asset (HTML) - Vistar (HTML) - DICOM Conformance Statement - Siemens. http://www.siemens.de/med/dicom/dicom.html dicom@ErlH.Siemens.DE - DICOM Conformance Statement - Survey. http://www.rahul.net/dclunie/dicom-conformance/survey.html - DICOM Conformance Statement - UCDMC. http://www-radiology.ucdmc.ucdavis.edu/pacs/MCONF.html - DICOM conversion tools (from proprietary formats) and utilities: - dicom3tools_*.tar.gz - ftp://ftp.rahul.net/pub/dclunie/dicom3tools/ - http://www.rahul.net/dclunie/dicom3tools/ - Tools and libraries for handling offline files. - Conversion from proprietary formats. - Can handle older ACR/NEMA format data. - Can handle SPI. - VERY limited X display capability. - No DICOM networking (yet). - Features. - Proprietary image conversions from ... - GE CT 9800 - GE CT High Speed Advantage (Genesis) - GE MR Signa 3X/4X - GE MR Signa 5X (Genesis) - GE CT Sytec - GE CT Pace - GE MR Max - Siemens CT Somatom DR family - Siemens CT Somatom Plus family (SPI) - Siemens MR Magnetom Impact (SPI) - Siemens MR Magnetom SP (SPI) - Siemens MR Magnetom GBS/GBS2 (native) - Siemens MR Vision (native) - Philips MR Gyroscan S5 (native,SPI) - Image format support ... - DICOM 3 offline file format (draft Part 10). - Parsing/validate DICOM modules and IODs. - Pbmplus extended 16 bit raw format. - Raw binary images. - Archive retrieval from ... - Generic extract 9-track and DAT. - GE CT 9800 9-track. - GE Genesis DAT. - Philips Gyroscan MR S5 ANSI tapes. - Miscellaneous image format utilities ... - Dump. - Patch. - Swap bytes. - Word to byte shift. - Extract 12 bit packed data. - Guess unknown image parameters. - Vax VMS DUMP output to binary. - DICOM data dictionary: - From NIH ftp://zippy.nimh.nih.gov/pub/nih-image - /documents/dicom-dict.txt - In dicom3tools_*.tar.gz - ftp://ftp.rahul.net/pub/dclunie - http://www.rahul.net/dclunie - DICOM Directory of Resources: - http://www.merge.com/subpage/DICOM.html - DICOM draft standards: - ftp://ftp.xray.hmc.psu.edu/dicom_docs - ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_docs - DICOM image samples: - ftp://wuerlim.wustl.edu/pub/dicom/images/version3 - ftp://ftp.med.ge.com/pub/DICOM - http://www.xray.hmc.psu.edu/public/med_img_dbs.html - http://www.zki.uni-frankfurt.de/disc95/ - DICOM Interfile Conversion Software - IDICON: - http://www.inf.u-szeged.hu/~idicon/ - DICOM Public Servers: - UC Davis MC Public PACS: - http://www-radiology.ucdmc.ucdavis.edu/pacs/PPP.html - information about the service - dicom://ppacs@mh_nt1.ucdmc.ucdavis.edu:104 - the server itself - Host is mh_nt1.ucdmc.ucdavis.edu (152.79.46.101) - Port is the standard well-known DICOM TCP port 104 - Application Entity Title is "ppacs" - The server is promiscuous and will respond to any Calling AE Title, but to target a C-Move you need to register your own AE Title and IP address and port number in order to receive images. To do this contact mhoskin@ucdavis.edu. - The UCDMC Public PACS acts as an SCP for the following SOP Classes: - Verification 1.2.840.10008.1.1 - Study Root Retrieve/FIND 1.2.840.10008.5.1.4.1.2.2.1 - Study Root Retrieve/MOVE 1.2.840.10008.5.1.4.1.2.2.2 - Computed Radiography Storage 1.2.840.100008.5.1.4.1.1 - CT Image Storage 1.2.840.10008.5.1.4.1.1.2 - Ultrasound Multi-frame Image Storage 1.2.840.10008.5.1.4.1.1.3 - MR Image Storage 1.2.840.10008.5.1.4.1.1.4 - Nuclear Medicine Image Storage 1.2.840.10008.5.1.4.1.1.5 - Ultrasound Image Storage 1.2.840.10008.5.1.4.1.1.6 - Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7 - DICOM resources at Medx: - http://topaz.sensor.com/work/fmt/dicom - DICOM resources in Chile: - http://www.dicom.cl - DICOM resources at Santel: - http://www.santel.lu/SANTEL/imgrel/imagproc.html - DICOM software - BMP conversion: - ftp://ftp.xray.hmc.psu.edu/dicom_software/dicombmp.zip - DICOM software - Cardiology: Lossless JPEG software for American College of Cardiology Digital Interchange Standards for Cardiology CD-R demo. From Brown University Institute for Medical Computing. - ftp://ftp.xray.hmc.psu.edu/dicom_software/Brown - Jonathan_Elion@brown.edu Jon Elion - DICOM software - Medx: DICOM dump utility. - http://topaz.sensor.com/links/mg/props/dicom - DICOM software - RSNA Central Test Node: Contact Steve Moore smm@wuerl.wustl.edu - ftp://wuerlim.wustl.edu/pub/dicom - ftp://ftp.xray.hmc.psu.edu/dicom_software - /Mallinckrodt Mallinkrodt RSNA - /European European CEN/TC251/WG4 - ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_software - Linux port of Mallinckrodt CTN software - From ftp://ss10.numed.szote.u-szeged.hu/pub/MIR-CTN/ - Modified sources /Linux/CTN.Linux.tar.Z - Compiled binaries /Linux/CTN.Linux.bin.tar.Z - Ported by boti@ss10.numed.szote.u-szeged.hu - DICOM software - UC Davis Medical Center: Binary libraries for Unix(various) and Windows/NT, written in C++, well documented, no royalties, supports Storage,Query/Retrieve for most objects. - ftp://imrad.ucdmc.ucdavis.edu/pub/dicom/UCDMC - http://www-radiology.ucdmc.ucdavis.edu/intro/radhome.html - http://www-radiology.ucdmc.ucdavis.edu/pacs/MCONF.html COnformance Statement - mhoskin@ucdavis.edu Mark Oskin - rlkennedy@ucdavis.edu R.L. Kennedy - DICOM Ultrasound/Echocardiography - ICMIT: - International Consortium for Medical Imaging Technology - http://dominica.ee.ic.ac.uk/ICMIT/ICMIT.html - s.claesen@ic.ac.uk Stefan Claesen - DICOM WWW gateway: - http://foyt.indyrad.iupui.edu/medres/iurad2.htmlSample gateway - ftp://foyt.indyrad.iupui.edu/pubImplementation - gcbrowni@foyt.indyrad.iupui.edu Grover Browning - Dr Razz - image viewer for MAC: - ftp://ftp.u.washington.edu/pub/user-supported/razz - ftp://ftp.u.washington.edu/public/razz - http://www.rad.washington.edu/ The author (Thurman Gillespy tg3@u.washington.edu) writes: Dr Razz is a 16 bit medical image display and analysis program for Macintosh computers. Dr Razz can window and level on full 16 bit image data in near real time on any Macintosh color computer. Images can be viewed individually, or an image series can be viewed in an image stack. The program attempts to automatically open CT and MRI images, and can usually handle different header sizes and byte order. The program can directly read the headers of images created with the GE Image Extract Tool, and can automatically handle compressed images created with this utility. Dr Razz is not a DICOM viewer, although it can probably automatically open many CT/MRI DICOM images if they are not compressed. An option for manually entering image parameters for problem files is available. Images can be saved as PICT files, and TIFF support will be added. - FITS - Flexible Image Transport System - for astronomical data: - ftp://fits.cv.nrao.edu/fits - ftp://nssdca.gsfc.nasa.gov/FITS - http://hdf.ncsa.uiuc.edu:4321/fits/ FITS Browser - Graphics file formats (gif,tiff,etc.) - ftp://zamenhof.cs.rice.edu/pub/graphics.formats - http://sunsite.unc.edu/boutell/png.html Portable Network Graphics format (PNG) - Hierarchical Database Management System (astronomy images): - ftp://starlink-ftp.rl.ac.uk/pub/doc/star-docs/sun92.tex - http://star-www.rl.ac.uk/ - Hospital News: - http://www.gate.net/hospital-news/ - Image guided surgery: - http://igs.slu.edu/ - http://www.cc.gatech.edu/gvu/medical_informatics/research/surg_sim.html - http://www.mni.mcgill.ca/demos/neurosurgery - http://cranium.unibe.ch/cas/ - Image utilities - miscellaneous: - ftp://oak.oakland.edu/pub3/simtel/win3/graphics/IMA20A.ZIP - Images - digitized mammograms - sites: - miasdb@icr.ac.uk (J.Suckling) (Normal and abnormal) - ftp://ftp.xray.hmc.psu.edu/mammo (10 Normal) - http://www.xray.hmc.psu.edu/ - http://cancer.med.upenn.edu/ - Images - medical - sites (may be out of date): - ftp://fokus.uke.uni-hamburg.de/.voxelman.images - ftp://rwja.umdnj.edu/pub - gopher://gopher.austin.unimelb.edu.au/11/images/petimages/ - ftp.nihon-u.ac.jp/pub/data/MRIMonkeyHead - http://ftp.nc.nihon-u.ac.jp/pub/data/MRIMonkeyHead - ftp://decaf.stanford.edu/pub/images/medical/mri - ftp://eedsp.gatech.edu/database/images/wchung/medical - ftp://omicron.cs.unc.edu/pub/softlab/CHVRTD - http://foyt.indyrad.iupui.edu/medres/iurad2.html - ftp://ccsun.unicamp.br - ftp://boris.umds.ac.uk/pub/images - http://www-ipg.umds.ac.uk/ - http://www.stjosephs.london.on.ca/~jd - http://www.santel.lu/SANTEL/imgrel/imagproc.html - http://chaos.uh.cwru.edu/uhweb1.html - http://pss023.psi.ch/ - http://visual-ra.swmed.edu - http://www.rad.upenn.edu/rundle/InteractiveKnee.html - http://www.ge.com/crd/ivl/three_dim_medical.html - ftp://ftp.med.ge.com/pub/DICOM/IMAGES - ftp://wuerlim.wustl.edu/pub/dicom/images/ - gopher://mirage.umdnj.edu:70/1/Radiology_Images - Interfile sources - see Nucmed ftp site at UWO. - JPEG Sources - PVRG-JPEG CODEC: ftp://havefun.stanford.edu/pub/jpeg Supports - sequential DCT baseline, - lossless modes. - IJG: ftp.uu.net/graphics/jpeg Supports - sequential DCT baseline, - 12 bit DCT modes. - progressive modes. - Kermit distribution: - ftp://ftp.cc.columbia.edu/kermit - LUNIS - Loyola University Nuclear Medicine Information System - http://147.126.104.3/ contact jhalama@lunis.nucmed.luc.edu (Jim Halama) for access, which is restricted ((708) 216-3777) - Magnetic Resonance Spectroscopy Resources: - http://members.aol.com/albrightmj - http://www.nmr.utmb.edu/#mrass - Medical Clip Art sites: - http://www.mindspring.com/~mperloe/gallery.html - ftp://goofy.cs.umd.edu/f/clipart/medical - Medical imaging research - University of Leeds: - http://agora.leeds.ac.uk/comir/comir.html - Medical imaging resources - Japanese site: - Images and tools, including DICOM, Osiris, NIH Image. - ftp://ftp.kurume-it.ac.jp/.kenchan/ftp/pub/ - Medical Informatics standards, including HL7 standards: - ftp://dumccss.mc.duke.edu/standards - read-me.txt - HL7/pubs/version2.2/ballot1.zip - Medical Resources - Miscellaneous: - http://kuhttp.cc.ukans.edu/cwis/units/medcntr/Lee/HOMEPAGE.HTML Medical Matrix - http://golgi.harvard.edu/biopages/medicine.html Virtual Library of Medicine - http://critcare.vichosp.london.on.ca Critical Care - http://world-health.net/ World Health Net - http://www.li.net/~edhayes/ed.html - http://enuxsa.eas.asu.edu/~wilkins Radiology links - http://www.netins.net/showcase/eri/ Electronic Resources - Multimedia Medical Reference Library: - http://www.tiac.net/users/jtward/index.html - Neuroscience Resources List: - http://golgi.harvard.edu/biopages/neuro.html - NIH Image - Macintosh image processing software: - ftp://zippy.nimh.nih.gov/pub/nih-image - Nucmed ftp site at UWO (run by Trevor Cradduck (cradduck@uwo.ca)): - ftp://uwovax.uwo.ca/PUB:[000000.NUCMED] - Orthopaedic Biomechanics - http://cranium.unibe.ch/ Maurice E. Muller Institute - PACS - EurIPACS: - http://www.rad.unipi.it:7080/ - /works/imphone/presentation-imphone.html - Papyrus and Osiris ftp site: - ftp://expasy.hcuge.ch/pub/Osiris - Papyrus specifications for versions 2.1 and 3. - Osiris for Mac, PC and Unix (SunOS, Solaris, Dec). - Sample images for Dicom, Papyrus 2 and Papyrus 2. - http://expasy.hcuge.ch/www/UIN/UIN.html - Pathology sites: - http://www.uniud.it/drmm/drmmeng.html - http://www.uniud.it/drmm/anpat/gallery/pathpuzzle.html - http://www.osaka-med.ac.jp/omc-lib/path.html - http://www.med.uiuc.edu/titlePage.html - http://www.flightpath.com/Clients/Pisces/pdchome.htm - http://www.med.nagoya-u.ac.jp/pathy/pathy.html - http://www.bocklabs.wisc.edu/ - http://www.derby.ac.uk - http://www.ets.bris.ac.uk/mru.htm - http://www.bgsm.wfu.edu/ - http://www-medlib.med.utah.edu/sol.htm - http://www-medlib.med.utah.edu/WebPath/webpath.html - http://pandoras-box.bgsm.edu/ - http://rmc-www.lbl.gov/ - http://bsd.meddean.luc.edu/lumen/ - gopher://caldmed.med.miami.edu:70/11/.gopher/discipline/Discipline-Specific Sources/Pathology - gopher://gopher.med.cornell.edu:70/1/Medical College/Images - gopher://gopher.rz.uni-karlsruhe.de:70/7waissrc:/zent/rz/netz/spez/WAIS/r/RPMS-pathology.src - gopher://mirage.umdnj.edu:70/1/Pathology_Images - http://128.196.106.42/ahsc-res.html - http://192.93.247.18/ - http://count51.med.harvard.edu/AANLIB/home.html - http://count51.med.harvard.edu/BWH/BRADHome.html - http://indy.radiology.uiowa.edu/VirtualHospital.html - http://info.med.yale.edu/caim/C_HOME.HTML - Penn State Radiology Web Server: - http://www.xray.hmc.psu.edu/ - PET Sites: - http://www-ipg.umds.ac.uk/pet/petcen.html - http://members.aol.com/albrightmj - http://www.nuc.ucla.edu/html_docs/crump/lpp.html - http://www.nucmed.buffalo.edu/cpethm.htm - Physics Sites: - http://www.physics.mcgill.ca/physics-services/ - http://tph.tuwien.ac.at/physics-services/ - Qsh ftp site: - ftp://nucmed.med.nyu.edu/pub - /dist compressed tar - /qsh source - Radiological Society of North America - On-Line Sources: This site is strongly recommended and has more points to jump to than you could possibly imagine !!! - http://www.rsna.org - http://www.rsna.org/edu/internet.html - Radiology History: - http://www.fh-wuerzburg.de/roentgen/ - Teaching File - Index: - http://www.xray.hmc.psu.edu/public/tf.html - Teaching File - University of Washington: Run by mrich@u.washington.edu - http://www.rad.washington.edu/ 1. Radiology Teaching File (CME credit) 2. Anatomy Teaching Modules 3. Radiology Exhibits from UW 4. Information on UW radiology residency/fellowship programs 5. Image processing software written by UW faculty - Teaching File - University of Western Ontario: - http://johns.largnet.uwo.ca - Telemedicine - DOD server - http://ftdetrck-matmoweb.army.mil/ - TIFF Specification Source- Tagged Image File Format: - gopher://palimpsest.stanford.edu:70/00/ByTopic/standards/tiff.5.0.txt TIFF 5.0 - ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.Z TIFF 6.0 - http://www.adobe.com/PDFs/TN/TIFF6.pdf - http://www-mipl.jpl.nasa.gov/~ndr/tiff/index.html Unofficial TIFF Home Page - University of North Carolina SoftLab /usr/image package: - ftp://ftp.cs.unc.edu/pub/projects/softlab/image/product/ - Vax help - "The Vax Book" by Joseph E St Sauver, U of Oregon: - ftp://decoy.uoregon.edu/pub/vaxbook/ - Virtual Hospital - University Of Iowa: - http://indy.radiology.uiowa.edu/Providers/ProviderDept/InfoByDept.Rad.html radiology - http://everest.radiology.uiowa.edu/image.html imaging resource links - Visible Human Project - http://www.nlm.nih.gov/ - /factsheets.dir/visible_human.html - /extramural_research.dir/visible_gallery.html Dr. Michael J. Ackerman Project Officer, Visible Human Project National Library of Medicine 8600 Rockville Pike Bethesda, MD 20894 Need to sign an agreement with the NLM before one can transfer the 15 GB of data or buy tapes. Tape can be purchased from NTIS (301) 402-4100 in Unix tar format for $1000. See also Visible Human CDROM - Visible Human Project - Experiments - http://www.ge.com/crd/ivl/vm/vm.html CT 3D Visible Man - http://aperture.stanford.edu/~lorensen/vw/vw.html CT 3D Visible Woman - Wavelet compression software: - ftp://pascal.math.yale.edu/pub/wavelets - Web Delivered Telemedicine and PACS: - http://www.mco.edu/iarc/telemed.html - Window level software (12/16 bits ->8): - ftp://alvin.ach.uams.edu/pub/winlev.tar.Z (Includes images) - ftp://alvin.ach.uams.edu/pub/winlev-noimages.tar.gz - Wxwin software: - ftp://skye.aiai.ed.ac.uk/pub/wxwin - Xsee - X-windows based display program for raw images: - available from Stefan Thurnhofer thurn@amadeus.ece.ucsb.edu The next part is part8 - information sources (continued). Archive-name: medical-image-faq/part8 Posting-Frequency: monthly Last-modified: Tue Jan 30 15:51:53 1996 Version: 2.11 7.6 Mailservers - FAQ about email access to internet services: To find out more, fetch the relevant FAQ from the mailserver at "mail-server@rtfm.mit.edu" with a message body: send usenet/news.answers/internet-services/access-via-email Or ftp it from "ftp://rtfm.mit.edu/pub/news.answers/internet-services/access-via-email" - Ftpmail: Ftpmail is a service provided by some extremely generous sites that allow you to send ftp commands to them by email and the server executes the commands and sends the results back. Very few sites offer this because of the huge load and potential for abuse. I only mention it here because a lot of medical imaging people don't seem to have anonymous ftp access. To find out more, fetch the relevant FAQ from the mailserver at "mail-server@rtfm.mit.edu" with a message body: send usenet/news.answers/ftp-list/faq The most commonly used site is "ftpmail@decwrl.dec.com" (send "help" (no quotes) in the message body). - HSPNET-L Hospital Computer Network Discussion Group and Data Base: Run by Don Parsons dfp10%albnydh2.bitnet@uacsc2.albany.edu. - To subscribe: To: listserv%albnydh2.bitnet@uacsc2.albany.edu Subject: SUBSCRIBE HSPNET-L your_full_name - For the monthly digest: To: listserv%albnydh2.bitnet@uacsc2.albany.edu Subject: AFD ADD HSP* DIGEST HSPNET-L - To contribute (if subscribed): To: hspnet-l%albnydh2.bitnet@uacsc2.albany.edu - To download from the LISTSERV Database: To: listserv%albnydh2.bitnet@uacsc2.albany.edu Subject: INDEX HSPNET-L GET HSPNET-L is mirrored by "sci.med.telemedicine" Usenet newsgroup. - Interfile mailing list: Don't know much about this list, but I am sure that atoddpok@medphys.ucl.ac.uk (Andrew Todd-Pokropek) would be able to fill you in on this. - ldicom mailing list for dicom3tools users: - to subscribe: ldicom-subscribe@flash.us.com - to unsubscribe, etc.: ldicom-unsubscribe@flash.us.com - to send to list: ldicom@flash.us.com - the relevant human: ldicom-admin@flash.us.com - Nucmed mailing list for medical physicists: - to subscribe: nucmed-request@irus.rri.uwo.ca - to unsubscribe, etc.: nucmed-owner@irus.rri.uwo.ca - to send to list: nucmed@uwo.ca - the relevant human: cradduck@uwo.ca (Trevor Cradduck) This list is not actually gated to "sci.med.physics", though Trevor often reposts significant items. See also Nucmed ftp site at UWO. - Radiation Safety Distribution list - RADSAFE: For Health Physicists, Medical Physicists, Radiological Engineers and others who have a professional interest in matters related to Radiation Protection. pet_mail-REQUEST@ncbapsun2.pet.wfu.edu Put request key word (help, subscribe, unsubscribe) in the body of the message, not the subject line. - PET Mail mailing list - Positron Emission Tomography: For Health Physicists, Medical Physicists, Radiological Engineers and others who have a professional interest in matters related to Radiation Protection. RADSAFE@romulus.ehs.uiuc.edu - Radiologic Science Discussion Group - Radsci-L: Discussion may choose to center around radiologic science education, medical radiography, CT (computerized scanning), MRI (magnetic resonance scanning), sonography, nuclear medicine, radiation oncology, veterinary medicine, industrial applications, radiologic patient care, etc. - command address: mailserv@western.tec.wi.us - commands: in message body not subject - list name: Radsci-L - to subscribe: subscribe Radsci-L firstname lastname (NB. not your email address, that is derived from the 'From ' header line) - sci.med.radiology gateway: sci.med.radiology@news.cs.indiana.edu 7.7 References - DICOM Publications - General: Kodak "Understanding DICOM 3.0" catalog # 1787928, $US 15.00 Ed Weaver Kodak Health Imaging Systems 18325 Waterview Parkway Dallas TX 75252 phone 1-800-767-3448 phone 1-214-454-1506 email eweaver@khis.kodak.com Kodak Distribution Center (credit cards) phone 1-800-233-1650 - DICOM Publications - Implementation: "Implementation of the DICOM 3.0 Standard - A Pragmatic Handbook" Robert Hindel, Editor RH Consulting 483 Ridge Road Orange CT 06477-2830 phone 203-799-2258 fax 203-795-8640 email 73030.1366@compuserve.com (Robert Hindel) Radiological Society of North America 2021 Spring Road Suite 600 Oak Brook IL 60521 - DICOM Publications - Resource Directories: "DICOM Tools for End User Applications and System Integration" Presented at EuroPACS'94 Geneva Switzerland Dwight Simon Merge Technologies Inc. 1126 S. 70th St. Suite N508B Milwaukee, Wisconsin 53214-3151 phone 414-475-4300 fax 414-475-3940 email dwight@merge.com (Dwight Simon) - PACS Publications: Understanding PACS:Picture Archiving & Communications Systems available for $5 from SCAR - Society for Computer Applications in Radiology: - Telemedicine Publications: Rural TeleHealth:Telemedicine,Distance Education & Informatics for Rural Health Care, A Report of the Office of Rural Health Policy Health Resources and Services Administration, DHSS (Nov,1993) available for $8 from: WICHE Publications Western Interstate Commission for Higher Education P.O. Drawer P Boulder, CO 80301-9752 phone (303) 541-0290 fax (303) 541-0291 - Wavelet compression publications: Press, et al. Numerical Recipes in C. Chapter 13.10. Wavelet Transforms. Cody,MA. The Wavelet Packet Transform. Dr. Dobb's Journal, April '94 7.8 Organizations, Societies and Journals - Association of Students of the Radiologic Sciences http://enuxsa.eas.asu.edu/~wilkins/asrs.html - IEEE Transactions on Medical Imaging Mike Vannier Mallinckrodt Institute of Radiology Washington University Medical Center 510 South Kingshighway Blvd. St. Louis, MO 63110 - SCAR - Society for Computer Applications in Radiology 4750 Lindle Road, P.O. Box 8800 Harrisburg, PA 17105-8800 phone 717-561-5266 fax 717-561-5360 email 73531.1173@compuserve.com email tg3@u.washington.edu (Thurman Gillespy). - Web server is at http://www.scar.rad.washington.edu/ - Official journal is the "Journal of Digital Imaging". - Last meeting was S/CAR'94 held in Winston-Salem, North Carolina during June 1994. - (membership is considered mandatory for FAQ readers :) ) 7.9 Usenet Newsgroups - alt.graphics.pixutils - alt.image.medical - alt.med.equipment - comp.graphics - comp.graphics.algorithms - comp.graphics.pixutils - comp.graphics.research - comp.protocols.dicom - sci.data.formats - sci.med.emergency - sci.med.informatics - sci.med.physics - sci.med.radiology - sci.med.telemedicine - sci.med.vision 8. Acknowledgements Thanks to the many people for contributions, general help, interesting postings or mail whose contents have found there way in here, or just plain old moral support. They used to be listed by name and email address here, but the list was getting so long and difficult to update that it got out of hand and has been retired ! The next part is index by keyword.