這一個案例看起來似乎並不困難，但是我之前的版本居然會將那個最後面的貨櫃號檢查碼0辨識成1？對於客戶來說這當然是難以接受的！但事出必有因，追蹤一下辨識流程的二值化圖是這樣的：

目前我的辨識最困難最容易出錯的就是這個檢查碼了！很諷刺的，這個檢查碼是用來驗證前面的十個貨櫃碼有沒有隨機的辨識錯誤，譬如把某個9看成8之類的，但是檢查碼本身因為原始設計者多事，規定必須加一個方框跟其他正常碼做區隔，這個方框本身反而變成影像辨識最大的雜訊！如上圖，如果檢查碼沒有方框，根本就不可能出錯！

所以辨識結果最不準確的第一名字元就是檢查碼！你還要用它來「校正」其實比較可能正確的其他號碼嗎？所以我目前的版本是根本放棄用檢查碼做CheckSum的動作了！就是盡量讓我的影像辨識正確而已，如果正常碼都會辨識錯誤，同一影像中的檢查碼就只會更不可靠！還是不要多事，拿比較不可靠的資訊來糾正比較可靠的資訊了吧？

加了方框如果可以確實與內部的數字分離也沒事，但是方框與內部的字元距離極近，隨便拍都會與內部的字元若即若離！這個案例就更慘！方框還跟更外部的貨櫃邊緣特徵相連！等於把一個純潔的少年0一路拉進黑幫沉淪了！結果呢？0看不到了，但是方框本身的線條也破碎了，剩下左邊界的碎片(紅色部分)孤立出來，就像個1字了！

這就是影像辨識的真實、殘酷、也很荒謬的世界！你不會跟我一樣大罵那個決定檢查碼必須加框的笨蛋嗎？實在是無事生非，天下本無事，庸人自擾之，就是這個意思！即使是用人眼看，加了這個框也不會比較清楚啊？十足的神經病！害我的工作變得特別困難。

老實說，為了盡量解決這個方框造成的「雜訊」，讓檢查碼的辨識盡量正確，我多寫的程式碼已經有上百行之多！面對這個案例，我還要寫更多！首先是嚴格檢查確認那個1字是假的！這樣我就會知道我其實還沒找到正確的檢查碼，怎麼辦呢？一定會有個檢查碼的啊？那就依據已知的字碼大小去右邊挖礦了！當然也成功了，所以新版軟體就不會再被考倒了！

這種技巧其實不是我現在才發明的，我的車牌辨識，尤其是六碼車牌左右邊緣的字也是常常與背景沾連，設計老車牌的人就是不願意給一點空間，大家看看字元4與車牌邊的白色空隙有多小？

所以六碼車牌辨識時常常都必須要從背景中把正確的字挖出來的！如果沒有這一招，我的車牌辨識率至少掉一成！還好七碼車牌的新設計已經有考慮到影像辨識的問題，好辨識多了！我很希望老式的六碼車牌快點從台灣消失！

或許有比較內行的人會問：如果我們用CNN，不用OCR，只用特徵組合找字元，不依賴目標的正確切割，不就可以跳過這種目標沾連的問題了嗎？這種想法不算錯誤，CNN確實可以做到不被這種沾連欺騙，但如果就以這一點點優勢認定CNN比OCR優越呢？你就是太天真，或者說是對於影像辨識太無知了！

CNN(或Yolo等相關演算法)確實可以鎖定字元的特徵範圍與「概略」位置，但是無法提供準確的字元目標邊界，如果想準確的框出所有清晰與不清晰，沾連與不沾連的字元，去做精確的字模比對，確認那是個甚麼字？其實我做的工作他們也一步都不能少！他們或許不需挖字就可以知道那裏有個字元(但不知道是甚麼字)，所以CNN要達到辨識的終點，一樣必須思考如何準確框出範圍，演算時間完全沒有比較少！

所以你就知道為何CNN的網路資訊故事永遠只停在「找到目標」，好像就結案了？真實世界的需求呢？找到目標只是一個開始，最多只是中途點，接下來的工作他們都故意不說了！其實跟我日常做的事情應該是完全一樣，一步都不能少的！如果沒有OCR技術讓他們到達最終目標，他們根本甚麼都不是！

其實CNN最大的問題是：要建立可搜尋評估比對的全圖特徵，實在太耗時了！消耗計算資源到一般電腦根本無法應付的程度，所以他們才需要大量的使用GPU資源來分散運算！但是使用傳統的OCR根本不需要這麼大量的計算，所以我的程式用一般電腦的CPU就跑得比CNN的軟體更快了！這一點是CNN擁護者絕對不會跟你說的！但確實是鐵的事實，你知道嗎？

我的上述補遺運算只會針對局部偶發的特殊狀況，程式碼雖然多，但不是每次都會用到，所以計算時間是很省的！這就是我不用那些AI科技，但是辨識率更高，辨識速度還更快的原因！有病才去看醫生吃藥，跟沒事也天天上大醫院檢驗你有沒有生病，兩者的資源耗費會差多少？就是我的OCR辨識與CNN辨識的差距了！

如果你支持環保，應該檢視CNN有多麼違背你的理念！使用CNN的耗電量大約是傳統OCR的十倍，甚至百倍！因為他們懶得寫程式，要用極大量資料「訓練」軟體的啊！我就根本不必！

千萬不要聽信那些所謂的AI影像辨識專家說CNN已經淘汰OCR辨識的說法！差得遠了！CNN其實根本還沒在商業產品上證明他們優於傳統OCR影像辨識，以我的觀點，他們最終只會變成OCR辨識的「輔助」工具！還不是特別有效率的工具，只是還堪用而已！OCR一定會奪回影像辨識的主流地位的！大家等著看我的預言成真吧！