我提了一下準備做藥盒辨識的議題，很多機器學習或深度學習的建議又來了！顯然在這個 AI 的新時代，機器學習變成顯學了！事實上我對此也是略知一二的，但實際操作的技術上確實是沒經驗，但我估計研發的時間與取得足夠樣本或資料庫的成本較高，讓我不會將機器學習當作最佳的選項，甚至我判斷較適合用這類方式解決的案子，就直接推辭或推薦別人做了！

很多人會懷疑：「你根本不用機器學習的技術，做那麼多影像辨識的工作不會受到限制嗎？會不會很多事做不好？做不快？或做不出來啊？」就像某位老闆居然沒有手機？這不會影響做生意嗎？其實目前對我來說是不會的，原因且聽我道來！

我目前的工作可以算是OCR(Optical Character Recognition，光學字元辨識)，就是讓影像中的文字變成真正可以在電腦中被識別編輯的文字資料，車牌辨識其實就是其中一個最廣用的案例！我以研究車牌為起點，意外地受到業界重視，開始幫忙很多領域去影像中「找字元」！掃描文件是在2D的基礎上做，拍攝的照片則是在3D的基礎上處理，前者已經不簡單了，後者變數就更多！

OCR包括兩個主要階段，先是要在影像中鎖定正確的字元位置，其次才是依據鎖定的目標區塊開始翻箱倒櫃，用資料庫中的資料比對出那是甚麼字(或圖案)。那些翻箱倒櫃辨識奇形異狀文字的工作目前的OCR軟體已經做得很好，是個和作業系統一樣成熟龐大的商品，所以這部份根本沒我的事！車牌辨識因為只需辨識少數的字元與字型，這部分我就簡單自己做了，不必買OCR軟體，如果買了就賠死了！

事實上機器學習的強項是和OCR軟體類似的！主要用於「認知」那個圖案是甚麼意義！目前我除了做車牌辨識之外，最大項的工作就是替以OCR為基礎，推出影像辨識軟硬體商品的公司服務。他們需要我幫忙的當然不是如何辨識奇奇怪怪的字，而是處理從原始影像中正確抓出字元區塊的這個步驟！

如果OCR或機器學習軟體完全沒有字元在哪裡的起點資訊，那就必須在原圖上逐點掃描，甚至也不知道目標大小，一個字模上是10x20的字型，在原始影像上可能是任何寬高比1:2的圖形，加上會傾斜甚至變形！OCR或機器學習軟體即使能跑出正確結果，所需時間也會慢到讓人無法接受的！OCR本身當然有「基本」的字元鎖定程式，但是能力有限，碰到印刷複雜或不是極清晰的影像就很容易辨識失敗。

所以我做的工作很像二廚替大廚準備食材，就是影像處理必要的準備步驟，灰階化→二值化→輪廓化→切割為獨立字元目標。簡單嗎？很難的！因為狀況非常多，如前面的圖形吧？點矩陣列表機印的文字，在影像上根本就是分離的目標，如何「融合」它們成為一個單一目標送給OCR辨識就是個很難處理的邏輯。相對的，印刷字太擠，影像相連沾在一起時，兩個字被當作一個字送去辨識，OCR當然沒這麼聰明，怎麼比對答案都是錯的！此時我就必須「切香腸」，正確切開相連目標之後才能餵給OCR。

所謂機器「學習」就隱含了嘗試錯誤的意義，感覺上OCR資料庫是死的，機器學習多了一些想像的空間，好像他會累積經驗？或至少比定型資料比對更有彈性！但是各位可想到運算時間的問題？OCR軟體目前很貴，主要原因就是它可以非常快速的從非常多的可能字元中比對出結果，它的價值是「快」不是聰明！所以這些年它不但沒有被機器學習軟體取代，還繼續保持很貴！

當然這些跟我的工作算是無關的，即使是辨識藥盒上的字串，他們也不是要我「翻譯全文」只是要抓出批號與過期日，我的大麻煩並不是「字很奇怪」而是字的位置範圍不好確定，必須有一個程式在任何顏色、字元大小與印刷方式下，即使字元沾連或破碎我都能正確圈出那些字來辨識，因為字的可能性不會太多，我不會用OCR，不然買授權就是我自己工作報價的好多倍了！

我「暫時」不用機器學習的原因也差不多！用機器學習機制來辨識字元，對我目前的需求來說沒必要。至於用機器學習幫我判斷字元形狀位置？判斷目標是否需要融合或切割呢？這是抽象思考，AI目前還沒這麼聰明啦！如果放手讓他們「自我學習」可能會算到天荒地老！使用軟體的客戶鐵定會抓狂的！請記得：機器學習的弱點是需要很多計算，你的手機或PC效能可以跟Alphago相比嗎？

所以不要誤會我對機器學習有偏見！還誤會我是自己不懂才故意不用的！真的不是這樣！我曾經最討厭JavaScript，但是HTML5興起後，一年之內我就變成JS的專家，還能教學生用JS寫出類似Line的通訊軟體！晚期的學生以為我一直都是寫JS的人！學姊返校跟我創業時卻很驚訝：「老師你不是一向喜歡用VB，很討厭JS的嗎？怎麼學弟們最熟練的語言是JS，而不是VB了？」以此觀之，我是堅持抗拒新科技的老頑固嗎？你們自己判斷吧！