上面兩張圖是我這幾天突破動態辨識速度的重大進展！我用兩個影片播放的畫面，模擬四個車道的連續影像，每個畫面大約五十萬畫素，一三與二四是辨識一樣的區域。關鍵的參數是圖上的「21.9Hz」，這表示每一車道每秒鐘會辨識21.9次，四車道就是大約作88次的車牌辨識了！平均辨識單一影像的時間是39毫秒！看看原始辨識資料，真的是每0.0X秒就有一個辨識結果出爐！

我研究動態車牌辨識接近兩年，推出正式產品也快一年了，前一階段的速度大約是作到四車道12Hz！所以這幾天的進展是很巨大的！最重要的是我的辨識核心辨識程序並沒有簡化打折扣來節省時間，裡面裝的是我辨識能力最完整的辨識核心版本，就是那些歪斜骯髒的車牌都很能辨識的最佳版本！連車門上的車牌都行！如下圖。

速度進步的原因一方面是來自「節流」，就是在演算法方面更為精簡不必要的運算，原本辨識一張五十萬畫素的影像約需60-70毫秒，現在不到50；另一方面是「開源」，就是更正確有效地配合電腦硬體資源，改善多執行緒與畫面擷取的流程所致。細節就暫時保留當作商業機密，錢賺夠了再公開分享，哈哈！但是這樣會不會把電腦操壞啊？看看下面的圖你應該就會放心了！

我的電腦是四年前買的i7，有八核心16G的記憶體。跑起來最吃重的是CPU，也不過60幾趴而已，記憶體的用量更省，其實8G就夠了！記憶體用量少是演算法設計良好的紅利之一，大幅減少不必要的陣列使用與記憶體轉移也是演算加速的關鍵！

但是有必要快到這麼變態嗎？眨個眼睛就需要0.1秒了，看到車子一秒鐘之內有結果就已經很夠用了！一秒鐘辨識二十幾次是要幹嘛啊？是的！前面的狀態是火力展示，以及軟硬體配合的極限測試。實務上我會用程式控制讓它自動控制速度到大約同一車道一秒辨識十次就可以了！這也是近期研發的重點之一！我的辨識速度機制從手排變成自排了！使用者不必再自己調整執行緒等等複雜的參數來控制速度了！降速到10Hz之後CPU用量就只需30幾趴了！厲害吧？

這次的研發突破，速度快了約六七十趴，也給了我更大的產品設計空間，如有必要我可以將四車道的產品推進到六車道甚至八車道的應用！當然那時就必須有雙螢幕了！不然就是可以辨識較少車道，但是車速更快，或一畫面內車子更多的情境，像是路口監視器看到的馬路上奔馳而過的車輛們。

所謂的「動態」車牌辨識，表面上的意義是可以直接從連續動態的串流影像，也就是攝影機影像中辨識車牌，而不是一張一張的辨識。但是動態就可以連續辨識很多張影像，不只多張，也代表每一張的拍攝角度是不太一樣的！不利的角度可能辨識錯誤或無法辨識，但是資料很多時，總有夠多數量是對的！

如果你的辨識核心本身就很強，那正確的答案數一定夠多，用一大堆辨識資料統計出某一輛車的結果，一定比只拍一張就定案的車牌辨識系統正確率高，所以只要是辨識率>95%的辨識核心，用動態架構大量資料去統計，正確率就能逼近百分百了！

所以終極的高辨識率沒有僥倖，辨識核心本身一定要很好，必須又快又準！不然即使放到動態架構，因為速度慢辨識張數少，統計效果不會好，如果辨識容忍度差，偏斜一點就無法辨識，那就更無法累積有效資料數，於是動態也等於只像靜態辨識一樣，必須等車子到達特定最佳位置才能辨識成功一兩張了！

動態辨識不只是連續辨識而已，光是速度快慢就學問很大！所謂速度其實是指有效的資料量，不只是硬體好壞的問題，即使你的電腦取像速度極快，如果軟體辨識失敗或太慢也是無法提供足夠資料作判斷的！我的21.9Hz在有車時幾乎是百分百都有辨識結果的！如果是不好的辨識核心，眼睛看到車牌的影像可能只有不到一半是可以辨識出結果的，那資料提供量就太少了！

其實也是這兩天完成的一個技術發展，可能更有未來價值！就是我建立了連續資料的軌跡判斷演算機制，運用車牌在影像中位置的連續性，我可以確定是來自同一輛車，也就是已經有「追蹤」系統的資料型態雛型了！

現階段軌跡追蹤對我的幫助是避免了同一車次有多個辨識結果的尷尬！譬如某車牌的B與8字交互蹲跳，同一輛車可能會有0123-B8與0123-8B兩個結果。我如果從車牌位置的連續性知道其實他們是同一輛車的辨識結果，就可以放在一起整理統計後才輸出一個結果，即使最後還是錯了，也不會好像有兩輛車嘛！但是未來這個技術主要是將用在多車同時動態辨識之用，譬如下圖：

一個畫面四張車牌，連續畫面也都有四張車牌，要作動態統計怎麼辦，當然要先分類出哪些辨識結果來自同一輛車吧？這就是軌跡追蹤的意義，四輛車就會有四條軌跡，每條軌跡內辨識結果不保證一樣，我們必須在「軌跡內」作統計就不會錯了！台北市警局就問我有沒有這種辨識軟體，我就說有！還畫出軌跡給他們看！

這些想法對我來說還不算商業機密，大家一起努力都可以！當然能看中文的人會比較有利，多幫幫自己人嘛！哈哈！野人獻曝，大家一起努力囉！