我目前的動態車牌辨識軟體都是以擷取電腦螢幕的畫面做辨識，當然我知道影像來源是某個IPCAM攝影機攝得的影像，以串流格式資料傳遞到電腦的。我是等電腦的作業系統、瀏覽器或播放軟體將串流格式的影像解碼變成標準的單格數位影像，顯示在電腦螢幕時，再到顯示卡的記憶體中直接取得已解碼的單張影像，作為我辨識的標的。其實就是大家都會用的：螢幕拷貝！Copy Screen啦！

我真的已經太多次被「專家們」詢問，甚至質疑！為什麼不直接讀取IPCAM傳來的串流影像做辨識？經過「螢幕轉接」不是比較沒效率嗎？這樣不是「必須」讓螢幕一直擺在那邊才能辨識嗎？人家用一個辨識盒接上攝影機的串流影像就能直接辨識車牌，不是比我高明嗎？我的設計真的太遜了嗎？

這真的是一個大哉問！我即使寫上五千字的文章也很難說得清楚，但是我真的有一肚子的經驗與理論支持自己的作法，目前我還是認為我的方式是對的！是最好的資料流程架構選擇。我以開放的心態接受所有質疑者與建議者的意見，但是真的還沒有人可以用明確的理論或實證說服過我！

理論上最「直接」的做法是：攝影機的感光陣列第一時間取得的未壓縮影像時就立即接上我的演算法進行辨識！那表示我的演算法必須和攝影機結合，攝影機裡就必須有可以順暢運作我的動態高效能軟體的i7等級電腦與作業系統，他們說那樣作攝影機太昂貴！

那就退一步，攝影機將資料傳給正常的電腦處理吧？但是如果直接傳遞連續的單格未壓縮影像，那網路資料流量就太大了，所以才需要串流壓縮嘛！既然壓縮了，到了電腦端，餵給我的程式之前總要解壓縮的！問題是誰來做這件事？須知影音串流的市場需求太大，大家都要看網路影音，壓縮解壓縮技術影響觀看品質甚鉅，所以作業系統與各播放軟體無不卯足全力提升壓縮解壓縮的品質與效率！

可以預期，「串流轉影像」這件事絕對不是簡單業餘水準的工作，Windows作業系統常常更新，裡面鐵定有提升這部分工作品質的程式。所以如果你以為找到網路上的「解碼程式」自己來做「串流轉影像」這件事，就會跟螢幕擷取的影像品質與效率一樣好？根本不可能！最多只是品質差不太多，但是解碼速度也會差很多！就像我會打籃球，但不會以為自己可以和NBA球星比較，差多了！

所以自己找串流轉影像的程式「整合」到我的軟體內，始終不是我覺得有意義的工作！這叫吃力不討好，很像明知有捷運這種東西，他們天天都在傾洪荒之力讓車速更快，讓你坐得更舒服，你不去坐，卻堅持要自己開車穿過整個台北市區去上班？我如果搬家到台北，第一件事就是將汽車賣掉！

最近的經驗是終於有合作廠商找到會寫串流轉影像程式的專家，給了我一個程式專案，要我嘗試將這種功能整合到我的程式內！但是很誇張的，他給我的專案內含很多我也不懂功能與目的的DLL檔案，整個專案的大小高達52M！而我的動態辨識程式執行檔只有300多K！也就是為了這個即使作了也未必效能比較好的功能整合！我的程式大小會暴增到150倍！只是為了解碼？可以買便當解決的晚餐，我變得需要花幾百萬買一塊地蓋一間廚房？

表面上我的程式如果自己作串流解壓縮就「跳過螢幕」直接跟攝影機溝通了！似乎效率會更好？但其實螢幕並不是重點，重點是電腦作業系統或播放軟體為了讓使用者看到螢幕上的影像，所作的串流資料解壓縮的動作！我只是搭便車，當他們解壓縮畫面後我直接取用！反正我的程式必須在電腦作業系統下運作，我的「同事」就是解壓縮的專家，他也願意幫我做，我還堅持要自己作傻事嗎？

那硬體的車牌影像辨識盒是怎麼回事？一個一萬元左右，比一般電腦便宜很多，還不必另買軟體？更不必使用螢幕！比我的軟體還必須搭配幾萬元的好電腦，不是強太多了嗎？大家只要試問裡面會有高效能的i7等級CPU與作業系統嗎？它可以執行跟我的軟體一樣的高效能辨識嗎？它可以執行跟電腦作業系統一樣好的串流解壓縮嗎？試問一顆頂級CPU的價格是多少？簡單說就是：因陋就簡！一萬元的微電腦，別幻想它有多好的效能了！

所以業界對於軟硬體系統整合的迷思成見真的還不少！我這個純軟體專家還有得辛苦的！