Contents ...
udn網路城邦
慢慢來比較快?
2017/09/18 05:53
瀏覽946
迴響0
推薦9
引用0

要做出一個可以辨識車牌的影像辨識流程是很容易的,任何有相關知識的人都能做到!有了OpenCV之類的軟體程式庫之後,那就更加簡便,誰都能做的!但是要做出一個商業化的車牌辨識軟體,不僅要能處理各種模糊邊緣的狀況,讓整體辨識成功率盡量提高,同時還要兼顧辨識速度夠快!那就是永無止盡的研發競爭過程了!就像跑步誰都會,但要跑到可以拿奧運金牌就是另外一回事了

一般大學研究團隊的車牌辨識研究,我覺得都是避重就輕!一種是大談「應用」端的功能,譬如辨識出車牌之後可以查贓車,那其實不是我說的車牌辨識研發。另一種是強調他們用了某種「新」的演算法,所謂的「新」也只是之前發表的論文中,好像沒提過用這種演算法做車牌辨識的某個程序,他們只是嘗試使用了,並不是他們自己發明了特殊的演算法。

這種「新方法」的實驗我們天天都在做的!早上想到此法或許有用,立刻就開始寫程式測試,到了下午就可以證明此法好不好用,不是放棄就是整合到我們的軟體之中。在我們只是一兩天的工作卻是多數大學研究團隊的一個研究計畫或一篇論文的大部分內容!因為他們的目的是「完成某個實驗」而不是完成某個可以銷售的產品,所以通常都是極端浪費時間的,不能期望他們能做出甚麼有用的東西?

我這邊的研發就熱鬧了!每一個車牌辨識的案子針對不同的情境,影像品質與性質不同,我們都會針對性的研究不同的演算法來因應,可以通用的好程序演算法就會加入到我們主要的產品之中。讓我們的主要辨識核心能辨識的容忍度範圍越來越大的同時,我們也必須時時兼顧到執行速度不能太慢!

譬如某些程序可以辨識字元破損或髒汙的車牌,但是計算比較耗時,那就只賣給不在乎辨識時間,只在乎最高成功率的使用者!另一方面,如果客戶是在馬路上辨識快速來往的車輛,只想快速辨識出最多的車子,那就要用快速版的辨識程序給他們了!

剛剛處理完的一個有趣案例是:有位客戶給了我一小段影片,說用我的動態辨識軟體會辨識不出來,我一看就知道是因為拍攝時周邊環境較暗,影像畫素偏低,加上車燈干擾,焦距也不太準,車速還不慢!好幾個不利的條件交集下,我的軟體確實容易辨識失敗。

於是我想到最近替某公司開發的路邊停車照片用的辨識核心,那就是對於模糊容忍度較大的版本,如果辨識核心換成那一個就肯定會能辨識。我立即動手測試也真的如我預期,辨識得很準。但是我知道以單張辨識時間來說,每個辨識程序大約會多出兩成以上的時間,因此擔心用了新的辨識核心,動態辨識軟體的執行速度會不會太慢?

讓我意外的是:即使單張辨識的時間真的多出了約二十毫秒,但是整體多車道的辨識次數完全沒有變低!還隱隱然快了三五趴?我以為我的程式有錯誤,所以仔細檢查了一遍。原來因為較慢的辨識程序成功率變高了,很多重複的辨識就會被我的動態程式忽略或簡化,整體的成功辨識流量反而增加了!就像一路連勝的球隊就不必多打額外的比賽一樣,這真是意外的收穫!

簡單說,我的主要產品「四車道動態車牌辨識軟體」又進化了!進化到本來需要特殊處理程序才能辨識的較昏暗或字元磨損的車牌,現在用標準版軟體也幾乎都可以直接辨識了!

有誰推薦more

限會員,要發表迴響,請先登入