Robust Reading的Task 4是今年才推出的比賽，與已經公開多年的Task1和Task2相比，Task4的樣本是用手機随機拍攝的生活場景，不是刻意針對文字拍攝的。
Task1的圖像樣例
Task2 的圖像樣例
Task4的圖像樣例
比賽要求是隻檢測人眼可以看出來的文字，比較直覺，不做過多贅述。
下面是一些我的感想吧。
代碼部分
1. 推薦一些高效的開發語言
對于一些工具，不需要考慮性能的情況下，推薦用C#, Java, Matlab等解釋型語言來進行編寫。C#, Java在做互動工具方面的開發效率極高，很多類都是現成的，尤其是C#的智能感覺清單是目前使用者體驗做的最好的；而Matlab的腳本可以做到在不建立工程的情況下實作一些小功能，比如修改檔案名，字尾名，移動、複制檔案等。
2. 一些比較好用的Matlab函數介紹，具體使用不做過多介紹，大家自行百度之吧
dir() 擷取檔案夾下的所有檔案或者指定格式的檔案
regexp(str_line, '\s+', 'split') 将str_line以空格進行分割，C#中也有一樣的函數，是string類下的split函數
regexp(str_line, ',', 'split') 将str_line以逗号進行分割
inpolygon() 判斷點是否在多邊形内的函數
cp2tform() 透視變換函數
fp = fopen('test.txt', 'r', 'n', 'utf-8'); 以utf-8格式打開檔案，檔案頭會有一個? 符合utf-8的編碼方式
movefile() 移動檔案
copyfile() 複制檔案
CNN部分
CNN的特點是逐層提取特征，随着深度增加，提取的特征級别也越高，淺層一般是認為提取邊緣特征或者顔色特征。
我将第一個Pooling層前的卷積都認為是淺層，這樣CNN可以根據淺層的核大小分為兩類，一類是Kernel Size=5，另一類Kernel Size=3。前者的設定在Caffe的樣例裡面非常常見，從可視化的角度來說，淺層的5×5能夠表達更豐富的邊緣資訊，而後者Small Kernel隻是在Ben Graham的論文[1]中見到，而且Ben Graham将網絡結構設計的極其有規律，從Ben Graham的結構中可以看出，他将結構資訊轉化到了大量的濾波器中，整個結構更像是一種編碼，而3×3的Kernel并不算是一種淺層特征提取，因為3×3的Kernel能展現的邊緣資訊太有限了。是以說，我根據淺層卷積核的大小，大緻将CNN分為兩類，一類是逐層提取特征的CNN，另一類是逐層編碼的CNN，但是這僅僅是一種了解，沒有相關的實驗做支撐。
從實驗的過程來看，Ben Graham的結構非常小巧精緻，訓練起來要更快，對于小尺度的圖像分類問題是很有效的。
一些小細節比如Leaky Relu代替了原來的Relu作為新的神經元激勵函數，從對比實驗上看Leaky Relu要比Relu好一些，但也不是絕對的，可以說是為網絡細節的調整多了一個不錯的選擇。
樣本部分
分類器結構的設計對于分類器訓練的作用并不是特别大，因為論文擺在那裡，開源的代碼擺在那裡，大家都會去試試，最後出來的結構都大同小異。而用什麼樣的資料進行訓練是更為重要的。
其實過分依賴資料是分類器的缺陷，但是目前的判别模型又有哪個不依賴資料呢？
其他
1. 有一個清晰的系統架構，一定要清楚先做什麼後做什麼要做什麼，這次比賽一個很大的失誤就是沒有很早的認識到連通部件提取的重要性，一開始沒有把連通部件提取作為工作之一，結果到後面非常被動。
2. 盡量早做完系統，再去追究細節。這個問題并不是沒有意識到，而是僥幸心理在作祟，一直是想萬一這個改進會是分類器性能有很大改變，就可以給後面省下很多事情，結果是從沒有出現過這麼好的運氣。不過也不是全然沒有收獲，做了這麼多實驗，感覺CNN的一個緻命問題就是對于樣本的數量與品質有很高的需求，CNN沒有想象的那麼好用。是以在深度學習這個方向，一味的追求資料集上的結果不是長久之策，反而是跟着别人的節奏，去解決深度學習中一些更有價值的問題是更長遠的選擇。
3. 良好的心态以及一個合适的沖刺時間。做有deadline的事情一定不能着急，不管出了多大的問題，第一個要想的是怎麼能夠用最高效的方式去解決，要花多大的時間以及人力成本；這樣的比賽如果前期沒有足夠好的積累，肯定是在最後幾天要熬夜的，前期不能熬夜，後面一定要提起精神來随時準備熬夜拼命。
4. 研究一下系統不同子產品的互補性，可以事半功倍。比如訓練CNN的模型，裡面肯定有“疑難雜症”，但是很可能這些樣本用MSER就很好解決，兩者都不好解決的，可能用文本行聚合就輕松搞定，一個好的系統可以不是步步完美，互補也會得到很好的結果。
5. 對于工作要做時間估算。比如有100W的Large Patch樣本要傳到伺服器進行訓練，假如網絡傳輸速度為10M/s，100W的樣本差不多是25G，傳到伺服器要43min，假如還要對這些樣本做擾動，至少要傳輸100G的資料，耗時為2.9小時，然後轉為caffe能用的leveldb格式至少用1小時，整個過程下來，保守估計用時4小時，中間出點差錯，可能一天都是在準備樣本。而把擾動的工作放到伺服器端來進行可以極大的縮減時間。
6. 定好标準：包括檔案名命名格式，資料是二進制還是ANSI，建議用二進制形式的資料檔案，可以通過檔案大小來檢查檔案的完整性，而且讀寫也友善。
7. 将正确分類以及錯誤分類的樣本挑出來檢視，有利于分析分類器的缺陷，以及改進的方法。