Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!ADS.COM!Vision-List-Request From: Vision-List-Request@ADS.COM (Vision-List moderator Phil Kahn) Newsgroups: comp.ai.vision Subject: Vision-List delayed redistribution Message-ID: <8909010416.AA01739@deimos.ads.com> Date: 1 Sep 89 05:12:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Vision-List@ADS.COM Distribution: inet Organization: The Internet Lines: 210 Approved: vision-list@ads.com Vision-List Digest Thu Aug 31 21:12:58 PDT 89 - Send submissions to Vision-List@ADS.COM - Send requests for list membership to Vision-List-Request@ADS.COM Today's Topics: GIPSY Re: some ideas on image analysis methods & vision ---------------------------------------------------------------------- Date: Sat, 26 Aug 89 15:15:28 PDT From: rameshv@george.ee.washington.edu (Ramesh Visvanathan) Subject: GIPSY Organization: University of Washington A recent article referenced GIPSY and cited that it ran very slowly under VMS. GIPSY was primarily written to provide a flexible environment for the researcher and it was intended to be very user-friendly. Speed was not of primary concern at the time of design of GIPSY. While all the old GIPSY code was written in RATFOR (Rational Fortran), new code being added to GIPSY is written in C. Further new GIPSY code provides for dynamic memory allocation, unlike the old RATFOR version. Hence, new GIPSY uses less memory. As far as usage of disk space is concerned, unless the system we are working with has unlimited image buffers one has to use the system's disk space to save processed images. From the GIPSY environment the user can delete or compress unwanted images. I agree that the old version of GIPSY was slow because of reading/writing from disk files. We are currently attempting to speed up GIPSY by using a large internal buffer to manage the number of I/O situations. We expect the speedup to be substantial. About GIPSY's documentation and its ease of use, with SUN GIPSY we now have a set of demo files which instructs the user about GIPSY file formats and GIPSY commands which use them. In addition, the working of each GIPSY command is tested by a GIPSY runfile (which is nothing but a batch file to test the command) and often the kind of preprocessing necessary for the command is given in the runfile. The document files may not explain the preprocessing necessary, but the runfiles give the sequence of GIPSY preprocessing commands that can be used to generate the test data set for using a particular GIPSY command. I give below the documentation file for the GIPSY RAG command and also the run file used to test this command. RAG.DOC *RAG Region adjacency graph VERSION: A.01 DATE: 09-15-80 AUTHOR: LINDA SHAPIRO , T.C.PONG ACTION: Given a symbolic image the command RAG, this command outputs two random access files representing the region adjacency graph of the image.The point file contains the pointers to and the adjacency lists for each region; point(i) has two fields: first is the pointer to the adjacency list for region i in the link file; second is the number of regions in this adjacency list the link file contains 16 region numbers (integers) per record; each adjacency list starts on a new record. SOURCE: Disk, input file name ( symbolic ) DESTINATION: Disk, 2 Random access files: point file and link file point file -- integer records RECORD I: pointer and number of neighors for region i link file -- integer records records in the link file are pointed to by the point file; there are 16 elements/record. FLAGS:(E) If the E flag is used then four neighbors are used. (F) If the F flag is used then eight neighbors are used. QUESTIONS: (1) The user is asked which band of the image to process and for two integers representing the highest and lowest numbered regions to be processed. (2) An option is given on four or eight neighbor adjacency COMMAND STRING EXAMPLE: RAG POINT.FILE , LINK.FILE < IMAGE.LBL Creates a region adjacency graph for the symbolic image named IMAGE.LBL. Put the pointers and lengths of the adjacency lists in POINT.FILE and the elements of the lists in LINK.FILE (in binary). ALGORITHM: For each line i in the image for each pixel labeled j in line i for each pixel labeld j' that is horizontally adjacent to the pixel labeld j on line i or vertically adjacent to it on line i+1 add j to adjacency list j' and add j' to adjacency list j end end end COMMENTS: Currently the point and link files are binary files and are initialized to have a maximum of 2000 records. The point file contains the pointers to and the adjacency lists for each region; point(i) has two fields: first is the pointer to the adjacency list for region i in the link file; second is the number of regions in this adjacency list the link file contains 16 region numbers (integers) per record; each adjacency list starts on a new record. "rag.run" $ ! TESTING THE COMMAND RAG $ ! CREATE A CHECKERBOARD AND MAKE IT A SYMBOLIC IMAGE $ ! $ MKCHK CHK.SYM 10 10 5 5 1 2 0 $ ! $ ! $ ! USE THE EXSIF COMMAND TO CHANGE THIS IMAGE TO SYMBOLIC IMAGE $ ! $ EXSIF OPEN CHK.SYM PROT OFF MID 1 1 MID 2 2 MID 18 1 DONE $ ! $ ! TESTING THE COMMAND RAG $ ! $ RAG CHK.PT4,CHK.LK4 < CHK.SYM 4 $ ! $ ! TEST THE COMMAND RAG USING THIS PROPERTY FILE $ ! $ PRTRAG TT Subject: Re: some ideas on image analysis methods & vision A previous posting wrote: >I have written down some ideas on the relevance of certain image analysis >methodologies (Fourier analysis and mathematical morphology) to vision. >They are not finalized, but a few people around have told me that the question >is interesting. I would like to have other people's thoughts on the subject. >So, if you think you have something to say about it, feel free to ask me a >copy of my working document, and if you are brave enough, send back any >comments. > PRLB Working Document WD54, June 1989 > Fourier analysis, mathematical morphology, and vision >Abstract: >etc... Yes, please, I would like to read your working document. In my opinion this is the kind of work that is needed in computer vision presently. I'm not sure that morphology should be done away with like you suggest, but rather combined with the signal processing methods. However, it is hard to comment only on the abstract. Btw, I'm a member of prof. Per-Erik Danielsson's image processing lab. I'm primarily working with morphology algorithms, and I have published a few conference papers. I believe that I'm knowledgable enough to comment on your work. Please send the copy to: Ingemar Ragnemalm Dept of Electrical Engineering Link|ping University S-58183 Link|ping SWEDEN . . where the "|" are "o" with two dots above, like: O Yours, Ingemar Dept. of Electrical Engineering ...!uunet!mcvax!enea!rainier!ingemar .. University of Linkoping, Sweden ingemar@isy.liu.se ------------------------------ End of VISION-LIST ********************