http://www.opencv.org.cn/forum.php?mod=viewthread&tid=34096
| Opencv內部提供了一個基於Hough變換理論的找圓算法，HoughCircle與一般的擬合圓算法比起來，各有優勢：優勢：HoughCircle對噪聲點不怎么敏感，並且可以在同一個圖中找出多個圓；反觀擬合圓算法，單純的擬合結果容易受噪聲點的影響，且不支持一個輸入中找多個圓 缺點：原始的Hough變換找圓，計算量很大，而且如果對查找圓的半徑不加控制，不但運算量巨大，而且精度也不足，在輸入噪聲點不多的情況下，找圓效果遠不如擬合找圓；為了提高找圓精度，相比擬合法，需要提供更多的參數加以控制，參數要求比較嚴格，且總體穩定性不佳 OpenCV內的HoughCircles對基礎的Hough變換找圓做了一定的優化來提高速度，它不再是在參數空間畫出一個完整的圓來進行投票，而只是計算輪廓點處的梯度向量，然后根據搜索的半徑R在該梯度方向距離輪廓點距離R的兩邊各投一點，最后根據投票結果圖確定圓心位置，其示意圖如圖1 <ignore_js_op>  圖1是比較理想的情況，輪廓點1-6的梯度方向都經過了點7，因此都給點7投了一票，點7得分最高，也正是我們所要找的圓心；同時由此可以看出基於參數空間投票法來確定圓心，8-12點就算有投票，但由於投票太散，對整個投票結果也幾乎不存在干擾，因而其天生抗干擾能力要比擬合法好不過在這種思想優化下，也存在致命的缺陷，如圖2： <ignore_js_op>  實際情況是該點算出的梯度方向其實總是有誤差的，有時因為圖像原因或結構原因，偏差甚至超過30度；圖2中由於梯度方向不精確，7點基本沒有獲得投票，反而不如ABC點。因此實際使用中HoughCircle的效果並沒有想象中的理想，情況往往如下列所述： （參與投票的輪廓點如圖3的右圖，噪點非常多，比想要查找的輪廓本身還多，而且斷斷續續的，顯然這種情況擬合法不適用） 1、半徑范圍限定不好時，如圖3，可能找到的圓非常多且雜亂無章 <ignore_js_op>  <ignore_js_op> 2、在此情況下，如果只輸出一個圓（Opencv的HoughCircle會默認按照投票結果的累加值排序），最好的圓是這樣的，竟然差這么多  <ignore_js_op>  3、假設我們找的東西的半徑我們是知道的，變化不大(+-8%)，現在限定下半徑。。。找出的排的靠前的圓是這樣的；再看下默認最好的圓。。。 <ignore_js_op>  <ignore_js_op> 半徑好像接近了一點，還是好坑爹啊。。。4、常規來說，使用該函數的時候，為避免找到太多的幾乎重合的圓，找圓的最小距離都設在一個比較合理的值（比如大於半徑1/5）,這樣在找多個圓的時候，就不會找出太多重合的圓了；不過這里我試下不限制最小距離，如下，默認排序下得分最高的幾個圓如左圖： <ignore_js_op>  <ignore_js_op> 貌似默認最好的圓並沒有任何改善很多初次使用該函數的看到這，或許就就覺得HoughCircles效果不咋地。。。本人剛開始使用時也感覺Opencv提供的這個算法太不穩定了，只能對某一個圖調出相對好一點的效果，換一個圖或者只改動其中某一個參數，找出來的圓就不知道跑哪去了，而且變化太大了 。。。觀察細心的可能發現了，第4步中的左圖找出的眾多圓其實已經比前面找出的圓靠譜很多了，而且這么多圓必定有一個圓就是我想要找的圓，只是按照投票分數排序下，最好的圓偏差較大。 但究其算法優化本身，輪廓梯度定位出來的圓心投票本來精度就低（如圖2），自然找出來的圓會有很多是錯誤的，但如果輪廓點足夠多，找出的正確的圓必定也是存在的，只是按照票數方法來評價可能排序會比較靠后，但畢竟也是出現了的；此處只需做個小小的優化，改下評價方法，優化下排序，結果就很接近了 <ignore_js_op>  這是經過優化排序方法后找出的最好的圓找出來的圓中與實際輪廓重合度最高的圓一般就是我們要找的圓；因此我們可以通過HoughCircles來找出一批差不多的圓（如步驟4），然后畫出這些圓，和實際輪廓比對一下，按實際重合像素的總數排序，這時分數最高的圓就如上面的結果圖！HoughCircles優化一下還是很給力的！ 附件為本算法優化源碼，有興趣的可以一起來進一步優化（qq:970117454）  |
<ignore_js_op>
-
最終優化結果
-
測試原圖
-
-
13.77 KB, 閱讀權限: 1, 下載次數: 3127
HoughCircle優化源碼