home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / sci / image / processi / 1696 < prev    next >
Encoding:
Text File  |  1993-01-25  |  9.1 KB  |  263 lines

  1. Newsgroups: sci.image.processing
  2. Path: sparky!uunet!mcsun!julienas!edf.edf.fr!cli23ne!ponthieu
  3. From: ponthieu@cli23ne.edf.fr ( Laurent PONTHIEU )
  4. Subject: Efficient algorithms for math. morphology : SUMMARY
  5. Message-ID: <1993Jan25.092906.24434@edf.fr>
  6. Sender: news@edf.fr
  7. Reply-To: ponthieu@cli23ne.edf.fr ( Laurent PONTHIEU )
  8. Organization: Electricite de France - DER , Clamart FRANCE
  9. Date: Mon, 25 Jan 1993 09:29:06 GMT
  10. Lines: 251
  11.  
  12. Hello,
  13.  
  14. some time ago, I posted a request for information about efficient
  15. algorithms for mathematical morphology (see the end of this posting).
  16.  
  17. Here is the summary of all private mails I have recieved. You'll have
  18. probably noticed that some answers were also given directly in this
  19. newsgroup.
  20.  
  21. Thanks again to all that helped.
  22.  
  23. Laurent.
  24.  
  25. ======================================================================
  26.  
  27. From weigl@sibelius.inria.fr Fri Jan  8 16:17:04 1993
  28. Return-Path: <weigl@sibelius.inria.fr>
  29.  
  30.  
  31. Pour toute question non triviale concernant la morpho mat, je
  32. suggere de contacter Michel Schmitt, au Labo
  33. Central de Recherche de Thomson (CSF ?), aux environs
  34. de Paris.
  35.  
  36. [ "please contact Michel Schmitt, at Labo Central de Recherche de
  37. Thomson" : schmitt@thomson-lcr.fr ]
  38.  
  39. Desole, pas de coordonnees.
  40.  
  41. Bonne chance,
  42.  
  43.  
  44. Konrad Weigl               Tel. +33 93 65 78 63
  45. Projet Pastis              Fax  +33 93 65 76 43
  46. INRIA                      email weigl@sophia.inria.fr
  47. B.P. 93
  48. 06902 Sophia Antipolis Cedex 
  49. France
  50.  
  51. ======================================================================
  52.  
  53. From ingemar@rainier.isy.liu.se Fri Jan  8 16:19:20 1993
  54. Return-Path: <ingemar@rainier.isy.liu.se>
  55.  
  56. In sci.image.processing you write:
  57.  
  58. >
  59. >    [ deleted ]
  60. >
  61.  
  62. I can't post, otherwise I would, but check out my recent paper in
  63. Pattern Recognition Letters:
  64.  
  65. "Fast erosion and dilation by contour processing and thresholding of
  66. distance maps", Pattern Recognition Letters 13 (1992), pp 161-166.
  67.  
  68. The algorithm does not allow arbitrary structuring element, so perhaps
  69. it is not the whole story, but I believe that it's impossible to make
  70. significant speedups over the straighforward implementations using
  71. arbitrary structuring elements. With my method, you can use circular or
  72. diamond-shape element, and with some modifications some other, but only
  73. convex shapes.
  74.  
  75. An older version of the paper is also in the Proc. of the latest Scandinavian
  76. Conf. on Image Analysis (SCIA).
  77.  
  78. -- 
  79. Ingemar Ragnemalm
  80. Dept. of Electrical Engineering         ...!uunet!mcvax!enea!rainier!ingemar
  81.                   ..
  82. University of Linkoping, Sweden         ingemar@isy.liu.se
  83.  
  84. ========================================================================
  85.  
  86. From schaefer@young.ece.cmu.edu Fri Jan  8 17:31:55 1993
  87. Return-Path: <schaefer@young.ece.cmu.edu>
  88. From: Roland Schaefer <schaefer@young.ece.cmu.edu>
  89. Organization: Electrical and Computer Engineering, Carnegie Mellon
  90.  
  91. In article <1993Jan8.131010.2436@edf.fr> you write:
  92. >
  93. > [ deleted ]
  94. >
  95.  
  96. I know we here use thresholded correlations to do our erosions and dilations. 
  97. We have a vector processor that does the FFTs pretty fast, and since we use 
  98. fairly large SEs, it's a lot faster than doing the work in the image domain.
  99.  
  100. Roly.
  101.  
  102. ======================================================================
  103.  
  104. From morse@cs.unc.edu Sat Jan  9 03:19:29 1993
  105. Return-Path: <morse@cs.unc.edu>
  106.  
  107. Erode and dilate can be written in terms of image translations and logical 
  108. and/or/invert operations on images.  If you have an efficient means for 
  109. translating images (such as efficient hardware block moves, shifts, etc.) 
  110. and for performing these logical operations, MM operations can be written 
  111. very efficiently.  Good luck.
  112.  
  113. -- 
  114. Bryan Morse                University of North Carolina at Chapel Hill
  115. morse@cs.unc.edu           Department of Computer Science
  116.  
  117. ======================================================================
  118.  
  119. From tmb@idiap.ch Sun Jan 10 12:03:21 1993
  120. Return-Path: <tmb@idiap.ch>
  121. From: tmb@idiap.ch (Thomas M. Breuel)
  122. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  123.     Perceptive)
  124.  
  125.  
  126.  
  127. For convex structuring elements, you can use the distance transform,
  128. which can be computed relatively quickly. But on 3000x3000 images,
  129. anything is going to be slow (several minutes for the DT).
  130.  
  131.                     Thomas.
  132.  
  133. ======================================================================
  134.  
  135. From wk5w@brain.med.Virginia.EDU Mon Jan 11 08:03:10 1993
  136. Return-Path: <wk5w@brain.med.Virginia.EDU>
  137. From: William Katz <wk5w@brain.med.Virginia.EDU>
  138. Organization: Medical Scientist Training Program, Univ. of Virginia
  139.  
  140. Hi,
  141.  
  142. I do alot of MM on very large images from MRI (256 x 256 x 128 voxels).
  143. The fastest way to do basic dilation/erosion/opening/closing is by
  144. using the Euclidean Distance Map as described by Russ' book
  145. Image Processing Handbook.  The first scan will store all border
  146. voxels/pixels in a queue, and then further erosion/dilation can
  147. be done from just those voxels/pixels in the queue.
  148.  
  149. -Bill
  150.  
  151. ======================================================================
  152.  
  153. From najman@thomson-lcr.fr Mon Jan 11 11:45:31 1993
  154. Return-Path: <najman@thomson-lcr.fr>
  155.  
  156. Pour ce genre d'algorithmes, lire la these de Luc Vincent 
  157. {Vincent90,
  158.     AUTHOR = "L. Vincent",
  159.     TITLE = "Algorithmes Morphologiques \`a Base de Files d'Attente et de
  160.         Lacets~: Extension aux Graphes",
  161.     HOWPUBLISHED = "Th\`ese Ecole des Mines de Paris",
  162.     MONTH = "May",
  163.     YEAR = "1990"
  164. }
  165.  
  166. Ou le livre de Michel Schmitt et Luc Vincent sur la M.M., qui sortira
  167. bientot (on espere).
  168.  
  169. A une prochaine visite au L.C.R.,
  170.  
  171.     Laurent Najman
  172.     A.S.R.F.
  173.     Thomson-CSF - Laboratoire Central de Recherches 
  174.     Domaine de Corbeville 91404 - Orsay Cedex / France
  175.     Tel : (33-1) 60 19 77 82 / Fax : (33-1) 60 19 71 20
  176.         / Telex : THOM 616 780 F
  177.     E-mail :     najman@thomson-lcr.fr
  178.  
  179. ======================================================================
  180.  
  181. From jjs@acd4.acd.com Mon Jan 11 22:35:42 1993
  182. Return-Path: <jjs@acd4.acd.com>
  183. From: jjs@acd4.acd.com ( James J. Song       )
  184. Organization: Applied Computing Devices, Inc., Terre Haute IN
  185.  
  186. I worked on the MM for a while. Since basic morphological transforms
  187. are very simple operations, especially for binary images, you can code
  188. the transforms without having to look for the existing software or
  189. fast algorithms.  As a matter of fact, I don't think those fast
  190. algorithms are really faster and most likely they are slower.
  191.  
  192. When you code, consider the image as an image plain. Than shift the whole
  193. plain around according to the structuring element and perform binary
  194. operation between the shifted plain and the unshifted one. The only thing
  195. you need to figure out is how to take care of the boundaries of the image 
  196. plain. I don't think the size of the code for each transform should 
  197. exceed 50 lines.
  198.  
  199. Since I am not working on that anymore and lost the interest in the
  200. area, I didn't keep my codes. So sorry that I cannot help with the
  201. code.
  202.  
  203. Good luck on MM research and development.
  204.  
  205. James
  206.  
  207.  
  208. ======================================================================
  209.  
  210. ORIGINAL POSTING :
  211.  
  212. > Path: cli23ne!ponthieu
  213. > Newsgroups: sci.image.processing
  214. > Distribution: world
  215. > Followup-To: 
  216. > From: ponthieu@cli23ne.edf.fr ( Laurent PONTHIEU )
  217. > Reply-To: ponthieu@cli23ne.edf.fr ( Laurent PONTHIEU )
  218. > Organization: Electricite de France - DER , Clamart FRANCE
  219. > Subject: Efficient algorithms for math. morphology : where are you ?
  220. > Keywords: 
  221. > There seems to be some interest here about mathematical morphology,
  222. > thus my question :
  223. > Does anybody know about _efficient_ algorithms for MM on binary images ?
  224. > Either article, book, ftp or _even_ commercial software.
  225. > Following Jose E. Hernandez's hint (of 14 Oct 92, in this newsgroup), I've 
  226. > bought
  227. >     "Morphological Methods in Image & Signal Processing" by C.R. Giardina
  228. >     & E.R. Dougherty, Prentice Hall, 1987, ISBN 0-13-601295-7,
  229. > which does not cover the question of algorithms efficiency.
  230. > I've also digged Khoros' lib without success : there, as everywhere I've
  231. > looked, opening and closings are implemented by composition of erosion and
  232. > dilatation, which in turn are made with brute force four level nested loops.
  233. > I must say that we work here on symbol recognition on binary images which,
  234. > at least for now, are 3000x3000 pixels large. Size is to increase for the
  235. > real application, and the results we've got make us think that we must not
  236. > abandon this method !
  237. > I have developed some algorithms inspired by classical string searching in
  238. > texts but I'm not fully satisfied because they do not work for arbitrary
  239. > structuring elements.
  240. > I've been told that contour or distance coding might be the good way.
  241. > What's you experience with all that ?
  242. > Feel free to answer. Thanks.
  243. > (I'll post a summary of personal answers, if any).
  244. > ------------------------------------------------------------------------
  245. >   Laurent PONTHIEU            |
  246. >   Electricite de France            | Tel: (+33 1) 47 65 56 38
  247. >   Direction des Etudes et Recherches    |
  248. >   Dept Traitement de l'Information    | Fax: (+33 1) 47 65 54 28
  249. >     et Etudes Mathematiques        |
  250. >   1, Avenue du General de Gaulle    | E-m: Laurent.Ponthieu@der.edf.fr
  251. >   92141 CLAMART Cedex, FRANCE        |      ponthieu@cli23ne.def.fr
  252. > ------------------------------------------------------------------------
  253.