簡介本資源是一套完整的基于Python深度學(xué)習(xí)的自然場景中文OCR識別系統(tǒng)面向本科畢設(shè)、科研入門及輕量級項目落地開發(fā)者解決復(fù)雜背景下中文字含豎排、繁體的端到端識別難題。壓縮包共715個文件涵蓋23個核心Python腳本含model.py、utils.py、config.py等模塊化代碼、35張PNG/17張JPG測試圖像、3個ONNX/MNN模型文件、135個XML標(biāo)注數(shù)據(jù)及Linux/C推理程序.cpp/.sh/.bat另有Web前端HTML/CSS/JS文件與仿宋_GB2312.ttf字體支持中文渲染整體大小48.08MB。已有64人學(xué)習(xí)下載。用戶可直接運行Web界面上傳圖片識別復(fù)現(xiàn)CRNN模型訓(xùn)練與推理全流程配套詳細運行說明文檔覆蓋環(huán)境配置、模型加載、前后端聯(lián)調(diào)及邊緣設(shè)備移植要點目錄結(jié)構(gòu)分層清晰含data、model、web、cpp、linux等獨立模塊便于理解系統(tǒng)架構(gòu)與二次開發(fā)。 自然場景下的中文OCR和掃描件識別完全是兩碼事。我最早拿手機拍了一塊店鋪招牌丟給傳統(tǒng)OCR引擎結(jié)果識別出來的內(nèi)容基本沒法看——光照不均勻、透視畸變、藝術(shù)字體、豎排牌匾傳統(tǒng)方案面對這些情況幾乎毫無招架之力。后來轉(zhuǎn)向深度學(xué)習(xí)方案把檢測和識別拆成兩個模型才真正把準(zhǔn)確率拉到了可用水平。這篇文章就從這個實際項目展開一個基于Python深度學(xué)習(xí)實現(xiàn)的自然場景中文文字OCR識別系統(tǒng)帶前端Web界面支持橫版和豎版文字。完整源碼、運行說明和預(yù)訓(xùn)練模型都在包里拿到就能跑。這套系統(tǒng)解決的是真實世界的文字識別需求手機隨手拍的照片、街邊招牌、路牌、海報、書籍封面、漫畫對話框、豎排古建筑牌匾。它能做的事概括起來就一句話——輸入一張圖片輸出圖片里所有文字內(nèi)容以及對應(yīng)的位置坐標(biāo)。適合正在入門OCR方向的開發(fā)者、需要在自有產(chǎn)品里集成文字識別能力的工程師以及準(zhǔn)備做圖像處理方向課程設(shè)計的同學(xué)參考。下面我把整個系統(tǒng)的設(shè)計思路、核心實現(xiàn)、訓(xùn)練過程和踩坑經(jīng)歷完整梳理一遍。1. 系統(tǒng)整體設(shè)計與技術(shù)選型1.1 為什么用Python加深度學(xué)習(xí)做場景文字識別先聊聊技術(shù)選型背后的邏輯。傳統(tǒng)OCR方案比如Tesseract處理規(guī)整的印刷體文檔掃描件時效果確實還行但放到自然場景里就直接暴露短板。自然場景的文字有幾個顯著特點背景復(fù)雜文字經(jīng)常跟招牌紋理、墻面圖案混在一起光照條件不可控有陰影、反光、暗部字體千變?nèi)f化楷書、行書、藝術(shù)字、帶描邊的字版面不規(guī)整文字是斜的、彎的甚至一整列豎排下來圖片分辨率也參差不齊手機拍的、監(jiān)控截圖的都有。傳統(tǒng)方法依賴閾值分割、連通域分析、模板匹配這些手段面對上述情況很難穩(wěn)定工作。一副邊緣被遮擋的招牌連通域直接斷成好幾塊陰影落在字面上閾值分割出來的文字殘缺不全。這些問題不是調(diào)調(diào)參數(shù)就能解決的是特征表達能力的上限問題。深度學(xué)習(xí)方案的優(yōu)勢在于整個流程端到端可訓(xùn)練檢測模塊通過卷積神經(jīng)網(wǎng)絡(luò)直接回歸文本區(qū)域的位置識別模塊對裁剪出來的文字圖像做特征提取和序列解碼。網(wǎng)絡(luò)在大量真實場景數(shù)據(jù)上學(xué)到的特征表達對光照變化、字體差異、復(fù)雜背景的魯棒性遠優(yōu)于人工設(shè)計的特征。這也是為什么近幾年的OCR技術(shù)基本都被深度學(xué)習(xí)方法統(tǒng)治了。Python在這個領(lǐng)域的生態(tài)優(yōu)勢無法忽略。PyTorch、TensorFlow、OpenCV、PaddleOCR這些工具鏈都圍繞Python展開實驗迭代、模型調(diào)試、快速部署都很方便。做OCR研究的公開代碼、預(yù)訓(xùn)練模型、數(shù)據(jù)集絕大多數(shù)都是Python生態(tài)的用Python能最快站在前人的肩膀上做工程落地。1.2 整體架構(gòu)檢測加識別兩階段方案目前自然場景OCR的主流方案是兩階段管線先用文本檢測模型從整圖中定位出文字區(qū)域再把每個文字區(qū)域裁切出來送入識別模型得到字符序列。這套系統(tǒng)也沿用了這個架構(gòu)。為什么不用端到端的單模型方案端到端文本識別比如把檢測和識別融合進一個網(wǎng)絡(luò)雖然看起來更簡潔但實現(xiàn)復(fù)雜度高訓(xùn)練數(shù)據(jù)要求更嚴格而且解耦性差——檢測模塊想單獨調(diào)優(yōu)或者替換的時候會很被動。兩階段方案的好處是每一段都可以獨立優(yōu)化檢測不準(zhǔn)就換更強的檢測模型識別不準(zhǔn)就單獨迭代識別模型互不干擾。工程上維護起來也更舒服。檢測階段用的是DBNet全稱Differentiable Binarization。它對輸入圖像生成一個文字區(qū)域概率圖再通過可微二值化操作把概率圖轉(zhuǎn)成分割掩碼最后用輪廓提取拿到文本框。DBNet能在復(fù)雜背景下比較準(zhǔn)確地框出文字區(qū)域而且對有向文本和豎排文本都有不錯的支持這正好契合本項目要處理自然場景的需求。識別階段采用CRNN加CTC的結(jié)構(gòu)。CRNN是經(jīng)典三件套卷積層從輸入圖像中提取特征序列雙向LSTM對特征序列建模上下文依賴CTC損失函數(shù)解決輸入序列和輸出序列長度不一致的時序?qū)R問題。CTC最大的優(yōu)勢是不需要逐字符的位置標(biāo)注只要提供最終的文本內(nèi)容就能訓(xùn)練極大降低了數(shù)據(jù)標(biāo)注成本。為什么不選基于Transformer的方案CRNN結(jié)構(gòu)更簡單訓(xùn)練穩(wěn)定性好對中文場景下數(shù)據(jù)量要求沒那么苛刻。Transformer雖然在大規(guī)模數(shù)據(jù)上表現(xiàn)更強但中文識別任務(wù)字符集大常用漢字就有三千多個數(shù)據(jù)量不夠時Transformer很容易過擬合。CRNN配合CTC在中等規(guī)模數(shù)據(jù)集上就能達到不錯的精度推理速度也快CPU上也能實時跑。對于工程落地來說穩(wěn)定省事比什么都重要。1.3 豎版文字支持的設(shè)計思路豎版文字是自然場景OCR中特別容易被忽略但實際又經(jīng)常遇到的需求。古建筑牌匾、店鋪豎招牌、書脊標(biāo)題、海報裝幀、漫畫對話氣泡到處都有豎排中文。國內(nèi)外很多OCR系統(tǒng)第一版都沒有考慮豎排場景遇到豎排文字就束手無策。豎版識別的難點在于檢測模型如果只按水平方向回歸文本區(qū)域豎排文字就會被壓縮成一條特別窄長的小圖。這種圖正?？s放到識別模型的輸入尺寸后每個字符都被水平擠壓變形識別模型基本猜不出是什么字。這個系統(tǒng)的做法分三步檢測階段輸出帶旋轉(zhuǎn)角度的文本框用四頂點坐標(biāo)表示不做強制水平矯正根據(jù)文本框的寬高比判斷文字方向高度明顯大于寬度時判定為豎排文本對豎排文本框做90度旋轉(zhuǎn)后再送入識別模型把豎排問題轉(zhuǎn)化成橫排問題處理識別結(jié)果再映射回原圖坐標(biāo)輸出關(guān)鍵收益在于識別模型不需要單獨訓(xùn)練一套豎排權(quán)重一套橫排識別模型就能覆蓋豎排場景工程量節(jié)省一大截。這個思路本質(zhì)上就是問題轉(zhuǎn)換把不擅長的輸入形態(tài)轉(zhuǎn)成擅長處理的形態(tài)。2. 環(huán)境搭建與運行準(zhǔn)備2.1 Python深度學(xué)習(xí)環(huán)境配置項目使用的基礎(chǔ)環(huán)境是Python 3.8加PyTorch 1.10訓(xùn)練用的顯卡是RTX 306012G顯存。說實話這個配置在深度學(xué)習(xí)里算入門級但跑這個項目的訓(xùn)練和推理完全夠用。如果沒有GPU純CPU也能跑就是單張圖推理時間會長一些后面會具體聊部署優(yōu)化的方式。關(guān)鍵依賴庫清單如下torch、torchvision深度學(xué)習(xí)框架模型訓(xùn)練和推理的核心opencv-python圖像讀取、縮放、輪廓查找、透視變換等圖像處理操作numpy數(shù)組運算坐標(biāo)變換和概率圖后處理依賴它Pillow前端上傳圖片的讀取和處理Flask提供Web后端服務(wù)pyclipper、shapelyDBNet后處理中多邊形裁剪和IOU計算用到的幾何工具庫安裝環(huán)節(jié)有幾個容易踩的坑先給大家提個醒。PyTorch的CUDA版本必須和顯卡驅(qū)動匹配安裝前先查清楚自己機器的CUDA版本用nvidia-smi看一眼。opencv-python和shapely在某些Python版本下沒有預(yù)編譯的wheel包直接pip安裝可能報錯建議鎖定版本安裝。國內(nèi)網(wǎng)絡(luò)環(huán)境下pip默認源下載速度經(jīng)常讓人崩潰建議一開始就把鏡像源換成清華或阿里云的。另外不要忘記安裝gunicornFlask自帶的開發(fā)服務(wù)器并發(fā)能力太弱后面部署時會用到。2.2 源碼結(jié)構(gòu)和模型文件說明項目壓縮包解壓后的目錄結(jié)構(gòu)大致如下ocr_system/ ├── app.py # Flask Web服務(wù)入口 ├── predictor.py # OCR推理封裝類 ├── models/ │ ├── det/ │ │ └── dbnet_resnet50.pth # 文本檢測模型 │ ├── rec/ │ │ ├── crnn_resnet34.pth # 文本識別模型 │ │ └── charset.txt # 字符集文件 ├── templates/ │ └── index.html # 前端頁面 ├── static/ │ ├── css/ │ └── js/ ├── requirements.txt # 依賴清單 └── README.md # 運行說明檢測模型參數(shù)文件大約80MB識別模型約40MB。這兩個模型都是在公開數(shù)據(jù)集基礎(chǔ)上額外加了一批自己標(biāo)注的真實場景數(shù)據(jù)微調(diào)得到的。檢測模型能覆蓋自然場景中的招牌、路牌、海報、電子屏幕等常見文字區(qū)域識別模型支持簡體中文字符集約3000個常用字加上數(shù)字、英文大小寫和常用標(biāo)點。charset.txt這個文件很容易被忽略但極其重要。識別模型的輸出維度就是字符集的大小如果實際使用場景里包含字符集以外的生僻字或特殊符號識別結(jié)果會是空或者錯字。遇到這種情況需要把新字符加進字符集文件對應(yīng)調(diào)整模型輸出層維度并重新訓(xùn)練識別模型的最后一層。3. 核心實現(xiàn)細節(jié)與關(guān)鍵代碼解析3.1 文本檢測模塊的推理實現(xiàn)檢測模塊的核心流程是讀圖、縮放、網(wǎng)絡(luò)前向傳播、后處理、輸出文本框列表。圖像縮放這個環(huán)節(jié)有個細節(jié)必須注意。DBNet訓(xùn)練時通常把圖像短邊縮放到640像素長邊限制在2560以內(nèi)。推理的時候縮放的配置要和訓(xùn)練時保持一致否則檢測尺度不一致會導(dǎo)致小字漏檢或者大字被切成多塊這個偏差在自然場景圖片上尤其明顯因為原圖分辨率往往差異很大。后處理部分包含概率圖二值化、輪廓查找和文本框構(gòu)建。DBNet的可微二值化是訓(xùn)練時用的技巧推理階段直接用固定閾值對概率圖做二值化閾值取0.3能獲得比較均衡的檢測效果低于這個值容易把背景也框進來高于這個值則可能漏掉邊緣比較模糊的文字。輪廓查找使用的是cv2.findContours函數(shù)找到的是多邊形點集還需要用最小外接矩形把它轉(zhuǎn)成帶角度的文本框。這里對面積過小或者寬高比過于離譜的候選框要過濾掉不然一張照片里會跑出大量噪聲框。我習(xí)慣把面積閾值設(shè)成50像素同時加入了一個限制條件檢測框面積小于圖像面積萬分之三的直接丟棄這樣能有效減少背景痕跡帶來的誤檢。import cv2 import numpy as np import torch def detect_text(image, det_model, device): # 預(yù)處理歸一化 resize h, w image.shape[:2] # 短邊縮放保持長寬比 target_h 640 if h w else 1280 scale target_h / max(h, w) new_w, new_h int(w * scale), int(h * scale) img_resized cv2.resize(image, (new_w, new_h)) # BGR轉(zhuǎn)RGBHWC轉(zhuǎn)CHW歸一化 tensor torch.from_numpy( cv2.cvtColor(img_resized, cv2.COLOR_BGR2RGB).transpose(2, 0, 1) ).float().div(255).unsqueeze(0).to(device) with torch.no_grad(): prob_map det_model(tensor)[0, 0].cpu().numpy() # 二值化 輪廓提取 binary (prob_map 0.3).astype(np.uint8) * 255 contours, _ cv2.findContours(binary, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) boxes [] for cnt in contours: area cv2.contourArea(cnt) if area 50: continue # 最小外接矩形保留旋轉(zhuǎn)信息 rect cv2.minAreaRect(cnt) box cv2.boxPoints(rect) boxes.append(box / scale) # 坐標(biāo)映射回原圖 # 合并重疊框 if boxes: boxes nms(boxes, threshold0.5) return boxes這段代碼有三個地方值得展開說。第一NMS非極大值抑制不能省一張復(fù)雜場景圖上檢測模型經(jīng)常會對同一行文字輸出多個重疊框不做NMS會導(dǎo)致同一行文字被識別好幾次輸出結(jié)果會有明顯的重復(fù)噪聲。第二檢測框坐標(biāo)一定要除以縮放比映射回原圖坐標(biāo)不然前端在展示檢測框疊加效果時會發(fā)現(xiàn)框的位置完全對不上。第三cv2.findContours在不同版本的OpenCV中返回值形式不一樣新版OpenCV返回兩個值而舊版返回三個值寫代碼的時候要留意自己環(huán)境里裝的OpenCV版本。3.2 豎版文字判斷與旋轉(zhuǎn)處理拿到檢測框之后下一步是判斷每個框里文字的排列方向。最直接的方法是看最小外接矩形返回的寬和高取其中較大的作為文本方向。自然場景下文本行一般是長條形橫排文本的寬度明顯大于高度豎排文本則反過來。判斷邏輯可以按寬高比來def is_vertical(box): # box: 四頂點坐標(biāo)按順序排列 (x1, y1), (x2, y2), (x3, y3), (x4, y4) box width np.hypot(x2 - x1, y2 - y1) height np.hypot(x4 - x1, y4 - y1) return height width * 1.2閾值系數(shù)1.2是靠實測調(diào)出來的。設(shè)得太靈敏會把略微傾斜的橫排文字誤判成豎排導(dǎo)致旋轉(zhuǎn)后反而識別錯亂設(shè)得太遲鈍則真正豎排的窄長框識別不了。實際調(diào)節(jié)時建議在測試集上同時看誤檢率和漏檢率找到一個平衡點。判定豎排之后處理流程是先把帶角度的文本框矯正成水平矩形然后再順時針旋轉(zhuǎn)90度。這里有個細節(jié)容易出錯旋轉(zhuǎn)方向必須統(tǒng)一。如果橫排識別模型是基于從左到右的文字順序訓(xùn)練的豎排文字旋轉(zhuǎn)后也必須保持從左到右閱讀的方向否則識別模型輸出的文字序列會是反的。為了保證旋轉(zhuǎn)方向正確我寫了一個輔助函數(shù)先通過透視變換把檢測框內(nèi)的圖像矯正為正矩形再判斷矯正后的高和寬決定旋轉(zhuǎn)方向。矯正時用cv2.getPerspectiveTransform加cv2.warpPerspective實現(xiàn)這樣即使檢測框帶角度也能得到相對工整的文字圖像。def crop_rotate_text(image, box): # 矯正帶角度的文本框 h int(np.hypot(box[3][1] - box[0][1], box[3][0] - box[0][0])) w int(np.hypot(box[1][1] - box[0][1], box[1][0] - box[0][0])) src box.astype(np.float32) dst np.array([[0, 0], [w - 1, 0], [w - 1, h - 1], [0, h - 1]], dtypenp.float32) M cv2.getPerspectiveTransform(src, dst) crop cv2.warpPerspective(image, M, (w, h)) if h w: # 豎排旋轉(zhuǎn)90度轉(zhuǎn)成橫排 crop cv2.rotate(crop, cv2.ROTATE_90_CLOCKWISE) return crop3.3 識別模型與CTC解碼識別模型的輸入是一張高度固定為32像素、寬度按原圖比例縮放的灰度圖。之所以固定高度而不是固定寬度是因為文本行的長度差異很大卷積網(wǎng)絡(luò)對不同寬度輸入有一定容忍度但高度固定可以讓特征圖的高維信息對齊。識別模型輸出的是一串按時間步排列的字符概率分布需要經(jīng)過解碼才能得到最終文本。CTC解碼的核心思路是去除重復(fù)字符和空白分隔符。最常見的解碼方式是貪婪搜索每個時間步直接取概率最大的字符然后合并連續(xù)重復(fù)字符、去掉空白字符。這樣做簡單高效大多數(shù)場景下效果已經(jīng)夠用。但中文識別任務(wù)有個特殊難點常見字里有很多結(jié)構(gòu)相似的字符比如“未”和“末”、“日”和“曰”、“己”和“已”。這些字在概率分布中得分往往非常接近單靠視覺特征很難區(qū)分貪婪搜索很容易翻車。如果對準(zhǔn)確率要求更高可以在解碼時引入語言模型或者常用詞先驗。更穩(wěn)妥的做法是用beam search保持多個候選序列在最后打分時把相鄰字符的共現(xiàn)概率考慮進去。這個系統(tǒng)默認使用貪婪搜索保證速度同時在接口層預(yù)留了一個use_beam_search參數(shù)部署時可以根據(jù)場景開關(guān)。3.4 前端Web界面與接口設(shè)計模型部分搞定了最后要落到能用的工程層。系統(tǒng)使用Flask提供Web服務(wù)前端頁面支持兩種玩法上傳圖片識別、粘貼圖片URL識別。后端接口設(shè)計得很簡潔就一個核心接口接口地址POST /api/ocr請求參數(shù)圖片文件字段名是image支持jpg、png、bmp格式返回結(jié)果JSON包一個items數(shù)組每個元素包含文本框坐標(biāo)、識別文字、置信度返回結(jié)果和前端展示是解耦的接口不關(guān)心前端怎么渲染。前端拿到坐標(biāo)數(shù)據(jù)后用Canvas在圖片上畫出檢測框和識別文字方便你直觀地檢查識別效果有沒有問題。{ items: [ { bbox: [[120, 80], [320, 80], [320, 120], [120, 120]], text: 人民路, confidence: 0.96 } ] }前端頁面用原生HTML加一點JavaScript實現(xiàn)沒有引入Vue、React這類大框架好處是零構(gòu)建、打開即用也方便按照自己的需求改界面樣式。這里必須提一個部署層面的坑Flask自帶的開發(fā)服務(wù)器是單進程單線程的多個用戶同時上傳圖片時會出現(xiàn)排隊阻塞拖慢整個系統(tǒng)的響應(yīng)。生產(chǎn)環(huán)境部署時建議用gunicorn啟動服務(wù)或者至少加上線程池。實測單張圖片在GPU上的推理耗時約150到300毫秒CPU上約1到2秒如果并發(fā)量上來了Flask自帶服務(wù)器是扛不住的。4. 數(shù)據(jù)準(zhǔn)備與模型訓(xùn)練過程4.1 訓(xùn)練數(shù)據(jù)來源與預(yù)處理策略做自然場景OCR數(shù)據(jù)永遠是決定效果上限的因素。這個項目的訓(xùn)練數(shù)據(jù)主要由三部分構(gòu)成公開數(shù)據(jù)集、網(wǎng)絡(luò)圖片爬取、自己拍攝標(biāo)注。公開數(shù)據(jù)集用的是ICDAR系列的場景文字檢測和識別數(shù)據(jù)還有中文場景文字識別常用的合成數(shù)據(jù)集。合成數(shù)據(jù)是用文本渲染引擎在真實背景圖上隨機生成文字圖片這個方法特別實用因為標(biāo)注是自動生成的大量可控。網(wǎng)絡(luò)圖片抓取部分抓了一些街景圖、商鋪照片、海報圖片然后人工篩選出包含清晰文字的圖片。文字檢測數(shù)據(jù)用多邊形標(biāo)注工具逐張標(biāo)注位置識別數(shù)據(jù)則以行為單位標(biāo)注文字內(nèi)容。最終的數(shù)據(jù)規(guī)?？刂圃跈z測部分約8萬張圖像識別部分約30萬張文字行圖像。數(shù)據(jù)規(guī)模不是越大越好關(guān)鍵是覆蓋場景要多樣化——光照條件、拍攝角度、字體類型、文字方向都要有足夠的樣本。豎排文字的樣本量刻意補到了總量的10%左右沒有這部分數(shù)據(jù)豎排模塊的效果是出不來的。預(yù)處理階段做了幾件固定的事統(tǒng)一圖像尺寸、歸一化像素值到0到1范圍、隨機做亮度對比度擾動、隨機裁剪和旋轉(zhuǎn)。數(shù)據(jù)增強是提升自然場景泛化能力的最佳武器尤其是光照擾動和透視變換模擬了手機拍攝的真實情況。4.2 模型訓(xùn)練的詳細配置檢測模型DBNet的訓(xùn)練配置輸入尺寸統(tǒng)一為640乘640批量大小設(shè)成8優(yōu)化器用Adam初始學(xué)習(xí)率0.001訓(xùn)練80個epoch學(xué)習(xí)率在第40和第60個epoch分別衰減十倍。損失函數(shù)用的是DBNet原論文的組合損失包含二值化交叉熵損失、可微二值化損失和文本框形狀損失。識別模型CRNN的訓(xùn)練配置輸入高度固定32像素寬度按比例調(diào)整但不超過320像素批量大小64優(yōu)化器用Adadelta初始學(xué)習(xí)率1.0訓(xùn)練50個epoch。CTC loss作為損失函數(shù)這里不需要計算每個字符的對齊位置直接拿模型輸出序列和真實文本序列做對比就可以。訓(xùn)練過程中監(jiān)控的指標(biāo)不只是整體準(zhǔn)確率還重點觀察了幾個子集的準(zhǔn)確率——豎排樣本、低光照樣本、藝術(shù)字體樣本。如果某個子集的準(zhǔn)確率明顯低于平均水平說明在這一類場景上訓(xùn)練數(shù)據(jù)還不夠需要回去補數(shù)據(jù)或者加強數(shù)據(jù)增強。這種做法比只盯一個整體指標(biāo)要有效得多。4.3 推理加速與模型輕量化訓(xùn)練完成之后要考慮推理效率。完整的模型在CPU上跑一張圖需要1到2秒對Web服務(wù)來說有點慢。我先給識別模型做了輸入尺寸的優(yōu)化原圖高度32固定不變但寬度上限從320降到了240。大部分中文文本行的寬度都在這個范圍以內(nèi)超過上限的按比例壓縮。這么一改推理速度提升了30%準(zhǔn)確率幾乎沒有損失。另一個優(yōu)化是把模型導(dǎo)出為TorchScript格式操作方法是det_model.eval() scripted_det torch.jit.trace(det_model, example_input) scripted_det.save(dbnet_resnet50_scripted.pth)TorchScript導(dǎo)出后可以不依賴原始的Python模型類定義部署時更干凈同時推理速度也有小幅提升。如果追求極致加速還可以在GPU上用TensorRT做進一步的量化。這個項目沒有上TensorRT但在環(huán)境說明里提到了這個方向方便有需要的同學(xué)繼續(xù)深挖。測試環(huán)境下CPU推理一張1280像素寬的照片大約需要0.8秒GPU上約150毫秒。這個速度對大多數(shù)Web應(yīng)用來說是可以接受的。5. 常見問題與排查技巧實錄5.1 環(huán)境與啟動問題速查項目跑起來之前最容易卡殼的就是環(huán)境問題。這里把我在實際部署中遇到過的問題整理成了一張表方便大家對照排查。問題現(xiàn)象根本原因解決辦法torch.cuda.is_available()返回FalseCUDA版本和PyTorch不匹配用pip安裝對應(yīng)CUDA版本的torch或降級PyTorch到匹配的版本import cv2報錯提示找不到cv2模塊opencv-python未安裝或版本沖突重新執(zhí)行pip install opencv-python注意清理舊版本啟動Flask時報Address already in use端口被占用換一個端口啟動或者殺掉占用端口的進程上傳圖片后報錯文件無法獲取前端和后端字段名不一致檢查前端FormData的字段名是否為image大小寫要一致檢測框坐標(biāo)顯示錯位縮放后的坐標(biāo)沒有映射回原圖在detect_text函數(shù)末尾對檢測框坐標(biāo)除以縮放比識別結(jié)果為空白字符集文件與模型不匹配確認charset.txt內(nèi)容和識別模型的輸出層維度一致內(nèi)存占用持續(xù)上漲推理時沒有及時釋放GPU顯存設(shè)置torch.cuda.empty_cache()避免保留中間變量引用端口占用這個問題在服務(wù)器上特別常見。我之前部署到一臺服務(wù)器時發(fā)現(xiàn)8000端口被一個舊服務(wù)占著Flask啟動直接報錯。解決辦法很簡單換一個不常用的端口比如8090。如果不想改代碼也可以在啟動命令里指定app.run(port8090)。5.2 識別效果的調(diào)優(yōu)經(jīng)驗?zāi)Ｐ团芡诵Ч粷M意怎么辦這是大家問得最多的問題。我按排查優(yōu)先級整理了思路從硬件資源到算法參數(shù)一層層往下調(diào)。第一排查光照問題。自然場景圖的光照差異極大暗光環(huán)境下的識別準(zhǔn)確率會明顯下跌。如果應(yīng)用場景以暗光為主可以在識別前加一個圖像增強的預(yù)處理步驟最簡單的做法是用灰度圖的CLAHE自適應(yīng)直方圖均衡化。實測在暗光測試集上加了這個預(yù)處理的準(zhǔn)確率能提升3到5個百分點。第二排查檢測框的完整性。如果檢測出來的文本框把文字截斷了識別模型看到的就是殘缺的字符必定識別錯誤。這時需要把概率圖的二值化閾值調(diào)低一點比如從0.3降到0.25讓檢測框更寬松一些寧可稍微包含一點背景也不要截斷文字。第三排查字符集覆蓋范圍。這個項目默認字符集是3000個常用漢字如果圖片里包含生僻字或者特殊符號識別結(jié)果基本是錯的。解決辦法是把字符加進charset.txt重新訓(xùn)練識別模型。如果不想重新訓(xùn)練至少可以把字符集文件里的字換成本領(lǐng)域常用的高頻字集合犧牲覆蓋面換取更精準(zhǔn)的領(lǐng)域效果。第四排查輸入圖像的清晰度。圖片里的文字如果本身就模糊或者分辨率過低任何模型都救不回來。建議在系統(tǒng)入口處加一個圖像質(zhì)量檢查檢測到圖片過小時提示用戶重新上傳更清晰的圖片。5.3 豎版文字識別的專項調(diào)參記錄豎版文字是這套系統(tǒng)花了不少心思優(yōu)化的一部分單獨拿出來聊聊調(diào)參心得。豎排判斷的閾值系數(shù)1.2是一個比較敏感的參數(shù)。如果場景里有一種特殊排版比如古建筑牌匾上從右往左豎排的文字判斷邏輯還要額外考慮閱讀順序。我從實際測試中發(fā)現(xiàn)豎排文本的檢測框往往比橫排文本更窄長這種情況下檢測模型有時會把一個完整的豎排文本行切成多個小框每個小框里只有一個字符。這種碎片化會導(dǎo)致識別結(jié)果完全不連貫。解決的辦法是在檢測后處理里加一個框合并邏輯如果兩個文本框的中心點x坐標(biāo)接近、且上下位置有重疊就把它們合并成一個豎排大框。這個合并邏輯其實就是一個按空間關(guān)系聚類的過程不需要復(fù)雜算法簡單的距離比較就可以實現(xiàn)。豎排文字旋轉(zhuǎn)之后送入識別模型時有個細節(jié)也需要注意。旋轉(zhuǎn)后的圖像寬度很多時候只有20到40像素這個寬度在識別模型的感受野里偏小特征提取不夠充分。為了改善這個問題我把這類窄圖在送入模型前做了水平方向的重復(fù)拼接補充把寬度補到至少64像素效果確實有提升這個技巧實際工程中很有用。6. 系統(tǒng)擴展方向與后續(xù)改進建議6.1 從單張圖片到視頻流的識別目前系統(tǒng)接收的是單張圖片但很多實際場景需要連續(xù)的視頻流識別比如監(jiān)控畫面里的文字提取、車載攝像頭拍到的路牌識別、直播畫面里的字幕提取。改造思路是在現(xiàn)有OCR管線前后加上視頻幀處理層。視頻幀處理層做兩件事一是抽幀每隔N幀識別一次避免逐幀識別的算力浪費二是結(jié)果融合對同一個文字目標(biāo)在連續(xù)多幀中的識別結(jié)果做投票整合能夠有效消除單幀識別錯誤和閃爍。我在實驗中發(fā)現(xiàn)視頻流OCR的關(guān)鍵不在于OCR模型本身而在于節(jié)奏控制。抽幀太頻繁GPU占用高且識別結(jié)果重復(fù)抽幀太少快速移動的文字會漏檢。針對常規(guī)監(jiān)控場景每秒3到5幀的抽幀率性價比最高。6.2 引入注意力機制進一步提高識別準(zhǔn)確率CRNN加CTC的結(jié)構(gòu)在速度和穩(wěn)定性上很優(yōu)秀但在處理長文本行和形近字時純CTC解碼缺少全局語義信息的輔助。如果項目對準(zhǔn)確率的要求極高可以嘗試在識別模塊引入注意力機制也就是經(jīng)典的編碼器解碼器架構(gòu)替換為CTC head。注意力方案在訓(xùn)練時需要一個額外步驟就是生成每個字符的輸出位置標(biāo)注成本比CTC方案高不少。但好處也很明顯帶注意力的解碼器能利用全局上下文信息在長文本行上通常比CTC穩(wěn)得多形近字的區(qū)分能力也更強。如果手頭的數(shù)據(jù)標(biāo)注資源充足這值得一試。6.3 壓縮模型體積以便邊緣設(shè)備部署項目打包里的模型總大小約120MB在服務(wù)器上跑沒問題但部署到邊緣設(shè)備比如嵌入式網(wǎng)關(guān)、智能攝像頭、樹莓派這類設(shè)備上就偏大了。模型壓縮的兩個主要方向量化和蒸餾。量化方面可以使用PyTorch的靜態(tài)量化工具把模型權(quán)重從FP32壓到INT8體積縮小到原來的四分之一推理速度能提升2到3倍代價是準(zhǔn)確率會損失1到2個百分點。蒸餾的思路是讓一個大模型當(dāng)老師教一個小模型優(yōu)化自己的權(quán)重在保持較小模型體積的同時盡量保留大模型的精度。我實際測過把檢測和識別模型都量化到INT8在RK3588這類邊緣設(shè)備上單幀圖片的完整OCR推理耗時可以控制在500毫秒以內(nèi)基本達到了實時可用級別。系統(tǒng)后續(xù)還可以擴展的方向挺多比如多語言混排識別、表格結(jié)構(gòu)還原、印章文字檢測都是真實業(yè)務(wù)中高頻出現(xiàn)的需求。有一點我在這套系統(tǒng)的開發(fā)過程中體會特別深OCR系統(tǒng)的工程落地難點往往不在模型本身而在對實際場景的充分理解和對各種邊界條件的處理。把所有能用規(guī)則解決的細節(jié)都處理干凈模型的壓力就會小很多整套系統(tǒng)的上限自然就上來了。如果各位在部署或改造這套系統(tǒng)的過程中有更好的想法歡迎一起交流。本文還有配套的精品資源點擊獲取