alex@dartvax.UUCP (Alex Hartov) (08/27/87)
>Received: from obelix.liu.se by asterix.liu.se; Mon, 17 Aug 87 21:02:11 +0200 >Received: by obelix.liu.se; Mon, 17 Aug 87 21:01:13 SDT >Date: Mon, 17 Aug 87 21:01:13 SDT >From: P{r Emanuelsson <linus!harvard!seismo!enea!obelix.liu.se!p_e> >Message-Id: <8708171901.AA25733@obelix.liu.se> >To: alex >Subject: Re: CT images conversion to VICOM format >Newsgroups: comp.graphics,comp.sys.workstations >In-Reply-To: <3285@ncoast.UUCP> >Organization: University of Linkoping, Sweden >Status: RO > >In article <3285@ncoast.UUCP> you write: >> I would like to know if anyone has some information to share concerning >>CT (aka CAT SCAN) file formats produced on GE systems. > >Well, is that something I would like to know! I have some tapes, but >have never been able to decipher them. If you get any information, please >forward them to me, or post in comp.graphics. Hope it's not proprietary :-( > >Cheers, > >/Per Emanuelsson Per, (also for the benefit of anyone interrested) Your were the only person to answer my posting. However I did find out a few things concerning CT file formats. First let me be more specific. There are several manufacturers that make CT machines and each have their own way of doing things. For my project I receive tapes made on a General Electric CT machine. The format they use is the so-called GE8800 system, as opposed to the 9800 system which is more recent. The computer they use is a Data General Eclipse equipped with an 800 bpi 1/2" tape drive. The tapes are transferred on a VAX unix machine using a program that swaps bytes (because of DG's tape format). From looking at the raw data and some trial and error I have been able to determine the following: Tapes contain several files separated by EOF's. The first 2 files do not contain image data and I do not use them. The image data is contained in the third and following files. There are several types of image files, so far I have only been able to display images that were saved as 'screen dumps' or 'screen save'. The image data starts at the 3rd block of the image files, a block being 256 words or 512 bytes. In the case of screen saves, the images are squares of 320 pixels to the side. The image data consists of 16 bit words (2 bytes) in integer format of 12 bits, the 4 most significant bits being used for graphic overlays. It is a simple matter to read the image data and pad it to a 512X512 image if that's what your system uses. GE uses another type of images which are elliptic, apparently with x and y axes that can be changed in scale. I haven't been able to figure these out although I have been able to show distorted images to convince myself that I was on the right track. Between images there is a block (256 words) of data that is some sort of image header. That's all I have.. Alex. -- P.S. The brain is in gear, the clutch is slipping...
sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) (09/05/87)
In article <6949@dartvax.UUCP> alex@dartvax.UUCP (Alex Hartov) writes: >>In article <3285@ncoast.UUCP> you write: >>> I would like to know if anyone has some information to share concerning >>>CT (aka CAT SCAN) file formats produced on GE systems. >> >>Well, is that something I would like to know! I have some tapes, but >>have never been able to decipher them. If you get any information, please >>forward them to me, or post in comp.graphics. Hope it's not proprietary :-( >> >>Cheers, >> >>/Per Emanuelsson > [What followed was a description of of an effort to decode data obtained] [from a GE 8800 CT Scanner ] As a matter of fact, that information IS proprietary (in spite of the fact that it is widely known). I have an objection to discussions such as these for the following reasons. Many people are working with data obtained from GE and Seimens scanners in many places across the country. I cannot speak for Seimens but in the case of General Electric, they were more than happy to supply us with a description of their Image File Format in exchange for a non-disclosure agreement. Since that time we have successfully worked with hundreds of images and GE has made no attempt to restrict our use of that information (we have never violated the non-disclosure agreement). In addition, we have been free to exchange information with other sites obligated by the same type of agreement, so that our research has never been hindered by a lack of information. It disturbs me to see people posting information derived from a proprietary format when access to that information under controlled conditions is nearly unrestricted. General Electric (I neither work with them or for them) has been exceptionally fair with respect to supporting legitimate research and efforts to circumvent what amounts to minimal restrictions on information jeopardizes the continued goodwill between industry and academia with regard to sharing proprietary information (at the other extreme is DEC; has anyone ever tried to get a source license, or even a technical description of LAT?). It is also the case that whoever operated the scanner from which the data you used was obtained had a contract with GE to prevent unauthorized disclosure of the data and tapes. These, after all, are not only proprietary, but also are parts of a patient's medical record, and as such, are a matter of professional confidence between the patient and the health care system. Strictly speaking, the disclosure of human CT scans derived from a medical context would require consent from the patient. I mention this only because as more and more commercial applications are being found for research information, access to that information is becoming increasingly limited. In the long run this trend may threaten the ability of academic centers to provide research and training opportunities at the forefront of technology. The trust relationship between academic areas and industry is essential to continued superiority of our educational system. It would be a shame to see it jeopardized by what are probably well-intentioned but misdirected efforts to provide access to proprietary information outside well-established channels. Sean McLinden Decision Systems Laboratory University of Pittsburgh