简介deep_ocr-master.zip 是一份基于 Caffe 的深度学习 OCR 开源项目适合希望从零上手文字识别的 Python 开发者与算法学习者。资源围绕 CNN、RNN/LSTM 等模型展开包含文字检测、单字符识别、验证码识别、身份证分割与识别等任务的完整 Python 脚本及演示数据并附有 README 说明。项目涵盖图像预处理、文字定位、字符分割与识别的完整流程可帮助快速理解 OCR 技术原理并用于二次开发。包体小巧共 51 个文件以 .py 源码、.prototxt 网络结构、.png 示例图像为主另有 .sh 启动脚本与 .md 文档压缩包约 198KB。结构上从数据准备到模型调用均有对应模块并提供训练与测试脚本便于对照学习 Caffe 框架下的实现细节。当前已有 267 人浏览学习对于需要动手实践和入门深度学习 OCR 的读者颇具参考价值。整体而言这份资源适合作为深度学习 OCR 入门的实践参考。1. deep_ocr一个能自己训练、也能直接用的 Python 深度学习 OCR 项目拿到deep_ocr-master.zip这个压缩包很多人第一反应是把它当成又一个 tesseract 包装器装上就能跑。实际不是这样。这个项目核心是一套基于深度学习模型的 OCR 训练与推理代码用 Python 写成训练部分不是调个现成 API 那么简单而是要从数据准备开始把图像文字检测、特征提取、序列建模、文字映射串成一条完整的流水线。它能解决的核心诉求是识别你自己的数据——比如验证码、票据字段、工厂钢印、截图文字而不是被通用引擎牵制。适合谁适合那些被商用 OCR 接口的黑匣子搞烦了的开发者以及手头有几百张带标注图片、想试试深度学习 OCR 落地效果的技术团队。这篇笔记就沿着「解压、跑通、训练、部署」这条路径把每一步的参数和坑讲清楚。2. 先把工程跑起来环境、目录与最小推理命令2.1 环境搭建Python 版本、CUDA 与深度学习框架选型deep_ocr 这类项目通常依赖 PyTorch 或 TensorFlow两者在代码组织上差异不小。命名里带master.zip的 GitHub 仓库一般会有requirements.txt。我习惯拿到压缩包先看这个文件再看README里写的框架版本。经验上讲PyTorch 的 OCR 项目更常见CRNN CTC 组合在 PyTorch 里实现起来代码量更少调试也更直观。如果你机器上有 NVIDIA 显卡先确认 CUDA 版本和 PyTorch 的对应关系。常见做法是这样的先建一个干净的虚拟环境再安装依赖。不要一上来就用pip install -r requirements.txt因为这会把项目需要的包装进全局环境之后换项目容易翻车。推荐用 conda 或者 venv 隔离。conda create -n deep_ocr python3.8 conda activate deep_ocr # 先装 PyTorch根据你的 CUDA 版本选命令 # CUDA 11.8 用这个 pip install torch2.0.1 torchvision0.15.2 --index-url https://download.pytorch.org/whl/cu118 # CPU 版就一行 # pip install torch2.0.1 torchvision0.15.2参数说明Python 3.8 兼容性最稳3.10 以上有些旧仓库的依赖会报错。CUDA 版本判断可以用nvidia-smi看驱动支持的最高版本但实际安装的 PyTorch 要对着运行库版本不是驱动版本这两个经常不是一个东西好多人栽在这里。装完框架后再装项目自己的依赖。如果requirements.txt里没列全后面跑的时候缺什么补什么。不要迷信一次装完按报错逐个装是常态。2.2 解压 deep_ocr-master.zip 之后先看目录结构再动手zip 解压出来先别急着找模型文件。先把目录结构摸清楚。一般会看到data/、models/、utils/、train.py、predict.py这几个常见元素。如果是 PyTorch 写的models/下会有crnn.py、resnet.py之类TensorFlow 版本则常见model.py加checkpoint目录。我一般会做两件事第一找README里有没有预训练模型下载链接第二看config.py或者options.py里的参数定义。很多作者会把图片高度、通道数、字符集路径、batch size 这些写死在配置文件里你要改数据就得先弄清楚这些参数的意义。unzip deep_ocr-master.zip cd deep_ocr-master ls -la find . -name *.py | head -30逻辑说明find命令筛出所有 Python 脚本目的是快速定位train.py和predict.py。如果看到demo.py或inference.py那才是真正能直接跑推理的入口。train.py只是训练用的未必能直接跑通推理。参数说明-la是查看隐藏文件有些仓库会把.env或model_config.json藏起来head -30是怕文件太多刷屏。没有目录结构概念就动手改代码是浪费时间。2.3 跑通第一个推理脚本最小命令与日志判读跑推理之前必须确认模型参数和字符集文件对得上号。如果模型是 100 个字符训练的你拿一个 200 字符的字典去加载必崩。这一步存在deep_ocr项目里通常叫char_dict.json或者labels.txt。先数一下字典行数。wc -l labels.txt # 或者 python -c import json; print(len(json.load(open(char_dict.json))))然后执行推理脚本。不同仓库入口不一样最常见的写法是这样python predict.py --model_pathmodels/best.pth --image_pathtest.jpg --configconfig.py如果没有predict.py那就得看train.py里有没有--mode test之类的参数或者直接用 Python 脚本加载模型import torch from models.crnn import CRNN model CRNN(img_h32, num_classeslen(char_list)) model.load_state_dict(torch.load(models/best.pth, map_locationcpu)) model.eval()这时候如果报size mismatch说明模型结构跟 checkpoint 对不上——最常见的原因是img_h不一致。图片高度 32 训练的模型你换成 48 去加载最后一层全连接维数就变了。日志判读方面第一次跑通会看到类似Tensor的输出或者直接打印识别字符串。如果输出的是乱码大概率是字典顺序和训练时不一致。这个坑太常见了我在后面避坑章节会专门讲。3. 数据这一关样本来源、标注格式与预处理流水线3.1 样本从哪来手动标注、合成数据与公开数据集三路并进训练深度学习 OCR数据的质和量直接决定效果。没有数据模型结构再花哨也是白搭。deep_ocr 这类项目一般支持两种数据组织形式一种是每个样本一个图片文件加一个 txt 标签文件另一种是把路径和标签写进一个列表文件像这样train/000001.jpg 你好世界 train/000002.jpg HELLO123没有标注数据的时候我自己常用合成数据来顶。把文字渲染到背景图上加噪声、加透视变换、加干扰线模拟真实场景。合成数据的价值在于可以免费造出十万级样本而且标签绝对准确。用 PIL 就能写个简单的合成脚本from PIL import Image, ImageDraw, ImageFont import random def synth_sample(text, font_path, output_path): # 创建一张 256x64 的白底图画上文字 img Image.new(L, (256, 64), colorrandom.randint(200, 255)) draw ImageDraw.Draw(img) font ImageFont.truetype(font_path, random.randint(24, 32)) draw.text((random.randint(0, 50), random.randint(0, 10)), text, fontfont, fillrandom.randint(0, 100)) # 加一条水平干扰线模拟票据折痕 draw.line((0, random.randint(20, 50), 256, random.randint(20, 50)), fill128, width2) img.save(output_path) synth_sample(ABC123, simsun.ttc, synth_00001.png)逻辑说明用ImageDraw.text把字符串画上去返回的 PIL 图像直接存文件。加干扰线是为了让模型不学到「白底黑字」这种过于干净的分布真实场景里没有这么理想的图片。参数说明图片宽度和高度根据你的使用场景来。票据一般 256x64 够用车牌这种长宽比更大的场景建议拉到 320x48。字体路径在 Windows 上用simsun.ttcLinux 用wqy-microhei.ttc不建议用英文字体生成中文样本笔画结构和中文完全不同。公开数据集方面常用的是 IC03、IC13、IC15 这些但都是英文为主。如果你要识别中文老老实实自己标注或者合成。用 opencv 标注工具也行但标注完记得导出成项目要求的格式别标的爽快到最后格式不认白干。3.2 预处理流水线灰度、二值化与归一化的参数设置图片从磁盘读进来不能直接丢给网络。深度模型吃的是固定尺寸、归一化到一定范围的张量。deep_ocr 里通常用 OpenCV 做预处理三个关键步骤是灰度化、缩放和归一化。import cv2 import numpy as np def preprocess(img_path, img_h32, img_w256): # 读图转灰度 img cv2.imread(img_path, cv2.IMREAD_GRAYSCALE) # 保持比例缩放到 img_h 高度 h, w img.shape ratio img_h / h new_w int(w * ratio) img cv2.resize(img, (new_w, img_h), interpolationcv2.INTER_CUBIC) # 宽度不足的用 0 填充到 img_w if new_w img_w: img cv2.copyMakeBorder(img, 0, 0, 0, img_w - new_w, cv2.BORDER_CONSTANT, value0) else: img cv2.resize(img, (img_w, img_h)) # 归一化到 [-1, 1] img img.astype(np.float32) / 255.0 img (img - 0.5) / 0.5 # 转成 (C, H, W) 供模型使用 img np.expand_dims(img, axis0) return img逻辑说明先按高度比例缩放避免图片直接被压扁导致文字变形、识别率下降。宽度不够时用黑边填充这是 CRNN 系列模型的标准操作——CNN 虽然能处理变长输入但 batch 训练要求尺寸统一填 0 比拉伸更安全。参数说明INTER_CUBIC是三次插值缩放画质比默认的INTER_LINEAR好适合文档类文字。归一化到[-1, 1]比[0, 1]收敛更快如果你的模型训练代码里用的是均值 0.5 标准差 0.5那这个预处理就跟训练对上了。千万别训练时归一化、推理时不归一化模型会输出一堆神秘概率。3.3 数据增强光照畸变与透视变换的坑OCR 模型最容易翻车的场景是训练集千篇一律白底黑字上线遇到红底白字、倾斜 30 度、反光、模糊的图。所以增强要做但不是随便做。图像分类里常用的随机裁剪、水平翻转OCR 场景要慎用——文字反过来还能认吗至少中文不能。水平翻转增强等于让模型学习认「匪」字的镜像「匪」字识别任务反而被搞乱。常用安全增强方式有这几类亮度扰动、对比度扰动、模糊、透视变换、随机噪声。透视变换是模拟拍照角度最有效的手段但幅度要控住别变换到文字彻底变形。看下面的代码import random import cv2 def perspective_augment(img): h, w img.shape # 四个角点随机往内或往外偏移不超过 10 像素 pts1 np.float32([[0, 0], [w, 0], [0, h], [w, h]]) dx1, dy1 random.uniform(-10, 10), random.uniform(-5, 5) dx2, dy2 random.uniform(-10, 10), random.uniform(-5, 5) pts2 np.float32([[dx1, dy1], [w dx2, dy2], [dx1, h], [w dx2, h]]) matrix cv2.getPerspectiveTransform(pts1, pts2) return cv2.warpPerspective(img, matrix, (w, h))参数说明偏移量 10 像素是经验值。对于 256 宽度的图10 像素大约 4% 的偏移模拟手持拍照自然晃动没问题超过 15 像素就过头了模型会学到一堆畸变特征反而在正常图上表现变差。阈值类增强方法带random属性我注释里标了这个值怎么调。增强在训练时做推理时不能做两个阶段做了同一变换就相当于白训练。4. 训练与调参CRNN CTC 的损失为什么掉不下去4.1 网络结构选择CNN 骨干与序列建模的搭配deep_ocr 的核心结构最常用的是 CRNN卷积层负责提取图像特征RNN 或 LSTM 负责建模序列关系最后接 CTC 损失做不定长识别。这个组合到现在仍然是 OCR 领域的经典结构没有之一。CNN 部分常用 ResNet 或者 VGG 的变体作用是把图像转成特征序列——把图片按列切分每一列是一个时间步。为什么不是直接用目标检测的思路去做因为文字长度不定检测框个数不定检测 识别两阶段方案复杂度高。CRNN 单阶段端到端省去字符级标注只需整行文本标签训练数据标注成本低很多。模型定义大致长这样import torch.nn as nn class CRNN(nn.Module): def __init__(self, img_h32, num_classes100): super().__init__() # CNN 主干逐步降低高度、增加通道 self.conv nn.Sequential( nn.Conv2d(1, 64, kernel_size3, stride1, padding1), nn.ReLU(), nn.MaxPool2d(2, 2), # 高从 32 - 16 nn.Conv2d(64, 128, kernel_size3, stride1, padding1), nn.ReLU(), nn.MaxPool2d(2, 2), # 高从 16 - 8 nn.Conv2d(128, 256, kernel_size3, stride1, padding1), nn.ReLU(), nn.MaxPool2d((2, 1)) # 高减半、宽不减 ) # 序列建模双向 LSTM self.lstm nn.LSTM(256 * 4, 256, bidirectionalTrue, num_layers2, batch_firstTrue) self.fc nn.Linear(512, num_classes) def forward(self, x): feat self.conv(x) b, c, h, w feat.shape feat feat.permute(0, 3, 1, 2).reshape(b, w, c * h) out, _ self.lstm(feat) return self.fc(out)逻辑说明MaxPool2d((2, 1))这一步很关键它对高度下采样 2 倍、宽度保持不动——因为宽度对应的是文字时间步方向每一列代表一个字符级别的感受野池化太狠会把字符信息压碎。LSTM 双向建模意味着模型同时看当前字符左侧和右侧的上下文对连续文字识别增益很大。参数说明LSTM 的hidden_size256、层数 2 是常见配置更大模型可以用 512但对 32x256 的输入提升有限训练时间翻倍。num_classes一定是字符集数量加 1多出的 1 是 CTC 的空位用来对齐不定长标注这个忘了好多人训练直接崩。4.2 超参数设置batch size、学习率与图像高度的联动训练深度学习 OCR 的调参不是孤立地调一个参数。batch size、学习率、图片高度这三者是联动的。先说图片高度。CRNN 系列模型对输入高度要求至少有 32 像素否则卷积下采样几次之后特征图高度变为 1后续没法做序列建模。你把img_h设为 32宽可以随便但 batch 里所有图片必须同宽。batch size 直接决定了显存占用。36 像素高度、256 宽度的灰度图batch size 128 在 8G 显存下勉强够用如果你的图是彩色三通道同样 batch 显存翻三倍。学习率呢PyTorch 的 Adam 优化器默认 lr0.001OCR 任务里我一般从 0.0003 起调。optimizer torch.optim.Adam(model.parameters(), lr0.0003) scheduler torch.optim.lr_scheduler.StepLR(optimizer, step_size20, gamma0.1) criterion torch.nn.CTCLoss(blanklen(char_list) - 1, zero_infinityTrue)参数说明StepLR每 20 个 epoch 把学习率乘 0.1这是个保守但稳的调度策略。blank参数对应 CTC 空位的索引前面说过字符集多出来的那个位置。zero_infinityTrue这个参数值得记住当某个 batch 的 loss 是无穷值时把它当 0 处理避免梯度直接炸掉。batch size 从 64 提到 128 的时候学习率也应该相应调大经验上新 batch 是旧 batch 的两倍学习率调成 1.2 倍左右。4.3 训练日志怎么看精度、召回与字符错误率训练 OCR 不能只看 loss。loss 掉到 0.1识别效果可能照样烂得一塌糊涂。看日志重点看三个指标字符准确率、整词准确率、平均编辑距离。字符准确率是每个字符预测对的比率整词准确率要求整行全对平均编辑距离衡量预测跟标注差几个字符。deep_ocr 项目一般会自己算没有的话得自己写。def cal_cer(pred_texts, gt_texts): 计算字符错误率 CER import Levenshtein total_dist 0 total_len 0 for pred, gt in zip(pred_texts, gt_texts): total_dist Levenshtein.distance(pred, gt) total_len len(gt) return total_dist / total_len # 每 500 步打印一次 if step % 500 0: cer cal_cer(val_preds, val_gt) print(fstep {step}, loss{loss:.4f}, CER{cer:.4f})逻辑说明val_preds是模型在当前验证集上的预测文本列表。CER 越低越好0 就是完全正确。工业级 OCR 模型 CER 通常控制在 2% 以内超过 5% 说明还有大问题。参数说明Levenshtein.distance需要额外安装python-levenshtein包。没有这个包可以手写动态规划但说实话没必要。注意 CER 的计算要在解码之后解码一般用贪婪解码就行——CTC 的argmax去重CRNN 推理阶段不需要 beam search 也能有不错效果。训练时发现 loss 掉不动的玄学时刻先看数据有没有配对成功——这是最常见的「 loss 死活不降」原因代码无论如何 log 都正常但标签顺序和图片顺序是错开的。5. 避坑手册deep_ocr 落地时最常翻车的 5 个现场5.1 现象英文和数字能识别中文全乱码这是新手最容易遇到的事。现象是英文、数字识别没问题一到中文就输出随机字符或者空串。原因字符集配置不对。训练时字符集合里没包含这些中文字模型压根不认识硬输出等于瞎猜。或者字符集里有中文但是字典文件在加载时排序方式变了同一个字在训练时是索引 17推理时变成了索引 53。解决核对三处——训练用的字符集文件、模型输出层num_classes、推理加载的labels.txt。这三个必须完全一致。我的习惯是训练前把字符集做一个md5sum存起来推理前比对一遍一秒钟的事能省半天排查时间。5.2 现象训练损失不降验证集精度来回震荡训练 loss 从 20 掉到 5 就卡死了或者一直在 3 到 6 之间震荡。原因学习率过大模型在损失平面里来回跳。或者 batch 数据混入了大量难样本——比如旋转 90 度的文字、几乎无法辨认的模糊图模型被这些样本主导了梯度方向。解决先把学习率降到 0.0001 跑 20 个 epoch 看曲线。如果还是震荡把难样本挑出来单独看一遍是不是标签错了。我自己就遇见过标注时把 0 和 O 搞混模型被错误标签带着跑怎么调都没用。5.3 现象推理速度慢到没法用CPU 占用极高在 GPU 上训练好的模型部署到 CPU 上识别一张 256x64 的图片要 800 毫秒接口完全没法用。原因模型结构臃肿LSTM 层数多、hidden size 大CPU 不支持并行加速。另外 OpenCV 读图 resize 的双线性插值在 CPU 上也有开销但大头还是 LSTM。解决用 PyTorch 的torch.jit.script把模型固化能省掉 Python 解释器开销。然后考虑把 LSTM 换成 Transformer 或纯 CNN 结构——CNN 的并行度远高于 RNNCPU 推理可以快 3 到 5 倍。如果只做推理部署可以牺牲一点精度做 INT8 量化。5.4 现象识别韩文、日文等非英文语种失败用 deep_ocr 训练好的模型识别韩文输出一堆空白或乱码。这不是模型坏了是字符集里压根没收录谚文字母。原因数据集和字符集只覆盖了英文 数字 少量中文韩文字形结构和英文完全不同模型没见过相关知识。解决针对语种重新准备字符集和训练数据。最小做法是收集目标语种的字符全集重新生成标注文件只训练最后一层 fc 和 LSTM 部分冻结 CNN 主干训练量能小很多。如果觉得这个投入不值直接换用 PaddleOCR 或者 RapidOCR 这类已经内置多语言模型的开源方案比自己训练省事多了。5.5 现象模型只认训练时的字体换个字体就翻车模型在 Arial、微软雅黑合成的数据上训练得很好一上线遇到手写体或者艺术字识别率断崖式下跌。原因训练数据太「干净」模型学到的是特定字体的纹理而不是字符的抽象结构。这是深度学习 OCR 的通病数据分布和真实分布不一致。解决在合成数据时多换字体。我一般至少混 5 种以上风格差异大的中文字体——宋体、黑体、楷体、手写体、圆体再加随机粗体倾斜。如果预算允许把真实样本也加进去一小部分比如 5%就能显著提升泛化能力。6. 让 deep_ocr 上生产从模型导出到服务化的最后一跳训练出满意的模型只是第一步真正到生产环境还差几步。首先是导出。PyTorch 训练完拿到的.pth是完整模型参数但生产环境不一定有 GPU也不一定装了一样的 PyTorch 版本。用torch.jit把模型和预处理全部打包成一个文件推理环境只需要 libtorch 或者 numpy 就能跑依赖大大减少。model.eval() example torch.rand(1, 1, 32, 256) traced torch.jit.trace(model, example) traced.save(ocr_model.pt)逻辑说明torch.jit.trace用一个示例输入走一遍前向把计算图记录下来。这里有个前提你的模型输入尺寸必须固定为训练时的尺寸动态输入长度 trace 会报错或丢失灵活性。固定宽度的模型 trace 没问题变宽输入的模型就别折腾了老老实实部署完整 PyTorch。服务化部署我用的是 FastAPI 包一层 HTTP 接口并发控制用信号量限制同时推理的请求数量。OCR 模型不像 Web 请求那么轻量单张图推理即使 50ms并发 20 个请求也会把 CPU 打满后端排队比报错更合理。import asyncio from fastapi import FastAPI, UploadFile import numpy as np app FastAPI() sem asyncio.Semaphore(4) app.post(/ocr) async def ocr(file: UploadFile): async with sem: img_bytes await file.read() # 解码 预处理 推理交给线程池避免阻塞事件循环 result await asyncio.to_thread(run_inference, img_bytes) return {text: result}参数说明信号量设 4是经验值。通常在单机 4 核 CPU 上并发超过 4 个推理任务每个任务都会显著变慢吞吐量反而下降。这个值要在你的真实硬件上压测不是拍脑袋定死的。最后效果验证我的习惯是留一批 1000 张真实场景图每次模型迭代后全部跑一遍算 CER 和整词准确率做成回归样本集。不要只看几张图效果好就觉得行了——OCR 模型的「黑匣子」特性决定了改一行预处理代码可能让某个字体彻底翻车只有回归测试能兜住这种运气问题。希望这些经验能帮你少走几步弯路祝你的 deep_ocr 一次跑通、顺利落地。本文还有配套的精品资源点击获取