車牌辨識是需要高度計算量的工作，除了要辨識正確之外，如何縮短辨識時間也是一大學問！如果速度太慢，譬如從拍照到辨識成功需要超過一秒鐘，大概就沒有商機了！如果你的計算速度比需求速度更快，還可以改用比較低階便宜的電腦當作硬體，那就可以降低成本，提升產品的價格競爭力！

如何節省時間當然最重要的是演算法本身，譬如我用一樣的電腦(一部老舊的第一代i7)，一路研究車牌辨識近三年了！第一個版本的速度大約是320X480畫素的影像需要0.4秒！現在的平均速度大約是1280X720的影像需要0.15~0.2秒，就是說一秒鐘可以連續辨識約五六張影像！

這樣好像夠快了？但是如果我想放在更低階的電腦，或者去辨識快速通過的車輛，再快都嫌不夠的！以我們現在鎖定研發中的路邊攔查車牌辨識系統來說，如果攝影機對準一個十公尺寬的車道，時速一百公里的車子飆過去，在鏡頭內停留的時間約0.36秒，我目前系統只能抓到一兩次，如果剛好影像有點瑕疵，我的辨識意外失敗一次，就可能完全錯過了這輛車子！

更糟糕的是我之前的停車場版本是不需要考慮紅底白字的遊覽車，或綠底白字的工程車的！這兩類的車牌因為字是白的，同樣影像必須用負片方式辨識才能看到車牌，現在路邊攔查的系統要同時能辨識這兩種大型車的車牌，就會讓我的系統又慢上一倍！如果無法妥善處理這個問題，我的系統就有可能不時會「漏車」了！

所以我最近積極的開發完成了多執行緒的車牌辨識版本，就是將車牌辨識的幾個主要程序像生產線一樣的分開，建立成獨立的執行緒，只要電腦有多核心時，就可以同時進行如同接力賽方式的運算，幾個CPU核心同步運轉，好像餃子店包水餃，一個人擀皮，一個人包，一個人拿去下鍋煮，出菜速度當然會快好多倍！

但是到底多快呢？今天終於有時間寫程式去測試看看了！在我的電腦上跑，依據畫面的複雜度，最少時是一秒十多張，多數時候約每秒20幾張！這樣即使碰到飆車族，也可以一晃過去就辨識到至少五六個畫面，通通辨識失敗的機率趨近於零！這下真的只有UFO才逃得掉了！哈哈！

其實有這個想法已經很久了！但是畢竟每一個完整的辨識還是需要一樣的時間，對於低速通過的停車場情境來說，將辨識流程分工為幾個執行緒不會讓工作更快！就像一個公車的體系，每輛公車從起站到終點的時間始終還是一樣的，如果你在乎的是「某個人」的單次行程時間，階段性的分工不會比較快，而且工作需要銜接，可能還會比單一執行緒還變慢一點。但是如果你在乎的是整體運輸量！那麼我讓每一個車站都持續有公車在進出載客，整體的流量就大增了！所以這個新系統讓我有了積極研發的動力。

當然，因為車牌辨識流程很複雜，很多程序還會互相糾結纏繞，要將它們如切香腸一樣乾淨俐落的「切開」，還要能完美的協力完成整個辨識過程其實很難！這也是只有完全擁有並理解自身演算法的團隊才能做到的事情，我做到了！也表示我將自行研發的優勢又擴大了一步！沒有多執行緒的系統除非演算法比我快上四五倍，不然怎麼努力都會比我開發的系統慢了！