找圓演算法（(HoughCircles)總結與優化
    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優化一下還是很給力的！ 【關鍵是可重入性。但是從原理到應用，甚至用於演算法庫提交，都值得來做】