車牌辨識軟體的首要目標，當然是要盡量準確！就是除了清晰好辨識的車牌一定要能正確辨識之外，「不好辨識」的邊緣狀況也要能盡量辨識。真實世界總是不會完美的！即使車牌本身很完美，安排攝影者的專業程度或受限於環境，拍攝得不完美，我們的軟體也要盡量努力辨識出來！這就是我認為的「人工智慧」研究了！我的競爭對手並不是號稱辨識率多高的同類廠商，而是你我的眼睛！

準確性達標了，接下來就是要努力提升速度！車牌辨識通常是即時系統，停車場辨識好車牌就應該立即開閘門，辨識時間超過兩秒就GG了！昨天才被某客戶抱怨我的車牌辨識軟體「反應太慢？」其實只是我的軟體統計判斷門檻設高了！要辨識很多次才發出確認通知，事實上單張影像辨識不過50毫秒左右，要快可以快到好像立即反應，參數調整一下就好了。

以目前的電腦水準，像停車場這種低速近距離的辨識環境，辨識速度一定夠快！但我還是繼續努力提升辨識速度，這樣就可以用一個軟體在一台電腦上提供多個車道的辨識服務！我的標準產品是四車道的動態辨識，每一車道每秒可以辨識到20次以上！那就是每秒辨識80多次，夠快了吧？當然這種速度不只是演算法要好，還必須有多核心電腦的平行運算加持。

速度快的另一種用途就是在馬路上的車牌辨識，路上跑的車子當然是不會停下來或減速讓你辨識的！而且馬路比較寬，拍攝的視野比較大，還可能有多輛車同時在畫面中，在叢林中抓狂奔的兔子當然比在雞籠裡抓一隻雞難上很多！這時考驗的重點又回到演算法的研究了！簡單畫面的辨識幾十毫秒，複雜畫面的辨識也不能成倍數增長，不然就跟不上車行的速度了！

我狂飆車牌辨識速度的研發算是成功的！所以四車道軟體賣得不錯，甚至已經在研發六車道版本了！馬路上的多車全景辨識方面，我的速度也是非常驚人的！以往車載辨識系統看路邊車輛的他牌軟體，速度到三十公里就甚麼都看不到了！我可以做到時速五十公里時都還辨識率高於八成，路口監視器多車道辨識的系統辨識率更達到九成！同步在台北街頭PK的其他廠商只能望塵莫及了！

但是達到這些里程碑之後我開始有一些隱憂，就是這麼高速的持續運轉並不是一般電腦與作業系統預設的狀況！如果CPU總是跑到90%以上，還長時間在戶外酷熱的環境，會不會很容易當機啊？我大量高速處理這麼多影像，圖像記憶體轉移非常頻繁快速，事實證明程式跑久了，就是會有偶爾隨機發生的記憶體錯誤。這些都是可能讓我的程式執行異常、卡住、甚至當掉的不定時炸彈！

以我目前的經驗，電腦硬體都做得很好了！我自己沒碰過電腦過熱當機之類的狀況，或許我的客戶有過，但應該極少發生。不過為了降低電力消耗(環保)與延長硬體壽命，我還是做了一個動態偵測的軟體機制，就是畫面如果趨於靜止時，實際辨識頻率會大幅下降，等於讓電腦在沒客人時就輪休放假。

多數不穩定的因子其實都是來自作業系統，第一種是多執行緒的錯誤，將每個辨識工作獨立為一個背景執行緒，偶爾就是會因為作業系統調配切換資源的失敗，或者我的程式中真有些很隱晦的BUG，讓辨識過程無法完成。如果你不理它，它就會永遠占住一個記憶體位置不結案，最終當然是記憶體不足囉！所以隨時檢視這些執行緒，逾時的就必須用主程式強制關閉，這是第一個必要的管理機制。

其次最常發生的意外就是圖像拷貝與移轉時發生的錯誤，這一部分也是跟我寫的辨識演算法無關的，更尷尬的是通常與電腦硬體有點關係！一樣的作業系統，一樣的程式，在我的電腦幾乎不會發生的Bitmap錯誤，到了客戶的電腦卻時常發生？這樣被客訴蠻難處理的！程式改了也不確定有效，電腦不一樣嘛！

我無法讓這些意外絕對不發生，就像我們沒辦法保證人不會感冒一樣！重點是如果意外發生了，我的程式該如何處理？讓使用者不必手動開關程式或電腦？這些問題確實困擾了我很久，實在不知道怎麼辦時，就只能請客戶降低辨識頻率或車道數，不然就是換好一點的電腦。但最佳的方向應該是軟體永遠可以自己從錯誤中復原，即使因此降低一些效能也是可以接受的，但必須人為介入處理就不好了！

還好，現在我已較能掌握影像錯誤時的有效處理機制，就是必須使用到較低階的記憶體處理程式，更精確的清理發生錯誤的記憶體，希望以後我的軟體可以達到：又快、又準、又穩定的境界！