home *** CD-ROM | disk | FTP | other *** search
/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / FAQSYS18.ZIP / FAQS.DAT / MEDIMAGE.202 < prev    next >
Internet Message Format  |  1995-12-12  |  223KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  2. From: dclunie@flash.us.com (David A. Clunie)
  3. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  4. Subject: Medical Image Format FAQ, Part 1/8
  5. Followup-To: alt.image.medical
  6. Date: 28 Mar 1995 23:03:04 +0300
  7. Organization: Her Master's Voice
  8. Lines: 661
  9. Approved: news-answers-request@MIT.EDU
  10. Distribution: world
  11. Expires: 28 Apr 1995 00:00:00 GMT
  12. Message-ID: <3l9q1o$djo@flash.ksapax>
  13. Reply-To: dclunie@flash.us.com (David A. Clunie)
  14. NNTP-Posting-Host: flash.ksapax
  15. Summary: This posting contains answers to the most Frequently Asked
  16.          Question on alt.image.medical - how do I convert from image
  17.          format X from vendor Y to something I can use ? In addition
  18.          it contains information about various standard formats.
  19. Xref: senator-bedfellow.mit.edu alt.image.medical:2433 comp.protocols.dicom:634 sci.data.formats:884 sci.med.informatics:1727 sci.med.radiology:1805 alt.answers:8364 comp.answers:10921 sci.answers:2329 news.answers:40884
  20.  
  21. Archive-name: medical-image-faq/part1
  22. Posting-Frequency: monthly
  23. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  24. Version: 2.02
  25.  
  26. This message is automatically posted once a month to help readers looking
  27. for information about medical image formats. If you don't want to see this
  28. posting every month, please add the subject line to your kill file.
  29.  
  30. Contents:
  31.  
  32.     part1    - contains index, general information & standard formats
  33.     part2    - contains standard formats (continued)
  34.     part3    - contains information about proprietary CT formats
  35.     part4    - contains information about proprietary MR formats
  36.     part5    - contains information about proprietary other formats
  37.     part6    - contains information about hosts & compression
  38.     part7    - contains information sources
  39.     part8    - contains information sources (continued)
  40.  
  41. Tools that describe and convert many of the formats described in this document 
  42. are available in the dicom3tools package from
  43.  
  44.     "ftp://ftp.rahul.net/pub/dclunie/".
  45.  
  46. A Mosaic browsable version of this FAQ is available at:
  47.  
  48.     "http://www.rahul.net/dclunie/medical-image-faq/html/".
  49.  
  50. Html, postscript and text forms of the FAQ are available at:
  51.  
  52.     "ftp://ftp.rahul.net/pub/dclunie/medical-image-faq/".
  53.  
  54. Many FAQs, including this Listing, are available on the archive site
  55. rtfm.mit.edu in the directory pub/usenet/news.answers.  The name under
  56. which a FAQ is archived appears in the Archive-name line at the top of
  57. the article.
  58.  
  59. There's a mail server on that machine. You send a e-mail message to
  60. mail-server@rtfm.mit.edu containing the keyword "help" (without quotes!)
  61. in the message body. To fetch this particular FAQ send a message with the 
  62. following body:
  63.  
  64.     send usenet/news.answers/medical-image-faq/part1
  65.     ...
  66.     send usenet/news.answers/medical-image-faq/part8
  67.  
  68. Please direct comments or questions and especially contributions to
  69.  
  70.     "dclunie@flash.us.com"
  71.  
  72. or reply to this article. All unknown formats and test images gratefully
  73. accepted, but please don't email them, rather contact me and we can
  74. arrange to exchange documents or disks or tapes by snail mail.
  75.  
  76.  
  77. Changes this issue
  78.  
  79.     Fixed typos in ACR/NEMA codes.
  80.     Comment on bad big endian byte order in ACR/NEMA files.
  81.     DICOM parts 10,11,12 passed ballot.
  82.     Fixed GE site directory.
  83.     Added more GE ftp and www sites.
  84.     Added GE CT Pace and MR Max formats.
  85.     Added GE image format document list and references.
  86.     Updated GE Genesis optical format saga and added Evergreen Technologies.
  87.     Added 8" floppy vendors.
  88.     Added Medical Imaging Technology Associates.
  89.     Expanded dicom3tools description.
  90.     Update Somatom Plus format.
  91.  
  92. Changes last issue
  93.  
  94.     Split into 8 smaller parts for News software that baulks on big posts.
  95.     Fixed numerous typos and difficulties with converting html to posting.
  96.     Visible Human project information.
  97.     RSNA WWW server.
  98.     New Evergreen Technologies email address.
  99.     More Mac and Windows viewer sources.
  100.     Dermatology server.
  101.     Physics server.
  102.     Fully functional 3DVIEWNIX1.1 now available for ftp.
  103.     Teleradiology vendors.
  104.     An NIH image macro to import ACR/NEMA files.
  105.     A few more Genesis hints/updates.
  106.     Update SCAR email address.
  107.     Ftp site for Linux DICOM CTN software.
  108.     Updated HSPNET-L entry.
  109.     Updated ADAM entry.
  110.     Angiography simulation site.
  111.     GE Ultrasound contact.
  112.     sci.med.radiology gateway.
  113.     Neuroscience Resources List www site.
  114.     Radiology history www site.
  115.     Updated DeJarnette details.
  116.     Updated Papyrus entry.
  117.     PET www site.
  118.     EurIPACS www site.
  119.     ImportAccess Photoshop plugin.
  120.     Described SPI in much more detail.
  121.     Siemens SPI devices including Somatom Plus, Impact, SP.
  122.     Sytec format added.
  123.     Siemens DR CT format updated.
  124.     ISG/Philips Gyroview comments added.
  125.  
  126. The next part is table of contents.
  127.  
  128.  
  129. Subject: Contents
  130.  
  131. 1.  Introduction
  132.  
  133.     1.1 Objective
  134.     1.2 Types of Formats
  135.     1.3 In Desperation - Quick & Dirty Tricks
  136.  
  137. 2.  Standard Formats
  138.  
  139.     2.1 ACR/NEMA 1.0 and 2.0
  140.     2.2 ACR/NEMA DICOM 3.0
  141.     2.3 Papyrus
  142.     2.4 Interfile V3.3
  143.     2.5 Qsh
  144.  
  145. 3.  Proprietary Formats
  146.  
  147.     3.1 Proprietary Formats - General Information
  148.  
  149.         3.1.1 SPI (Standard Product Interconnect)
  150.  
  151.     3.2 CT - Proprietary Formats
  152.  
  153.         3.2.1 General Electric CT
  154.  
  155.               3.2.1.1 GE CT 9800
  156.  
  157.                       3.2.1.1.1 GE CT 9800 Image data
  158.                       3.2.1.1.2 GE CT 9800 Tape format
  159.                       3.2.1.1.3 GE CT 9800 Raw data MR
  160.  
  161.               3.2.1.2 GE CT Advantage - Genesis
  162.  
  163.                       3.2.1.2.1 GE CT Advantage Image data
  164.                       3.2.1.2.2 GE CT Advantage Archive format
  165.                       3.2.1.2.3 GE CT Advantage Raw data
  166.  
  167.               3.2.1.3 GE CT Pace
  168.               3.2.1.4 GE CT Sytec
  169.  
  170.         3.2.2 Siemens CT
  171.  
  172.               3.2.2.1 Siemens Somatom DR
  173.               3.2.2.2 Siemens Somatom Plus
  174.               3.2.2.3 Siemens Somatom AR
  175.  
  176.         3.2.3 Philips CT
  177.         3.2.4 Picker CT
  178.         3.2.5 Toshiba CT
  179.         3.2.6 Hitachi CT
  180.         3.2.7 Shimadzu CT
  181.         3.2.8 Elscint CT
  182.  
  183.     3.3 MR - Proprietary Formats
  184.  
  185.         3.3.1 General Electric MR
  186.  
  187.               3.3.1.1 GE MR Signa 3.x,4.x
  188.  
  189.                       3.3.1.1.1 GE MR Signa 3.x,4.x Image data
  190.                       3.3.1.1.2 GE MR Signa 3.x,4.x Tape format
  191.                       3.3.1.1.3 GE MR Signa 3.x,4.x Raw data
  192.  
  193.               3.3.1.2 GE MR Signa 5.x - Genesis
  194.  
  195.                       3.3.1.2.1 GE MR Signa 5.x Image data
  196.                       3.3.1.2.2 GE MR Signa 5.x Archive format
  197.                       3.3.1.2.3 GE MR Signa 5.x Raw data
  198.  
  199.               3.3.1.3 GE MR Max
  200.               3.3.1.4 GE MR Vectra
  201.  
  202.         3.3.2 Siemens MR
  203.  
  204.               3.3.2.1 Siemens Magnetom GBS II
  205.               3.3.2.2 Siemens Magnetom SP
  206.               3.3.2.3 Siemens Magnetom Impact
  207.               3.3.2.4 Siemens Magnetom Vision
  208.  
  209.         3.3.3 Philips MR
  210.  
  211.               3.3.3.1 Philips Gyroscan S5
  212.               3.3.3.2 Philips Gyroscan ACS
  213.               3.3.3.3 Philips Gyroscan T5
  214.               3.3.3.4 Philips Gyroscan NT5 & NT15
  215.  
  216.         3.3.4 Picker MR
  217.         3.3.5 Toshiba MR
  218.         3.3.6 Hitachi MR
  219.         3.3.7 Shimadzu MR
  220.         3.3.8 Elscint MR
  221.  
  222.     3.4 Proprietary Workstations
  223.  
  224.         3.4.1 ISG Workstations
  225.  
  226.               3.3.3.1 Gyroview
  227.  
  228.     3.5 Other Proprietary Formats
  229.  
  230. 4.  Host Machines
  231.  
  232.     4.1 Data General
  233.  
  234.         4.1.1 Data General Data
  235.  
  236.               4.1.1.1 Data General Integers
  237.               4.1.1.2 Data General Floating Point
  238.  
  239.         4.1.2 Data General Operating System
  240.  
  241.               4.1.2.1 Data General RDOS
  242.               4.1.2.2 Data General AOS/VS
  243.  
  244.         4.1.3 Data General Network
  245.  
  246.     4.2 Vax
  247.  
  248.         4.2.1 Vax Data
  249.  
  250.               4.2.1.1 Vax Integers
  251.               4.2.1.2 Vax Floating Point
  252.               4.2.1.3 Vax Strings
  253.  
  254.         4.2.2 Vax Operating System
  255.  
  256.               4.2.2.1 Vax VMS
  257.               4.2.2.2 ULTRIX
  258.               4.2.2.3 OSF
  259.  
  260.     4.3 Sun - Sun3 68000 and Sun4 Sparc
  261.  
  262.         4.3.1 Sun Data
  263.  
  264.               4.3.1.1 Sun Integers
  265.               4.3.1.2 Sun Floating Point
  266.               4.3.1.3 Sun Strings
  267.  
  268.         4.3.2 Sun Operating System
  269.  
  270. 5.  Compression Schemes
  271.  
  272.     5.1 Reversible Compression
  273.     5.2 Irreversible Compression
  274.  
  275.         5.2.1 Perimeter Encoding
  276.  
  277. 6.  Getting Connected
  278.  
  279.     6.1 Tapes
  280.     6.2 Ethernet
  281.     6.3 Serial Ports
  282.  
  283. 7.  Sources of Information
  284.  
  285.     7.1 Vendor Contacts
  286.     7.2 Relevant FAQ's
  287.     7.3 Source Code
  288.     7.4 Commercial Offerings
  289.     7.5 FTP/WWW sites
  290.     7.6 Mailservers
  291.     7.7 References
  292.     7.8 Organizations and Societies
  293.     7.9 Usenet Newsgroups
  294.  
  295. 8.  Acknowledgements
  296.  
  297. The next part is part1 - general information & standard formats.
  298.  
  299.  
  300. 1.  Introduction
  301.  
  302.     1.1 Objective
  303.  
  304.         The goal of this FAQ is to facilitate access to medical images stored
  305. on digital imaging modalities such as CT and MR scanners, and their
  306. accompanying descriptive information. The document is designed particularly for
  307. those who do not have access to the necessary proprietary tools or
  308. descriptions, particularly in those moments when inspiration strikes and one
  309. just can't wait for the local sales person to track down the necessary
  310. authority and go through the cycle of correspondence necessary to get a
  311. non-disclosure agreement in place, by which time interest in the project has
  312. usually faded, and another great research opportunity has passed! It may also
  313. be helpful for those keen to experiment with home-grown PACS-like systems using
  314. their existing equipment, and also for those who still have equipment that is
  315. still useful but so old even the host computer vendor doesn't support it any
  316. more!
  317.  
  318.         There is of course no substitute for the genuine tools or descriptions
  319. from the equipment vendors themselves, and pointers to helpful individuals in
  320. various organizations, as well as names and catalog numbers of various useful
  321. documents, are included here where known.
  322.  
  323.         In addition there are several small companies that specialize in such
  324. connectivity problems that have a good reputation and are well known. Contact
  325. information is provided for them, though I personally have no experience with
  326. their products and am not endorsing them.
  327.  
  328.         Finally, great care has been taken not to include any information that
  329. has been released under non-disclosure agreements. What is included here is the
  330. result of either information freely released by vendors, handy hints from
  331. others working in the field, or in many cases close scrutiny of hex dumps and
  332. experimentation with scanner parameters and study of the effects on the image
  333. files. The intent is to spread hard-earned knowledge gained over many years
  334. amongst those new to the field or a particular piece of equipment, not to
  335. threaten anyone's proprietary interests, or to substitute for the technical
  336. support available from vendors that ranges from free to extortionate, and
  337. excellent to abysmal, depending on who your are dealing with and where in the
  338. world you are located!
  339.  
  340.          Please use this information in the spirit in which is intended, and
  341. where possible contribute whatever you know in order to expand the information
  342. to cover more vendors and equipment.
  343.  
  344.     1.2 Types of Formats
  345.  
  346.         Later sections will deal with the problems of getting the image files
  347. from the modality to the workstation, but for the moment assume the files are
  348. there and need to be deciphered.
  349.  
  350.         Four types of information are generally present in these files:
  351.  
  352.            - image data, which may be unmodified or compressed,
  353.            - patient identification and demographics,
  354.            - technique information about the exam, series, and slice/image.
  355.  
  356.         Extracting the image information alone is usually straightforward and
  357. is described in 1.3. Dealing with the descriptive information, for example to
  358. make use of the data for dissemination in a PACS environment, or to extract
  359. geometry details in order to combine images into 3D datasets, is more difficult
  360. and requires deeper understanding of how the files are constructed.
  361.  
  362.         There are three basis families of formats that are in popular use:
  363.  
  364.            - fixed format, where layout is identical in each file,
  365.            - block format, where the header contains pointers to information,
  366.            - tag based format, where each item contains its own length.
  367.  
  368.         The block format is one of the most popular, though in most cases, the
  369. early part of the header contains only a limited number of pointers to large
  370. blocks, the blocks are almost always in the same place and a constant length,
  371. for standard rather than reformatted images at least, and if one doesn't know
  372. the specifics of the layout one can get by assumming a fixed format. I presume
  373. this reflects the intent of the designers to handle future expansion and
  374. revision of the format.
  375.  
  376.          The example par excellence of the tag based format is the ACR/NEMA
  377. style of data stream, which, though never intended as a file format per se has
  378. proven useful as model. See for example the sections dealing with the ACR/NEMA
  379. standards as well as DICOM (whose creators are about to vote on a media
  380. interchange format after all this time) and Papyrus. ACR/NEMA style tags are
  381. described in more detail elsewhere, but each is self-contained and
  382. self-describing (at least if you have the appropriate data dictionary) and
  383. contains its own length, so if you can't interpret it you can skip it! Very
  384. convenient. Most file formats based on this scheme are just concatenated series
  385. of tags, and apart from having to guess the byte order, which is not specified
  386. (unlike TIFF which is a similar deal for those in the "real" imaging world),
  387. and sometimes skip a fixed length but short header, are dead easy to handle.
  388.  
  389.          To identify such a file just do a "strings <file | grep 'ACR-NEMA'" -
  390. if it is such a file, just look through the start of the hex dump until you
  391. start to see the characteristic sequentially ordered pairs of 16 bit words that
  392. identify ACR/NEMA attributes, decide the byte order, et voila, you can pipe it
  393. into any general ACR/NEMA dumping program to see what it contains. If you see
  394. even group tags, they will be described in the standard. If you see odd group
  395. tags then they are vendor specific and you will have to ask the vendor or
  396. correlate them with identification information printed on the film until you
  397. figure out the ones that are important to you.
  398.  
  399.     1.3 In Desperation - Quick & Dirty Tricks
  400.  
  401.         Because radiologists, radiographers, technologists, physicists and
  402. imaging programmers are dedicated long suffering creatures who work long hours
  403. under adverse conditions for little reward, the vendors in their generosity
  404. have seen fit to make life a little easier, by almost universally putting the
  405. image data at the end of the file. Rarely you will see files that are padded
  406. out to fixed record size boundaries (eg. Vax VMS 512 byte records), and
  407. sometimes overlay plane data may be stored after the image data. Furthermore
  408. there is almost always an option at archive time to allow for storage in an
  409. uncompressed and totally unadulterated form. Even in ACR/NEMA the tag for image
  410. pixel data is numerically the highest and hence the last to appear in the
  411. sequence which is guaranteed to be sorted. They could have screwed us up
  412. totally by gratuitously adding variable length blocks of other stuff at the
  413. end, but the only time I have encountered this was on a Siemens Impact with the
  414. ACR/NEMA based SPI format padded out to 512 bytes.
  415.  
  416.         In other words, if an image is 256 by 256, uncompressed, and 12-16 bits
  417. deep (and hence usually, though not always, stored as two bytes per pixel),
  418. then we all know that the file is going to contain 256*256*2=131072 bytes of
  419. pixel data at the end of the file. If the file is say 145408 bytes long, as all
  420. GE Signa 3X/4X files are for example, then you need to skip 14336 bytes of
  421. header before you get to the data. Presume row by row starting with top left
  422. hand corner raster order, try both alternatives for byte order, deal with the
  423. 16 to 8 bit windowing problem, and very soon you have your image on the screen
  424. of your workstation.
  425.  
  426.          This technique is so useful, even NIH Image for the Macintosh (an
  427. excellent must-have free program BTW.) provides a raw import tool to do this,
  428. and describes it in the manual using the 14336 byte offset! This tool is
  429. something that is sadly lacking in most commercial image handling programs for
  430. non-medical applications, which can't import images with more than 8 bits per
  431. channel.
  432.  
  433.          Of course you have to live without the identification, demographic and
  434. technique information (other than what can be derived from the file name in
  435. some cases), but for many research and presentation purposes this is quite
  436. adequate.
  437.  
  438.          Occasionally one runs into clever files where four 12 bit words are
  439. packed into three 16 bit words and one goes crazy trying to figure out the
  440. logic of how they are packed. The back of the old ACR/NEMA standard describes
  441. somewhere one way in which this is done. One should still be able to calculate
  442. the length easily enough.
  443.  
  444.          I haven't yet encountered a format that did nasty things like have
  445. strips of rows seperated by padding ... I guess we are lucky that most images
  446. are nice powers of two or even multiples thereof (256,320,512).
  447.  
  448.          Of course the GE CT 9800 uses perimeter encoding even when DPCM
  449. compression is not selected, so this technique won't work.
  450.  
  451. 2.  Standard Formats
  452.  
  453.     2.1 ACR/NEMA 1.0 and 2.0
  454.  
  455.         ACR/NEMA Standards Publication No. 300-1985      <- ACR/NEMA 1.0
  456.         ACR/NEMA Standards Publication No. 300-1988      <- ACR/NEMA 2.0
  457.         ACR/NEMA Standards Publication PS2-1989          <- data compression
  458.  
  459.         The American College of Radiologists (ACR) and the National Electrical
  460. Manufacturers Association (NEMA) recognized some time ago the need for
  461. standards to facilitate multi-vendor connectivity to promote the development of
  462. PACS and what is now referred to as Wide Area Networking. The first such
  463. standard was version 1.0 which was released in 1985 as ACR/NEMA Standards
  464. Publication No. 300-1985, subsequently revised several times, then revised
  465. again and released as version 2.0 in 1988, described in ACR/NEMA Standards
  466. Publication No. 300-1988. There it remained until a radically revised and
  467. reorganized approach, preserving backward compatibility, was released during
  468. 1992-1993 as ACR/NEMA Standards Publication PS3, also referred to as DICOM 3.
  469.  
  470.         In the interim, to facilitate the transfer of compressed images,
  471. another standard described in ACR/NEMA Standards Publication PS2-1989, was
  472. released which described various means fo extending standard 300-1985 to handle
  473. compression utilizing a broad range of reversible and irreversible schemes.
  474. Though this part of the standard was never apparently implemented by anyone,
  475. and has been quietly bypassed by those working on DICOM 3 compression, it makes
  476. very interesting reading and is a nice summary of applicable techniques.
  477.  
  478.         What does one need to know about ACR/NEMA 1.0 and 2.0 ? The standards
  479. define a mechanism along the lines of the layered ISO-OSI (Open Systems
  480. Interconnect) model, with physical, transport/network, session, and
  481. presentation and application layers. Unless one actually wants to physically
  482. connect to a device that supports the unique 50 pin point-to-point electrical
  483. interface, then one really only needs to be aware of how ACR/NEMA implements
  484. the presentation and application layers, which are described in terms of a
  485. "message format". This message format is important to many people, not because
  486. anyone seriously wants to connect devices in the limited fashion envisaged by
  487. these early standards, but because many proprietary formats and other de facto
  488. standards have adopted the ACR/NEMA message format and its corresponding data
  489. dictionary and extension mechanisms.
  490.  
  491.          The message format is described in sections 4, 5 and 10 of ACR/NEMA SP
  492. 300-1988 which are summarized briefly here. Section 6 describes command
  493. structure which is not really relevant other than that commands are also
  494. structured in the same way as data and consume part of the data dictionary. You
  495. will not encounter command tags in data streams ("messages") encapsulated in
  496. file formats though.
  497.  
  498.          A message consists of a series of "data elements" each of which
  499. contains a piece of information. Each element is described by an "element name"
  500. consisting of a pair of 16 bit unsigned integers ("group number", "data element
  501. number"). The data stream is ordered by ascending group number, and within each
  502. group by ascending data element number. Each element may occur only once in a
  503. message. Even numbered groups describe elements defined by the standard. Odd
  504. numbered groups are available for use by vendors or users, but must conform to
  505. the same structure as standard elements. Following the (group number, data
  506. element number) pair is a length field that is a 32 bit unsigned even integer
  507. that describes the number of bytes from the end of the length field to the
  508. beginning of the next data element. The last part of a data element is its
  509. value, which is defined by the data dictionary to be an ascii (numeric AN or
  510. text AT) or binary value (BI 16 bit or BD 32 bit), which may be single values
  511. or multiple in which case ascii values are delimited by the '\' backslash
  512. character. Odd length ascii values are padded with a space (020H).
  513.  
  514.         For example:
  515.  
  516.             0008 0010  000C 0000  4341 2D52 454E 414D
  517.                                   3120 302E
  518.  
  519.         is data element "Recognition Code" because that is what the dictionary
  520. defines group 0008 element 0010 to be. The dictionary says it is of type AT
  521. (ascii text), has a value multiplicity of single and only enumerated values are
  522. allowed, in this case the ascii string "ACR-NEMA 2.0". It is of length 0000000C
  523. hex or 12 bytes long.
  524.  
  525.         The electrical interface is a 16 bit one, and hence even though 32
  526. binary values are defined to be transmitted least significant word first
  527. (though the order for the 32 bit length is not actually specified), there is no
  528. mention in the standard as to how to encapsulate the message in an 8 bit world,
  529. hence different users and vendors have chosen little or big endian schemes. The
  530. new DICOM standard assumes a default little endian representation which seems
  531. to be the most appropriate considering the old definition for 32 bit words,
  532. which specified that the least significant 16 bit word be transmitted first.
  533.  
  534.         Hence there are three likely possible byte orders that a vendor
  535. interpreting the ACR/NEMA standard in a byte oriented world may have used:
  536.  
  537.             - little endian 16 and 32 bit words, as in DICOM 3,
  538.             - big endian 16 and 32 bit words, as in DICOM 3,
  539.             - big endian 16 bit words, but the least significant half of
  540.               a 32 bit word is sent first (as per ACR/NEMA 2.0).
  541.  
  542.         The choice seems to be made usually on the basis of the native byte
  543. order of integers on the host processor. Most of the formats I have encountered
  544. are one of the first two, but I did encounter one from Philips that used the
  545. last scheme and it drove me crazy for a while, until I appreciated the subtlety
  546. of it ! I call it "Big Bad Endian" format in my implementation that recognizes
  547. it, but that may be a value judgement on my part :)
  548.  
  549.         Notice particularly how this design allows one to parse the message
  550. even if the data dictionary is not complete. Consider an element that has an
  551. unrecognized element name. One cannot interpret the content of the element and
  552. so has to ignore it. One doesn't even know whether it contains binary or ascii
  553. information (this is what DICOM later refers to as "implicit representation".
  554. despite this, the length value allows one to skip to the next element and
  555. proceed.
  556.  
  557.         Over the years there has been much discussion amongst those who favour
  558. such implicit dictionary driven schemes, and those who prefer explicit
  559. representations, including explicit description of the element type (binary or
  560. ascii, etc.) and even the element description itself! Some would prefer the
  561. message to contain something like "RecognitionCode='ACR-NEMA 2.0';" for
  562. example. The nuclear medicine groups have adopted a de facto standard called
  563. Interfile that makes use of ACR/NEMA data elements, but uses such a descriptive
  564. representation. Their argument is that the data stream is much more readable
  565. which is true enough, and more readily extensible.
  566.  
  567.         The groups are organized as follows:
  568.  
  569.             0000                    Command
  570.             0008                    Identifying
  571.             0010                    Patient
  572.             0018                    Acquisition
  573.             0020                    Relationship
  574.             0028                    Image Presentation
  575.             4000                    Text
  576.             6000-601E (even)        Overlay
  577.             7FE0                    Pixel Data
  578.  
  579.         Some of the more interesting elements are:
  580.  
  581.             (nnnn,0000) BD S Group Length           # of bytes in group nnnn
  582.             (nnnn,4000) AT M Comments
  583.  
  584.             (0008,0010) AT S Recognition Code       # ACR-NEMA 1.0 or 2.0
  585.             (0008,0020) AT S Study Date             # yyyy.mm.dd
  586.             (0008,0021) AT S Series Date            # yyyy.mm.dd
  587.             (0008,0022) AT S Acquisition Date       # yyyy.mm.dd
  588.             (0008,0023) AT S Image Date             # yyyy.mm.dd
  589.             (0008,0030) AT S Study Time             # hh.mm.ss.frac
  590.             (0008,0031) AT S Series Time            # hh.mm.ss.frac
  591.             (0008,0032) AT S Acquisition Time       # hh.mm.ss.frac
  592.             (0008,0033) AT S Image Time             # hh.mm.ss.frac
  593.             (0008,0060) AT S Modality               # CT,NM,MR,DS,DR,US,OT
  594.  
  595.             (0010,0010) AT S Patient Name
  596.             (0010,0020) AT S Patient ID
  597.             (0010,0030) AT S Patient Birthdate      # yyyy.mm.dd
  598.             (0010,0040) AT S Patient Sex            # M, F, O for other
  599.             (0010,1010) AT S Patient Age            # xxxD or W or M or Y
  600.  
  601.             (0018,0010) AT M Contrast/Bolus Agent   # or NONE
  602.             (0018,0030) AT M Radionuclide
  603.             (0018,0050) AN S Slice Thickness        # mm
  604.             (0018,0060) AN M KVP
  605.             (0018,0080) AN S Repetition Time        # ms
  606.             (0018,0081) AN S Echo Time              # ms
  607.             (0018,0082) AN S Inversion Time         # ms
  608.             (0018,1120) AN S Gantry Tilt            # degrees
  609.  
  610.             (0020,1040) AT S Position Reference     # eg. iliac crest
  611.             (0020,1040) AN S Slice Location         # in mm (signed)
  612.  
  613.             (0028,0010) BI S Rows
  614.             (0028,0011) BI S Columns
  615.             (0028,0030) AN M Pixel Size             # row\col in mm
  616.             (0028,0100) BI S Bits Allocated         # eg. 12 bit for CT
  617.             (0028,0101) BI S Bits Stored            # eg. 16 bit
  618.             (0028,0102) BI S High Bit               # eg. 11
  619.             (0028,0102) BI S Pixel Representation   # 1 signed, 0 unsigned
  620.  
  621.             (7FE0,0010) BI M Pixel Data             # as described by grp 0028
  622.  
  623.         The way in which the pixel data is stored can vary tremendously, though
  624. thankfully most users and vendors use the simple unimaginative scheme that is
  625. shown above, ie. 1 12 bit pixel stored in the low order part of a 16 bit word
  626. with no attempt at packing more compactly. Following are some examples shown in
  627. Appendix E of the standard. Note that when one adds the little/big endian
  628. question the permutations mount!
  629.  
  630.         Bits Allocated = 16
  631.         Bits Stored    = 12
  632.         High Bit       = 11
  633.  
  634.                           |<------------------ pixel ----------------->|
  635.             ______________ ______________ ______________ ______________
  636.            |XXXXXXXXXXXXXX|              |              |              |
  637.            |______________|______________|______________|______________|
  638.             15          12 11           8 7            4 3            0
  639.  
  640.         ---------------------------
  641.  
  642.         Bits Allocated = 16
  643.         Bits Stored    = 12
  644.         High Bit       = 15
  645.  
  646.            |<------------------ pixel ----------------->|
  647.             ______________ ______________ ______________ ______________
  648.            |              |              |              |XXXXXXXXXXXXXX|
  649.            |______________|______________|______________|______________|
  650.             15          12 11           8 7            4 3            0
  651.  
  652.         ---------------------------
  653.  
  654.         Bits Allocated = 12
  655.         Bits Stored    = 12
  656.         High Bit       = 11
  657.  
  658.            ------ 2 ----->|<------------------ pixel 1 --------------->|
  659.             ______________ ______________ ______________ ______________
  660.            |              |              |              |              |
  661.            |______________|______________|______________|______________|
  662.             15          12 11           8 7            4 3            0
  663.  
  664.            -------------- 3 ------------>|<------------ 2 --------------
  665.             ______________ ______________ ______________ ______________
  666.            |              |              |              |              |
  667.            |______________|______________|______________|______________|
  668.             15          12 11           8 7            4 3            0
  669.  
  670.            |<------------------ pixel 4 --------------->|<----- 3 ------
  671.             ______________ ______________ ______________ ______________
  672.            |              |              |              |              |
  673.            |______________|______________|______________|______________|
  674.             15          12 11           8 7            4 3            0
  675.  
  676.         ---------------------------
  677.  
  678.         And so on ... refer to the standard itself for more detail.
  679.  
  680. The next part is part2 - standard formats (continued).
  681.  
  682. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  683. From: dclunie@flash.us.com (David A. Clunie)
  684. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  685. Subject: Medical Image Format FAQ, Part 2/8
  686. Followup-To: alt.image.medical
  687. Date: 28 Mar 1995 23:03:12 +0300
  688. Organization: Her Master's Voice
  689. Lines: 415
  690. Approved: news-answers-request@MIT.EDU
  691. Distribution: world
  692. Expires: 28 Apr 1995 00:00:00 GMT
  693. Message-ID: <3l9q20$dk9@flash.ksapax>
  694. Reply-To: dclunie@flash.us.com (David A. Clunie)
  695. NNTP-Posting-Host: flash.ksapax
  696. Summary: This posting contains answers to the most Frequently Asked
  697.          Question on alt.image.medical - how do I convert from image
  698.          format X from vendor Y to something I can use ? In addition
  699.          it contains information about various standard formats.
  700. Xref: senator-bedfellow.mit.edu alt.image.medical:2434 comp.protocols.dicom:635 sci.data.formats:885 sci.med.informatics:1728 sci.med.radiology:1806 alt.answers:8365 comp.answers:10922 sci.answers:2330 news.answers:40885
  701.  
  702. Archive-name: medical-image-faq/part2
  703. Posting-Frequency: monthly
  704. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  705. Version: 2.02
  706.  
  707.  
  708.     2.2 ACR/NEMA DICOM 3.0
  709.  
  710.         ACR/NEMA Standards Publications
  711.  
  712.             No. PS 3.1-1992   <- DICOM 3 - Introduction & Overview
  713.             No. PS 3.8-1992   <- DICOM 3 - Network Communication Support
  714.  
  715.             No. PS 3.2-1993   <- DICOM 3 - Conformance
  716.             No. PS 3.3-1993   <- DICOM 3 - Information Object Definitions
  717.             No. PS 3.4-1993   <- DICOM 3 - Service Class Specifications
  718.             No. PS 3.5-1993   <- DICOM 3 - Data Structures & Encoding
  719.             No. PS 3.6-1993   <- DICOM 3 - Data Dictionary
  720.             No. PS 3.7-1993   <- DICOM 3 - Message Exchange
  721.             No. PS 3.9-1993   <- DICOM 3 - Point-to-Point Communication
  722.  
  723.             No. PS 3.10-????  <- DICOM 3 - Media Storage & File Format
  724.             No. PS 3.11-????  <- DICOM 3 - Media Storage Application Profiles
  725.             No. PS 3.12-????  <- DICOM 3 - Media Formats & Physical Media
  726.  
  727.         DICOM (Digital Imaging and Communications in Medicine) standards are of
  728. course the hot topic at every radiological trade show. Unlike previous attempts
  729. at developing a standard, this one seems to have the potential to actually
  730. achieve its objective, which in a nutshell, is to allow vendors to produce a
  731. piece of equipment or software that has a high probability of communicating
  732. with devices from other vendors.
  733.  
  734.         Where DICOM differs substantially from other attempts, is in defining
  735. so called Service-Object Pairs. For instance if a vendor's MR DICOM conformance
  736. statement says that it supports an MR Storage Class as a Service Class
  737. Provider, and another vendor's workstation says that it supports an MR Storage
  738. Class as a Service Class User, and both can connect via TCP/IP over Ethernet,
  739. then the two devices will almost certainly be able to talk to each other once
  740. they are setup with each others network addresses and so on.
  741.  
  742.         The keys to the success of DICOM are the use of standard network
  743. facilities for interconnection (TCP/IP and ISO-OSI), a mechanism of association
  744. establishment that allows for negotiation of how messages are to be
  745. transferred, and an object-oriented specification of Information Objects (ie.
  746. data sets) and Service Classes.
  747.  
  748.         Of course all this makes for a huge and difficult to read standard, but
  749. once the basic concepts are grasped, the standard itself just provides a
  750. detailed reference. From the users' and equipment purchasers' points of view
  751. the important thing is to be able to read and match up the Conformance
  752. Statements from each vendor to see if two pieces of equipment will talk.
  753.  
  754.         Just being able to communicate and transfer information is of course
  755. not sufficient - these are only tools to help construct a total system with
  756. useful functionality. Because a workstation can pull an image off an MRI
  757. scanner doesn't mean it knows when to do it, when the image has become
  758. available, to which patient it belongs, and where it is subsequently archived,
  759. not to mention notifying the Radiology or Hospital Information System (RIS/HIS)
  760. when such a task has been performed. In other words DICOM Conformance does not
  761. guarantee functionality, it only facilitates connectivity.
  762.  
  763.         In otherwords, don't get too carried away with espousing the virtues of
  764. DICOM, demanding it from vendors, and expecting it to be the panacea to create
  765. a useful multi-vendor environment.
  766.  
  767.         Fred Prior (prior@xray.hmc.psu.edu) has come up with the concept of a
  768. User Conformance Statement to be generated by purchasers and to be satisfied by
  769. vendors. The idea is that one describes what one expects and hence gives the
  770. vendor a chance to realistically satisfy the buyer! Of course each such
  771. statement must be tailored to the user's needs, and simply stapling a copy of
  772. Fred's statement to a Request For Proposals is not going to achieve the desired
  773. objective. Caveat empor.
  774.  
  775.         To get more information about DICOM:
  776.  
  777.            - Purchase the standards from NEMA.
  778.  
  779.            - Ftp the final versions of the drafts in electronic form
  780.               one of the sites described below.
  781.  
  782.            - Follow the Usenet group comp.protocols.dicom.
  783.  
  784.            - Get a copy of "Understanding DICOM 3.0" $12.50 from Kodak.
  785.  
  786.            - Insist that your existing and potential vendors supply you
  787.               with DICOM conformance statements before you upgrade or
  788.               purchase, and don't buy until you know what they mean. Don't
  789.               take no for an answer!!!!
  790.  
  791.         What is all this doing in an FAQ about medical image formats you ask ?
  792. Well first of all, in many ways DICOM 3.0 will solve future connectivity
  793. problems, if not provide functional solutions to common problems. Hence
  794. actually getting the images from point A to B is going to be easier if everyone
  795. conforms. Furthermore, for those of us with old equipment, interfacing it to
  796. new DICOM conforming equipment is going to be a problem. In otherwords old
  797. network solutions and file formats are going to have to be transformed if they
  798. are going to communicate unidirectionally or bidirectionally with DICOM 3.0
  799. nodes. One is still faced with the same old questions of how does one move the
  800. data and how does one interpret it.
  801.  
  802.          The specifics of the DICOM message format are very similar to the
  803. previous versions of ACR/NEMA on which it is based. The data dictionary is
  804. greatly extended, and certain data elements have been "retired" but can be
  805. ignored gracefully if present. The message itself can now be transmitted as a
  806. byte stream over networks, rather than using a point-to-point paradigm
  807. excusively (though the old point-to-point interface is available). This message
  808. can be encoded in various different Transfer Syntaxes for transmission. When
  809. two devices ("Application Entities" or AE) begin to establish an "Association",
  810. they negotiate an appropriate transfer syntax. They may choose an Explicit
  811. Big-Endian Transfer Syntax in which integers are encoded as big-endian and
  812. where each data element includes a specific field that says "I am an unsigned
  813. 16 bit integer" or "I am an ascii floating-point number", or alternatively they
  814. can fall back on the default transfer syntax which every AE must support, the
  815. Implicit Little-Endian Transfer Syntax which is just the same as an old
  816. ACR/NEMA message with the byte order defined once and for all.
  817.  
  818.         This is all very well if you are using DICOM as it was originally
  819. envisaged - talking over a network, negotiating an association, and determining
  820. what Transfer Syntax to use. What if one wants to store a DICOM message in a
  821. file though ? Who is to say which transfer syntax one will use to encode it
  822. offline ? One approach, used for example by the Central Test Node software
  823. produced by Mallinkrodt and used in the RSNA Inforad demonstrations, is just to
  824. store it in the default little-endian implicit syntax and be done with it. This
  825. is obviously not good enough if one is going to be mailing tapes, floppies and
  826. optical disks between sites and vendors though, and hence the DICOM group
  827. decided to define a "Media Storage & File Format" part of the standard, the new
  828. Parts 10, 11 and 12 which have recently passed their ballot and shoul;d be
  829. available in final form from NEMA soon.
  830.  
  831.         Amongst other things, Part 10 defines a generic DICOM file format that
  832. contains a brief header, the "DICOM File Meta Information Header" which
  833. contains a 128 byte preamble (that the user can fill with anything), a 4 byte
  834. DICOM prefix "DICM", then a short DICOM format message that contains newly
  835. defined elements of group 0002 in a specified Transfer Syntax, which uniquely
  836. identify the data set as well as specifying the Transfer Syntax for the rest of
  837. the file. The rest of the message must specify a single SOP instance. The
  838. length of the brief message in the Meta Header is specified in the first data
  839. element as usual, the group length.
  840.  
  841. Originally the draft of Part 10 specified the default Implicit Value
  842. Representation Little Endian Transfer Syntax as the DICOM File Meta Information
  843. Header Transfer Syntax, which is in keeping with the concept that it is the
  844. default for all other parts of the standard. The final standard has changed
  845. this to Explicit Value Representation Little Endian Transfer Syntax. This seems
  846. like an extremely irritating change to me but I guess purists have prevailed.
  847.  
  848.         So what choices of Transfer Syntax does one have and why all the fuss ?
  849. Well the biggest distinction is between implicit and explicit value
  850. representation which allows for multiple possible representations for a single
  851. element, in theory at least, and perhaps allows one to make more of an unknown
  852. data element than one otherwise could perhaps. Some purists (and Interfile
  853. people) would argue that the element should be identified descriptively, and
  854. there is nothing to stop someone from defining their own private Transfer
  855. Syntax that does just that (what a heretical thought, wash my mouth out with
  856. soap). With regard to the little vs. big endian debate I can't see what the
  857. fuss is about, as it can't really be a serious performance issue.
  858.  
  859.         Perhaps more importantly in the long run, the Transfer Syntax mechanism
  860. provides a means for encapsulating compressed data streams, without having to
  861. deal with the vagaries and mechanics of compression in the standard itself. For
  862. example, if DICOM version 3.0, in addition to the "normal" Transfer Syntaxes, a
  863. series are defined to correspond to each of the Joint Photographic Experts
  864. Group (JPEG) processes. Each one of these Transfer Syntaxes encodes data
  865. elements in the normal way, except for the image pixel data, which is defined
  866. to be encoded as a valid and self-contained JPEG byte stream. Both reversible
  867. and irreversible processes of various types are provided for, without having to
  868. mess with the intricacies of encoding the various tables and parameters that
  869. JPEG processes require. Presumably a display application that supports such a
  870. Transfer Syntax will just chop out the byte stream, pass it to the relevant
  871. JPEG decode, and get an uncompressed image back. More importantly, an archive
  872. server can store the image and retrieve it without ever having to know anything
  873. about how the image pixel data is encoded. Contrast this approach with that
  874. taken by those defining the TIFF (Tagged Image File Format) for general imaging
  875. and page layout applications. In their version 6.0 standard they attempted to
  876. disassemble the JPEG stream into its various components and assign each to a
  877. specific tag. Unfortunately this proved to be unworkable after the standard was
  878. disseminated and they have gone back to the drawing board.
  879.  
  880.         Now one may not like the JPEG standard, but one cannot argue with the
  881. fact that the scheme is workable, and a readily available means of reversible
  882. compression has been incorporated painlessly. How effective a compression
  883. scheme this is remains to be determined, and whether or not the irreversible
  884. modes gain wide acceptance will be dictated by the usual medico-legal paranoia
  885. that prevails in the United States, but the option is there for those who want
  886. to take it up. There is of course no reason why private compression schemes
  887. cannot be readily incorporated using this "encapsulation" mechanism, and to
  888. preserve bandwidth this will undoubtedly occur. This will not compromise
  889. compatibility though, as one can always fall back to a default, uncompressed
  890. Transfer Syntax. The DICOM Working Group IV on compression will undoubtedly
  891. bring out new possibilities. Currently there is a lot of interest in RLE (Run
  892. Length Encoded) compression, particularly from the Ultrasound group.
  893.  
  894.         In order to identify all these various syntaxes, information objects,
  895. and so on, DICOM has adopted the ISO concept of the Unique Identifier (UID)
  896. which is a text string of numbers and periods with a unique root for each
  897. organization that is registered with ISO and various organizations that in turn
  898. register others in a hierarchical fashion. For example 1.2.840.10008.1.2 is
  899. defined as the Implicit VR Little Endian Transfer Syntax. The 1 identifies ISO,
  900. the 2 is the ISO member body branch, the 840 is the specific member body
  901. country code, in this case ANSI, and the 10008 is registered by ANSI to NEMA
  902. for DICOM.  UID's are also used to uniqely identify non-DICOM specific things,
  903. such as information objects. These are constructed from a prefix registered to
  904. the supplier or vendor or site, and a unique suffix that may be generated from
  905. say a date and time stamp (which is not to be parsed). For example an instance
  906. of a CT information object might have a UID of
  907. 1.2.840.123456.002.999999.940623.170717 where a (presumably US) vendor
  908. registered 123456, and the modality generated a unique suffix based on its
  909. device number, patient hospital id, date and time, which have no other
  910. significance other than to create a unique suffix.
  911.  
  912.         The other important new concept that DICOM introduced was the concept
  913. of Information Objects. In the previous ACR/NEMA standard, though modalities
  914. were identified by a specific data element, and though there were rules about
  915. which data elements were mandatory, conditional or optional in ceratin
  916. settings, the concept was relatively loosely defined. Presumably in order to
  917. provide a mechanism to allow conformance to be specified and hence ensure
  918. interoperability, various Information Objects are defined that are composed of
  919. sets of Modules, each module containing a specific set of data elements that
  920. are present or absent according to specific rules. For example, a CT Image
  921. Information Object contains amongst others, a Patient module, a General
  922. Equipment module, a CT Image module, and an Image Pixel module. An MR Image
  923. Information module would contain all of these except the CT Image module which
  924. would be replaced by an MR Image module. Clearly one needs descriptive
  925. information about a CT image that is different from an MR image, yet the
  926. commonality of the image pixel data and the patient information is recognized
  927. by this model.
  928.  
  929.         Hence, as described earlier, one can define pairs of Information
  930. Objects and Services that operate on such objects (Storage, Query/Retrieve,
  931. etc.) and one gets SOP classes and instances. All very object oriented and
  932. initially confusing perhaps, but it provides a mechanism for specifying
  933. conformance. From the point of view of an interpreters of a DICOM compatible
  934. data stream this means that for a certain instance of an Information Object,
  935. certain information is guaranteed to be in there, which is nice. As a creator
  936. of such a data stream, one must ensure that one follows all the rules to make
  937. sure that all the data elements from all the necessary modules are present.
  938. Having done so one then just throws all the data elements together, sorts them
  939. into ascending order by group and element order, and pumps them out. It is a
  940. shame that the data stream itself doesn't reflect the underlying order in the
  941. Information Objects, but I guess they had to maintain backward compatibility,
  942. hence this little bit of ugliness. This gets worse when one considers how to
  943. put more than one object in a folder inside another object.
  944.  
  945.         At this point I am tempted to include more details of various different
  946. modules, data elements and transfer syntaxes, as well as the TCP/IP mechanism
  947. for connection. However all this information is in the standard itself, drafts
  948. of which are readily available electronically from ftp sites, and in the
  949. interests of brevity I will not succumb to temptation at this time.
  950.  
  951.     2.3 Papyrus
  952.  
  953.         Papyrus is an image file format based on ACR/NEMA version 2.0. It was
  954. developed by the Digital Imaging Unit of the University Hospital of Geneva for
  955. the European project on telemedicine (TELEMED project of the RACE program),
  956. under the leadership of Dr. Osman Ratib (osman@cih.hcuge.ch). The University
  957. Hospital of Geneva uses Papyrus for their hospital-wide PACS.
  958.  
  959.         The medical file format component of Papyrus version 2 extended the
  960. ACR/NEMA format, particularly in order to reference multiple images by placing
  961. folder information referencing ACR-NEMA data sets in a shadow (private) group.
  962. Contributing to the development of DICOM 3, the team are updating their format
  963. to be compatible with the offline file format provisions of the draft Part 10
  964. of DICOM 3 in Papyrus version 3.
  965.  
  966.         The specifications, toolkit and image manipulation software that is
  967. Papyrus aware, Osiris, is available for the Mac, Windows, and Unix/X11/Motif by
  968. ftp from ftp://expasy.hcuge.ch/pub/Osiris.
  969.  
  970. See also Papyrus and Osiris ftp site.
  971.  
  972.         Further information is available in printed form. Contact
  973. yves@cih.hcuge.ch (Yves Ligier).
  974.  
  975.     2.4 Interfile V3.3
  976.  
  977.         Interfile is a "file format for the exchange of nuclear medicine image
  978. data" created I gather to satisfy the needs of the European COST B2 Project for
  979. the transfer of images of quality control phantoms, and incorporates the AAPM
  980. (American Association of Physicists in Medicine) Report No. 10, and has been
  981. subsequently used for clinical work.
  982.  
  983.         It specifies a file format composed of ascii "key-value" pairs and a
  984. data dictionary of keys. The binary image data may be contained in the same
  985. file as the "administrative information", or in a separate file pointed to by a
  986. "name of data file" key. Image data may be binary integers, IEEE floating point
  987. values, or ascii and the byte order is specified by a key "imagedata byte
  988. order". The order of keys is defined by the Interfile syntax which is more
  989. sophisticated than a simple list of keys, allowing for groups, conditionals and
  990. loops to dictate the order of key-value pairs.
  991.  
  992.         Conformance to the Interfile standard is informally described in terms
  993. of which types of image data types, pixel types, multiple windows, special
  994. Interfile features including curves, and restriction to various maximum
  995. recommended limits.
  996.  
  997.         Interfile is specifically NOT a communications protocol and strictly
  998. deals with offline files. There are efforts to extend Interfile to include
  999. modalities other than nuclear medicine, as well as to keep ACR/NEMA and
  1000. Interfile data dictionaries in some kind of harmony.
  1001.  
  1002.         A sample list of Interfile 3.3 key-value pairs is shown here to give
  1003. you some idea of the flavor of the format. The example is culled from part of a
  1004. Static study in the Interfile standard document and is not complete:
  1005.  
  1006.                 !INTERFILE :=
  1007.                 !imaging modality :=nucmed
  1008.                 !version of keys :=3.3
  1009.                 data description :=static
  1010.                 patient name :=joe doe
  1011.                 !patient ID  :=12345
  1012.                 patient dob :=1968:08:21
  1013.                 patient sex :=M
  1014.                 !study ID :=test
  1015.                 exam type :=test
  1016.                 data compression :=none
  1017.                 !image number :=1
  1018.                 !matrix size [1] :=64
  1019.                 !matrix size [2] :=64
  1020.                 !number format :=signed integer
  1021.                 !number of bytes per pixel :=2
  1022.                 !image duration (sec) :=100
  1023.                 image start time :=10:20: 0
  1024.                 total counts :=8512
  1025.                 !END OF INTERFILE :=
  1026.  
  1027.         One can see how easy such a format would be to extend, as well as how
  1028. it is readable and almost useable without reference to any standard document or
  1029. data dictionary.
  1030.  
  1031.         Undoubtedly ACR/NEMA DICOM 3.0 to Interfile translators will soon
  1032. proliferate in view of the fact that many Nuclear Medicine vendors supply
  1033. Interfile translators at present.
  1034.  
  1035.         To get hold of the Interfile 3.3 standard, see the Interfile sources,
  1036. Interfile information contacts and Interfile mailing list described later in
  1037. this document.
  1038.  
  1039.     2.5 Qsh
  1040.  
  1041.         Qsh is a family of programs for manipulating images, and it defines an
  1042. intermediate file format. The following information was derived with the help
  1043. of one of the authors maguire@it.kth.se(Chip Maguire):
  1044.  
  1045.         Uses an ASCII key-value-pair (KVP sic.) system, based on the AAPM
  1046. Report #10 proposal. This format influenced both Interfile and ACR-NEMA
  1047. (DICOM). The file format is referred to as "IMAGE" in some of their articles
  1048. (see references). The header and the image data  are stored as two separate
  1049. files with extensions *.qhd and *.qim respectively.
  1050.  
  1051.         Qsh is available by anonymous ftp from the Qsh ftp site. This is a
  1052. seriously large tar file, including as it does some sample images, and lots of
  1053. source code, as well as some post-script documents. Subtrees are available as
  1054. separate tar files.
  1055.  
  1056.         QSH's Motif-based menu system (qmenu) will work with OpenWindows 3.0 if
  1057. SUN patch number 100444-54 for SUNOS 4.1.3 rev. A is applied. The patch is
  1058. available from ftp://sunsolve1.sun.com (192.9.9.24).
  1059.  
  1060.         The image access subroutines take the same parameters as the older
  1061. /usr/image package from UNC, however, the actual subroutines support the qsh
  1062. KVP and image data files.
  1063.  
  1064.         The frame buffer access subroutines take the same parameters as the
  1065. Univ. of Utah software (of the mid.  1970s). The design is based on the use of
  1066. a virtual frame buffer which is then implemented via a library for a specific
  1067. frame buffer.  There exists a version of the the display routines for X11.
  1068.  
  1069.         Conversions are not supported any longer, instead there is a commercial
  1070. product called InterFormat. InterFormat includes a qsh to Interfile conversion,
  1071. along with DICOM to qsh, and many others. Information is available from
  1072. reddy@nucmed.med.nyu.edu (David Reddy) (see InterFormat in the Sources
  1073. section).
  1074.  
  1075.         [Editorial note: this seems a bit of a shame to me - the old
  1076. distribution included lots of handy bits of information, particularly on
  1077. driving tape drives. I am advised however that the conversion stuff was pulled
  1078. out because people wanted it supported, the authors were worried they were
  1079. disclosing things perhaps they ought not to be, and NYU had switched to using
  1080. InterFormat themselves anyway. DAC.]
  1081.  
  1082.         The authors of the qsh package are:
  1083.  
  1084.                - maguire@it.kth.se (Gerald Q. (Chip) Maguire)
  1085.                - noz@nucmed.NYU.EDU (Marilyn E Noz)
  1086.  
  1087.         The following references are helpful in understanding the philosophy
  1088. behind the file format, and are included in postscript form in the qsh ftp
  1089. distribution:
  1090.  
  1091.         @Article[noz88b,
  1092.                 Key=<noz88b>,
  1093.                 Author=<M. E. Noz and G. Q. Maguire Jr.>,
  1094.                 Title=<QSH: A Minimal but Highly Portable Image Display
  1095.                        and Processing Toolkit>,
  1096.                 Journal=<Computer Methods and Programs in Biomedicine>,
  1097.                 volume=<27>,
  1098.                 month=<November>,
  1099.                 Year=<1988>,
  1100.                 Pages=<229-240>
  1101.         ]
  1102.         @Article[maguire89e,
  1103.                 Key=<maguire>,
  1104.                 Author=<G.Q. Maguire Jr., and M.E. Noz>,
  1105.                 Title=<Image Formats: Five Years after the AAPM Standard Format
  1106.                 for Digital Image Interchange>,
  1107.                 Journal=<Medical Physics>,
  1108.                 volume=<16>,
  1109.                 month=<September/October>,
  1110.                 year=<1989>,
  1111.                 pages=<818-823>,
  1112.                 comment=<Also as CUCS-369-88>
  1113.         ]
  1114.  
  1115. The next part is part3 -  proprietary CT formats.
  1116.  
  1117. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!swrinde!cs.utexas.edu!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  1118. From: dclunie@flash.us.com (David A. Clunie)
  1119. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  1120. Subject: Medical Image Format FAQ, Part 3/8
  1121. Followup-To: alt.image.medical
  1122. Date: 28 Mar 1995 23:03:22 +0300
  1123. Organization: Her Master's Voice
  1124. Lines: 1023
  1125. Approved: news-answers-request@MIT.EDU
  1126. Distribution: world
  1127. Expires: 28 Apr 1995 00:00:00 GMT
  1128. Message-ID: <3l9q2a$dkq@flash.ksapax>
  1129. Reply-To: dclunie@flash.us.com (David A. Clunie)
  1130. NNTP-Posting-Host: flash.ksapax
  1131. Summary: This posting contains answers to the most Frequently Asked
  1132.          Question on alt.image.medical - how do I convert from image
  1133.          format X from vendor Y to something I can use ? In addition
  1134.          it contains information about various standard formats.
  1135. Xref: senator-bedfellow.mit.edu alt.image.medical:2435 comp.protocols.dicom:636 sci.data.formats:886 sci.med.informatics:1729 sci.med.radiology:1807 alt.answers:8366 comp.answers:10923 sci.answers:2331 news.answers:40886
  1136.  
  1137. Archive-name: medical-image-faq/part3
  1138. Posting-Frequency: monthly
  1139. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  1140. Version: 2.02
  1141.  
  1142.  
  1143. 3.  Proprietary Formats
  1144.  
  1145.     3.1 Proprietary Formats - General Information
  1146.  
  1147.         3.1.1 SPI (Standard Product Interconnect)
  1148.  
  1149.               Used for files exported from:
  1150.  
  1151.                 - Siemens Somatom Plus
  1152.                 - Siemens Magnetom Impact
  1153.                 - Siemens Magnetom SP
  1154.                 - Siemens Magnetom Vision
  1155.                 - Philips Gyroscan S5
  1156.                 - ? what else ?
  1157.  
  1158.               SPI is a standard based on the old ACR/NEMA 1 standard, devised I
  1159. gather by Siemens and Philips, for use in a PACS environment. Who currently
  1160. maintains it and whether or not Sienet PACS systems are based on it, I am not
  1161. certain. Many machines in the workplace use it in some shape or form, or can
  1162. export files in SPI format. I gather it has been around since 1987 or so, but I
  1163. do not yet have access to the reference documents, nor permission to disclose
  1164. their contents, so much of the following is guess work or hearsay from Usenet.
  1165.  
  1166.                Like the ACR/NEMA standard, SPI is designed to define
  1167. interconnections between pieces of equipment from the physical level through to
  1168. the application level. Where appropriate it utilized relevant parts of
  1169. ACR/NEMA. Unlike ACR/NEMA, I gather that SPI is aware of the concept of
  1170. networks, objects containing information, the need to uniquely identify
  1171. instances of objects, and defines an offline file format. Thus in many ways it
  1172. sounds like the missing link between ACR/NEMA 2.0 and DICOM 3.0.
  1173.  
  1174.               SPI makes use of ACR/NEMA data elements and groups, and in
  1175. addition provides "shadow" private odd-numbered groups as dictated by the
  1176. ACR/NEMA standard for the purpose of storing additional items of information,
  1177. including a means of uniquely identifying objects, as well as allowing for
  1178. enumerated values for elements beyond those defined by ACR/NEMA. SPI also
  1179. defines a byte order for offline storage of data streams. Integers are stored
  1180. in little endian format (least significant byte first).
  1181.  
  1182.               The private groups mechanism works as follows. For each odd
  1183. numbered group (other than 0x0001,0x0003,0x0005,0x0007 and 0xffff), the
  1184. elements 0x00nn in the range 0x0010 through 0x00ff contain a single valued
  1185. string identification code that identifies the creator of the range of elements
  1186. 0xnn00 through 0xnnff. Neat eh ? For example:
  1187.  
  1188.     (0x0009,0x0010) PrivateCreatorDataElement
  1189.     (0x0009,0x0011) PrivateCreatorDataElement
  1190.     ...
  1191.     (0x0009,0x1000) DavidElement1
  1192.     (0x0009,0x1001) DavidElement2
  1193.     ...
  1194.     (0x0009,0x1100) HarryElement1
  1195.     (0x0009,0x1101) HarryElement2
  1196.  
  1197.               You get the idea. The nice thing about this scheme is that each
  1198. creator dictionary considers its elements numbered from 0x0000, but these will
  1199. be remapped to a block of elements depending on exactly which
  1200. PrivateCreatorDataElement is used in the particular data set. Hence multiple
  1201. groups from different creators can co-exist happily in the same data set, and
  1202. vary in position between data sets.
  1203.  
  1204.               Note that the group number IS taken into consideration ... a
  1205. private element with the same element offset and the same creator will have a
  1206. different meaning depending on which group it is in.
  1207.  
  1208.               SPI uses this concept extensively and defines a large dictionary
  1209. with different creators with convoluted names for different modalities and PACS
  1210. operations. A few sample elements are described here. Particularly important
  1211. are those elements for purposes that were not envisaged when ACR/NEMA 1 was
  1212. written, but are necessary to create valid DICOM 3 data sets. Such things as
  1213. FlipAngle for MR scans for example. Note that the SPI UID is not the same as a
  1214. DICOM UID, but presumably it is unique ! Note also that the creator of "SPI
  1215. RELEASE 1" is the same as "SPI Release 1" and "SPI" ... presumably someone
  1216. messed up between machines or modalities or manufacturers. For a more extensive
  1217. SPI data dictionary see the dicom3tools package from release 0.08 onwards. The
  1218. value representation fields are shown here using the modern DICOM equivalents
  1219. rather than the older, less specific ACR/NEMA names. The "owner" is what is
  1220. used as the string value of the PrivateCreatorDataElement when a range of
  1221. elements in a group is claimed.
  1222.  
  1223. Element     Owner                 Name                  VR VM
  1224.  
  1225. (0009,0010) SPI                   Comments              LO  1
  1226. (0009,0015) SPI                   UID                   LO  1
  1227. (0009,0010) SIEMENS MED           RecognitionCode       LO  1
  1228.  
  1229. (0011,0010) SPI RELEASE 1         Organ                 LO  1
  1230. (0011,0015) SPI RELEASE 1         AllergyIndication     LO  1
  1231. (0011,0020) SPI RELEASE 1         Pregnancy             LO  1
  1232. (0011,0010) SIEMENS CM VA0  CMS   RegistrationDate      DA  1
  1233. (0011,0011) SIEMENS CM VA0  CMS   RegistrationTime      TM  1
  1234. (0011,0023) SIEMENS CM VA0  CMS   UsedPatientWeight     IS  1
  1235.  
  1236. (0013,0020) SIEMENS CM VA0  CMS   PatientName           LO  1
  1237. (0013,0022) SIEMENS CM VA0  CMS   PatientId             LO  1
  1238. (0013,0030) SIEMENS CM VA0  CMS   PatientBirthdate      LO  1
  1239. (0013,0031) SIEMENS CM VA0  CMS   PatientWeight         DS  1
  1240. (0013,0035) SIEMENS CM VA0  CMS   PatientSex            LO  1
  1241. (0013,0040) SIEMENS CM VA0  CMS   ProcedureDescription  LO  1
  1242. (0013,0042) SIEMENS CM VA0  CMS   RestDirection         LO  1
  1243. (0013,0044) SIEMENS CM VA0  CMS   PatientPosition       LO  1
  1244.  
  1245. (0019,0010) SIEMENS CM VA0  CMS   NetFrequency          DS  1
  1246. (0019,0011) SIEMENS CM VA0  ACQU  SequenceFileName      LO  1
  1247. (0019,0021) SIEMENS CT VA0  GEN   Exposure              DS  1
  1248. (0019,0026) SIEMENS CT VA0  GEN   GeneratorVoltage      DS  1
  1249. (0019,0050) SIEMENS MR VA0  GEN   NumberOfAverages      IS  1
  1250. (0019,0060) SIEMENS MR VA0  GEN   FlipAngle             DS  1
  1251. (0019,0012) SIEMENS MR VA0  COAD  MagneticFieldStrength DS  1
  1252.  
  1253. (0021,0010) SIEMENS MED           Zoom                  DS  1
  1254. (0021,0011) SIEMENS MED           Target                DS  2
  1255. (0021,0020) SIEMENS CM VA0  CMS   FoV                   DS  2
  1256. (0021,0060) SIEMENS CM VA0  CMS   ImagePosition         DS  3
  1257. (0021,0061) SIEMENS CM VA0  CMS   ImageNormal           DS  3
  1258. (0021,006a) SIEMENS CM VA0  CMS   ImageRow              DS  3
  1259. (0021,006b) SIEMENS CM VA0  CMS   ImageColumn           DS  3
  1260. (0021,0039) SIEMENS MR VA0  GEN   SlabThickness         DS  1
  1261. (0021,0070) SIEMENS MR VA0  GEN   NumberOfEchoes        IS  1
  1262.  
  1263.     3.2 CT - Proprietary Formats
  1264.  
  1265.         3.2.1 General Electric CT
  1266.  
  1267.               Now we get to the meaty part. After years of being faced with the
  1268. problem of either a) hours of detective work, or b) tediously tracking down the
  1269. name of the responsible person and exercising a non-disclosure agreement,
  1270. General Electric (or Generous Electric as I heard them described the other day)
  1271. now really are being generous, as well as sensible, and are making their image
  1272. format description documents freely available. For details see the GEMS image
  1273. format information contacts section later on. In the meantime, both for
  1274. historical completeness, educational purposes, and for those who can't wait for
  1275. document to come in the mail, a summary of the relevant formats and
  1276. decompression algorithms is provided here.
  1277.  
  1278.               3.2.1.1 GE CT 9800
  1279.  
  1280.                       References (see the GEMS image format information
  1281. contacts section):
  1282.  
  1283.                                 - 46-021855 CT 9800 Image Data Format
  1284.  
  1285.                       3.2.1.1.1 GE CT 9800 Image data
  1286.  
  1287.                                 - "block format" header
  1288.                                 - perimeter encoding
  1289.                                 - optional DPCM compression
  1290.                                 - Data General host (various)
  1291.                                 - RDOS (yuck !)
  1292.  
  1293.                                 Almost everyone in this field has at some stage
  1294. encountered the dreaded CT 9800 format. The world is divided into two groups of
  1295. people ... those who have seen the documents or the critical piece of code in
  1296. another program or have been given a handy hint, and those who will never
  1297. figure out the format themselves.
  1298.  
  1299.                                 Essentially the format fits into the "block
  1300. format" described earlier, with pointers to each of the major header
  1301. components. Rarely, if ever, does one encounter a file that doesn't have the
  1302. same size blocks in the same place, so most people treat it as a fixed layout.
  1303. I believe that reformatted images may have another header stored in there, but
  1304. I have never tested for it.
  1305.  
  1306.                                 The data itself is stored in one of two forms
  1307. depending on whether compression is selected or not during archival. In the
  1308. uncompressed form, a type of perimeter encoding is used (see later section) in
  1309. which for an essentially circular object, the outer parts of a rectangular
  1310. image are discarded (and expected to be filled in with a background pixel value
  1311. during reconstitution of the image). In the case of the CT9800 then, the image
  1312. pixel data is interpreted using a map, which contains an entry for each row of
  1313. the image (either 256, 320 or 512 entries) which specifies the length of the
  1314. row that is actually stored, centered about the midline of the image. This
  1315. obviously saves a lot of space.
  1316.  
  1317.                                  If compression is selected on one of the later
  1318. model machines, then a form of Differential Pulse Code Modulation is used, in
  1319. which advantage is taken of the fact that not all the bits of a 16 bit word are
  1320. need to store a CT value. I gather only 12 bits of data are actually
  1321. significant, but one can theoretically represent 15 using this scheme.
  1322. Essentially, the first 16 bit word is read and used as is. Then another byte is
  1323. read. If its most significant bit is set, then the remaining 7 bits represent a
  1324. signed difference value relative to the previous pixel. If its most significant
  1325. bit is not set, then the difference must have exceeded the range of 7 bits, and
  1326. hence the next byte is read to complete a valid 16 bit word (15 bits really)
  1327. which is the actual pixel value. The really neat thing about this scheme is
  1328. that the same algorithm can be used for compressed or uncompressed data as an
  1329. uncompressed stream of words will never have the most significant bit set !
  1330.  
  1331.                                   The following piece of C++ code pulled out of
  1332. a CT9800 to DICOM translator will give you the general idea. Note that the
  1333. perimeter encoding map has already been read in. Note in particular the need to
  1334. deal with sign extension of the difference value. Also note that the code
  1335. doesn't handle the first pixel specially because its high bit will not be set.
  1336.  
  1337. static void
  1338. copy9800image(ifstream& instream,DC3ofstream& outstream,
  1339.           Uint16 resolution,Uint16 *map)
  1340. {
  1341.     unsigned i;
  1342.     Int16 last_pixel;
  1343.  
  1344.     last_pixel=0;
  1345.     for (i=0; i<resolution; ++i) {
  1346.         unsigned line    = map[i];
  1347.         unsigned start    = resolution/2-line;
  1348.         unsigned end    = start+line*2;
  1349.         unsigned j;
  1350.  
  1351.         // Pad the first "empty" part of the line ...
  1352.         for (j=0; j<start; j++) outstream.write16(0);
  1353.  
  1354.         // Copy the middle of the line (compressed or uncompressed)
  1355.         while (start<end) {
  1356.             unsigned char byte;
  1357.             instream.read(&byte,1);
  1358.             if (!instream) break;
  1359.             if (byte & 0x80) {
  1360.                 signed char delta;
  1361.                 if (byte & 0x40) {
  1362.                     delta=byte;
  1363.                 }
  1364.                 else {
  1365.                         delta=byte & 0x3f;
  1366.                 }
  1367.                 last_pixel+=delta;
  1368.             }
  1369.             else {
  1370.                 last_pixel=byte << 8;
  1371.                 instream.read(&byte,1);
  1372.                 if (!instream) break;
  1373.                 last_pixel+=byte;
  1374.             }
  1375.             outstream.write16((Uint16)last_pixel & 0x0fff);
  1376.             ++start;
  1377.         }
  1378.  
  1379.         // Pad the last "empty" part of the line ...
  1380.         for (j=end; j<resolution; j++) outstream.write16(0);
  1381.     }
  1382. }
  1383.  
  1384.                                 What about the rest of the header information
  1385. and where is this map stored anyway ? Well, the file is described as a series
  1386. of 256 by 16 bit word blocks, blocks numbered from 0, words numbered from 1,
  1387. integers are 16 bit words, as follows:
  1388.  
  1389.         block 0 - global header
  1390.  
  1391.                word 34   - Int - pointer to global header
  1392.                word 35   - Int - pointer to exam header
  1393.                word 36   - Int - pointer to image header
  1394.                word 37   - Int - pointer to image header2
  1395.                word 38   - Int - pointer to image map
  1396.                word 39   - Int - pointer to image data
  1397.                word 40   - Int - number of blocks in global header
  1398.                word 41   - Int - number of blocks in exam header
  1399.                word 42   - Int - number of blocks in image header
  1400.                word 43   - Int - number of blocks in image header2
  1401.                word 44   - Int - number of blocks in image map
  1402.                word 45   - Int - number of blocks in image data
  1403.  
  1404.                                 Now almost always the layout is as follows, for
  1405. non-reformatted images:
  1406.  
  1407.         block 0 - global header
  1408.         block 1 - exam header
  1409.         block 2 - image header
  1410.         block 3 - image header 2
  1411.         block 4 - image map
  1412.         block 6 - image data
  1413.  
  1414.                                 For reformatted images the layout is said to be
  1415. different, but I have never seen a description of the contents of the so-called
  1416. "arrange header", nor do I know where in the global header the pointer and
  1417. length are stored:
  1418.  
  1419.         block 0 - global header
  1420.         block 1 - exam header
  1421.         block 2 - image header
  1422.         block 3 - image header 2
  1423.         block 4 - arrange header
  1424.         block 9 - image map
  1425.         block 11 - image data
  1426.  
  1427.                                 Some of the more important contents of the
  1428. various headers are listed here. For more complete information get the
  1429. documents from GE or study any one of a number of programs kicking around to
  1430. dump the header of this kind of file (see sources later). Integers are 16 bit
  1431. words, ascii strings are Fortran style specifications with two characters per
  1432. word, and reals are 4 bytes long (see Host machines - Data General):
  1433.  
  1434.         block 0 - global header
  1435.  
  1436.                word 17-23    - 7A2  - file name
  1437.  
  1438.         block 1 - exam header
  1439.  
  1440.                word  4       - Int  - exam number
  1441.                word  5-11    - 7A2  - exam number
  1442.                word  12-17   - 6A2  - patient id
  1443.                word  18-32   - 15A2 - patient name
  1444.  
  1445.         block 2 - image header
  1446.  
  1447.                word  11      - Int  - position (study) number
  1448.                word  13      - Int  - group type (2=scout,3=standard,4=dynamic)
  1449.                word  14      - Int  - group number
  1450.                word  47      - Int  - scan number
  1451.                word  48      - Int  - image number
  1452.                word  50      - Int  - patient orientation (1=head first,2=feet)
  1453.                word  51      - Int  - AP orientation (1=prone,2=sup,3=lt,4=rt)
  1454.                word  55      - Int  - contrast (0=no,1=yes)
  1455.                word  93-94   - Real - gantry tilt
  1456.                word  95-96   - Real - table height mm
  1457.                word  97-98   - Real - axial table location mm
  1458.                word  124     - Int  - image size (256,320,512) NOT FOR SCOUTS
  1459.                word  132     - Int  - detectors/view        - width  for scouts
  1460.                word  137     - Int  - compressed views/scan - height for scouts
  1461.                word  144-145 - Real - X diameter of recon mm
  1462.                word  146-147 - Real - Y diameter of recon mm
  1463.                word  155-156 - Real - magnification factor
  1464.                word  157-158 - Real - X center
  1465.                word  159-160 - Real - Y center
  1466.                word  175     - Int  - image map used (1=yes,2=no)
  1467.                word  218     - Int  - file type (1=prospective,2=scout,
  1468.                                       3=retrospective,4=segmented,
  1469.                                       5=screen save,6=plot)
  1470.                word  219     - Int  - data range (number of bits)
  1471.                word  236     - Int  - scout orientation (0=ap,1=lateral)
  1472.                                       (the 9800 rotates the scout magically)
  1473.  
  1474.                                 It is important to check the filetype and image
  1475. map used entries, particularly if trying to read scouts rather just prospective
  1476. images. If the map is not in use, it is filled with zeroes and hence if the
  1477. flag is not checked a simplistic demapping algorithm will fail. Furthermore the
  1478. number of rows and columns in the image is not specified as such. For
  1479. prospective images, the imagesize field is valid for both (images are square).
  1480. For scouts, one must use the detectors/view field for the width and the
  1481. compressed views/scan field as the height.
  1482.  
  1483.                                 The filename entry is quite useful. Therein is
  1484. stored the RDOS filename of the image, which follows the following convention:
  1485.  
  1486.         seeeeeppdd.tt
  1487.  
  1488.         s     = originating scan station id
  1489.         eeeee = exam number
  1490.         pp    = prs number (position related set)
  1491.         dd    = image number
  1492.         tt    = file type
  1493.                 YP = prospective
  1494.                 YV = scout
  1495.                 YR = retrospective
  1496.                 YG = segmented recon
  1497.                 YS = screen save
  1498.                 YL = plot
  1499.                 YF = reformatted
  1500.  
  1501.         eg. B038500165.YP
  1502.  
  1503.                                 Having said this, my GE 9800 stores its scouts
  1504. on tape at least with no file extension at all, rather than the .YV that it is
  1505. supposed to use.
  1506.  
  1507.                       3.2.1.1.2 GE CT 9800 Tape format
  1508.  
  1509.                                 Probably more CT images have been exchanged for
  1510. clinical and research purposes using GE 9800 9-track magnetic tapes than any
  1511. other means. These things are just ubiquitous, particularly considering the
  1512. proliferation of services providing 3D reconstruction and fabrication a few
  1513. years ago. Fortunately the format is easy to deal with. The tapes are produced
  1514. on a primitive DG tape drive and hence are never more than 1600bpi. The first
  1515. thing on the tape is a directory consisting of two 4096 word (8192 byte)
  1516. records, then two EOF marks, then 20" of blank tape (because the directory
  1517. keeps getting updated) followed by image files each separated by an EOF mark
  1518. and finally an additional EOF mark after the last file.
  1519.  
  1520.                                 I won't describe the tape directory format here
  1521. unless someone specifically asks for it, though it is very simple. I usually
  1522. just read everything on the tape and sort the files out later. Remember that
  1523. their filenames are stored in the global header.
  1524.  
  1525.                                 Don't forget to set the input magnetic tape
  1526. record size to 8192 bytes when you are copying these files. If you don't do
  1527. this some systems quietly truncate each record to some default size. It took me
  1528. a week to figure out why my files were screwed up the first time I tried this
  1529. on a DG under AOS/VS (I was desperate and using a networked Signa to read files
  1530. off a non-networked 9800).
  1531.  
  1532.                                 A simple script to read an entire tape from a
  1533. SCSI tape drive /dev/nrst1 under SunOS, which will peek in each image file to
  1534. extract the correct filename (simpler than trying to decipher the directory)
  1535. looks like
  1536. this:
  1537.  
  1538. #!/bin/sh
  1539.  
  1540. echo "Rewinding"
  1541. mt -f /dev/nrst1 rewind
  1542.  
  1543. echo "Extracting directory ..."
  1544. dd if=/dev/nrst1 ibs=8192 of=TAPEDIR
  1545.  
  1546. while dd if=/dev/nrst1 ibs=8192 of=tape.tmp
  1547. do
  1548.     name=`dd if=tape.tmp ibs=16 skip=2 count=1 2>/dev/null`
  1549.     if [ -z "$name" ]; then break; fi
  1550.     mv tape.tmp $name
  1551.     echo "Extracted $name"
  1552. done
  1553.  
  1554. echo "Rewinding"
  1555. mt -f /dev/nrst1 rewind
  1556. echo "Finished"
  1557.  
  1558.                       3.2.1.1.2 GE CT 9800 Raw data MR
  1559.  
  1560.                                 No idea about this one ... I have never had the
  1561. need or seen any documention. Anyone who does or has please fill in this space.
  1562.  
  1563.               3.2.1.2 GE CT Advantage - Genesis
  1564.  
  1565.                       References (see the GEMS image format information
  1566. contacts section):
  1567.  
  1568.                                 - 46-021861 Image Data Format
  1569.                                 - 46-021863 Optical Disk Raw Partition
  1570.                                 - 46-021864 Image Extract Tool
  1571.                                 - 46-021865 DAT Archive Format
  1572.  
  1573.                       General Electric now uses the same Sun based architecture
  1574. for its Advantage CT and Signa 5X MR family, referred to as Genesis, and hence
  1575. the general details of this scheme will be discussed under the GE MR Signa 5.x
  1576. - Genesis section. Specifics related to the CT modality will be described here.
  1577.  
  1578.                       3.2.1.2.1 GE CT Advantage Image data
  1579.  
  1580.                                 The Image Extract Tool is used in the same way
  1581. as on the Signa to extract an image from the database into a single file,
  1582. either asis or using the requested compression and packing mode. The Genesis
  1583. file contains headers consisting of several components in common with MR and
  1584. then a specific CT or MR header. Theroetically, one should be able to use
  1585. "/usr/g/insite/bin/ximg -g" to extract a prototype C header file describing the
  1586. file format, as on the Signa, though last time I tried this on a High Speed
  1587. Advantage this didn't work. Some of the more interesting fields in the CT image
  1588. header include:
  1589.  
  1590.         image header - for CT (1020 bytes long):
  1591.  
  1592.                 26  - float    - slice thickness (mm)
  1593.                 30  - short    - image matrix size - X
  1594.                 32  - short    - image matrix size - Y
  1595.                 34  - float    - display field of view - X
  1596.                 38  - float    - display field of view - Y
  1597.                 42  - float    - image dimension - X
  1598.                 46  - float    - image dimension - Y
  1599.                 50  - float    - pixel size - X
  1600.                 54  - float    - pixel size - Y
  1601.                 58  - char[14] - pixel data ID
  1602.                 72  - char[17] - iv contrast agent
  1603.                 89  - char[17] - oral contrast agent
  1604.                 194 - float    - table start Location
  1605.                 198 - float    - table end Location
  1606.                 202 - float    - table speed (mm/sec)
  1607.                 206 - float    - table height
  1608.                 224 - float    - gantry tilt (degrees)
  1609.  
  1610.                       3.2.1.2.2 GE CT Advantage Archive format
  1611.  
  1612.                                 See the GE MR Signa 5.x Archive format.
  1613.  
  1614.                       3.2.1.2.3 GE CT Advantage Raw data
  1615.  
  1616.                                 Again, unknown. Please fill in this space.
  1617.  
  1618.               3.2.1.3 GE CT Pace
  1619.  
  1620.                       References (see the GEMS image format information
  1621. contacts section):
  1622.  
  1623.                                 - 46-021856 CT Pace Image Data Format
  1624.                                 - 46-021862 MR Max  Image Data Format
  1625.  
  1626.                       The Pace is a CT scanner made by Yokogawa Medical
  1627. Systems(YMS) in Japan. The format documents I have for it are partially in
  1628. Japanese and partially in English, but they get the job done. I have only
  1629. tested the following on a few images that were extracted off a nine-track tape,
  1630. so the offsets to the image header fields may not be correct in other cases,
  1631. but here are "eye-catcher" fields at the start of each header which should be
  1632. easy to find. The format seems to be shared with the GE MR Max family.
  1633.  
  1634.                        The images described in the documents have a 512 byte
  1635. study header that begins with "!STD" and an image header of 1024 bytes that
  1636. begins with "!IMG". In the image that I had to play with, there was a 256 byte
  1637. header that I am not familiar with tacked on the front, presumambly something
  1638. to do with being a mag tape rather than a disk image. Anyway this meant that
  1639. the offset to the study header was 256 bytes, the image header was 768 bytes,
  1640. and the compressed image data began at 1792 bytes.
  1641.  
  1642.                        I don't know what kind of host is used on the Pace
  1643. though I have seen some cryptic references to "DOS-68K" in the documents.
  1644. Regardless, the integers are 16 or 32 bit big-endian. The image data is stored
  1645. as SIGNED not unsigned 16 bit values, same as on the Sytec and presumably all
  1646. the YMS systems. Most of the useful dates and times are provided as string
  1647. values, however there are some dates and times that are 32 bit binary integers.
  1648. Though not specified in the docs it seems that the dates are days since an
  1649. epoch of "0 Jan 1980" and the times are in milliseconds. Floats are 32 bit IEEE
  1650. format, dfined in the Pace documentation as follows:
  1651.  
  1652.     bit  31        sign (s)    (0 is +ve)
  1653.  
  1654.     bits 30-23    exponent (e)
  1655.             - unsigned integer
  1656.             - e == 0 for denormalized numbers
  1657.             - 0 < e < 255 for normalized numbers
  1658.             - e == 255 for other reserved operands
  1659.  
  1660.     bits 22-0    significand (f)
  1661.  
  1662.     Normalized numbers:
  1663.         Exponent:
  1664.             - bias 127
  1665.             - range 0 < e < 255
  1666.         Significand:
  1667.             - interpreted as 1.f
  1668.             - range 1.0 <= f < 2.0
  1669.  
  1670.         (-1)^s * 2^(e-127) * 1.f
  1671.  
  1672.     Denormalized numbers:
  1673.         Exponent:
  1674.             - e == 0
  1675.             - bias 126
  1676.         Significand:
  1677.             - interpreted as 0.f
  1678.             - range f != 0
  1679.  
  1680.         (-1)^s * 2^(-126) * 0.f
  1681.  
  1682.     Signed Infinities:
  1683.         - e == 255
  1684.         - f == 0
  1685.  
  1686.     Not-a-numbers:
  1687.         - e == 255
  1688.         - f != 0
  1689.  
  1690.                        The image header has a chunk in the middle where
  1691. different values are defined for CT and MR. One can use the first byte of the
  1692. model number field to distinuish the two modalities. Some of the more important
  1693. study and image header values are:
  1694.  
  1695.     Study header (offset 256 bytes, length 512 bytes):
  1696.  
  1697.         Offset  Type    Length  Meaning       Units or values
  1698.  
  1699.         0x0     string  4        Eyecatcher         !STD
  1700.         0x6     byte    1        Modality           1=CT,2=MR
  1701.         0xa     string  5        Study Number
  1702.         0x10    datestring       Study Date         yyyy/mm/dd
  1703.         0x1a    timestring       Study Time         hh/mm/ss.xxx
  1704.         0x26    string  12       Patient ID
  1705.         0x36    string  12       Patient Name
  1706.         0x50    string  6        Patient Age        yyy;mm
  1707.         0x5c    string  2        PatientSex"        'M ','F '
  1708.         0xbc    string  4        Contrast media     'NO C','+C  '
  1709.  
  1710.     Image header (offset 768 bytes, length 1024 bytes):
  1711.  
  1712.         Offset  Type    Length  Meaning       Units or values
  1713.  
  1714.         0x0     string  4       Eyecatcher          !IMG
  1715.         0x6     byte    1       Modality            1=CT,2=MR
  1716.         0xa     string  5       Study Number
  1717.         0x10    string  2       Series Number
  1718.         0x12    string  2       Acquisition Number
  1719.         0x14    string  2       Image Number
  1720.         0x20    datestring      Image Date          yyyy/mm/dd
  1721.         0x2a    timestring      Image Time          hh/mm/ss.xxx
  1722.         0x40    string  2       'H '=Head First,'F '=Feet First
  1723.         0x42    string  2       'SP'=Supine,'PR'=Prone,
  1724.                                 'LL'=Left Lateral Decubitus,
  1725.                                 'RL'=Right Lateral Decubitus,'OT'=Other
  1726.         0x44    string  6       Anatomic location
  1727.         0x50    string  4       'AX  '=Axial,'SAG '=Sagittal,'COR '=Coronal
  1728.         0x54    float32         Slice position by body coords HF mm
  1729.         0x58    float32         Slice position by body coords AP mm
  1730.         0x5c    float32         Slice position by body coords LR mm
  1731.         0x6c    string  4       Scan fov cm
  1732.         0x70    string  4       Scan thickness mm
  1733.         0xa0    string  4       Contrast media      'NO C','+C  '
  1734.  
  1735.         0x188   float32         Recon center X mm
  1736.         0x18c   float32         Recon center Y mm
  1737.         0x190   string  4       Recon FOV cm [xx.x]
  1738.         0x1a0   u_int16         Pixels in X-axis
  1739.         0x1a2   u_int16         Pixels in Y-axis
  1740.         0x1a4   float32         Pixel size mm
  1741.         0x1b0   float32         Mag center X mm
  1742.         0x1b4   float32         Mag center Y mm
  1743.         0x1b8   float32         Mag factor
  1744.  
  1745.     For CT only:
  1746.  
  1747.         0xc8    string  5       Gantry tilt machine coords degrees
  1748.         0xe0    string  5       Exposure time ms
  1749.         0xe6    string  3       Tube current mA
  1750.         0xea    string  5       Exposure mAS
  1751.         0xf0    string  3       KVP
  1752.         0xf4    string  2       'CW'=Clockwise,'CC'=CounterClockwise
  1753.  
  1754.     For MR only:
  1755.  
  1756.         0xc0    string  5       Tilt ordered by user Axis+/-Angle [xx+/-xx]
  1757.         0x100   string  2       Echo number
  1758.         0x102   string  2       Number of echoes
  1759.         0x104   string  2       Slice number
  1760.         0x106   string  2       Number of slices
  1761.         0x108   string  2       Number of excitations
  1762.         0x10a   string  5       Repetition time ms
  1763.         0x110   string  5       Inversion time ms
  1764.         0x115   string  5       Echo time ms
  1765.         0x130   string  4       Magnetic flux density (T)
  1766.  
  1767.                        Unlike the Sytec sample images I had, compression was
  1768. used in the Pace images I received. This is a neat scheme that uses both Run
  1769. Length Encoding and Differential Pulse Code Modulation. Essentially, each byte
  1770. may be a flag value 0x81 which indicates the next byte is a run length of the
  1771. current pixel, or a flag value 0x80 which indicates that the current mode
  1772. should be toggled between "reference" mode, in which the subsequent 16 bit
  1773. words are new pixel values, or "difference" mode, in which case subsequent
  1774. bytes are signed differences added to the current pixel value. The initial mode
  1775. is "reference" mode. Runs do extended across horizontal line boundaries.
  1776.  
  1777.                        I am not totally clear from the documentation or the
  1778. sample images where in the header is the flag to say compression is in use or
  1779. not. It is probably bit 5 of the Image Attribute field in offset 0x1ac in the
  1780. image header, where a false value specifies DPCM and a true value specifies
  1781. uncompressed or "Original" encoding. The docs say this is for optical disk
  1782. only, but the compressed image from tape I have has this bit false, which is
  1783. correct.
  1784.  
  1785.                        The following piece of code will decode such a
  1786. compressed image:
  1787.  
  1788. static void
  1789. copypaceimage(istream& instream,ostream& outstream,
  1790.           Uint16 width,Uint16 height)
  1791. {
  1792. // NB. the exclusive or with 0x8000 makes the signed Pace values unsigned
  1793. // which is what the PGM convention is ... just omit the ^0x8000
  1794. // everywhere if you want the data left signed.
  1795.  
  1796.     unsigned i;
  1797.     Int16 pixel=0;
  1798.     enum Mode { Difference, Reference } mode = Reference;
  1799.     for (i=0; i<height*width;) {
  1800.         unsigned char byte;
  1801.         instream.read(&byte,1);
  1802.         if (!instream) break;
  1803.         if (byte == 0x80) {        // Mode switch
  1804.             if (mode == Difference)
  1805.                 mode=Reference;
  1806.             else
  1807.                 mode=Difference;
  1808.         }
  1809.         else if (byte == 0x81) {    // Run length flag
  1810.             instream.read(&byte,1);
  1811.             if (!instream) break;
  1812.             unsigned repeat=byte;
  1813.             i+=repeat;
  1814.             while (repeat--) write16little(outstream,pixel^0x8000);
  1815.         }
  1816.         else {
  1817.             if (mode == Difference) {
  1818.                 pixel+=(signed char)byte;
  1819.             }
  1820.             else {
  1821.                 pixel=byte<<8;
  1822.                 instream.read(&byte,1);
  1823.                 if (!instream) break;
  1824.                 pixel|=byte;
  1825.             }
  1826.             write16little(outstream,pixel^0x8000);
  1827.             ++i;
  1828.         }
  1829.     }
  1830.     if (!instream) cerr << "Premature EOF byte " << i << "\n" << flush;
  1831. }
  1832.  
  1833.               3.2.1.4 GE CT Sytec
  1834.  
  1835.                       I don't have one of these either, and it turns out that
  1836. the format is NOT the same as the Pace as GE Milwaukee initially thought. The
  1837. format may be shared with the Vectra, but this is not known for certain. I do
  1838. have a few sample images and have worked out many of the values in the headers.
  1839. The format may be available from Yokogawa in Japan. Milwaukee apparently
  1840. doesn't have it.
  1841.  
  1842.                       The host is an MS-DOS clone using the J-DOS operating
  1843. system, a Japanese version of DOS to handle 16 bit Kanji characters. Alan
  1844. Rowberg tells me it has a 5.25" drive that writes disks that are unreadable by
  1845. anything else in the universe.
  1846.  
  1847.                       The images have a header of 3752 bytes and are followed
  1848. by 16-bit signed integers. The surround is -1500 which is probably -1500 H.U.
  1849. The sample files I had did not use any form of compression.
  1850.  
  1851.                       The data formats are big-endian. Fortuitously the
  1852. date/time format is the same as unix ... a 32 bit unsigned integer containing
  1853. seconds since an epoch of 00:00:00 GMT 1 Jan 1970. Floats are 32 bit IEEE
  1854. format as described in the Pace format.
  1855.  
  1856.                       The head first/feet first and prone/supine fields in the
  1857. Sytec file are not known. The sense and identification of corners in the Sytec
  1858. sample files was done by guess work, and may be wrong if the samples weren't
  1859. scanned head first supine, and the images are not supposed to be looked at from
  1860. bottom up in the usual convention.
  1861.  
  1862.                       The header is 3752 bytes long. The known header values
  1863. are (byte offsets from 0):
  1864.  
  1865.       Offset   Type         Meaning               Units or values
  1866.  
  1867.         7      string       ModelNumber
  1868.  
  1869.         126    string       Organization
  1870.         204    string       PatientID
  1871.         217    string       PatientName
  1872.  
  1873.         328    datetime     ExamDateTime
  1874.         402    string       ExamDescription
  1875.         425    string       Modality
  1876.         444    string       ExamStationID
  1877.  
  1878.         1164   int16        ExamNumber
  1879.         1166   int16        SeriesNumber
  1880.         1172   datetime     SeriesDate
  1881.         1176   string       SeriesDescription
  1882.         1206   string       SeriesStationID
  1883.  
  1884.         1224   int16        ScanType                # 1=axial,3=scout
  1885.         1240   string       AnatomicalReference
  1886.  
  1887.         1280   float32      SeriesStartLocation
  1888.         1288   float32      SeriesEndLocation
  1889.  
  1890.         2192   u_int16      ImageExamNumber
  1891.         2194   u_int16      ImageSeriesNumber
  1892.         2196   u_int16      ImageNumber
  1893.         2204   datetime     ScanDateTime
  1894.         2208   float32      ScanDuration            #? secs
  1895.         2212   float32      SliceThickness          # mm
  1896.         2216   u_int16      XMatrix
  1897.         2218   u_int16      YMatrix
  1898.         2220   float32      FieldOfView             # mm
  1899.         2224   float32      ScoutLength             # mm
  1900.         2228   float32      XDimension              # mm
  1901.         2232   float32      YDimension              # mm
  1902.         2236   float32      XPixelSize              # mm
  1903.         2240   float32      YPixelSize              # mm
  1904.  
  1905.         2310   u_int16      ScoutOrientation        # 0=none,1=ap,2=lateral
  1906.         2316   float32      TablePosition           # mm
  1907.         2320   float32      SliceCenterX            # mm
  1908.         2324   float32      SliceCenterY            # mm
  1909.         2328   float32      SliceCenterZ            # mm
  1910.         2332   float32      NormalVectorX           # unitized
  1911.         2336   float32      NormalVectorY           # unitized
  1912.         2340   float32      NormalVectorZ           # unitized
  1913.         2344   float32      TopRightHandCornerX     # mm
  1914.         2348   float32      TopRightHandCornerY     # mm
  1915.         2352   float32      TopRightHandCornerZ     # mm
  1916.         2356   float32      TopLeftHandCornerX      # mm
  1917.         2360   float32      TopLeftHandCornerY      # mm
  1918.         2364   float32      TopLeftHandCornerZ      # mm
  1919.         2368   float32      BottomLeftHandCornerX   # mm
  1920.         2372   float32      BottomLeftHandCornerY   # mm
  1921.         2376   float32      BottomLeftHandCornerZ   # mm
  1922.         2384   float32      ScoutStartLocation      # mm
  1923.         2388   float32      ScoutEndLocation        # mm
  1924.         2408   int32        GeneratorVoltage        # kVP
  1925.         2412   int32        TubeCurrent             # mA
  1926.         2416   float32      GantryTilt              # degrees
  1927.  
  1928.         2716   float32      XReconOffset            # mm
  1929.         2720   float32      YReconOffset            # mm
  1930.  
  1931.         3256   int32        BitsPerSample
  1932.         3264   int32        DefaultWindowWidth
  1933.         3268   int32        DefaultWindowLevel
  1934.  
  1935.         3.2.2 Siemens CT
  1936.  
  1937.               3.2.1.1 Siemens Somatom DR
  1938.  
  1939.                       - NOT in SPI format
  1940.                       - fixed format
  1941.                       - files 133120 bytes (for 256 square images)
  1942.                       - image pixel data 256*256*2 little endian
  1943.                       - image pixel offset 2048 bytes
  1944.                       - same for axial images and topograms (scouts)
  1945.  
  1946.                       This description pertains to the DR family, and possibly
  1947. also earlier Siemens CT models, but I have no files from these to test.
  1948.  
  1949.                       The files are in fixed format (cf. the early Magnetom
  1950. format which is similar, but has block pointers) with three major blocks of
  1951. entries:
  1952.  
  1953.         - binary data      - offset 0    - 512 bytes
  1954.         - text overlay     - offset 512  - 960 bytes plus 676 bytes free
  1955.         - image pixel data - offset 2048 - 131072 bytes
  1956.  
  1957.                       The binary data block is filled with the usual cryptic
  1958. enumerated values and useful parameters. Some of the more interesting ones are:
  1959.  
  1960.         - binary data block:
  1961.  
  1962.                 66  - byte        - archive mode (0=raw data,B=256,C=512)
  1963.                 67  - byte        - archive mode (0=uncompressed,
  1964.                                     2=compressed)
  1965.  
  1966.                 72  - short       - matrix size (256 or 512)
  1967.  
  1968.                 130 - byte        - scan mode (P=image data,R=raw data)
  1969.                 131 - byte        - scan mode (0=tomogram,Q=quick,S=serial,
  1970.                                     C=cardiac,T=topogram,X=test,H=chronogram)
  1971.                 132 - short       - fov - mm
  1972.                 134 - short       - scan time - secs * 10
  1973.                 136 - short       - kv
  1974.                 138 - short       - dose - maS
  1975.                 140 - short       - slice thickness - mm
  1976.                 142 - short       - gantry tilt - degrees
  1977.                 144 - short       - table position - mm
  1978.                 146 - short       - table height - mm
  1979.                 148 - short       - scan mode (1=standard(360),
  1980.                                     2=quickscan(240),4=topogram)
  1981.  
  1982.                 236 - short       - view direction (1=cranial,-1=caudal)
  1983.                 238 - byte        - head position (0=head first,
  1984.                                     1=feet first)
  1985.                 239 - byte        - patient position (0=supine,
  1986.                                     1=prone,2=r lat dec,3=l lat dec)
  1987.  
  1988.                 310 - short       - window width  A
  1989.                 312 - short       - window center A
  1990.                 314 - short       - window width  B
  1991.                 316 - short       - window center B
  1992.  
  1993.                       Unfortunately, the patient identification information is
  1994. NOT stored in the binary data block, rather one has to extract it from the
  1995. image text overlay block, which consists of 960 characters (24 lines of 40
  1996. characters WITHOUT carriage control characters) in a fixed format. This is
  1997. where what you see overlayed on the filmed images is stored. Some of these
  1998. values are duplicates of what is in the binary data block, but things like the
  1999. patient name and so on are here and nowhere else :(
  2000.  
  2001.                     0123456789012345678901234567890123456789
  2002.  
  2003.                 0   SOMATOM DR2       ST. ELSEWHERE GEN HOSP
  2004.                 40  999999-9999  JOHN DOE                EF2
  2005.                 80  01-JAN-90        FRONT               35B
  2006.                 120 13:31:22                            H/SP
  2007.                 160
  2008.                 200 SCAN 60                             L
  2009.                 240                                     E
  2010.                 280                                     F
  2011.                 320                                     T
  2012.                 360
  2013.                 400
  2014.                 440
  2015.                 480
  2016.                 520
  2017.                 560
  2018.                 600
  2019.                 640
  2020.                 680
  2021.                 720 TI 5
  2022.                 760 KV 125
  2023.                 800 AS .35
  2024.                 840 SL 2
  2025.                 880 GT 0
  2026.                 920 TP 144
  2027.  
  2028.         - text overlay block: (some of this is guess work)
  2029.  
  2030.                 0   - char[14]    - product
  2031.                 15  - char[25]    - hospital name
  2032.                 40  - char[12]    - patient number
  2033.                 53  - char[22]    - patient name
  2034.                 80  - char[2]     - date - dd
  2035.                 83  - char[3]     - date - mmm
  2036.                 87  - char[2]     - date - yy
  2037.                 120 - char[2]     - time - hh
  2038.                 123 - char[2]     - time - mm
  2039.                 126 - char[2]     - time - ss
  2040.                 156 - char[1]     - H=head first,F=feet first
  2041.                 158 - char[2]     - SP=supine,PR=prone,
  2042.                                     RP=right lateral decubitus,
  2043.                                     LP=left lateral decubitus
  2044.                 205 - char[4]     - slice number
  2045.                 723 - char[4]     - scan time - secs
  2046.                 763 - char[4]     - kv
  2047.                 803 - char[4]     - dose - AmpS
  2048.                 843 - char[4]     - slice thickness - mm
  2049.                 883 - char[4]     - gantry tilt - degrees
  2050.                 923 - char[4]     - table position - mm
  2051.  
  2052.                       If anyone knows what "EF2" and "35B" stand for I would
  2053. love to know - I presume they are something like the filter used, or field of
  2054. view or something ?
  2055.  
  2056.                       Also the DR family don't seem to be aware of the concept
  2057. of a hierarchy of examination/study and series numbering, which makes it
  2058. annoying to try to import them into PACS systems :( Correct me if I am wrong
  2059. but they just seem to keep bumping up the slice number for each patient as each
  2060. group of scans is done.
  2061.  
  2062.               3.2.2.2 Siemens Somatom Plus
  2063.  
  2064.                       There seem to be different formats for different versions
  2065. of the machine. Either that or some sites have PACS software and some don't or
  2066. something. Anyway, one set of files that were sent to me used a fixed format
  2067. header much like the DR family, but of different length and with different
  2068. fields. I have not yet adequately deciphered this header but will include it
  2069. here when I have. This may be what is referred to as the "original header"
  2070. stored in the SPI format.
  2071.  
  2072.                        Another site uses a Siemens version of SPI, containing
  2073. the following private data elements. Note that there is overlayed data in the
  2074. high four bytes of the image pixel data, and that there seems to be a bunch of
  2075. padding in the middle. The intent seems to be to store the "original header"
  2076. and the image pixel data at accessible, presumably standard locations,
  2077. presumably indexed by the byte offsets and lengths described in group 9. This
  2078. is a shame because it seems that none of the really interesting CT attributes
  2079. have been included in the SPI form, although SPI private tags are available for
  2080. lots of CT parameters. I don't have one of these image to test this theory,
  2081. someone just sent me an output of the attribute dump.
  2082.  
  2083. SPI private tags:
  2084.  
  2085. (0009,0010)                                      <SPI RELEASE 1>
  2086. (0009,0011)                                        <SIEMENS MED>
  2087. (0009,1011) SPI RELEASE 1   UID     <049S03CT031995011712072452>
  2088. (0009,1040) SPI RELEASE 1   DataObjectSubtype           [0x0000]
  2089. (0009,1041) SPI RELEASE 1   DataObjectSubtype         <IMA TOPO>
  2090. (0009,1110) SIEMENS MED     RecognitionCode             <CT 1.4>
  2091. (0009,1130) SIEMENS MED     ByteOffsetOfOriginalHeader
  2092. (0009,1131) SIEMENS MED     LengthOfOriginalHeader
  2093. (0009,1140) SIEMENS MED     ByteOffsetOfPixelmatrix
  2094. (0009,1141) SIEMENS MED     LengthOfPixelmatrixInBytes
  2095.  
  2096. (0011,0010)                                      <SPI RELEASE 1>
  2097.  
  2098. (0021,0010)                                        <SIEMENS MED>
  2099. (0021,1010) SIEMENS MED     Zoom                          <01.0>
  2100. (0021,1011) SIEMENS MED     Target              <000.000\00.000>
  2101. (0021,1012) SIEMENS MED     TubeAngle                     <0270>
  2102. (0021,1020) SIEMENS MED     ROIMask                     [0xf000]
  2103.  
  2104. Overlay descriptions (overlays already in image pixel data):
  2105.  
  2106. (6000,0040)                 ROI                              <G>
  2107. (6000,0102)                 BitPosition                 [0x000c]
  2108. (6000,0102)                 OverlayLocation             [0x7fe0]
  2109.  
  2110. (6002,0040)                 ROI                              <G>
  2111. (6002,0102)                 BitPosition                 [0x000d]
  2112. (6002,0102)                 OverlayLocation             [0x7fe0]
  2113.  
  2114. (6004,0040)                 ROI                              <G>
  2115. (6004,0102)                 BitPosition                 [0x000e]
  2116. (6004,0102)                 OverlayLocation             [0x7fe0]
  2117.  
  2118. (6006,0040)                 ROI                              <G>
  2119. (6006,0102)                 BitPosition                 [0x000f]
  2120. (6006,0102)                 OverlayLocation             [0x7fe0]
  2121.  
  2122. More SPI private stuff ... padding and original header ...
  2123.  
  2124. (7001,0010)                                        <SIEMENS MED>
  2125. (7001,1010) SIEMENS MED     Dummy
  2126.  
  2127. (7003,0010)                                        <SIEMENS MED>
  2128. (7003,1010) SIEMENS MED     Header
  2129.  
  2130. (7005,0010)                                        <SIEMENS MED>
  2131. (7005,1010) SIEMENS MED     Dummy
  2132.  
  2133.               3.2.2.3 Siemens Somatom AR
  2134.  
  2135.               Unknown, but likely to be SPI unless Siemens have second sourced
  2136. this machine like Philips does theirs from Hitachi or GE theirs from Yokogawa !
  2137.  
  2138.         3.2.3 Philips CT - Big black hole
  2139.  
  2140.         3.2.4 Picker CT
  2141.  
  2142.               Grey hole perhaps. This information probably pertains to the IQ
  2143. and PQ CT models, though I have no sample images to experiment with yet. I am
  2144. told that:
  2145.  
  2146.               - axial images are 512x512
  2147.               - pilot images are 1024x1024
  2148.               - uncompressed images are 12 bits stored in 16 bits
  2149.               - don't know how to handle compression scheme
  2150.               - raster order is as usual, by row, TLHC first
  2151.               - 8k header to be skipped
  2152.  
  2153.         3.2.5 Toshiba CT - another black hole
  2154.         3.2.6 Hitachi CT - another black hole
  2155.         3.2.7 Shimadzu CT - another black hole
  2156.         3.2.8 Elscint CT - another black hole
  2157.  
  2158. The next part is part4 -  proprietary MR formats.
  2159.  
  2160. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  2161. From: dclunie@flash.us.com (David A. Clunie)
  2162. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  2163. Subject: Medical Image Format FAQ, Part 4/8
  2164. Followup-To: alt.image.medical
  2165. Date: 28 Mar 1995 23:03:31 +0300
  2166. Organization: Her Master's Voice
  2167. Lines: 817
  2168. Approved: news-answers-request@MIT.EDU
  2169. Distribution: world
  2170. Expires: 28 Apr 1995 00:00:00 GMT
  2171. Message-ID: <3l9q2j$dlb@flash.ksapax>
  2172. Reply-To: dclunie@flash.us.com (David A. Clunie)
  2173. NNTP-Posting-Host: flash.ksapax
  2174. Summary: This posting contains answers to the most Frequently Asked
  2175.          Question on alt.image.medical - how do I convert from image
  2176.          format X from vendor Y to something I can use ? In addition
  2177.          it contains information about various standard formats.
  2178. Xref: senator-bedfellow.mit.edu alt.image.medical:2436 comp.protocols.dicom:637 sci.data.formats:887 sci.med.informatics:1730 sci.med.radiology:1808 alt.answers:8367 comp.answers:10924 sci.answers:2332 news.answers:40887
  2179.  
  2180. Archive-name: medical-image-faq/part4
  2181. Posting-Frequency: monthly
  2182. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  2183. Version: 2.02
  2184.  
  2185.  
  2186.     3.3 MR - Proprietary Formats
  2187.  
  2188.         3.3.1 General Electric MR
  2189.  
  2190.               3.3.1.1 GE MR Signa 3.x,4.x
  2191.  
  2192.                       References (see the GEMS image format information
  2193. contacts section):
  2194.  
  2195.                                 - 46-021858 MR Signa 4.x Mag Tape/Image Fmt
  2196.  
  2197.                       3.3.1.1.1 GE MR Signa 3.x,4.x Image data
  2198.  
  2199.                                 - "fixed format" header
  2200.                                 - image data is not compressed
  2201.                                 - image data fixed offset 14336 bytes
  2202.                                 - Data General host
  2203.                                 - AOS/VS
  2204.  
  2205.                                 The image files are of fixed layout, described
  2206. here as a series of 256 by 16 bit word blocks (512 bytes), blocks numbered from
  2207. 0. The headers start at the following block offsets:
  2208.  
  2209.         block 0  - length 4 blocks   - System configuration
  2210.         block 4  - length 2 blocks   - Site customization
  2211.         block 6  - length 2 blocks   - Study header
  2212.         block 8  - length 2 blocks   - Series header
  2213.         block 10 - length 2 blocks   - Image header
  2214.         block 12 - length 4 blocks   - Raw database header
  2215.         block 16 - length 10 blocks  - Pulse sequence description
  2216.         block 26 - length 2 blocks   - Pixel map (? not ever used)
  2217.         block 28 - length 256 blocks - Image data
  2218.  
  2219.                                 As decribed earlier, the header is a fixed
  2220. length of 14336 bytes, after which the uncompressed image data starts.
  2221.  
  2222.                                 Some of the more important fields are described
  2223. here. Integers are 16 bit words (big-endian), ascii strings are Fortran style
  2224. specifications with length in bytes, and reals are 4 bytes long (see Host
  2225. machines - Data General), word offsets are numbered from 0:
  2226.  
  2227.         block 6 - study header
  2228.  
  2229.                word  32      - 5A   - Study number
  2230.                word  39      - 9A   - Date of study (dd-mmm-yy)
  2231.                word  47      - 8A   - Time of study (hh:mm:ss)
  2232.                word  54      - 32A  - Patient name
  2233.                word  70      - 12A  - Patient ID
  2234.                word  78      - 3A   - Age xxx years or xxD or W or M or Y
  2235.                word  80      - 1A   - Sex
  2236.  
  2237.         block 8 - series header
  2238.  
  2239.                word  31      - 3A   - Series number
  2240.                word  52      - 120A - Series description
  2241.                word  112     - Int  - Series type (0=normal,1=screensave,
  2242.                                           2=composite)
  2243.                word  113     - Int  - Coil type (0=head,1=body,2=surface)
  2244.                word  114     - 16A  - Coil name
  2245.                word  122     - Int  - Contrast description
  2246.                word  138     - Int  - Plane type (0=axial,1=sagittal,2=coronal,
  2247.                                           3=oblique,4=screen save)
  2248.                word  147     - Int  - Image mode (0=2D single,1=2D multiple,
  2249.                                           2=3D volume,3=cine,4=spectroscopy)
  2250.                word  148     - Int  - Field strength (gauss)
  2251.                word  149     - Int  - Pulse sequence (0=memp,1=ir,2=ps,3=rm,
  2252.                                           4=rmge,5=gre,6=vemp,7=mpgr,8=mpgrv,
  2253.                                           9=mpirs,10=mpiri,11=3d/gre,
  2254.                                           12=cine/gre,13=spgr,14=sspf,
  2255.                                           15=cin/spgr,16=3d/spgr,17=fse,
  2256.                                           18=fve,19=fspgr,20=fgr,21=fmpspgr,
  2257.                                           22=fmpgr,23=fmpir,24=probe.s,
  2258.                                           25=probe.p)
  2259.                word  150     - Int  - Pulse sequence subtype (0=chopper)
  2260.                word  151     - Real - Field of view mm
  2261.                word  153     - Real - Center (3 values;R+L-,A+P-,S+I-)
  2262.                word  159     - Int  - Orientation (0=supine,1=prone,2=Lt,3=Rt)
  2263.                word  160     - Int  - Position (0=head first,1=feet first)
  2264.                word  161     - 32A  - Longitudinal anatomical reference
  2265.                word  177     - 32A  - Vertical anatomical reference
  2266.                word  199     - Int  - Scan matrix X
  2267.                word  200     - Int  - Scan matrix Y
  2268.                word  201     - Int  - Image matrix
  2269.  
  2270.         block 10 - image header
  2271.  
  2272.                word  44      - Int  - Image number
  2273.                word  73      - Real - Image location
  2274.                word  75      - Real - Table position
  2275.                word  77      - Real - Image thickness
  2276.                word  79      - Real - Image spacing
  2277.                word  82      - Real - TR
  2278.                word  86      - Real - TE
  2279.                word  88      - Real - TI
  2280.                word  98      - Int  - Number of echos
  2281.                word  99      - Int  - Echo number
  2282.                word  101     - Int  - NEX (if not fractional)
  2283.                word  146     - Real - NEX
  2284.                word  146     - Int  - Flip angle
  2285.  
  2286.                       3.3.1.1.2 GE MR Signa 3.x,4.x Tape format
  2287.  
  2288.                       3.3.1.1.3 GE MR Signa 3.x,4.x Raw data
  2289.  
  2290.               3.3.1.2 GE MR Signa 5.x - Genesis
  2291.  
  2292.                       References (see the GEMS image format information
  2293. contacts section):
  2294.  
  2295.                                 - 46-021861 Image Data Format
  2296.                                 - 46-021863 Optical Disk Raw Partition
  2297.                                 - 46-021864 Image Extract Tool
  2298.                                 - 46-021865 DAT Archive Format
  2299.  
  2300.                       General Electric now uses the same Sun based architecture
  2301. for its HighLite Advantage (HLA) and High Speed Advantage (HSA) CT and Signa 5X
  2302. MR family, referred to as Genesis. The general details of this scheme will be
  2303. discussed here, as well as the description of the MR image header. Specifics
  2304. related to the CT modality are described elsewhere.
  2305.  
  2306.                       3.3.1.2.1 GE MR Signa 5.x Image data
  2307.  
  2308.                                 Genesis is a system running under SunOS 3.5G
  2309. (NOT Solaris) on, believe it or not, a sun3 68000 architecture, not a sun4
  2310. sparc.
  2311.  
  2312.                                 It would appear that unlike in the previous
  2313. Data General based system, the active database is stored as one large
  2314. monolithic file in a raw partition, which doesn't make it very easy to extract
  2315. single imgaes. Fortunately, GE have saved the day by kindly providing, and
  2316. thoroughly documenting in the material that they send you when you ask for the
  2317. image file format, an Image Extract Tool that lives in "/usr/g/insite/bin" and
  2318. is called "ximg". To see what options are available just type "ximg -h" for
  2319. help. Note that ximg's default is to strip out the patient's name and ID number
  2320. which is annoying, so don't forget the "-s" flag. The default directory to put
  2321. the extracted images in is "/usr/g/insite/tmp". The input names to select
  2322. images in silent (non-menu) mode are of the following form:
  2323.  
  2324.                 EeeeeeSsssIiii
  2325.  
  2326.                 eeeee =  exam number   or "all"
  2327.                 sss   =  series number or "all"
  2328.                 iii   =  image number  or "all"
  2329.  
  2330. and the resultant filenames are the same with an extension of ".MR" or ".CT"
  2331. depending. For example:
  2332.  
  2333.                 % /usr/g/insite/bin/ximg -i e673s1i1 -st
  2334.                 % ls -l /usr/g/insite/tmp
  2335.                 E673S1I1.MR
  2336.  
  2337. which extracts the selected image in silent mode (-i) without stripping the
  2338. identification (-s) in rectangular (-t) mode, ie. not compressed or packed.
  2339.  
  2340.                                 One nifty feature that allows you to keep up to
  2341. date with the latest version header contents is the "-g" switch which invokes
  2342. the GenIncl utility that produces a file called "imageFileOffsets.h" that lists
  2343. the type and offsets of each field in the header ! Remarkable, huh ?
  2344.  
  2345.                                 How does one get access to the operating system
  2346. on the Signa ? Let me count the ways. First, from the Advantage console one can
  2347. just call up a command shell from the Utilities menu, or one can invoke the Ftp
  2348. option uner Networks and then use the "!" command to ftp, which like in many
  2349. Unix tools, spawns a shell. Or from another workstation on the network one can
  2350. just telnet or rsh across. If you are connected using an Advantage Windows
  2351. workstation you can pull up a command shell by using the right menu button with
  2352. the cursor on the desktop. Doing a few "cat /etc/hosts" around the place will
  2353. let you know what all the machines are called.
  2354.  
  2355. One can also access the console directly from the plasma screen by toggling
  2356. "L1-B" on or off.
  2357.  
  2358.                                 Once you have extracted them, the Genesis file
  2359. contains headers consisting of several components in common with CT and then a
  2360. specific CT or MR header. The file is structured as a "block type" header with
  2361. a brief "control header" of fixed size, followed by a bunch of optional
  2362. headers, some of which reflect internal database structures and are of no
  2363. interest, others (such as the suite/exam/series/image) headers that contain
  2364. descriptive and identification information, and two that are of importance for
  2365. deciphering the pixel data (unpack control & compression control). Some of the
  2366. more important fields are described here:
  2367.  
  2368.         Sun3 Sun Data Types:
  2369.  
  2370.            - short is 16 bits
  2371.            - int is 32 bits
  2372.            - float is 32 bits IEEE
  2373.            - double is 64 bits IEEE
  2374.            - byte offsets from 0 start of file
  2375.            - length ==0 means header absent/empty
  2376.  
  2377.         control header (offset 0):
  2378.  
  2379.                 0   - int      - magic number = 0x494d4746 = "IMGF"
  2380.                 4   - int      - byte displacement to pixel data
  2381.                 8   - int      - width
  2382.                 12  - int      - height
  2383.                 16  - int      - depth (bits)
  2384.                 20  - int      - compression (0=asis,1=rectangular,2=packed,
  2385.                                  3=compressed,4=compressed&packed)
  2386.                 32  - int      - background shade to use for non-image
  2387.                 54  - u_short  - 16 bit end_around_carry sum of pixels
  2388.                 56  - int      - ptr to unique image identifier
  2389.                 60  - int      - length of unique image identifier
  2390.                 64  - int      - ptr to unpack header
  2391.                 68  - int      - length of unpack header
  2392.                 72  - int      - ptr to compression header
  2393.                 76  - int      - length of compression header
  2394.                 80  - int      - ptr to histogram header
  2395.                 84  - int      - length of histogram header
  2396.                 88  - int      - ptr to text plane
  2397.                 92  - int      - length of text plane
  2398.                 96  - int      - ptr to graphics plane
  2399.                 100 - int      - length of graphics plane
  2400.                 104 - int      - ptr to data base header
  2401.                 108 - int      - length of data base header
  2402.                 112 - int      - value to add to stored pixels
  2403.                 116 - int      - ptr to user defined data
  2404.                 120 - int      - length of user defined data
  2405.                 124 - int      - ptr to suite header
  2406.                 128 - int      - length of suite header
  2407.                 132 - int      - ptr to exam header
  2408.                 136 - int      - length of exam header
  2409.                 140 - int      - ptr to series header
  2410.                 144 - int      - length of series header
  2411.                 148 - int      - ptr to image header
  2412.                 152 - int      - length of image header
  2413.  
  2414.         unpack header:
  2415.  
  2416.                 // used when compression is packed, or compressed & packed
  2417.                 // contains perimeter encoding map ... cf. GE 9800
  2418.  
  2419.                 struct {
  2420.                         short pixels_to_left_of_line;
  2421.                         short pixels_in_stored_line;
  2422.                 } table [height_of_image];
  2423.  
  2424.         compression header:
  2425.  
  2426.                 Not necessary for decompressing entire image ... rather it
  2427.                 contains seeds for various "strips" of the image to allow
  2428.                 jumping into the compressed pixel data ... see the GE docs.
  2429.  
  2430.         histogram header:
  2431.  
  2432.                 Contains statistical information for determining optimum
  2433.                 windowing ... see the GE docs and GenIncl produced header
  2434.  
  2435.         exam header:
  2436.  
  2437.                 0   - char[4]  - suite ID
  2438.                 8   - u_short  - exam number
  2439.                 84  - char[13] - patient ID
  2440.                 97  - char[25] - patient name
  2441.                 122 - short    - patient age
  2442.                 126 - short    - patient sex
  2443.                 305 - char[3]  - exam type - "MR" or "CT"
  2444.  
  2445.         series header:
  2446.  
  2447.                 10  - short    - series number
  2448.                 84  - char[3]  - anatomical reference
  2449.                 92  - char[25] - scan protocol name
  2450.  
  2451.         image header - for MR (1022 bytes long):
  2452.  
  2453.                 12  - short    - image number
  2454.                 26  - float    - slice thickness mm
  2455.                 30  - short    - matrix size - X
  2456.                 32  - short    - matrix size - Y
  2457.                 34  - float    - display field of view - X (mm)
  2458.                 38  - float    - display field of view - Y (mm)
  2459.                 42  - float    - image dimension - X
  2460.                 46  - float    - image dimension - Y
  2461.                 50  - float    - pixel size - X
  2462.                 54  - float    - pixel size - Y
  2463.                 72  - char[17] - iv contrast agent
  2464.                 89  - char[17] - oral contrast agent
  2465.                 194 - int      - repetition time(usec)
  2466.                 198 - int      - inversion time(usec)
  2467.                 202 - int      - echo time(usec)
  2468.                 210 - short    - number of echoes
  2469.                 212 - short    - echo number
  2470.                 218 - float    - NEX
  2471.                 308 - char[33] - pulse sequence name
  2472.                 362 - char[17] - coil name
  2473.                 640 - short    - ETL for FSE
  2474.  
  2475.                                 So much for the headers. Now how does one deal
  2476. with the image data ? The easiest way of course is to save it as "rectangular",
  2477. that is not compressed and not packed. If you want to do it the hard way, then
  2478. if the data is packed, then unpack it, then if it is compressed, uncompress it.
  2479. The packing is a perimeter encoding method like the CT 9800, except that
  2480. instead of using a map containing just the width of the stored data, both a
  2481. left offset and a width are stored for each row, as described in the "unpack
  2482. header". The compression scheme is DPCM again but with a difference ... three
  2483. alternative encodings are possible ... a 7 bit difference (one byte), a 14 bit
  2484. difference (two bytes), or a flag byte followed by a true 16 bit pixel value
  2485. (three bytes). Presumably this scheme was devised to handle a greater dynamic
  2486. range than in the CT 9800 scheme when necessary, but produce a similar degree
  2487. of compression otherwise.
  2488.  
  2489.              0  +/- <------ 6 bits ------->
  2490.             _______________ _______________
  2491.            |   |   |   |   |   |   |   |   |
  2492.            |_______________|_______________|
  2493.              7           4   3           0
  2494.  
  2495.     or
  2496.  
  2497.              1   0  +/- <------------------ 13 bits ---------------------->
  2498.             _______________ _______________ _______________ _______________
  2499.            |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
  2500.            |_______________|_______________|_______________|_______________|
  2501.             15           12 11           8   7           4   3           0
  2502.  
  2503.     or
  2504.  
  2505.              1   1  <----- discarded ----->  Then two bytes for 16 bit word
  2506.             _______________ _______________
  2507.            |   |   |   |   |   |   |   |   |
  2508.            |_______________|_______________|
  2509.              7           4   3           0
  2510.  
  2511.                                   The following piece of C++ code pulled out of
  2512. a Genesis to DICOM translator will give you the general idea. Note that the
  2513. perimeter encoding map has already been read in (map_left and map_wide). Note
  2514. in particular the need to deal with sign extension of the difference values.
  2515. Unlike the CT 9800 example earlier, one has to use a separate loop for the
  2516. compressed data stream as all 16 bits are potentially in use.
  2517.  
  2518. static void
  2519. copygenesisimage(ifstream& instream,DC3ofstream& outstream,
  2520.     Uint16 width,Uint16 height,Uint16 depth,Uint16 compress,
  2521.     Uint16 *map_left,Uint16 *map_wide)
  2522. {
  2523.     unsigned row;
  2524.     Int16 last_pixel=0;
  2525.     for (row=0; row<height; ++row) {
  2526.         unsigned j;
  2527.         unsigned start;
  2528.         unsigned end;
  2529.  
  2530.         if (compress == 2 || compress == 4) { // packed/compacked
  2531.             start=map_left[row];
  2532.             end=start+map_wide[row];
  2533.         }
  2534.         else {
  2535.             start=0;
  2536.             end=width;
  2537.         }
  2538.         // Pad the first "empty" part of the line ...
  2539.         for (j=0; j<start; j++) outstream.write16(0);
  2540.  
  2541.         if (compress == 3 || compress == 4) { // compressed/compacked
  2542.             while (start<end) {
  2543.                 unsigned char byte;
  2544.                 instream.read(&byte,1);
  2545.                 if (!instream) return;
  2546.                 if (byte & 0x80) {
  2547.                     unsigned char byte2;
  2548.                     instream.read(&byte2,1);
  2549.                     if (!instream) return;
  2550.                     if (byte & 0x40) {    // next word
  2551.                         instream.read(&byte,1);
  2552.                         if (!instream) return;
  2553.                         last_pixel=
  2554.                             (((Uint16)byte2<<8)+byte);
  2555.                     }
  2556.                     else {            // 14 bit delta
  2557.                         if (byte & 0x20) byte|=0xe0;
  2558.                         else byte&=0x1f;
  2559.                         last_pixel+=
  2560.                             (((Int16)byte<<8)+byte2);
  2561.                     }
  2562.                 }
  2563.                 else {                // 7 bit delta
  2564.                     if (byte & 0x40) byte|=0xc0;
  2565.                     last_pixel+=(signed char)byte;
  2566.                 }
  2567.                 outstream.write16((Uint16)last_pixel);
  2568.                 ++start;
  2569.             }
  2570.         }
  2571.         else {
  2572.             while (start<end) {
  2573.                 Uint16 u=readUint16(instream);
  2574.                 if (!instream) return;
  2575.                 outstream.write16(u);
  2576.                 ++start;
  2577.             }
  2578.         }
  2579.  
  2580.         // Pad the last "empty" part of the line ...
  2581.         for (j=end; j<width; j++) outstream.write16(0);
  2582.     }
  2583. }
  2584.  
  2585.                       3.3.1.2.2 GE MR Signa 5.x Archive format
  2586.  
  2587.                                 GE supply both DAT tape and 5.25" write once
  2588. and rewriteable optical disk drives.
  2589.  
  2590.                                 The optical drives are made by Pioneer. This is
  2591. an unfortunate choice as the media format is incompatible with any other vendor
  2592. so you need a Pioneer (DEC 702 ?) drive to read it. The person who made this
  2593. choice tells me the fundamental technology seemed more sound on the Pioneer
  2594. side than from the other companies, and there were also two sources for the
  2595. Pioneer and no one was producing any other interchangeable systems.
  2596. Interestingly Siemens made the same choice.
  2597.  
  2598.                                 As for the file system, there seem to be two
  2599. methods in use. One is to use a monolithic file system on a raw partition. I
  2600. haven't seen it but there is now apparently a document from GE available
  2601. describing this format "direction 46-021863 CT HLA/HSA MR Signa 5.x Optical
  2602. Disk Raw Partition". See the GEMS image format information contacts section.
  2603. This is what is used on the MOD.
  2604.  
  2605.                                 For the WORM, a different choice was made, to
  2606. use a commericially available filesystem product that made the disk look like a
  2607. unix filesystem with the ability to store and replace and update on a write
  2608. once medium. It is available from DoroTech of France and called DoroFile.
  2609. Because it is a commerical product, GE are restrained from disclosing the file
  2610. structure.
  2611.  
  2612.                                 The formats have been reverse engineered by
  2613. Jeffrey Siegel of Evergreen Technologies however, and he can supply you with
  2614. software to read both GE and Siemens MOD and WORM formats, on a PC or Mac for
  2615. $495. He can sell you the drive as well if necessary for $2800. It can run on a
  2616. Mac or on a PC with an Adaptec card and driver. Some driver software for the
  2617. Pioneer drive is also available from Corel.
  2618.  
  2619.                                 If you have an GE Advantage Windows
  2620. workstation, there is an optional MOD/WORM drive and software for that.
  2621.  
  2622.                                 As far as the DAT format is concerned, this
  2623. format is available though I don't have it (yet). Examining a tape reveals the
  2624. following however:
  2625.  
  2626.         - One file used as a tape label (single 8192 byte record)
  2627.         - Tape mark
  2628.         - Series of image files separated by tape marks
  2629.  
  2630.                                 There does not seem to be a tape directory per
  2631. se.
  2632.  
  2633.                                 Each image file is a modification of the format
  2634. created by the ximg utility to extract images from the database.
  2635.  
  2636.                                 The ximg format is described as a file header
  2637. beginning with the magic number "IMGF" and then a short header that contains
  2638. byte offsets to the image data, and various suite, exam, series and image
  2639. headers.
  2640.  
  2641.                                 The DAT images are NOT organized like this, but
  2642. do use exactly the same headers and image data layout (and compression
  2643. schemes). The difference is in the order of the header.
  2644.  
  2645.                                 The first record of the file is 3180 bytes long
  2646. and contains:
  2647.  
  2648.         0-113      suite  header   (length 114)
  2649.         114-1137   exam   header   (length 1024)
  2650.         1138-2157  series header   (length 1020)
  2651.         2158-3079  image  header   (length 1022 for mr)
  2652.                                    (length 1020 for ct)
  2653.         3080-3179  zero padding
  2654.  
  2655.                                 NB. this record DOES NOT begin with "IMGF" !
  2656.  
  2657.                                 The second record of the file is 5208 bytes
  2658. long (in my case anyway) and followed by 8192 byte records and a final record
  2659. of whatever is left over.
  2660.  
  2661.                                 This 5208 byte record contains a "proper"
  2662. header in the ximg output format and starts with "IMGF". The subsequent byte
  2663. offsets to the image data, compression headers, histogram header etc. are
  2664. correct and offset from the beginning of this second record and NOT the start
  2665. of the file. Furthermore the pointers to those headers in the first record
  2666. (suite, exam, series and image headers) are TOTALLY WRONG and must be ignored
  2667. ... I don't know how their values are derived but it is not obvious.
  2668.  
  2669.                                 I presume that the files were reorganized this
  2670. way in order to make it easy for simple utilities to access the demographic
  2671. data to index the tape or something. Anyway it is easy to rewrite utilities
  2672. that read the ximg format to take all this into account and extract the tags
  2673. and the
  2674. images.
  2675.  
  2676.                                 The image data byte offset (eg. 5204) in the
  2677. file header is 4 bytes too short, eg. 3180 + 5204 + 4 -> 3188 which is where
  2678. the image data starts.
  2679.  
  2680.                                 If you are not familiar with the Genesis ximg
  2681. format, on a Signa at least, you can run "/usr/g/insite/bin/ximg -g" to extract
  2682. a prototype C header file describing the file format.
  2683.  
  2684.                       3.3.1.2.3 GE MR Signa 5.x Raw data
  2685.  
  2686.               3.3.1.3 GE MR Max
  2687.  
  2688.                       References (see the GEMS image format information
  2689. contacts section):
  2690.  
  2691.                                 - 46-021856 CT Pace Image Data Format
  2692.                                 - 46-021862 MR Max  Image Data Format
  2693.  
  2694.                       I do not have any MR Max images to try this on, but am
  2695. told that the format is essentially the same as the CT GE CT Pace, with some
  2696. different fields in the image header:
  2697.  
  2698.     For MR only:
  2699.  
  2700.         0xc0    string  5       Tilt ordered by user Axis+/-Angle [xx+/-xx]
  2701.         0x100   string  2       Echo number
  2702.         0x102   string  2       Number of echoes
  2703.         0x104   string  2       Slice number
  2704.         0x106   string  2       Number of slices
  2705.         0x108   string  2       Number of excitations
  2706.         0x10a   string  5       Repetition time ms
  2707.         0x110   string  5       Inversion time ms
  2708.         0x115   string  5       Echo time ms
  2709.         0x130   string  4       Magnetic flux density (T)
  2710.  
  2711.               3.3.1.4 GE MR Vectra
  2712.  
  2713.                       Same comments as pertain to the Sytec/Pace entry in the
  2714. CT section. A few sample files on a floppy would be much appreciated.
  2715.  
  2716.         3.3.2 Siemens MR
  2717.  
  2718.               3.3.2.1 Siemens Magnetom GBS II
  2719.  
  2720.                       - it is NOT in SPI format
  2721.                       - seems to be fixed format
  2722.                       - files 133120 bytes
  2723.                       - image pixel data 256*256*2 little endian
  2724.                       - image pixel offset 4096 bytes
  2725.  
  2726.               3.3.2.2 Siemens Magnetom SP
  2727.  
  2728.                       - it IS in SPI format (Release 1)
  2729.                       - ACR/NEMA data stream starts immediately
  2730.                       - big-endian byte order
  2731.                       - lots of private groups containing SPI & MR specific
  2732.                         tags, but much useful information in standard tags
  2733.                       - 12 bit allocated data in 16 bits stored, high bit 11
  2734.                       - after ACR/NEMA data, trailing garbage
  2735.  
  2736.                       Similar story as for the Siemens Somatom Plus. Siemens
  2737. version of SPI, containing the following private data elements. Note that there
  2738. is overlayed data in the high four bytes of the image pixel data, and that
  2739. there seems to be a bunch of padding in the middle. The intent seems to be to
  2740. store the "original header" and the image pixel data at accessible, presumably
  2741. standard locations, presumably indexed by the byte offsets and lengths
  2742. described in group 9. This is a shame because it seems that none of the really
  2743. interesting MR attributes have been included in the SPI form, although SPI
  2744. private tags are available for lots of MR parameters. This is in contrast to
  2745. the Siemens Magnetom Impact which contains more interesting SPI tags.
  2746.  
  2747. SPI private tags:
  2748.  
  2749. (0009,0010)                                      <SPI RELEASE 1>
  2750. (0009,0011)                                        <SIEMENS MED>
  2751. (0009,1010) SPI RELEASE 1   Comments        <SPI VERSION  01.00>
  2752. (0009,1015) SPI RELEASE 1   UID     <000S00MR001994122719161248>
  2753. (0009,1110) SIEMENS MED     RecognitionCode             <MR 2.0>
  2754. (0009,1130) SIEMENS MED     ByteOffsetOfOriginalHeader   [0x800]
  2755. (0009,1131) SIEMENS MED     LengthOfOriginalHeader      [0x1600]
  2756. (0009,1140) SIEMENS MED     ByteOffsetOfPixelmatrix     [0x2000]
  2757. (0009,1141) SIEMENS MED     LengthOfPixelmatrixInBytes [0x20000]
  2758.  
  2759. (0011,0010)                                      <SPI RELEASE 1>
  2760.  
  2761. (0021,0010)                                        <SIEMENS MED>
  2762. (0021,1010) SIEMENS MED     Zoom                          <01.0>
  2763. (0021,1011) SIEMENS MED     Target                            <>
  2764. (0021,1020) SIEMENS MED     ROIMask                     [0x0000]
  2765.  
  2766. Overlay descriptions (overlays already in image pixel data):
  2767.  
  2768. (6000,0010)                 OverlayRows                 [0x0100]
  2769. (6000,0011)                 OverlayColumns              [0x0100]
  2770. (6000,0040)                 ROI                              <R>
  2771. (6000,0050)                 OverlayOrigin        [0x5c31,0x2031]
  2772. (6000,0060)                 OverlayCompressionCode        <NONE>
  2773. (6000,0100)                 OverlayBitsAllocated        [0x0010]
  2774. (6000,0102)                 OverlayBitPosition          [0x000c]
  2775. (6000,0110)                 OverlayFormat                 <RECT>
  2776. (6000,0200)                 OverlayLocation             [0x7fe0]
  2777.  
  2778. (6002,0010)                 OverlayRows                 [0x0100]
  2779. (6002,0011)                 OverlayColumns              [0x0100]
  2780. (6002,0040)                 ROI                              <R>
  2781. (6002,0050)                 OverlayOrigin        [0x5c31,0x2031]
  2782. (6002,0060)                 OverlayCompressionCode        <NONE>
  2783. (6002,0100)                 OverlayBitsAllocated        [0x0010]
  2784. (6002,0102)                 OverlayBitPosition          [0x000d]
  2785. (6002,0110)                 OverlayFormat                 <RECT>
  2786. (6002,0200)                 OverlayLocation             [0x7fe0]
  2787.  
  2788. (6004,0010)                 OverlayRows                 [0x0100]
  2789. (6004,0011)                 OverlayColumns              [0x0100]
  2790. (6004,0040)                 ROI                              <R>
  2791. (6004,0050)                 OverlayOrigin        [0x5c31,0x2031]
  2792. (6004,0060)                 OverlayCompressionCode        <NONE>
  2793. (6004,0100)                 OverlayBitsAllocated        [0x0010]
  2794. (6004,0102)                 OverlayBitPosition          [0x000e]
  2795. (6004,0110)                 OverlayFormat                 <RECT>
  2796. (6004,0200)                 OverlayLocation             [0x7fe0]
  2797.  
  2798. (6006,0010)                 OverlayRows                 [0x0100]
  2799. (6006,0011)                 OverlayColumns              [0x0100]
  2800. (6006,0040)                 ROI                              <R>
  2801. (6006,0050)                 OverlayOrigin        [0x5c31,0x2031]
  2802. (6006,0060)                 OverlayCompressionCode        <NONE>
  2803. (6006,0100)                 OverlayBitsAllocated        [0x0010]
  2804. (6006,0102)                 OverlayBitPosition          [0x000f]
  2805. (6006,0110)                 OverlayFormat                 <RECT>
  2806. (6006,0200)                 OverlayLocation             [0x7fe0]
  2807.  
  2808. More SPI private stuff ... padding and original header ...
  2809.  
  2810. (7001,0010)                                        <SIEMENS MED>
  2811. (7001,1010) SIEMENS MED     Dummy
  2812.  
  2813. (7003,0010)                                        <SIEMENS MED>
  2814. (7003,1010) SIEMENS MED     Header
  2815.  
  2816. (7005,0010)                                        <SIEMENS MED>
  2817. (7005,1010) SIEMENS MED     Dummy
  2818.  
  2819. NB. Siemens VR for OverlayOrigin seems to be wrong. ACR/NEMA says it should be
  2820. binary, but [0x5c31,0x2031] translates to a string <1\1> which seems more
  2821. plausible!
  2822.  
  2823.                       The models in this family include the SP (which the SPI
  2824. describes as a GBS 3 !), the SP/4000 which got a faster Vax, and the new
  2825. Vision. I have only examined the files from the SP so far, but they are bog
  2826. standard SPI with no surprises, and I have no reason to doubt the same is true
  2827. of the later models.
  2828.  
  2829.                       The usual Vax VMS problems apply. Use the console serial
  2830. port on the back of the Vax. There is a C compiler supplied so you can compile
  2831. the more recent C version of kermit ... although the old Bliss version works
  2832. fine. Unlike the Philips, there is no problem with CR delimited file attributes
  2833. being set on the binary files. Kermit transfers are glacially slow as always.
  2834.  
  2835.               3.3.2.3 Siemens Magnetom Impact
  2836.  
  2837.                       - it IS in SPI format (Release 1, based on ACR/NEMA 2.0)
  2838.                       - skip the 1st 128 bytes to get to ACR/NEMA data stream
  2839.                            (may be artifact of transfer process)
  2840.                       - big-endian byte order
  2841.                       - lots of private groups containing SPI & MR specific
  2842.                         tags, but much useful information in standard tags
  2843.                       - 12 bit allocated data in 16 bits stored, high bit 11
  2844.                       - after ACR/NEMA data, file is padded to 512 byte mark
  2845.  
  2846.                       Siemens version of SPI, containing the following private
  2847. data elements. More comprehensive attributes than the Siemens Somatom Plus or
  2848. Siemens Magnetom SP. There is no overlayed data in the high four bytes of the
  2849. image pixel data, and that there is no padding in the middle or "original
  2850. header", or byte offsets and lengths described in group 9. Only some of the
  2851. more significant elements are described here in the interest of brevity.
  2852. Sources for a more comprehensive dictionary are described under SPI.
  2853.  
  2854. SPI private tags:
  2855.  
  2856. (0009,0010)                 PrivateCreator                <SPI RELEASE 1>
  2857. (0009,0012)                 PrivateCreator          <SIEMENS CM VA0  CMS>
  2858. (0009,0013)                 PrivateCreator          <SIEMENS CM VA0  LAB>
  2859. (0009,1010) SPI RELEASE 1   Comments                 <SPI VERSION  01.00>
  2860. (0009,1015) SPI RELEASE 1   UID              <000S00MR001994021614211710>
  2861. (0009,1040) SPI RELEASE 1   DataObjectSubtype                    [0x0000]
  2862. (0009,1041) SPI RELEASE 1   DataObjectSubtype                  <MRUPNONE>
  2863. (0009,1210) SIEMENS CM VA0  CMS  StorageMode                   <EXPANDED>
  2864. (0009,1212) SIEMENS CM VA0  CMS  EvaluationMask                  [0x0000]
  2865. (0009,1226) SIEMENS CM VA0  CMS  LastMoveDate                <1994.02.16>
  2866. (0009,1227) SIEMENS CM VA0  CMS  LastMoveTime              <13:41:52.000>
  2867. (0009,1320) SIEMENS CM VA0  LAB  HeaderVersion                      <VB6>
  2868.  
  2869. (0011,0011)                 PrivateCreator          <SIEMENS CM VA0  CMS>
  2870. (0011,1110) SIEMENS CM VA0  CMS RegistrationDate             <1994.02.16>
  2871. (0011,1111) SIEMENS CM VA0  CMS RegistrationTime          <113:43:49.000>
  2872. (0011,1123) SIEMENS CM VA0  CMS UsedPatientWeight                <000050>
  2873.  
  2874. (0019,0010)                 PrivateCreator          <SIEMENS CM VA0  CMS>
  2875. (0019,0012)                 PrivateCreator          <SIEMENS MR VA0  GEN>
  2876. (0019,0014)                 PrivateCreator         <SIEMENS MR VA0  COAD>
  2877. (0019,0015)                 PrivateCreator         <SIEMENS CM VA0  ACQU>
  2878. (0019,1060) SIEMENS CM VA0  CMS NumberOfDataBytes                <310127>
  2879. (0019,1220) SIEMENS MR VA0  GEN NominalNumberOfFourierLines      <000128>
  2880. (0019,1226) SIEMENS MR VA0  GEN NumberOfFourierLinesafterZero    <000063>
  2881. (0019,1228) SIEMENS MR VA0  GEN FirstMeasuredFourierLine         <-00064>
  2882. (0019,1230) SIEMENS MR VA0  GEN AcquisitionColumns               <000512>
  2883. (0019,1231) SIEMENS MR VA0  GEN ReconstructionColumns            <000512>
  2884. (0019,1250) SIEMENS MR VA0  GEN CurrentNumberOfAverages          <000010>
  2885. (0019,1260) SIEMENS MR VA0  GEN FlipAngle                <00.8000000+E00>
  2886. (0019,1290) SIEMENS MR VA0  GEN NumberOfSaturationRegions        <000000>
  2887. (0019,1294) SIEMENS MR VA0  GEN ImageRotationAngle       <00.0000000+E00>
  2888. (0019,1412) SIEMENS MR VA0  COAD MagneticFieldStrength   <009.500702E-01>
  2889. (0019,1456) SIEMENS MR VA0  COAD ReceiverFilterFrequency         <500000>
  2890.  
  2891. (0021,0010)                     PrivateCreator              <SIEMENS MED>
  2892. (0021,0011)                     PrivateCreator      <SIEMENS CM VA0  CMS>
  2893. (0021,0013)                     PrivateCreator      <SIEMENS MR VA0  GEN>
  2894. (0021,1010) SIEMENS MED Zoom                                           <>
  2895. (0021,1011) SIEMENS MED Target                                         <>
  2896. (0021,1020) SIEMENS MED ROIMask                                     [0x0]
  2897. (0021,1120) SIEMENS CM VA0  CMS FoV        <00.2050000+E200\.2050000+E20>
  2898. (0021,1122) SIEMENS CM VA0  CMS ImageMagnificationFactor <001.000000E+00>
  2899. (0021,1130) SIEMENS CM VA0  CMS ViewDirection                      <HEAD>
  2900. (0021,1132) SIEMENS CM VA0  CMS RestDirection                      <HEAD>
  2901. (0021,1160) SIEMENS CM VA0  CMS ImagePosition        <000.000000E+00\.\.>
  2902. (0021,1161) SIEMENS CM VA0  CMS ImageNormal          <-00.000000E+00\.\.>
  2903. (0021,1163) SIEMENS CM VA0  CMS ImageDistance            <002.787480E+01>
  2904. (0021,116a) SIEMENS CM VA0  CMS ImageRow             <001.000000E+00\.\.>
  2905. (0021,116b) SIEMENS CM VA0  CMS ImageColumn          <000.000000E+00\.\.>
  2906. (0021,1170) SIEMENS CM VA0  CMS PatientOrientationSet1          <R\AH\HP>
  2907. (0021,1171) SIEMENS CM VA0  CMS PatientOrientationSet2          <L\PF\FA>
  2908. (0021,1180) SIEMENS CM VA0  CMS StudyName    <routine_brain/6_opt3_mprag>
  2909. (0021,1182) SIEMENS CM VA0  CMS StudyType                           <MEA>
  2910. (0021,1334) SIEMENS MR VA0  GEN NumberOf3DImagePartitions        <000128>
  2911. (0021,1339) SIEMENS MR VA0  GEN SlabThickness            <001.800000E+02>
  2912. (0021,1342) SIEMENS MR VA0  GEN CurrentSliceNumber               <000001>
  2913. (0021,1343) SIEMENS MR VA0  GEN CurrentGroupNumber               <000001>
  2914. (0021,134f) SIEMENS MR VA0  GEN OrderofSlices                 <ASCENDING>
  2915. (0021,1370) SIEMENS MR VA0  GEN NumberOfEchoes                   <000001>
  2916.  
  2917. (0029,0011)                     PrivateCreator      <SIEMENS CM VA0  CMS>
  2918. (0029,1120) SIEMENS CM VA0  CMS PixelQualityCode         <NONE\NONE\NONE>
  2919.  
  2920. (0051,0010)                     PrivateCreator      <SIEMENS CM VA0  CMS>
  2921. (0051,1010) SIEMENS CM VA0  CMS ImageText                           <...>
  2922.  
  2923.               3.3.2.4 Siemens Magnetom Vision
  2924.  
  2925.                       Unknown. Bound to be SPI but don't know what attributes
  2926. are present.
  2927.  
  2928.         3.3.3 Philips MR
  2929.  
  2930.               3.3.3.1 Philips Gyroscan S5
  2931.  
  2932.                       - can export as ACR/NEMA (actually SPI) files
  2933.                       - little endian byte order
  2934.                       - 12 bit packed data
  2935.  
  2936.                       This description pertains to "exported ACR/NEMA", not the
  2937. native image files, which I am not familiar with. In fact I am not even sure in
  2938. which directory they live.
  2939.  
  2940.                       Use the ADMIN menu on the operator's console to find the
  2941. import/export ACR/NEMA utility, with which you can select an exam, series or
  2942. image to export as an ACR/NEMA file. The default directory is the GYROVIEW home
  2943. directory, which is already pretty cluttered so it is better to make another
  2944. subdirectory like "ANI" to keep exported files in. The exported files have huge
  2945. names composed of identification information, but all have a ".ANI" extension.
  2946. For example:
  2947.  
  2948.         DIR SYS$SYSROOT:[GYROSCAN]*.ANI;*
  2949.  
  2950.         SMITH__FA02010801010001.ANI;1
  2951.  
  2952.                       These files are stored as, wait for it, fixed length 512
  2953. byte records, with the "carriage return carriage control" record attributes set
  2954. from some bizarre reason, which totally messes up kermit which starts messing
  2955. with adding and changing CR/LF characters. See the Vax diatribe below for a
  2956. method of getting around this, by using DUMP as a poor man's uuencode
  2957. permitting ascii transfer. Unfortunately the nature of fixed length records
  2958. under VMS means that the last record will be padded out to 512 bytes without
  2959. any indication of the "real" end-of-file. This means your ACR/NEMA reader has
  2960. to cope with trailing garbage gracefully.
  2961.  
  2962.                       Unlike the Siemens SPI files, the Philips ones are stored
  2963. in little-endian format. There is no fixed size header to skip, just go
  2964. straight into the ACR/NEMA data stream. For the image pixel data four 12 bit
  2965. words are packed without padding into 16 bit words, without any compression
  2966. sheme. See the ACR/NEMA section for description of the packing organization.
  2967. Lots of private tags are defined, but these can be ignored. Some of the
  2968. identifying tags present are as follows:
  2969.  
  2970. (0000x8,000x10) CS RecognitionCode       VR=<CS>   VL=<0xc>  <ACR-NEMA 1.0>
  2971. (0000x8,000x70) LO Manufacturer          VR=<LO>   VL=<0x8>  <Philips >
  2972. (0000x8,0x1090) LO ManufacturerModelName VR=<LO>   VL=<0x2>  <S5>
  2973. (0000x9,000x10) LT SPIComments   VR=<LT>   VL=<0xe>   <SPI Release 1 >
  2974. (000x19,000x10)                  VR=<LT>   VL=<0x14>  <PHILIPS MR R5.6/PART>
  2975.  
  2976.                       To get the files off, I plug a portable with a serial
  2977. cable into one of the spare serial ports inside one of the Vax cabinets, at
  2978. 9600 baud, and login as "GYROVIEW/NOCOM" without any password needed. This
  2979. dumps you in the same directory as the files will be stored by default. You
  2980. will probably need to set local echo on on your portable, or "SET
  2981. TERMINAL/ECHO" on the Vax.
  2982. Kermit was already loaded on my system, accessed as "RUN [SYSEXE]KERMIT". See
  2983. the Vax section later for more help.
  2984.  
  2985.               3.3.3.2 Philips Gyroscan ACS
  2986.               3.3.3.3 Philips Gyroscan T5
  2987.               3.3.3.4 Philips Gyroscan NT5 & NT15
  2988.  
  2989.         3.3.4 Picker MR - another black hole
  2990.         3.3.5 Toshiba MR - another black hole
  2991.         3.3.6 Hitachi MR - another black hole
  2992.         3.3.7 Shimadzu MR - another black hole
  2993.         3.3.8 Elscint MR - another black hole
  2994.  
  2995. The next part is part5 -  proprietary other formats.
  2996.  
  2997. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  2998. From: dclunie@flash.us.com (David A. Clunie)
  2999. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  3000. Subject: Medical Image Format FAQ, Part 5/8
  3001. Followup-To: alt.image.medical
  3002. Date: 28 Mar 1995 23:03:36 +0300
  3003. Organization: Her Master's Voice
  3004. Lines: 155
  3005. Approved: news-answers-request@MIT.EDU
  3006. Distribution: world
  3007. Expires: 28 Apr 1995 00:00:00 GMT
  3008. Message-ID: <3l9q2o$dls@flash.ksapax>
  3009. Reply-To: dclunie@flash.us.com (David A. Clunie)
  3010. NNTP-Posting-Host: flash.ksapax
  3011. Summary: This posting contains answers to the most Frequently Asked
  3012.          Question on alt.image.medical - how do I convert from image
  3013.          format X from vendor Y to something I can use ? In addition
  3014.          it contains information about various standard formats.
  3015. Xref: senator-bedfellow.mit.edu alt.image.medical:2437 comp.protocols.dicom:638 sci.data.formats:888 sci.med.informatics:1731 sci.med.radiology:1809 alt.answers:8368 comp.answers:10925 sci.answers:2333 news.answers:40888
  3016.  
  3017. Archive-name: medical-image-faq/part5
  3018. Posting-Frequency: monthly
  3019. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  3020. Version: 2.02
  3021.  
  3022.  
  3023.     3.4 Proprietary Workstations
  3024.  
  3025.         3.4.1 ISG Workstations
  3026.  
  3027.               3.4.1.1 Gyroview
  3028.  
  3029.                       The Philips Gyroview workstation is a high-resolution
  3030. graphical workstation for MR images from Gyroscan scanners, that can also
  3031. handle CT images and other modalities, and has an optional package for three
  3032. dimensional processing of images. It is based on a Sun SPARC system with
  3033. proprietary graphics hardware. The software is actually written by ISG in
  3034. Canada. The image format is an ACR/NEMA based format with various private tags
  3035. defined, and a proprietary scheme of image compression that has me stumped. I
  3036. am told by some that there is no means of telling the Gyroview not to compress
  3037. the images. I use compress in the sense that includes packing four 12 bit words
  3038. into three 16 bit big-endian words, which appears to be part of the scheme in
  3039. use. Unfortunately, some form of perimeter encoding is also in use, and I just
  3040. can't figure it out :( Some people have had more luck using "the export utility
  3041. of the Gyroview" to produce just 12 bit packed images without the perimeter
  3042. encoding. I don't know whether this is a standard feature of the workstation or
  3043. not. Others have suggested looking in the "/isg/3dmr/DataRoot/tscript/"
  3044. directory for hints.
  3045.  
  3046.                       Despite prolonged exchanges of email, and encouragement
  3047. from other individuals at ISG, it seems that the formal decision by the manager
  3048. of the customer service department, Irene Gearin, is not to release the format.
  3049. Customers may contact her at ireneg@isgtec.com for information on how to obtain
  3050. a software package called the External Developers Tool which contains a tool
  3051. called xdimage which can only be used on ISG's proprietary hardware. Whether
  3052. this is free to customers or costs extra I am not sure, but I believe a
  3053. non-disclosure agreement is required.
  3054.  
  3055.                       I would still prefer to know the format, as people keep
  3056. asking (these machines were pretty popular I gather), and if anyone has any
  3057. hints about the data format, I would appreciate them. Here follows part of a
  3058. reply to one of these people when I made an unsuccesful attempt to figure this
  3059. out:
  3060.  
  3061. Firstly, I presume this file is generated by a Philips Gyroview workstation
  3062. judging by ...
  3063.  
  3064. (0008,0070) LO Manufacturer  VR=<LO>  VL=<8>  <GYROVIEW>
  3065.  
  3066. The file says it is an MRI image ...
  3067.  
  3068. (0008,0060) CS Modality  VR=<CS>  VL=<2>  <MR>
  3069.  
  3070. and yet it is missing many of the mri attributes normally present. Also it
  3071. includes some CT specific attributes, notably ...
  3072.  
  3073. (0018,1120) DS GantryDetectorTilt  VR=<DS>  VL=<2>  < 0>
  3074.  
  3075. which is pretty weird. I presume that this format is generated by something
  3076. purely for the purposes of 3D reconstruction and only the attributes needed for
  3077. that have been preserved.
  3078.  
  3079. The image appears to be 512*512 ...
  3080.  
  3081. (0028,0010) US Rows     VR=<US>  VL=<2>  [200]
  3082. (0028,0011) US Columns  VR=<US>  VL=<2>  [200]
  3083.  
  3084. As far as the compression format is concerned ...
  3085.  
  3086. (0028,0060) CS CompressionCode  VR=<CS>  VL=<2>  < 2>
  3087.  
  3088. is not in itself a valid ACR/NEMA value, and hence some proprietary variation
  3089. is in use. The most important clue is ...
  3090.  
  3091. (0028,0040) CS ImageFormat  VR=<CS>  VL=<4>  <CIRC>
  3092.  
  3093. which is also not valid ACR/NEMA (only RECT is permitted). From this I conclude
  3094. that some sort of 'circular' perimeter encoding scheme is in use that only
  3095. sends the meaningful central pixels in each row and leaves out the background.
  3096. This is substantiated by the fact that the image pixel data seems to be
  3097. preceded by a table of 257 long words in ascending order, each value separated
  3098. by relatively low values (80-100 or so). I suspect that these are pointers into
  3099. the data to the start of each row...
  3100.  
  3101. % od -x I011_1_001 +1404 | more
  3102. 0001404  0000 0202 0000 0252 0000 02a2 0000 02f2
  3103. 0001424  0000 0342 0000 0392 0000 03e2 0000 0432
  3104. 0001444  0000 0482 0000 04d2 0000 0522 0000 0572
  3105. 0001464  0000 05c2 0000 0612 0000 0662 0000 06b3
  3106. 0001504  0000 0705 0000 0757 0000 07ab 0000 0800
  3107. 0001524  0000 0857 0000 08ae 0000 0905 0000 095e ...
  3108.  
  3109. [0000] 000514 -> 000514
  3110. [0001] 000594 -> 000080
  3111. [0002] 000674 -> 000080
  3112. [0003] 000754 -> 000080
  3113. [0004] 000834 -> 000080
  3114. [0005] 000914 -> 000080
  3115.  
  3116.  ...
  3117.  
  3118. [0155] 015322 -> 000103
  3119. [0156] 015425 -> 000103
  3120. [0157] 015527 -> 000102
  3121. [0158] 015629 -> 000102
  3122.  
  3123.  ...
  3124.  
  3125. [0254] 024484 -> 000080
  3126. [0255] 024564 -> 000080
  3127. [0256] 024564 -> 000000
  3128.  
  3129. The first of these values seems to be a pointer in two byte word units past the
  3130. table, the entries for a series of rows, then a final "257th" value that is the
  3131. same as the preceding with a difference of zero, possibly flagging the end of
  3132. the table.
  3133.  
  3134. What confuses me is the fact that there are 256 or so entries rather than 512
  3135. (number of rows), and that the difference values are relatively small for 512
  3136. columns. Perhaps each entry applies to two successive rows though this seems
  3137. rather peculiar.
  3138.  
  3139. Furthermore, if it is true that the units are two byte words, then the last
  3140. pointer value is much lower than the number of remaining bytes in the image
  3141. pixel data attribute, so what are all the other bytes for ?
  3142.  
  3143. The other thing that is going to make extraction difficult is the fact that the
  3144. data are supposed to be 12 bits packed into 16 bit words ...
  3145.  
  3146. (0028,0100) US BitsAllocated  VR=<US>  VL=<2>  [c]
  3147. (0028,0101) US BitsStored     VR=<US>  VL=<2>  [c]
  3148. (0028,0102) US HighBit        VR=<US>  VL=<2>  [b]
  3149.  
  3150. Hence 3 two byte words are used to store 4 12 bit pixels. It may not be easy to
  3151. figure out in what order this packing is performed. The ACR/NEMA standard has
  3152. an example of its intent in this case, but the byte order was never specified
  3153. for this standard, which had a 16 bit hardware data path and was not originally
  3154. intended for offline data storage in bytes, so there are a number of possible
  3155. permutations to deal with :(
  3156.  
  3157. Finally I don't know what to make of the "private" tags ...
  3158.  
  3159. Unrecognized (0029,0010)  VR=<LT>  VL=<a> <ISG shadow>
  3160. Unrecognized (0029,1070)  VR=<LT>  VL=<6> < 49128>
  3161. Unrecognized (0029,1080)  VR=<LT>  VL=<6> <123432>
  3162. Unrecognized (0029,1090)  VR=<LT>  VL=<2> < 0>
  3163.  
  3164. which presumably have some significance or they wouldn't be there !
  3165.  
  3166.     3.5 Other Proprietary Formats
  3167.  
  3168.          Empty at present.
  3169.  
  3170. The next part is part6 -  hosts & compression.
  3171.  
  3172. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  3173. From: dclunie@flash.us.com (David A. Clunie)
  3174. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  3175. Subject: Medical Image Format FAQ, Part 6/8
  3176. Followup-To: alt.image.medical
  3177. Date: 28 Mar 1995 23:03:44 +0300
  3178. Organization: Her Master's Voice
  3179. Lines: 634
  3180. Approved: news-answers-request@MIT.EDU
  3181. Distribution: world
  3182. Expires: 28 Apr 1995 00:00:00 GMT
  3183. Message-ID: <3l9q30$dmd@flash.ksapax>
  3184. Reply-To: dclunie@flash.us.com (David A. Clunie)
  3185. NNTP-Posting-Host: flash.ksapax
  3186. Summary: This posting contains answers to the most Frequently Asked
  3187.          Question on alt.image.medical - how do I convert from image
  3188.          format X from vendor Y to something I can use ? In addition
  3189.          it contains information about various standard formats.
  3190. Xref: senator-bedfellow.mit.edu alt.image.medical:2438 comp.protocols.dicom:639 sci.data.formats:889 sci.med.informatics:1732 sci.med.radiology:1810 alt.answers:8369 comp.answers:10926 sci.answers:2334 news.answers:40889
  3191.  
  3192. Archive-name: medical-image-faq/part6
  3193. Posting-Frequency: monthly
  3194. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  3195. Version: 2.02
  3196.  
  3197.  
  3198. 4.  Host Machines
  3199.  
  3200.     4.1 Data General
  3201.  
  3202.         4.1.1 Data General Data
  3203.  
  3204.               4.1.1.1 Data General Integers
  3205.  
  3206.                       Integers are 16 bit two's complement and stored in
  3207. big-endian format as on Sun Sparc and opposite to the Dec VAX.
  3208.  
  3209.               4.1.1.2 Data General Floating Point
  3210.  
  3211.                       Single precision real values are 32 bits long, in
  3212. big-endian format. The high bit is the sign bit, followed by a 7 bit excess 64
  3213. exponent (power to which 16 must be raised) then a 24 bit hexadecimally
  3214. normalized mantissa with the decimal point to the left of the most significant
  3215. bit. Double precision values just have another 32 bits tacked on the mantissa
  3216. and the same exponent format.
  3217.  
  3218.             Sign
  3219.            |<-->|<------ Exponent ------>|<--------- Mantissa -------->|
  3220.             ______________ ______________ ______________ ______________
  3221.            |              |              |              |              |
  3222.            |______________|______________|______________|______________|
  3223.             31          28 27          24 23          20 19          16
  3224.            |<----------------------- Mantissa ------------------------>|
  3225.             ______________ ______________ ______________ ______________
  3226.            |              |              |              |              |
  3227.            |______________|______________|______________|______________|
  3228.             15          12 11           8 7            4 3            0
  3229.  
  3230.                       Here is a little piece of C++ code that should run on
  3231. anything and convert Data General floats to whatever the host's floating point
  3232. format is.
  3233.  
  3234.         double    value;
  3235.         unsigned char    sign;
  3236.         Uint16        exponent;
  3237.         Uint32        mantissa;
  3238.  
  3239.         typedef struct {
  3240.             unsigned    sign : 1;
  3241.             unsigned    exponent : 7;
  3242.             unsigned    mantissa : 24;
  3243.         } DG_FLOAT;
  3244.  
  3245.         DG_FLOAT number;
  3246.  
  3247.         unsigned char buffer[4];
  3248.         instream.read(buffer,4);
  3249.         if (instream) {
  3250.             // DataGeneral is a Big Endian machine
  3251.             memcpy ((char *)(&number),buffer,4);
  3252.             sign     = number.sign;
  3253.             exponent = number.exponent;
  3254.             mantissa = number.mantissa;
  3255.  
  3256.             value = (double) mantissa / (1 << 24) *
  3257.                 pow (16.0, (long)(exponent) - 64);
  3258.             value = (sign == 0) ? value : -value;
  3259.         }
  3260.         else {
  3261.             cerr << "read failed\n" << flush;
  3262.             value=0;
  3263.         }
  3264.  
  3265.         4.1.2 Data General Operating System
  3266.  
  3267.               4.1.2.1 Data General RDOS
  3268.  
  3269.                       Used on the GE CT 9800 family. Severely primitive but
  3270. then is running on an old machine that can only map 64Kb of memory at a time
  3271. after all. It is apparently multitasking. Documentation may still be available
  3272. from Data General (try DG Direct) but is not supplied with the scanner by GE.
  3273. If anyone knows where I can find it at a reasonable price let me know. Here is
  3274. a brief command summary culled from a nifty pocket book from GE for
  3275. SunOS/Genesis users that compares commands:
  3276.  
  3277.                  CHATR  - file attributes
  3278.                  CRAND  - create randomly organized file
  3279.                  CDIR   - create directory
  3280.                  DELETE - files or directories
  3281.                  DIR    - change directory
  3282.                  DISK   - free space
  3283.                  FILCOM - compare files
  3284.                  GDIR   - show working directory name
  3285.                  GTOD   - show date and time
  3286.                  LINK   - files (symbolic)
  3287.                  LIST   - directory contents
  3288.                  MOVE   - a file
  3289.                  RENAME - a file
  3290.                  SDAT   - set date
  3291.                  STOD   - set time
  3292.                  SDUMP  - write files to a device
  3293.                  SLOAD  - read dumped files
  3294.                  SPEED  - tex editor
  3295.                  TYPE   - contents of file
  3296.                  XFER   - copy a file
  3297.  
  3298.                  wildcards: '-' is series, '*' is single character
  3299.  
  3300.               4.1.2.2 Data General AOS/VS
  3301.  
  3302.                       Used on the GE Signa 3X and 4X family. Quite a nice
  3303. operating system with multi-tasking and hierarchical directories. Here is a
  3304. brief command summary again culled from a nifty pocket book from GE for
  3305. SunOS/Genesis users that compares commands:
  3306.  
  3307.                  ACL         - access control list (ownership)
  3308.                  BYE         - exit command process
  3309.                  COPY        - a file
  3310.                  CREATE      - a text file
  3311.                  CREATE/DIR  - a directory
  3312.                  CREATE/LINK - link files
  3313.                  DELETE      - files & directories
  3314.                  DIR         - display or change working directory
  3315.                  DUMP        - to peripheral
  3316.                  F/AS/S      - directory listing with file status
  3317.                  DATE        - show or set
  3318.                  HELP
  3319.                  LOAD        - DUMPed files
  3320.                  MOVE        - a file
  3321.                  RENAME      - a file
  3322.                  PATH        - show pathname of a file
  3323.                  PAUSE       - the command line interpreter
  3324.                  SUPERU ON   - enable superuser
  3325.                  SED         - text editor
  3326.                  TIME        - show or set
  3327.                  TYPE        - contents of text file
  3328.                  ?           - list processes running
  3329.  
  3330.                  wildcards: '+' is series, '*' is single character
  3331.  
  3332.                       Other useful hints include the use of "^" to refer to the
  3333. next directory up (like ".." in Unix) in DIR commands. Command options follow
  3334. the command name without any spaces and are indicated by a slash. COPY
  3335. operations specify the destination name first and then the source name. Devices
  3336. like the mag tape are indicated by "@", for example "@MTB0" is tape drive zero.
  3337. Files on the tape can be referred to as "@MTB0:nn" which is very handy. For
  3338. example to read a file off a CT 9800 tape under AOS/VS:
  3339.  
  3340.                 COPY/V/IMTRSIZE=8192 B038040101.YP @MTB0:18
  3341.  
  3342.                       Perhaps most importantly, there is an extensive online
  3343. help system ... use the HELP command.
  3344.  
  3345.         4.1.3 Data General Network
  3346.  
  3347.               If you have a GE Signa based on a DG then you can get the
  3348. so-called "High Speed Network" card and software from GE. From memory it is
  3349. pretty pricey, and there used to be a "slower" network interface that was
  3350. cheaper, but I don't think this is available anymore.
  3351.  
  3352.               If you have a CT 9800 based on the DG S/140 and you need to get
  3353. it connected there are a number of solutions:
  3354.  
  3355.              - Talk to GE about there ID/LINK II product ... I gather this is a
  3356. device that hooks into the SCSI cable to the hard drive (you need one of the
  3357. Ace drives not the old Zebra drive), monitors disk activity and snatches pieces
  3358. of the conversation to make a copy of the image data, stores it and makes it
  3359. available via some network protocol. Sound crazy ? Perhaps, but they tell me it
  3360. works and the price is reasonable, at least for something from GE anyway. Get
  3361. them to throw one in next time you buy something big.
  3362.  
  3363.              - The do-it-yourself approach. Talk to John Clayton
  3364. (clayton@c-c.com) at Claflin and Clayton. They supply a complete R-level
  3365. solution by providing Ethernet hardware and TCP/IP software for 16 bit DG OS
  3366. including AOS and RDOS (specifically including the GE CT version of RDOS). He
  3367. tells me "you can expect a file transfer rate of 25 kbytes/s for S/140
  3368. systems". The package consists of:
  3369.  
  3370.               $2,850 - EC-10 ethernet controller
  3371.               $1,645 - RDOS TCP/IP software (telnet client,ftp client/server)
  3372.  
  3373.               I have not personally tried either of these approaches, and I am
  3374. sure there are others (talk to Merge or DeJarnette), but I am getting really
  3375. tired of carrying 9-track tapes around so perhaps I will bite the bullet soon
  3376. (and upgrade to a HighSpeed Advantage !).
  3377.  
  3378.     4.2 Vax
  3379.  
  3380.         4.2.1 Vax Data
  3381.  
  3382.               4.2.1.1 Vax Integers
  3383.  
  3384.                       - little endian
  3385.                       - 8, 16, or 32 bits
  3386.  
  3387.               4.2.1.2 Vax Floating Point
  3388.  
  3389.                       - little endian
  3390.                       - D_float
  3391.  
  3392.                         - 8 bytes
  3393.                         - sign bit 15
  3394.                         - exponent bits 14-7 excess 128 binary
  3395.                         - fraction MSB firstbits 6-0, 31-16, 47-32, 63-48
  3396.                         - normalized bit is not represented (hidden)
  3397.  
  3398.                       - G_float
  3399.  
  3400.                         - 8 bytes
  3401.                         - like D, but
  3402.                         - exponent is bits 14-4 excess 1024
  3403.                         - fraction 3-0 and 63-16
  3404.  
  3405.                       - F_float
  3406.  
  3407.                         - 4 bytes
  3408.                         - like D, smaller fraction
  3409.  
  3410.                       - H_float
  3411.  
  3412.                         - 16 bytes
  3413.                         - like G, but
  3414.                         - exponent is bits 14-0 excess 16384
  3415.                         - fraction is bits 127-16
  3416.  
  3417.                           - same wierd order
  3418.                           - bit 112 least significant
  3419.  
  3420.               4.2.1.3 Vax Strings
  3421.  
  3422.                       - 16 bits of length
  3423.                       - byte of type
  3424.                       - byte of class
  3425.                       - 32 bits of pointer
  3426.  
  3427.         4.2.2 Vax Operating System
  3428.  
  3429.               4.2.2.1 Vax VMS
  3430.  
  3431.                       Truely one of the world's most irritating operating
  3432. systems to use, especially if you are a unix fan. Still it works, has a great
  3433. online help system that saves one's butt almost often enough to be useful, and
  3434. if you can remember the directory where kermit is stored and the weird command
  3435. to invoke it one can get by (barely).
  3436.  
  3437.                       If you don't know VMS and the vendor doesn't supply the
  3438. manuals, get them from DEC ... you need them bad ... real bad. If (like me) you
  3439. throw them out everytime you move then encounter another piece of archaic
  3440. equipment, you need the "vaxbook" which is available via ftp from
  3441. decoy.uoregon.edu, written by Joseph E St Sauver, which summarizes commands,
  3442. files and all sorts of application specific stuff, though it is no substitute
  3443. for the real thing.
  3444.  
  3445.                       Recent VMS update: goddamn file formats ! Why can't VMS
  3446. behave like a real operating system and forget this file format crap ! I have
  3447. some Philips S5 MR images exported in ACR/NEMA format and I can't get the
  3448. things off the hosts's Vax using Kermit, because though they have fixed length
  3449. 512 byte records, some cretinous program sets the "carriage return carriage
  3450. control" record attributes, which causes kermit to send with all the '0A'
  3451. characters scrubbed out amongst other atrocities. I am getting desperate and
  3452. about to try using the Hex/Dehex utility that came with Kermit to get the stuff
  3453. off and then decode the hex format ! Or perhaps even use "dump" to make a
  3454. textfile, transfer, and decipher that. (No I don't have a C compiler for the
  3455. Vax so I guess I can't use uuencode unless someone wants to mail me a hex'ed
  3456. executable). Any hints, or instructions as to how to use FDL and Convert, to
  3457. change it to a normal format would be appreciated. (Why can't they just have a
  3458. "set file record attribute xxx" command like all the other millions of set
  3459. commands ? Grrrr.).
  3460.  
  3461.                       More recent VMS update: finally had an inspiration while
  3462. staring at hex dumps of these files - why not use the VMS "DUMP" utility which
  3463. produces hex dumps as a "poor man's uuencode" by saving the dump to a file,
  3464. transferring it as an ascii file, and then decoding it at the destination ? Of
  3465. course there are no nifty line checksums or anything, but a transfer protocol
  3466. such as kermit takes care of this. The DUMP output defaults to 8 32 bit long
  3467. words separated by a space per line displayed as hex, then an ascii string (32
  3468. bytes) and then a 24 bit word hex address offset from the start of the fixed
  3469. length record. All the data containing lines start with a single space, where
  3470. as descriptions at the start of each record begin in the first column, hence
  3471. the data lines can be easily selected out. By the way, the hex version of the
  3472. data is listed in reverse order ! VMS is so bizarre ! For example, here is a
  3473. fixed length 512 byte record file from a Philips S5 MRI (some of the hex words
  3474. elided to make the line fit on the page):
  3475.  
  3476. Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ...
  3477. File ID (2419,301,0)   End of file block 198 / Allocated 200
  3478.  
  3479. Virtual block number 1 (00000001), 512 (0200) bytes
  3480.  
  3481.  0000000C 00100008 ... 00000008 ........╢...........≡........... 000000
  3482.  00083932 2E36302E ... 2D524341 ACR-NEMA 1.0.. .....1994.06.29.. 000020
  3483.  00600008 4D5F4553 ... 00000030 0.......@.........A.....SE_M..`. 000040
  3484.  494B0000 00100080 ... 00000002 ....MR..p.....Philips ........KI 000060
  3485.  
  3486.  00183148 00000002 ... 32200000 .. 2........63865375........H1.. 0001E0
  3487. ^L
  3488. Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ...
  3489. File ID (2419,301,0)   End of file block 198 / Allocated 200
  3490.  
  3491. Virtual block number 2 (00000002), 512 (0200) bytes
  3492.  
  3493.  40000018 45424F52 ... 00161250 P.....AGACQ_PT_SURFACE_PROBE...@ 000000
  3494.  
  3495. And so on ... you get the idea. This ugly little C++ utility written quickly
  3496. during this moment of inspiration will take saved DUMP output and make it
  3497. binary again:
  3498.  
  3499. #include <fstream.h>
  3500.  
  3501. #include "MainCmd.h"
  3502.  
  3503. signed char
  3504. hextobin(char c)
  3505. {
  3506.     signed char r;
  3507.     switch (c) {
  3508.         case '0':    r=0; break;
  3509.                 case '1':       r=1; break;
  3510.                 case '2':       r=2; break;
  3511.                 case '3':       r=3; break;
  3512.                 case '4':       r=4; break;
  3513.                 case '5':       r=5; break;
  3514.                 case '6':       r=6; break;
  3515.                 case '7':       r=7; break;
  3516.                 case '8':       r=8; break;
  3517.                 case '9':       r=9; break;
  3518.         case 'A':
  3519.                 case 'a':       r=0xa; break;
  3520.                 case 'B':
  3521.         case 'b':       r=0xb; break;
  3522.                 case 'C':
  3523.         case 'c':       r=0xc; break;
  3524.                 case 'D':
  3525.         case 'd':       r=0xd; break;
  3526.                 case 'E':
  3527.         case 'e':       r=0xe; break;
  3528.                 case 'F':
  3529.         case 'f':       r=0xf; break;
  3530.         default:    r=-1; break;
  3531.     }
  3532.     return r;
  3533. }
  3534.  
  3535. int
  3536. main(int argc,char **argv)
  3537. {
  3538.     CCOMMAND(argc,argv);
  3539.  
  3540.     while (1) {
  3541.         const linemax=132;        // only needs 113
  3542.         char line[linemax];
  3543.         cin.getline(line,linemax);
  3544.         if (!cin || cin.eof()) {
  3545.             // cerr << "Bad or eof\n" << flush;
  3546.             break;
  3547.         }
  3548.         unsigned count=cin.gcount();
  3549.         if (count == 0 || line[0] != ' ') continue;
  3550.         if (count != 113) {
  3551.             cerr << "Line length " << count << "\n" << flush;
  3552.             break;
  3553.         }
  3554.         unsigned i;
  3555.         char *ptr = line + 8*(1+8);
  3556.         // line is in reverse order ...
  3557.         for (i=0; i<8; ++i) {
  3558.             unsigned j;
  3559.             for (j=0; j<4; ++j) {
  3560.                 // 2 hex bytes -> 1 byte
  3561.                 char bytelo = *--ptr;
  3562.                 char bytehi = *--ptr;
  3563.                 unsigned char byte
  3564.                     = (hextobin(bytehi)<<4)
  3565.                       + hextobin(bytelo);
  3566.                 cout.put(byte);
  3567.             }
  3568.             --ptr;    // space between long words
  3569.         }
  3570.     }
  3571.     return 0;
  3572. }
  3573.  
  3574.                       Note that the nature of fixed length records under VMS
  3575. means that the last record will be padded out to 512 bytes without any
  3576. indication of the "real" end-of-file. This means you have to cope with trailing
  3577. garbage gracefully.
  3578.  
  3579.                       Hot VMS/Philips news: neelin@pet.mni.mcgill.ca (Peter
  3580. Neelin) tells me there is an extremely useful tool for fiddling binary files
  3581. called FILE from DECUS. It allows you to change a file's header information
  3582. without modifying the content of the file. This then permits ftp, kermit, etc.
  3583. to do the right thing with Philips .ANI files. It also permits wildcards and
  3584. does not make a copy of the file (so it is fast). He says also that someone has
  3585. told him that they succeeded in using convert to fix these files, but his
  3586. general experience with it is not positive (it will often change the content of
  3587. the file and it doesn't allow wildcards, in addition to promoting the use of
  3588. the horrible fdl editor!). If you are interested, you can get FILE through
  3589. gopher from decus.org (look for the DECUS software library archives, under
  3590. essential tools). The binary is provided in case you don't have a compiler.
  3591.  
  3592.                       Some other useful hints:
  3593.  
  3594.                       - To log onto a serial terminal without executing the
  3595. login command file add "/NOCOM" to the username ... this way you can use the
  3596. operator console login which often won't require a password.
  3597.  
  3598.                       - There is a kermit available for the Vax under VMS (file
  3599. prefix "vms" in area or tape b) ... I use the "obsolete" version written in
  3600. Bliss, because it comes from the archives at columbia with a hex encoded
  3601. executable which can be uploaded just using an ordinary text capture into a
  3602. file, and doing the same with the short Macro hex program that can then be
  3603. assembled and used to make the convert into the real executable. Look in places
  3604. like [SYSEXE] first though to be sure Kermit is not already there. The generic
  3605. C version of kermit runs under VMS (file prefix "ck" in area or tape f), but
  3606. not every imaging machine comes with a VMS C compiler, whereas Macro is always
  3607. supposed to be there I gather. There is however also a hex encoded executable
  3608. of the C version in the archives (ckvker.hex) which I haven't tried, and is the
  3609. one that is recommended in the kermit documentation.
  3610.  
  3611.                       - There is apparently a zmodem for VMS but I don't know
  3612. where it comes from or how to get it.
  3613.  
  3614.                       - Serial ports are almost always defaulted to 9600 baud.
  3615.  
  3616.                       - "SET TERMINAL/ECHO" often isn't set.
  3617.  
  3618.               - Vax/VMS ftp conventions:
  3619.  
  3620.             UNIX FTP server     Vax/VMS FTP server
  3621.  
  3622.             cd dir                cd [.dir]
  3623.             cd dir/subdir         cd [.dir.subdir]
  3624.             cd ..                 cd [-]
  3625.  
  3626.               4.2.2.2 ULTRIX
  3627.               4.2.2.3 OSF
  3628.  
  3629.     4.3 Sun - Sun3 68000 and Sun4 Sparc
  3630.  
  3631.         4.3.1 Sun Data
  3632.  
  3633.               The sun3 and sun4 architectures use much the same formats. Even
  3634. though the processors are different both are big-endian and the float formats
  3635. are IEEE. See the Sparc Architecture Manual - Chapter 3 - Data Formats for more
  3636. details.
  3637.               4.3.1.1 Sun Integers
  3638.  
  3639.                       Integers are 8, 16, 32, or 64 bit unsigned or signed
  3640. two's complement and stored in big-endian format as on Data General and
  3641. opposite to the Dec VAX. Most C compilers treat short as 16 bits, and int and
  3642. long as 32 bits.
  3643.  
  3644.               4.3.1.2 Sun Floating Point
  3645.  
  3646.                       Formats conform to IEEE 754-1985. Single precision real
  3647. values are 32 bits long, in big-endian format. The high bit is the sign bit,
  3648. followed by a 8 bit excess 127 exponent (power to which 2 must be raised) then
  3649. a 23 bit normalized mantissa with the decimal point to the left of the most
  3650. significant bit, from which 1.0 has been subtracted. Double precision values
  3651. have a 11 bit excess 1023 exponent and a 52 bit mantissa. Quad precision values
  3652. have a 15 bit excess 16383 exponent and a 112 bit mantissa.
  3653.  
  3654.             Sign
  3655.            |<-->|<-------- Exponent -------->|<------- Mantissa ------>|
  3656.             ______________ ______________ ______________ ______________
  3657.            |              |              |              |              |
  3658.            |______________|______________|______________|______________|
  3659.             31          28 27          24 23          20 19          16
  3660.            |<----------------------- Mantissa ------------------------>|
  3661.             ______________ ______________ ______________ ______________
  3662.            |              |              |              |              |
  3663.            |______________|______________|______________|______________|
  3664.             15          12 11           8 7            4 3            0
  3665.  
  3666.                       Here is a little piece of C++ code that should run on
  3667. anything and convert Sun IEEE floats to whatever the host's floating point
  3668. format is. It probably should take into account a few special cases to be
  3669. strictly correct:
  3670.  
  3671.         unsigned char buffer[4];
  3672.         instream.read(buffer,4);
  3673.         if (instream) {
  3674. #ifdef USESUN4NATIVEFLOAT
  3675.             float fvalue;
  3676.             memcpy ((char *)(&fvalue),buffer,4);
  3677.             value=fvalue;
  3678. #else  USESUN4NATIVEFLOAT
  3679.             unsigned char    sign;
  3680.             Uint16        exponent;
  3681.             Uint32        mantissa;
  3682.  
  3683.             typedef struct {
  3684.                 unsigned    sign : 1;
  3685.                 unsigned    exponent : 8;
  3686.                 unsigned    mantissa : 23;
  3687.             } IEEE_FLOAT_SINGLE;
  3688.  
  3689.             IEEE_FLOAT_SINGLE number;
  3690.             // Sparc is a Big Endian machine
  3691.             memcpy ((char *)(&number),buffer,4);
  3692.             sign     = number.sign;
  3693.             exponent = number.exponent;
  3694.             mantissa = number.mantissa;
  3695.  
  3696.             if (exponent) {
  3697.                 value = (1.0 + (double)mantissa / (1 << 23)) *
  3698.                     pow (2.0, (long)(exponent) - 127);
  3699.             }
  3700.             else {
  3701.                 if (mantissa) {
  3702.                     value = (double)mantissa / (1 << 23) *
  3703.                         pow (2.0, (long)(-126));
  3704.                 }
  3705.                 else {
  3706.                     value=0;
  3707.                 }
  3708.             }
  3709.             value = (sign == 0) ? value : -value;
  3710. #endif USESUN4NATIVEFLOAT
  3711.         }
  3712.         else {
  3713.             cerr << "read failed\n" << flush;
  3714.             value=0;
  3715.         }
  3716.  
  3717.               4.3.1.3 Sun Strings
  3718.  
  3719.                       Strings obey the usual C convention of null terminated
  3720. strings without a length preamble.
  3721.  
  3722.         4.3.2 Sun Operating System
  3723.  
  3724. 5.  Compression Schemes
  3725.  
  3726.     5.1 Reversible Compression
  3727.     5.2 Irreversible Compression
  3728.         5.2.1 Perimeter Encoding
  3729.  
  3730. 6.  Getting Connected
  3731.  
  3732.     6.1 Tapes
  3733.  
  3734.         Nine-track half-inch tapes were the old medium of choice for archiving
  3735. and image exchange and many older pieces of equipment will have these.
  3736. Unfortunately most people don't have such a drive on their workstation or
  3737. personal computer. There are several possibilities:
  3738.  
  3739.           - Use another piece of equipment that has a more modern or
  3740.            networked or serial-ported host and a nine-track drive, and
  3741.            use it to do the extraction. I used to use a networked Signa 4X
  3742.            to do this to extract GE 9800 CT tapes.
  3743.  
  3744.           - Visit your MIS department, which almost certainly has an archaic
  3745.            mainframe with a tape drive. Sometimes tough to get them to read
  3746.            formats they aren't expecting though (the hosts not the people
  3747.            I mean :) ).
  3748.  
  3749.           - Buy a nine-track for your workstation. This may seem a ridiculous
  3750.            idea given the price of new 6250 bpi drives are around $5,000, but
  3751.            one can often pick up bargain primitive non-6250 or refurbished
  3752.            drive that is adequate for the job.
  3753.  
  3754.         The Qualstar 1054 is one such drive, that attaches to a SCSI port, and
  3755. works with the regular SunOS SCSI tape driver, once a few tables in the kernel
  3756. have been updated as follows, and the kernel rebuilt:
  3757.  
  3758. {root}% pwd
  3759. /usr/kvm/sys/scsi/targets
  3760.  
  3761. {root}% diff -c stdef.h.prequalstar stdef.h
  3762. *** stdef.h.prequalstar Tue Aug 30 19:32:24 1994
  3763. --- stdef.h     Tue Aug 30 19:32:24 1994
  3764. ***************
  3765. *** 43,48 ****
  3766. --- 43,49 ----
  3767.   #define       ST_TYPE_FUJI            0x21    /* Fujitsu - (not tested) */
  3768.   #define       ST_TYPE_KENNEDY         0x22    /* Kennedy */
  3769.   #define       ST_TYPE_HP              0x23    /* HP */
  3770. + #define       ST_TYPE_QUALSTAR        0x24    /* Qualstar */
  3771.   #define       ST_TYPE_HIC             0x26    /* Generic 1/2" Cartridge */
  3772.   #define       ST_TYPE_REEL            0x27    /* Generic 1/2" Reel Tape */
  3773.  
  3774. {root}% diff -c st_conf.c.prequalstar st_conf.c
  3775. *** st_conf.c.prequalstar       Tue Aug 30 19:32:22 1994
  3776. --- st_conf.c   Tue Aug 30 19:32:22 1994
  3777. ***************
  3778. *** 153,158 ****
  3779. --- 153,174 ----
  3780.    * so our best guess as to their capabilities is
  3781.    * included herein.
  3782.    */
  3783. + /* Qualstar 1054 or 1260s scsi 9-track with 64KB buffer */
  3784. + {
  3785. +       "Qualstar 1054/1260s 1/2\" Reel", 7, "NCR ADP-53", ST_TYPE_QUALSTAR,
  3786. 10240,+       (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
  3787. +       300, 300,
  3788. +       { 0x00, 0x02, 0x06, 0x03},
  3789. +       {  0, 0, 0, 0 }
  3790. + },
  3791. + /* Qualstar 1054 scsi 9-track with 256KB buffer */
  3792. + {
  3793. +       "Qualstar 1054 1/2\" Reel", 10, "QUALSTAR10", ST_TYPE_QUALSTAR, 10240,
  3794. +       (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
  3795. +       300, 300,
  3796. +       { 0x00, 0x02, 0x06, 0x06},
  3797. +       {  0, 0, 0, 0 }
  3798. + },
  3799.   /* Wangtek QIC-150 1/4" cartridge */ {
  3800.         "Wangtek QIC-150", 14, "WANGTEK 5150ES", ST_TYPE_WANGTEK, 512,
  3801.         (ST_QIC | ST_AUTODEN_OVERRIDE),
  3802.  
  3803.         I got my Qualstar 1054 from Bill Power at Power Computer Services for
  3804. only $750 and have successfully read GE 9800 CT and Philips S15 MR tapes with
  3805. it so far. See the "Sources" section for where to get one.
  3806.  
  3807.         Once you have such a tape connected to the SCSI port, one can either
  3808. write simple programs to read files (easiest if the tape has variable length
  3809. records) or use shell scripts and the "dd" command with whatever the correct
  3810. block size is. See dd(1), mt(1), and mtio(3) for more information. Remember
  3811. that the read(2) call reads one fixed or variable length record at a time, and
  3812. returns 0 bytes read for a tape mark, and two tape marks in a row indicates the
  3813. end of the tape (normally). If you encounter short files with a series of
  3814. records 80 bytes long chances are you are dealing with header/end markers. This
  3815. is what ANSI standard tapes off VAX VMS seem to look like.
  3816.  
  3817.         Anyone who has any further information about tape formats and handling,
  3818. especially references to standard or on-line documents please let me know.
  3819.  
  3820.     6.2 Ethernet
  3821.  
  3822.     6.3 Serial Ports
  3823.  
  3824. The next part is part7 - information sources.
  3825.  
  3826. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!cs.utexas.edu!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  3827. From: dclunie@flash.us.com (David A. Clunie)
  3828. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  3829. Subject: Medical Image Format FAQ, Part 7/8
  3830. Followup-To: alt.image.medical
  3831. Date: 28 Mar 1995 23:03:55 +0300
  3832. Organization: Her Master's Voice
  3833. Lines: 952
  3834. Approved: news-answers-request@MIT.EDU
  3835. Distribution: world
  3836. Expires: 28 Apr 1995 00:00:00 GMT
  3837. Message-ID: <3l9q3b$dmu@flash.ksapax>
  3838. Reply-To: dclunie@flash.us.com (David A. Clunie)
  3839. NNTP-Posting-Host: flash.ksapax
  3840. Summary: This posting contains answers to the most Frequently Asked
  3841.          Question on alt.image.medical - how do I convert from image
  3842.          format X from vendor Y to something I can use ? In addition
  3843.          it contains information about various standard formats.
  3844. Xref: senator-bedfellow.mit.edu alt.image.medical:2439 comp.protocols.dicom:640 sci.data.formats:890 sci.med.informatics:1733 sci.med.radiology:1811 alt.answers:8370 comp.answers:10927 sci.answers:2335 news.answers:40890
  3845.  
  3846. Archive-name: medical-image-faq/part7
  3847. Posting-Frequency: monthly
  3848. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  3849. Version: 2.02
  3850.  
  3851.  
  3852. 7.  Sources of Information
  3853.  
  3854.     7.1 Vendor Contacts
  3855.  
  3856.        - ANSI - Getting a Registered Organization Number for a DICOM UID Root:
  3857.  
  3858.                 Registration Coordinator
  3859.                 Michelle A. Maas
  3860.                 phone (212) 642-4900
  3861.                 phone (212) 642-4884
  3862.                 fax   (212) 398-0023
  3863.                 e-mail ATTMAIL.COM!MMAAS
  3864.                 X.400  C=US AD=ATTMAIL G=MICHELLE S=MAAS USER NAME=MMAAS
  3865.  
  3866.                 numeric identifier costs $1000 and takes 10 days
  3867.                 organization name  costs $1500 and takes 90 days
  3868.  
  3869.        - DICOM and ACR/NEMA standards:
  3870.  
  3871.                 NEMA Publication Sales
  3872.                 2101 L St. NW, Suite 300
  3873.                 Washington DC 20037-1526
  3874.                 phone (202) 457-8474
  3875.  
  3876.        - DICOM standards comments and working group information:
  3877.  
  3878.                 David Snavely, Staff Executive
  3879.                 NEMA
  3880.                 2101 L St. NW, Suite 300
  3881.                 Washington DC 20037-1526
  3882.                 phone (202) 457-1965
  3883.  
  3884.                 Gordon Bass
  3885.                 American College of Radiology
  3886.                 1891 Preston White Drive
  3887.                 Reston VA 22091
  3888.                 phone (703) 648-8900
  3889.  
  3890.        - FDA approval for PACS and Related Devices:
  3891.  
  3892.         Guidance for the Comment and Review of 510(k)
  3893.         Notifications for PACS and Related Devices
  3894.  
  3895.         Small Manufacturers Assistance
  3896.         phone (800) 638-2041
  3897.         fax   (301) 443-9435 (flash system for document delivery)
  3898.  
  3899.        - FDA standards:
  3900.  
  3901.         Fedworld Gateway
  3902.         modem (703) 321-8020
  3903.         telnet://fedworld.gov
  3904.         ftp://ftp.fedworld.gov
  3905.         http://www.fedworld.gov/
  3906.  
  3907.        - General Electric (not just GEMS):
  3908.  
  3909.         http://www.ge.com/
  3910.  
  3911.        - General Electric CRD (Corporate Research & Development):
  3912.  
  3913.         http://www.ge.com/crd/
  3914.  
  3915.        - General Electric, GEMS DICOM information contacts:
  3916.  
  3917.                 Donald E. Van Syckle
  3918.                 Senior Systems Analyst
  3919.                 GE Medical Systems
  3920.                 3200 N. Grandview Blvd.
  3921.                 Waukesha WI 53188
  3922.                 phone (414) 521-6262
  3923.                 fax   (414) 521-6800
  3924.                 email vansyckled@med.ge.com
  3925.  
  3926.        - GEMS image format information contacts:
  3927.  
  3928.                 GE Format Documents currently available:
  3929.  
  3930.                 - 46-021852 Technicare Magnetic Tape Image Fmt
  3931.                 - 46-021853 CT 8800 Image Data Fmt
  3932.                 - 46-021854 CT 9000 Image Data Fmt
  3933.                 - 46-021855 CT 9800 Image Data Fmt
  3934.                 - 46-021856 CT Pace Image Data Fmt
  3935.                 - 46-021862 MR Max  Image Data Fmt
  3936.                 - 46-021858 MR Signa 4.x Mag Tape and Image Data Fmt
  3937.                 - 46-021861 CT HLA/HSA MR Signa 5.x Image Data Fmt
  3938.                 - 46-021863 CT HLA/HSA MR Signa 5.x Optical Disk Raw Partition
  3939.                 - 46-021864 CT HLA/HSA MR Signa 5.x Image Extract Tool
  3940.                 - 46-021865 CT HLA/HSA MR Signa 5.x DAT Archive Fmt
  3941.                 - 46-021866 PET 4096 Plus and 2048 Plus Image Fmt
  3942.                 - 46-269546 IDNet v2.0 Implementation Profiles
  3943.  
  3944.                 Field engineers are now supposedly well informed about these
  3945.                 documents and can obtain them directly for you. They are
  3946.                 freely distributable.
  3947.  
  3948.                 You can try calling GE documentation direct at:
  3949.  
  3950.                 phone (800) 558-2040
  3951.                 phone (414) 548-2520
  3952.  
  3953.                 If these approaches doesn't work, try one of these guys.
  3954.  
  3955.                 John Meissner
  3956.                 Networks Technical Leader
  3957.                 GE Medical Systems
  3958.                 N25 W23255 Paul Road
  3959.                 Pewaukee WI 53072
  3960.                 phone (414) 896-2707
  3961.                 email meissnerj@med.ge.com
  3962.  
  3963.                 Alan Cuellar-Amrod
  3964.                 CT - G.E. OnLine Support
  3965.                 GE Medical Systems
  3966.                 email cuellara@iscmed.med.ge.com
  3967.  
  3968.        - General Electric Medical Systems:
  3969.  
  3970.         ftp://ftp.med.ge.com/
  3971.  
  3972.        - General Electric, GEMS Ultrasound contact:
  3973.  
  3974.                 Paul Mullen
  3975.                 Radiology Product Manager
  3976.                 email logiq@med.ge.com
  3977.                 email mullenp@delphi.com (Paul Mullen)
  3978.  
  3979.        - Independent JPEG Group (IJG):
  3980.  
  3981.                 tgl@netcom.com (Tom Lane)
  3982.  
  3983.        - Interfile information contacts:
  3984.  
  3985.                 cradduck@irus.rri.uwo.ca (Trevor Cradduck)
  3986.                 a.todd@ucl.ac.uk (Andrew Todd-Pokropek)
  3987.  
  3988.        - Images - digitized mammograms:
  3989.  
  3990.                 - no FTP site
  3991.                 - 50 each, normal and cancer mammograms
  3992.                 - digitized at 200 micrometers and 8 bits
  3993.                 - provide them with an appropriate tape
  3994.                 - Contact:
  3995.  
  3996.                 Maria Kallergi, PhD
  3997.                 Department of Radiology
  3998.                 University of South Florida
  3999.                 12901 Bruce B. Downs Blvd., Box 17
  4000.                 Tampa, FL   33612-4799
  4001.                 phone (813) 975-7873
  4002.                 fax   (813) 975-7831
  4003.                 email kallergi@rad.usf.edu
  4004.  
  4005.     7.2 Relevant FAQ's
  4006.  
  4007.        - Archive-name: graphics/resources-list/part[1-3]
  4008.        - Archive-name: graphics/faq
  4009.        - Archive-name: pixutils-faq
  4010.        - Archive-name: image-processing/Macintosh
  4011.        - Archive-name: sci-data-formats
  4012.        - Archive-name: compression-faq/part[1-3]
  4013.        - Archive-name: jpeg-faq
  4014.        - Archive-name: medical-image-faq/volume-visualization
  4015.  
  4016.        - DICOM FAQ
  4017.  
  4018.                   - maintained by dsc@xray.hmc.psu.edu (David S. Channin)
  4019.                   - periodically posted to comp.protocols.dicom
  4020.  
  4021.        - FITS basics and information (periodic posting)
  4022.  
  4023.                 - FITS (Flexible Image Transport System)
  4024.                 - for astronomical data
  4025.                 - periodically posted by
  4026.                       bschlesinger@nssdca.gsfc.nasa.gov (Barry M. Schlesinger)
  4027.                 - in sci.astro.fits,sci.data.formats
  4028.  
  4029.     7.3 Source Code
  4030.  
  4031.         See under FTP/WWW Sites
  4032.  
  4033.     7.4 Commercial Offerings
  4034.  
  4035.        - Anatomical images on CDROM and other atlases:
  4036.  
  4037.         A.D.A.M Software, Inc.
  4038.         phone (800) 408-ADAM Dept 502
  4039.         phone (800) 408-ADAM Dept 504
  4040.         phone (404) 980-0888
  4041.  
  4042.         Lifeart
  4043.         phone (800) 543-3278
  4044.         phone (216) 291-1922
  4045.  
  4046.         BodyWorks
  4047.         Software Marketing Corp
  4048.         9830 South 51st St, Bldg. A-131
  4049.         Phoenix, AZ  85044
  4050.         phone (602) 893-3377
  4051.  
  4052.         VoxelMan Atlas
  4053.         Springer-Verlag, Electronic Media
  4054.         175 Fifth Avenue
  4055.         New York, NY 10010
  4056.         phone  (212) 460-1682
  4057.         phone  (212) 533 5587
  4058.         email  blange@springer-ny.com
  4059.  
  4060.        - Conversion from proprietary formats:
  4061.  
  4062.         Phil Femano
  4063.         Medical Imaging Consultants
  4064.         phone (201) 812-1122
  4065.  
  4066.        - Conversion from proprietary formats (Nuclear medicine):
  4067.  
  4068.                 Medical Imaging Technology Associates
  4069.                 Ray Deininger
  4070.                 29 Main Street
  4071.                 P.O. Box 197
  4072.                 Mainland PA 19451
  4073.                 phone (215) 513-0440
  4074.                 fax   (215) 513-0442
  4075.                 email  info@mita.com
  4076.                 email  ray@mita.com
  4077.  
  4078.                 Images can be read from floppies, tapes, or networks on a PC.
  4079.                 Import formats include:
  4080.  
  4081.                 - Elscint SBACK (5.25")
  4082.                 - Elscint UST   (5.25, 3.5")
  4083.                 - Elscint RECord (5.25")
  4084.                 - Gamma11 (5.25")
  4085.                 - Picker PCS (5.25")
  4086.                 - GE Starcam/StarII (3.5")
  4087.                 - GE Plink (5.25, 3.5")
  4088.                 - NIC (5.35")
  4089.                 - Interfile (5.25, 3.5")
  4090.                 - Medasys Paragon (5.25")
  4091.                 - Siemens Microdelta (5.25")
  4092.                 - Sophy F83 (5.25, 3.5")
  4093.                 - Sophy NXT (5.25, 3.5")
  4094.                 - ADAC (5.25")
  4095.  
  4096.                 Export formats include:
  4097.  
  4098.                 - TARGA (.TGA)
  4099.                 - GIF
  4100.                 - TIF
  4101.                 - PCX
  4102.                 - WPG
  4103.                 - PICT (MAC)
  4104.                 - Medvision*
  4105.                 - Interfile
  4106.                 - GE Starcam
  4107.                 - Elscint
  4108.                 - Siemens
  4109.                 - Sopha
  4110.                 - Gamma11
  4111.  
  4112.                 8" floppy formats (Microtek Conversion Systems include:
  4113.  
  4114.                 - Technicare
  4115.                 - GE Star
  4116.                 - Starcam
  4117.                 - StarII
  4118.                 - MDS
  4119.                 - Toshiba
  4120.                 - Elscint F1
  4121.                 - Scintronix
  4122.                 - Siemens
  4123.                 - Gamma11
  4124.                 - NIC
  4125.                 - Picker PCS
  4126.  
  4127.        - Conversion from proprietary to ACR/NEMA format (MedVision for Mac):
  4128.  
  4129.                 Evergreen Technologies
  4130.         Jeffrey Siegel
  4131.                 Main Street, PO Box 795
  4132.                 Castine  ME 04421
  4133.                 phone 207-326-8300
  4134.                 fax   207-326-8333
  4135.         email evergreen@applelink.apple.com
  4136.         email jsiegel@lunis.nucmed.luc.edu
  4137.         email 71035.3156@CompuServe.com
  4138.  
  4139.        - Data General RDOS & AOS TCP/IP solution:
  4140.  
  4141.                 Claflin & Clayton
  4142.                 203 Southwest Cutoff
  4143.                 Northboro, MA 01532
  4144.                 phone 508-393-7979
  4145.                 fax   508-393-8788
  4146.                 email clayton@c-c.com
  4147.                 email 70262.3663@compuserve.com
  4148.  
  4149.        - Data General themselves:
  4150.  
  4151.                 DG Direct
  4152.                 phone 1-800-343-8842
  4153.  
  4154.        - Eight inch floppy solutions for PC's:
  4155.  
  4156.                 Microtek Conversion Systems
  4157.                 940 Industrial Ave
  4158.                 Palo Alto, Ca. 94303
  4159.                 phone (415) 424-1174
  4160.                 fax   (415) 424-1176
  4161.  
  4162.                 8" drive and controller $2,095
  4163.                 Format software each package $595-$695
  4164.  
  4165.                 Computer Peripherals Unlimited
  4166.                 2355 N. Steves Blvd, Suite C
  4167.                 Flagstaff AZ 86004
  4168.                 phone (602) 526-2261
  4169.                 fax   (602) 773-9183
  4170.  
  4171.                 8" drive and controller $1,245
  4172.                 Format software ? included
  4173.  
  4174.        - Interfaces between vendors and DICOM 3.0 toolkits:
  4175.  
  4176.                 DeJarnette Research Systems Inc.
  4177.                 Suite 700
  4178.                 401 Washington Avenue
  4179.                 Towson, Maryland 21204
  4180.                 USA
  4181.                 phone 410-583-0680
  4182.                 fax   410-583-0696
  4183.                 email info@dejarnette.com
  4184.  
  4185.                 Merge Technologies, Inc.
  4186.                 1126 S. 70th St
  4187.                 Milwaukee, Wisconsin 53214-3151
  4188.                 phone 414-475-4300
  4189.                 fax   414-475-3940
  4190.                 email dwight@merge.com (Dwight Simon)
  4191.  
  4192.                 Kodak Health Imaging Systems
  4193.                 18325 Waterview Parkway
  4194.                 Dallas TX 75252
  4195.                 phone 214-994-1266
  4196.                 fax   214-994-4180
  4197.                 email cbs@khis.com (C.B.Stone)
  4198.  
  4199.        - InterFormat - qsh to Interfile conversion, ACR/NEMA to qsh, et al.
  4200.  
  4201.                 - medical image format translation program
  4202.                 - automatically identifies and translates heterogeneous files
  4203.                 - Motif interface for user browsing & image selection
  4204.                 - input formats:
  4205.  
  4206.                         - GE 8800 CT, 9800 CT, Advantage CT & MR, Signa MR
  4207.                         - Technicare 2000 CT
  4208.                         - Positron PET
  4209.                         - Philips 300 Series CT
  4210.                         - Trionix Triad SPECT
  4211.                         - Siemens Somatom CT, Siemens Magnetom MR, CTI PET
  4212.                         - Varian CTSIM
  4213.                         - ACR-NEMA 1.0, ACR-NEMA 2.0, and AAPM/qsh
  4214.  
  4215.                 - output formats:
  4216.  
  4217.                         - AAPM/qsh
  4218.                         - Interfile
  4219.                         - ADAC Interfile
  4220.                         - Varian CTSIM
  4221.  
  4222.                 - other formats planned, including DICOM 3
  4223.  
  4224.                 David Reddy                       <--- USA contact
  4225.                 Radio Logic, Inc.
  4226.                 P.O. Box 9665
  4227.                 New Haven CT 06536
  4228.                 phone  (203) 624-8113
  4229.                 email  reddy@nucmed.med.nyu.edu
  4230.  
  4231.                 Bartec Medical Systems Ltd.       <--- UK, Europe & Mideast
  4232.                 Impression House
  4233.                 Invincible Road
  4234.                 Farnborough Hampshire
  4235.                 GU14 7NP England
  4236.                 email  bob@bartec.demon.co.uk
  4237.  
  4238.        - Network hardware for PACS/telemedicine/WAN.
  4239.  
  4240.         John A Hansen
  4241.         Networks Northwest Inc.
  4242.         PO Box 40209
  4243.         Bellevue Wa 98015
  4244.         phone  (800) 835-9462
  4245.         phone  (206) 641-8779
  4246.         fax    (206) 641-8909
  4247.         email  jahansen@networksnw.com
  4248.  
  4249.        - Plug-ins for Adobe Photoshop and NIH Image.
  4250.  
  4251.         
  4252.         - ImportACCESS
  4253.  
  4254.         A commercial Photoshop plugin that works with the many other
  4255.                 programs that support the plugin format. Reads fixed format
  4256.                 proprietary formats, and extra modules for ACR-NEMA 2.0,
  4257.                 DICOM 3.0, Interfile 3.3 files are available. Particularly
  4258.                 good at multi-slice images and color images, and clearly has
  4259.                 a nuclear medicine bias to it. Well documented. Recommended.
  4260.                 Note of potential bias - I was a beta tester.
  4261.  
  4262.         Hugh Lyshkow
  4263.         Designed Access
  4264.         702 Wrightwood Ave.
  4265.         Chicago IL 60614
  4266.         phone  (312) 880-2034
  4267.         fax    (312) 472-8834
  4268.         email  daccess@interaccess.com (Hugh Lyshkow)
  4269.         
  4270.  
  4271.        - Scanners for Xray films.
  4272.  
  4273.         Nathan Harris
  4274.         DBA Systems, Inc.
  4275.         phone  (407) 727-0660
  4276.         email  nharris@dba-sys.com
  4277.  
  4278.         Lumisys
  4279.  
  4280.         Cobrascan
  4281.  
  4282.         Vidar
  4283.  
  4284.         XRS
  4285.         email xrs@netcom.com
  4286.  
  4287.        - Tape drives - 9-track 1/2".
  4288.  
  4289.         Power Computer Services           <--- $750 Qualstar 1054 SCSI
  4290.         1132 Olympic Drive
  4291.         Corona CA 91719
  4292.         phone 800-323-0694
  4293.         phone 909-371-3992
  4294.         fax   909-371-1401
  4295.         email billp@cerfnet.com (Bill Power)
  4296.  
  4297.         Bill is also working on an 9-track interface replacement
  4298.         to record on removable hard disk cartridges, to upgrade
  4299.         old equipment.
  4300.  
  4301.        - Teleradiology equipment vendors.
  4302.  
  4303.         CompuMed Inc
  4304.         Cary Cole
  4305.         1200 No El Dorado Pl
  4306.         Suite C300
  4307.         Tucson AZ 85715
  4308.         phone 602-544-0544
  4309.         fax   602-722-9096
  4310.         email compumed@indirect.com
  4311.  
  4312.        - Video capture from medical devices.
  4313.  
  4314.         Precision Digital Images
  4315.         Lewis C. Larson
  4316.         6742 - 185th Ave. NE
  4317.         Suite 100
  4318.         Redmond, WA  98052
  4319.         phone 206-882-0218
  4320.         fax   206-867-9177
  4321.         email lewlar@aol.com (Lewis C. Larson)
  4322.  
  4323.        - Viewers for Mac and/or Windows:
  4324.  
  4325.                 Evergreen Technologies
  4326.         Jeffrey Siegel
  4327.                 Main Street, PO Box 795
  4328.                 Castine  ME 04421
  4329.                 phone 207-326-8300
  4330.                 fax   207-326-8333
  4331.         email evergreen@applelink.apple.com
  4332.         email jsiegel@lunis.nucmed.luc.edu
  4333.         email 71035.3156@CompuServe.com
  4334.  
  4335.         MultiView for Macintosh
  4336.         Image Data Corp.
  4337.         Don Alvarez
  4338.         11550 IH-10 West
  4339.         San Antonio, TX 78230-1024
  4340.         phone (210) 641-8340
  4341.         fax   (210) 641-7428
  4342.  
  4343.         Alice
  4344.         Hayden Image Processing Group
  4345.         Boulder, Colorado, USA
  4346.         phone (303) 449-3433
  4347.         fax   (303) 449-3772
  4348.         email help@perceptive.com
  4349.  
  4350.         Imaging Solutions
  4351.         phone (908) 780-7836
  4352.         email mdinkes@delphi.com (Marc Dinkes)
  4353.  
  4354.         SiteView (Windows and SunOS 4.x)
  4355.         Joe Shapiro
  4356.         phone (617) 674-2199
  4357.         fax   (617) 674-2217
  4358.         email gbb@ConSolve.com
  4359.         email joe@ConSolve.com
  4360.                 demo ftp://wuarchive.wustl.edu/graphics/graphics/demo-packages/
  4361.                 demo ftp://ftp.cica.indiana.edu/pub/pc/win3/demo/
  4362.  
  4363.        - Visible Human on CDROM.
  4364.  
  4365.         Research Systems, Inc
  4366.         email visible@rsinc.com
  4367.         email peter@rsinc.com (Peter Hallett)
  4368.  
  4369.     7.5 FTP/WWW sites
  4370.  
  4371.        - 3D Reconstruction:
  4372.  
  4373.                 - http://biocomp.arc.nasa.gov/3dreconstruction
  4374.  
  4375.        - 3DVIEWNIX (University of Pennsylvania):
  4376.  
  4377.         NB. The new 1.1 version has a different distribution policy
  4378.         and complete binary software, rather than just a demo, is
  4379.         available from the ftp site.
  4380.  
  4381.                 - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/BINARIES
  4382.                 - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MPEG_MOVIES
  4383.                 - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/DATA
  4384.                 - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/PAPERS
  4385.                 - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MANUALS
  4386.                 - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/SRC
  4387.                 - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/TUTORIALS
  4388.                 - http://mipgsun.mipg.upenn.edu
  4389.  
  4390.        - ACR Index of Radiologic Diagnoses (ascii text files):
  4391.  
  4392.                 - ftp://ftp.xray.hmc.psu.edu/acr_codes
  4393.                 - http://www.xray.hmc.psu.edu/
  4394.  
  4395.        - ACR/NEMA plugins for Adobe Photoshop (works with NIH Image also):
  4396.  
  4397.                 - ftp://sumex-aim.stanford.edu/info-mac
  4398.             
  4399.                     - /Graphic/Utility/photoshop-acr-nema.hqx
  4400.             
  4401.                 - ftp://zippy.nimh.nih.gov/pub/nih-image
  4402.  
  4403.             - /plug-ins/ACRNema.hqx
  4404.             - /user-macros/import_ACR_NEMA.txt
  4405.             
  4406.  
  4407.        - Anatomy - interactive programs:
  4408.  
  4409.                 - ftp://ftp.monash.edu.au/pub/medical
  4410.  
  4411.        - Anatomy - lung:
  4412.  
  4413.                 - http://indy.radiology.uiowa.edu
  4414.                          /rad/books/LungAnat/LungAnat.html
  4415.  
  4416.        - Angiography simulation:
  4417.  
  4418.                 - ftp://ftp.comp.vuw.ac.nz/pub/graphics/peter/xras-1.0.tar.gz
  4419.                 - http://www.comp.vuw.ac.nz/~peter/
  4420.  
  4421.        - Blood flow modelling:
  4422.  
  4423.                 - georgef@server1.usa (George Foutrakis)
  4424.                 - http://www.neuronet.pitt.edu:8910/~georgef
  4425.                 - http://www.pitt.edu/~gnfst1
  4426.  
  4427.        - CT reconstruction software:
  4428.  
  4429.                 - ftp://peipa.essex.ac.uk/ipa/src/process
  4430.  
  4431.                         - ct.tar.Z
  4432.                         - snark77.tar.Z
  4433.  
  4434.        - Clip Art of things medical:
  4435.  
  4436.                 - http://www.mindspring.com/~mperloe/gallery.html
  4437.                 - ftp://goofy.cs.umd.edu/f/clipart/medical
  4438.  
  4439.        - Dermatology:
  4440.  
  4441.                 - http://www.rrze.uni-erlangen.de/
  4442.  
  4443.                     - /docs/FAU/fakultaet/med/kli/derma/
  4444.  
  4445.        - DICOM conformance statements:
  4446.  
  4447.                 -  General Electric.
  4448.             ftp://ftp.med.ge.com/pub/DICOM
  4449.  
  4450.                 -  Index.
  4451.             http://www.xray.hmc.psu.edu/
  4452.  
  4453.        - DICOM conversion tools (from proprietary formats) and utilities:
  4454.  
  4455.                 - dicom3tools_*.tar.gz
  4456.             
  4457.             - ftp://ftp.rahul.net/pub/dclunie
  4458.                     - http://www.rahul.net/dclunie
  4459.             
  4460.                 - Tools and libraries for handling offline files.
  4461.                 - Conversion from proprietary formats.
  4462.                 - Can handle older ACR/NEMA format data.
  4463.                 - Can handle SPI.
  4464.                 - VERY limited X display capability.
  4465.                 - No DICOM networking (yet).
  4466.                 - Features.
  4467.             
  4468.             - Proprietary image conversions from ...
  4469.             
  4470.                     - GE CT 9800
  4471.                     - GE CT High Speed Advantage (Genesis)
  4472.                     - GE MR Signa 3X/4X
  4473.                     - GE MR Signa 5X (Genesis)
  4474.                     - GE CT Sytec
  4475.                     - GE CT Pace
  4476.                     - GE MR Max
  4477.                     - Siemens CT Somatom DR family
  4478.                     - Siemens CT Somatom Plus family (SPI)
  4479.                     - Siemens MR Magnetom Impact     (SPI)
  4480.                     - Siemens MR Magnetom SP         (SPI)
  4481.                     - Siemens MR Magnetom GBS/GBS2   (native)
  4482.                     - Philips MR Gyroscan S5         (native,SPI)
  4483.             
  4484.             - Image format support ...
  4485.             
  4486.                     - DICOM 3 offline file format (draft Part 10).
  4487.                     - Parsing/validate DICOM modules and IODs.
  4488.                     - Pbmplus extended 16 bit raw format.
  4489.                     - Raw binary images.
  4490.             
  4491.             - Archive retrieval from ...
  4492.             
  4493.                     - Generic extract 9-track and DAT.
  4494.                     - GE CT 9800 9-track.
  4495.                     - GE Genesis DAT.
  4496.                     - Philips Gyroscan MR S5 ANSI tapes.
  4497.             
  4498.             - Miscellaneous image format utilities ...
  4499.             
  4500.                     - Dump.
  4501.                     - Patch.
  4502.                     - Swap bytes.
  4503.                     - Word to byte shift.
  4504.                     - Extract 12 bit packed data.
  4505.                     - Guess unknown image parameters.
  4506.                     - Vax VMS DUMP output to binary.
  4507.             
  4508.             
  4509.  
  4510.        - DICOM data dictionary:
  4511.  
  4512.                 - From NIH ftp://zippy.nimh.nih.gov/pub/nih-image
  4513.             
  4514.             - /documents/dicom-dict.txt
  4515.             
  4516.                 - In dicom3tools_*.tar.gz
  4517.             
  4518.             - ftp://ftp.rahul.net/pub/dclunie
  4519.                     - http://www.rahul.net/dclunie
  4520.             
  4521.  
  4522.        - DICOM draft standards:
  4523.  
  4524.                - ftp://ftp.xray.hmc.psu.edu/dicom_docs
  4525.                - ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_docs
  4526.  
  4527.         - DICOM RSNA demonstration software:
  4528.  
  4529.                  Contact smm@wuerl.wustl.edu (Steve Moore)
  4530.  
  4531.                 - ftp://wuerlim.wustl.edu/pub/dicom
  4532.  
  4533.                 - ftp://ftp.xray.hmc.psu.edu/dicom_software
  4534.  
  4535.                         - /Mallinckrodt
  4536.                          Mallinkrodt RSNA
  4537.                         - /European
  4538.                          European CEN/TC251/WG4
  4539.  
  4540.                 - ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_software
  4541.  
  4542.                 - Linux port of Mallinckrodt CTN software
  4543.  
  4544.                         - From ftp://ss10.numed.szote.u-szeged.hu/pub/MIR-CTN/
  4545.  
  4546.                             - Modified sources /Linux/CTN.Linux.tar.Z
  4547.                             - Compiled binaries /Linux/CTN.Linux.bin.tar.Z
  4548.  
  4549.                         - Ported by boti@ss10.numed.szote.u-szeged.hu
  4550.  
  4551.         - DICOM sample images:
  4552.  
  4553.                - ftp://wuerlim.wustl.edu/pub/dicom/images/version3
  4554.  
  4555.                - In the Mallinckrodt software, there are a few sample
  4556.         images ... look in:
  4557.  
  4558.                        - apps/simple_storage/D19051502.9
  4559.                        - apps/simple_storage/D19051513.9
  4560.                         (contain images, but are ACR/NEMA 2 and missing lots
  4561.                         of required type 1 and 2 attributes)
  4562.  
  4563.         same in:
  4564.  
  4565.                        - apps/send_image
  4566.                        - apps/move_image
  4567.  
  4568.         also:
  4569.  
  4570.                        - apps/displays/TEST_IMAGES/baby.color.img
  4571.                         (contains image, but is not legal DICOM 3 (no UID's))
  4572.                        - apps/displays/TEST_IMAGES/ct1.1
  4573.                         (valid DICOM 3 CT IOD (passes Mallinckrodt dcm_verify))
  4574.  
  4575.                 - ftp://ftp.med.ge.com/pub/DICOM
  4576.                 - http://www.xray.hmc.psu.edu/public/med_img_dbs.html
  4577.  
  4578.        - Dr. Razz - image viewer for MAC:
  4579.  
  4580.                 - ftp://ftp.u.washington.edu/pub/user-supported/razz
  4581.                 - ftp://ftp.u.washington.edu/public/razz
  4582.                 - http://www.rad.washington.edu/
  4583.  
  4584.         The author (Thurman Gillespy tg3@u.washington.edu) writes:
  4585.  
  4586.         Dr Razz is a 16 bit medical image display and analysis
  4587.         program for Macintosh computers. Dr Razz can window and
  4588.         level on full 16 bit image data in near real time on any
  4589.         Macintosh color computer. Images can be viewed individually,
  4590.         or an image series can be viewed in an image stack. The
  4591.         program attempts to automatically open CT and MRI images,
  4592.         and can usually handle different header sizes and byte order.
  4593.         The program can directly read the headers of images created
  4594.         with the GE Image Extract Tool, and can automatically handle
  4595.         compressed images created with this utility. Dr Razz is not a
  4596.         DICOM viewer, although it can probably automatically open many
  4597.         CT/MRI DICOM images if they are not compressed. An option for
  4598.         manually entering image parameters for problem files is
  4599.         available. Images can be saved as PICT files, and TIFF support
  4600.         will be added.
  4601.  
  4602.        - FITS (Flexible Image Transport System) for astronomical data:
  4603.  
  4604.                 - ftp://fits.cv.nrao.edu/fits
  4605.                 - ftp://nssdca.gsfc.nasa.gov/FITS
  4606.  
  4607.        - Graphics file formats (gif,tiff,etc.)
  4608.  
  4609.                 - ftp://zamenhof.cs.rice.edu/pub/graphics.formats
  4610.  
  4611.        - Hierarchical Database Management System (astronomy images):
  4612.  
  4613.                 - ftp://starlink-ftp.rl.ac.uk/pub/doc/star-docs/sun92.tex
  4614.                 - http://star-www.rl.ac.uk/
  4615.  
  4616.        - Interfile Interfile sources -  see Nucmed ftp site at UWO.
  4617.  
  4618.        - JPEG Sources
  4619.  
  4620.                - PVRG-JPEG CODEC:
  4621.  
  4622.                 ftp://havefun.stanford.edu/pub/jpeg
  4623.  
  4624.                         Supports
  4625.  
  4626.                           - sequential DCT baseline,
  4627.                           - lossless modes.
  4628.  
  4629.                 - IJG:
  4630.  
  4631.                  ftp.uu.net/graphics/jpeg
  4632.  
  4633.                         Supports
  4634.  
  4635.                           - sequential DCT baseline,
  4636.                           - 12 bit DCT modes.
  4637.  
  4638.        - Kermit distribution:
  4639.  
  4640.                 - ftp://ftp.cc.columbia.edu/kermit
  4641.  
  4642.        - LUNIS - Loyola University Nuclear Medicine Information System
  4643.  
  4644.                 - http://147.126.104.3/
  4645.  
  4646.                 contact jhalama@lunis.nucmed.luc.edu (Jim Halama) for
  4647.         access, which is restricted ((708) 216-3777)
  4648.  
  4649.        - Medical imaging research (University of Leeds):
  4650.  
  4651.                 - http://agora.leeds.ac.uk/comir/comir.html
  4652.  
  4653.        - Medical Informatics standards, including HL7:
  4654.  
  4655.                 - ftp://dumccss.mc.duke.edu/standards
  4656.  
  4657.                         - read-me.txt
  4658.                         - HL7/pubs/version2.2/ballot1.zip
  4659.  
  4660.        - Neuroscience Resources List:
  4661.  
  4662.                 - http://golgi.harvard.edu/biopages/neuro.html
  4663.  
  4664.        - NIH Image - Macintosh image processing software:
  4665.  
  4666.                 - ftp://zippy.nimh.nih.gov/pub/nih-image
  4667.  
  4668.        - PACS - EurIPACS:
  4669.  
  4670.                 - http://www.rad.unipi.it:7080/
  4671.  
  4672.                     - /works/imphone/presentation-imphone.html
  4673.  
  4674.        - Papyrus and Osiris ftp site:
  4675.  
  4676.                 - ftp://expasy.hcuge.ch/pub/Osiris
  4677.             
  4678.             - Papyrus specifications for versions 2.1 and 3.
  4679.             - Osiris for Mac, PC and Unix (SunOS, Solaris, Dec).
  4680.             - Sample images for Dicom, Papyrus 2 and Papyrus 2.
  4681.             
  4682.                 - http://expasy.hcuge.ch/www/UIN/UIN.html
  4683.  
  4684.        - Nucmed ftp site at UWO (run by Trevor Cradduck (cradduck@uwo.ca)):
  4685.  
  4686.                 - ftp://uwovax.uwo.ca/PUB:[000000.NUCMED]
  4687.  
  4688.        - Penn State Radiology Web Server:
  4689.  
  4690.                 - http://www.xray.hmc.psu.edu/
  4691.  
  4692.        - PET:
  4693.  
  4694.                 - http://www-ipg.umds.ac.uk/pet/petcen.html
  4695.  
  4696.        - Physics:
  4697.  
  4698.                 - http://www.physics.mcgill.ca/physics-services/
  4699.                 - http://tph.tuwien.ac.at/physics-services/
  4700.  
  4701.        - Qsh by Qsh ftp site:
  4702.  
  4703.                 - ftp://nucmed.med.nyu.edu/pub
  4704.  
  4705.                         - /dist
  4706.                                  compressed tar
  4707.                         - /qsh
  4708.                                  source
  4709.  
  4710.        - Radiological Society of North America - On-Line Sources:
  4711.  
  4712.                 - http://www.rsna.org
  4713.                 - http://www.rsna.org/edu/internet.html
  4714.  
  4715.        - Radiology History:
  4716.  
  4717.                 - http://www.fh-wuerzburg.de/roentgen/
  4718.  
  4719.        - Sample mammogram images:
  4720.  
  4721.                 - miasdb@icr.ac.uk (J.Suckling) (Normal and abnormal)
  4722.  
  4723.                 - ftp://ftp.xray.hmc.psu.edu/mammo (10 Normal)
  4724.                 - http://www.xray.hmc.psu.edu/
  4725.  
  4726.        - Sample medical images (may be out of date):
  4727.  
  4728.                 - ftp://fokus.uke.uni-hamburg.de/.voxelman.images
  4729.                 - ftp://rwja.umdnj.edu/pub
  4730.                 - gopher://gopher.austin.unimelb.edu.au/11/images/petimages/
  4731.                 - ftp.nihon-u.ac.jp/pub/data/MRIMonkeyHead
  4732.                 - http://ftp.nc.nihon-u.ac.jp/pub/data/MRIMonkeyHead
  4733.                 - ftp://decaf.stanford.edu/pub/images/medical/mri
  4734.                 - ftp://eedsp.gatech.edu/database/images/wchung/medical
  4735.                 - ftp://omicron.cs.unc.edu/pub/softlab/CHVRTD
  4736.                 - http://foyt.indyrad.iupui.edu/medres/iurad2.html
  4737.                 - ftp://ccsun.unicamp.br
  4738.                 - ftp://boris.umds.ac.uk/pub/images
  4739.                 - http://www-ipg.umds.ac.uk/
  4740.  
  4741.        - University of Washington Teaching File (mrich@u.washington.edu):
  4742.  
  4743.                 - http://www.rad.washington.edu/
  4744.  
  4745.                 1.  Radiology Teaching File (CME credit)
  4746.                 2.  Anatomy Teaching Modules
  4747.                 3.  Radiology Exhibits from UW
  4748.                 4.  Information on UW radiology residency/fellowship programs
  4749.                 5.  Image processing software written by UW faculty
  4750.  
  4751.        - University of Western Ontario Teaching File:
  4752.  
  4753.                 - http://johns.largnet.uwo.ca
  4754.  
  4755.        - Vax help - "The Vax Book" by Joseph E St Sauver, U of Oregon:
  4756.  
  4757.                 - ftp://decoy.uoregon.edu
  4758.  
  4759.        - Visible Human Project
  4760.  
  4761.                 - http://www.nlm.nih.gov/
  4762.  
  4763.                     - /factsheets.dir/visible_human.html
  4764.                     - /extramural_research.dir/visible_gallery.html
  4765.  
  4766.         Dr. Michael J. Ackerman
  4767.         Project Officer, Visible Human Project
  4768.         National Library of Medicine
  4769.         8600 Rockville Pike
  4770.         Bethesda, MD 20894
  4771.  
  4772.         Need to sign an agreement with the NLM before one can
  4773.         transfer the 15 GB of data or buy tapes.
  4774.  
  4775.         Tape can be purchased from NTIS (301) 402-4100 in Unix
  4776.         tar format for $1000.
  4777.  
  4778.        - Wavelet compression software:
  4779.  
  4780.                 - ftp://pascal.math.yale.edu/pub/wavelets
  4781.                 - ftp://pascal.math.yale.edu/pub/software
  4782.  
  4783.        - Window level software (12/16 bits ->8):
  4784.  
  4785.                 - ftp://alvin.ach.uams.edu/pub/winlev.tar.Z (Includes images)
  4786.                 - ftp://alvin.ach.uams.edu/pub/winlev-noimages.tar.gz
  4787.  
  4788.        - Wxwin software:
  4789.  
  4790.                 - ftp://skye.aiai.ed.ac.uk/pub/wxwin
  4791.  
  4792.        - Xsee - X-windows based display program for raw images:
  4793.  
  4794.                 - available from thurn@amadeus.ece.ucsb.edu (Stefan Thurnhofer)
  4795.  
  4796. The next part is part8 - information sources (continued).
  4797.  
  4798. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.near.net!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!flash.us.com!flash.us.com!not-for-mail
  4799. From: dclunie@flash.us.com (David A. Clunie)
  4800. Newsgroups: alt.image.medical,comp.protocols.dicom,sci.data.formats,sci.med.informatics,sci.med.radiology,alt.answers,comp.answers,sci.answers,news.answers
  4801. Subject: Medical Image Format FAQ, Part 8/8
  4802. Followup-To: alt.image.medical
  4803. Date: 28 Mar 1995 23:04:03 +0300
  4804. Organization: Her Master's Voice
  4805. Lines: 349
  4806. Approved: news-answers-request@MIT.EDU
  4807. Distribution: world
  4808. Expires: 28 Apr 1995 00:00:00 GMT
  4809. Message-ID: <3l9q3j$dnf@flash.ksapax>
  4810. Reply-To: dclunie@flash.us.com (David A. Clunie)
  4811. NNTP-Posting-Host: flash.ksapax
  4812. Summary: This posting contains answers to the most Frequently Asked
  4813.          Question on alt.image.medical - how do I convert from image
  4814.          format X from vendor Y to something I can use ? In addition
  4815.          it contains information about various standard formats.
  4816. Xref: senator-bedfellow.mit.edu alt.image.medical:2440 comp.protocols.dicom:641 sci.data.formats:891 sci.med.informatics:1734 sci.med.radiology:1812 alt.answers:8371 comp.answers:10928 sci.answers:2336 news.answers:40891
  4817.  
  4818. Archive-name: medical-image-faq/part8
  4819. Posting-Frequency: monthly
  4820. Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
  4821. Version: 2.02
  4822.  
  4823.  
  4824.     7.6 Mailservers
  4825.  
  4826.        - Ftpmail:
  4827.  
  4828.                 Ftpmail is a service provided by some extremely generous
  4829.                 sites that allow you to send ftp commands to them by email
  4830.                 and the server executes the commands and sends the results
  4831.                 back. Very few sites offer this because of the huge load
  4832.                 and potential for abuse. I only mention it here because a
  4833.                 lot of medical imaging people don't seem to have anonymous
  4834.                 ftp access.
  4835.  
  4836.                 To find out more, fetch the relevant FAQ from the mailserver
  4837.                 at "mail-server@rtfm.mit.edu" with a message body:
  4838.  
  4839.                         send usenet/news.answers/ftp-list/faq
  4840.  
  4841.                 The most commonly used site is "ftpmail@decwrl.dec.com" (send
  4842.                 "help" (no quotes) in the message body).
  4843.  
  4844.        - HSPNET-L Hospital Computer Network Discussion Group and Data Base:
  4845.  
  4846.         Run by Don Parsons dfp10%albnydh2.bitnet@uacsc2.albany.edu.
  4847.  
  4848.         - To subscribe:
  4849.  
  4850.             To: listserv%albnydh2.bitnet@uacsc2.albany.edu
  4851.             Subject:
  4852.             SUBSCRIBE HSPNET-L your_full_name
  4853.  
  4854.         - For the monthly digest:
  4855.  
  4856.             To: listserv%albnydh2.bitnet@uacsc2.albany.edu
  4857.             Subject:
  4858.             AFD ADD HSP* DIGEST HSPNET-L
  4859.  
  4860.         - To contribute (if subscribed):
  4861.  
  4862.             To: hspnet-l%albnydh2.bitnet@uacsc2.albany.edu
  4863.  
  4864.         - To download from the LISTSERV Database:
  4865.  
  4866.             To: listserv%albnydh2.bitnet@uacsc2.albany.edu
  4867.             Subject:
  4868.             INDEX HSPNET-L
  4869.             GET <filename> <filetype>
  4870.  
  4871.         HSPNET-L is mirrored by "sci.med.telemedicine" Usenet newsgroup.
  4872.  
  4873.        - Interfile Interfile mailing list:
  4874.  
  4875.                 Don't know much about this list, but I am sure that
  4876.                 atoddpok@medphys.ucl.ac.uk (Andrew Todd-Pokropek) would
  4877.                 be able to fill you in on this.
  4878.  
  4879.        - Medimagex list for medical image format discussions:
  4880.  
  4881.                 Precursor to "alt.image.medical" usenet news group. Now
  4882.                 essentially defunct. Maybe useful if you don't have
  4883.                 Usenet News access.
  4884.  
  4885.         - command address:   listserver@cs.columbia.edu
  4886.                 - commands:          in message body not subject
  4887.                 - list name:         MEDIMAGEX
  4888.                 - to get help:       HELP and/or HELP LISTSERV
  4889.                 - to subscribe:      SUBSCRIBE MEDIMAGEX firstname lastname
  4890.                                     (NB. not your email address, that is
  4891.                                      derived from the 'From ' header line)
  4892.                 - to unsubscribe:    UNSUBSCRIBE MEDIMAGEX
  4893.                 - to send to list:   medimagex@cs.columbia.edu
  4894.  
  4895.        - Nucmed mailing list for medical physicists:
  4896.  
  4897.                 - to subscribe:          nucmed-request@irus.rri.uwo.ca
  4898.                 - to unsubscribe, etc.:  nucmed-owner@irus.rri.uwo.ca
  4899.                 - to send to list:       nucmed@uwo.ca
  4900.                 - the relevant human:    cradduck@uwo.ca (Trevor Cradduck)
  4901.  
  4902.                 This list is not actually gated to "sci.med.physics",
  4903.         though Trevor often reposts significant items.
  4904.  
  4905.                 See also Nucmed ftp site at UWO.
  4906.  
  4907.        - Radiation Safety Distribution list:
  4908.  
  4909.         For Health Physicists, Medical Physicists, Radiological
  4910.         Engineers and others who have a professional interest in
  4911.         matters related to Radiation Protection.
  4912.  
  4913.         RADSAFE@romulus.ehs.uiuc.edu
  4914.  
  4915.        - Radiologic Science Discussion Group - Radsci-L:
  4916.  
  4917.          Discussion may choose to center around radiologic science
  4918.          education, medical radiography, CT (computerized scanning),
  4919.          MRI (magnetic resonance scanning), sonography, nuclear
  4920.          medicine, radiation oncology, veterinary medicine, industrial
  4921.          applications, radiologic patient care, etc.
  4922.  
  4923.         - command address:   mailserv@western.tec.wi.us
  4924.                 - commands:          in message body not subject
  4925.                 - list name:         Radsci-L
  4926.                 - to subscribe:      subscribe Radsci-L firstname lastname
  4927.                                     (NB. not your email address, that is
  4928.                                      derived from the 'From ' header line)
  4929.  
  4930.        - sci.med.radiology gateway:
  4931.  
  4932.         sci.med.radiology@news.cs.indiana.edu
  4933.  
  4934.     7.7 References
  4935.  
  4936.        - DICOM - Directory of Resources:
  4937.  
  4938.                 "DICOM Tools for End User Applications
  4939.                 and System Integration"
  4940.                 Presented at EuroPACS'94 Geneva Switzerland
  4941.                 Dwight Simon
  4942.  
  4943.                 Merge Technologies, Inc.
  4944.                 1126 S. 70th St. Suite N508B
  4945.                 Milwaukee, Wisconsin 53214-3151
  4946.                 phone 414-475-4300
  4947.                 fax   414-475-3940
  4948.                 email dwight@merge.com (Dwight Simon)
  4949.  
  4950.        - DICOM - General:
  4951.  
  4952.                 Kodak "Understanding DICOM 3.0" for $US 12.50 (no credit cards)
  4953.  
  4954.                 Angie Helms
  4955.                 Kodak Health Imaging Systems
  4956.                 18325 Waterview Parkway
  4957.                 Dallas TX 75252
  4958.                 phone 1-800-767-3448
  4959.  
  4960.        - DICOM - Implementation:
  4961.  
  4962.                 "Implementation of the DICOM 3.0 Standard
  4963.                     - A Pragmatic Handbook"
  4964.                 Robert Hindel, Editor
  4965.  
  4966.         RH Consulting
  4967.                 483 Ridge Road
  4968.                 Orange CT 06477-2830
  4969.                 phone 203-799-2258
  4970.                 fax   203-795-8640
  4971.                 email 73030.1366@compuserve.com (Robert Hindel)
  4972.  
  4973.         Radiological Society of North America
  4974.                 2021 Spring Road Suite 600
  4975.                 Oak Brook IL 60521
  4976.  
  4977.        - PACS:
  4978.  
  4979.                 Understanding PACS:Picture Archiving & Communications Systems
  4980.  
  4981.                 available for $5 from:
  4982.  
  4983.                         SCAR, Society for Computer Applications in Radiology
  4984.                         4750 Lindle Road,
  4985.                         P.O. Box 8800
  4986.                         Harrisburg, PA 17105-8800
  4987.                         phone 717-561-5266
  4988.  
  4989.        - Telemedicine:
  4990.  
  4991.                 Rural TeleHealth:Telemedicine,Distance Education &
  4992.                 Informatics for Rural Health Care, A Report of the Office
  4993.                 of Rural Health Policy Health Resources and Services
  4994.                 Administration, DHSS (Nov,1993)
  4995.  
  4996.                 available for $8 from:
  4997.  
  4998.                         WICHE Publications
  4999.                         Western Interstate Commission for Higher Education
  5000.                         P.O. Drawer P
  5001.                         Boulder, CO  80301-9752
  5002.                         phone (303) 541-0290
  5003.                         fax   (303) 541-0291
  5004.  
  5005.        - Wavelet compression:
  5006.  
  5007.                 Press, et al. Numerical Recipes in C.
  5008.                 Chapter 13.10. Wavelet Transforms.
  5009.  
  5010.                 Cody,MA. The Wavelet Packet Transform.
  5011.                 Dr. Dobb's Journal, April '94
  5012.  
  5013.     7.8 Organizations and Societies
  5014.  
  5015.        - IEEE Transactions on Medical Imaging
  5016.  
  5017.         Mike Vannier
  5018.         Mallinckrodt Institute of Radiology
  5019.         Washington University Medical Center
  5020.         510 South Kingshighway Blvd.
  5021.         St. Louis, MO 63110
  5022.  
  5023.        - Society for Computer Applications in Radiology
  5024.  
  5025.         4750 Lindle Road,
  5026.         P.O. Box 8800
  5027.         Harrisburg, PA 17105-8800
  5028.         phone 717-561-5266
  5029.         email 73531.1173@compuserve.com
  5030.         email tg3@u.washington.edu (Thurman Gillespy).
  5031.  
  5032.                - Web server is at http://www.scar.rad.washington.edu/
  5033.  
  5034.                - Official journal is the "Journal of Digital Imaging".
  5035.  
  5036.                - Last meeting was S/CAR'94 held in Winston-Salem,
  5037.                 North Carolina during June 1994.
  5038.  
  5039.                - (membership is considered mandatory for FAQ readers :) )
  5040.  
  5041.     7.9 Usenet Newsgroups
  5042.  
  5043.        - alt.graphics.pixutils
  5044.        - alt.image.medical
  5045.        - alt.med.equipment
  5046.        - comp.graphics
  5047.        - comp.graphics.algorithms
  5048.        - comp.graphics.pixutils
  5049.        - comp.graphics.research
  5050.        - comp.protocols.dicom
  5051.        - sci.data.formats
  5052.        - sci.med.emergency
  5053.        - sci.med.informatics
  5054.        - sci.med.physics
  5055.        - sci.med.radiology
  5056.        - sci.med.telemedicine
  5057.        - sci.med.vision
  5058.  
  5059. 8.  Acknowledgements
  5060.  
  5061.     Thanks to the following people for contributions, general help, interesting
  5062. postings or mail whose contents have found there way in here, or just plain old
  5063. moral support. If I have inadvertently omitted anyone, sorry !
  5064.  
  5065.                -                     <axagarwa@seldon.cs.twsu.edu>
  5066.                -                     <clp@acs.bu.edu>
  5067.                - Aaron Davis         <Aaron_Davis@iucc.iupui.edu>
  5068.                - Alan Rowberg        <rowberg@u.washington.edu>
  5069.                - Allen Rueter        <allen@wuerl.WUstl.EDU>
  5070.                - Alvis D. Harding Jr <adh@george.ach.uams.edu>
  5071.                - Andreas Bittorf <Andreas.Bittorf@derma.med.uni-erlangen.de>
  5072.                - Andreas Pommert     <pommert@uke.uni-hamburg.de>
  5073.                - Andrei Cornoiu      <cornoiu@monu1.cc.monash.edu.au>
  5074.                - Andrew ToddPokropek <a.todd@ucl.ac.uk>
  5075.                - Andy Hewett         <Andy.Hewett@informatik.uni-oldenburg.de>
  5076.                - Bob Dempsey         <dempsey@metronet.com>
  5077.                - Bob Manich          <rdm@wdl.loral.com>
  5078.                - Botond K. Szabo     <boti@ss10.numed.szote.u-szeged.hu>
  5079.                - Bud Wendt           <rwendt@bcm.tmc.edu>
  5080.                - C.B.Stone           <cbs@khis.com>
  5081.                - CC Yau              <ccyau@iohk.com>
  5082.                - Charles Bird        <cb@xerxes.umds.ac.uk>
  5083.                - Christoph Ozdoba    <ozdoba@insel.unibe.ch>
  5084.                - Chuck Batishko      <cr_batishko@pnl.gov>
  5085.                - Craig D. von Land   <craig@care3.uab.es>
  5086.                - David P Reddy       <reddy@nucmed.med.nyu.edu>
  5087.                - David S. Channin    <dsc@xray.hmc.psu.edu>
  5088.                - Derek Hill          <D.Hill@umds.ac.uk>
  5089.                - Dick St.Peters      <stpeters@NetHeaven.com>
  5090.                - Dick St.Peters      <stpeters@dawn.crd.ge.com>
  5091.                - Don Parsons         <dfp10%albnydh2.bitnet@uacsc2.albany.edu>
  5092.                - Donald Van Syckle   <vansyckled@med.ge.com>
  5093.                - Dwight Simon        <dwight@merge.com>
  5094.                - Edward Gosfield     <gosfield@udcemail.udc.upenn.edu>
  5095.                - Eric John Finegan   <efinegan@dejarnette.com>
  5096.                - Fred W. Prior       <prior@xray.hmc.psu.edu>
  5097.                - George Foutrakis    <georgef@server1.usa>
  5098.                - Gerald Q. Maguire   <maguire@it.kth.se>
  5099.                - Gerrit Visser       <gerrit@isgtec.com>
  5100.                - Greg Gibbs          <ggibbs@csn.net>
  5101.                - Guillaume Thelissen <Guillaume.Thelissen@RAD.RULIMBURG.NL>
  5102.                - Gunther Nowotny     <gnowotny@tph23.tuwien.ac.at>
  5103.                - Herve Delingette    <hdeling@hippocrate.inria.fr>
  5104.                - Hugh Lyshkow        <daccess@interaccess.com>
  5105.                - Irene Gearin        <ireneg@isgtec.com>
  5106.                - James Harrison      <james@hplb.hpl.hp.com>
  5107.                - Jeff Paynowski      <paynowsk@ct.picker.com>
  5108.                - Jeff Wade           <wade@kegs.saic.com>
  5109.                - Jeffrey Siegel      <jsiegel@lunis.nucmed.luc.edu>
  5110.                - Jerry McCarthy      <ab003@freenet.HSC.Colorado.EDU>
  5111.                - Jim Berilla         <jb@falstaff.MAE.cwru.edu>
  5112.                - Jim Swan            <jim@swanmed.com>
  5113.                - Joe Shapiro         <joe@consolve.com>
  5114.                - Joel Davis          <jdavis@iea.com>
  5115.                - John A. Hansen      <jahansen@halcyon.halcyon.com>
  5116.                - John Clayton        <clayton@c-c.com>
  5117.                - John Hearns         <johnh@gerbil.umds.ac.uk>
  5118.                - John L. Groezinger  <jlgroezinger@mmm.com>
  5119.                - John Meissner       <meissnerj@med.ge.com>
  5120.                - K Schulze           <kschulze@aol.com>
  5121.                - Keith Robison       <robison@nucleus.harvard.edu>
  5122.                - Kevin Montgomery    <kevin@biocomp.arc.nasa.gov>
  5123.                - Krishna Iyer        <iyer@mipg.upenn.edu>
  5124.                - Lasse Jyrkinen      <ljj@stekt16.oulu.fi>
  5125.                - Marilyn E Noz       <noz@nucmed.NYU.EDU>
  5126.                - Mark Dinkes         <mdinkes@delphi.com>
  5127.                - Mark Perloe         <mperloe@mindspring.com>
  5128.                - Martin Liversage    <operator@iris.kth.dk>
  5129.                - Matthew T. Adams    <mtadams@columbine.hsc.colorado.edu>
  5130.                - Matti Haveri        <mhaveri@cc.oulu.fi>
  5131.                - Michael P. McIntyre <mikey@lobby.ti.com>
  5132.                - Michael Richardson  <mrich@u.washington.edu>
  5133.                - Nathan A. Harris    <nharris@dba-sys.com>
  5134.                - Neil Weisenfeld     <weisen@alw.nih.gov>
  5135.                - Nick Efford         <nde@dcre.leeds.ac.uk>
  5136.                - Pat Wallace         <ptw@rlsaxp.bnsc.rl.ac.uk>
  5137.                - Paul Malloy         <Paul_Malloy@brown.edu>
  5138.                - Paul Morgan         <ppxpsm@unicorn.ccc.nottingham.ac.uk>
  5139.                - Paul Mullen         <mullenp@delphi.com>
  5140.                - Peter Hall          <Peter.Hall@comp.vuw.ac.nz>
  5141.                - Peter Hallett       <peter@rsinc.com>
  5142.                - Peter Jurgensen     <pju@vision.auc.dk>
  5143.                - Peter Neelin        <neelin@pet.mni.mcgill.ca>
  5144.                - Phil Pillet         <eng48bxny@aol.com>
  5145.                - Phillip Berman      <compumed@indirect.com>
  5146.                - R. Krishnamurthy    <rk@cedar.Buffalo.EDU>
  5147.                - Rafael Pous         <pous@gaig.upc.es>
  5148.                - Rex Harmon          <indexrex@aol.com>
  5149.                - Richard R Carlton   <rcarlton@magnus.acs.ohio-state.edu>
  5150.                - Robert Hindel       <73030.1366@compuserve.com>
  5151.                - Roch Comeau         <roch@nil.mni.mcgill.ca>
  5152.                - Rutie Adar          <rutie@asp.co.il>
  5153.                - Scott M Metzger     <smetzger@harp.aix.calpoly.edu>
  5154.                - Shigeru Muraki      <muraki@etl.go.jp>
  5155.                - Steve Moore         <smm@wuerl.wustl.edu>
  5156.                - Thurman Gillespy    <tg3@u.washington.edu>
  5157.                - Tom Lane            <tgl@netcom.com>
  5158.                - Tracy N. Tipping    <tipping@phys.ksu.edu>
  5159.                - Trevor Cradduck     <cradduck@irus.rri.uwo.ca>
  5160.                - Tunc Iyriboz        <iyriboz@dialup.francenet.fr>
  5161.                - Varun Mitroo        <mitroo@magnus.acs.ohio-state.edu>
  5162.                - Wayne Rasband       <wayne@helix.nih.gov>
  5163.                - Yuichi Kimura       <kimura@cit.nihon-u.ac.jp>
  5164.  
  5165. The next part is index by keyword.
  5166.  
  5167.