自然场景OCR实战：DB检测与CRNN中文识别全流程

简介：一套针对自然场景文字检测与中文OCR识别的毕业设计完整源码，基于TensorFlow和Keras、PyTorch实现，适合计算机视觉方向学生作为课程设计或毕业设计参考。项目包含三个核心网络：文本方向检测网络、文本区域检测网络以及端到端不定长文字识别网络，并给出CPU与GPU两种环境构建脚本、Keras与PyTorch双版本训练代码，体现了完整的OCR实现思路。

资源压缩包共237个文件，大小约62.71MB。其中91个Python脚本是训练与推理的主干，38张JPG和19张PNG图片可直接用于测试，另有8个Shell脚本辅助环境配置、模型权重和Cython加速模块等，整体结构清晰，便于按目录查阅。作者还提供了百度云模型地址，便于复现方向分类模型的较高准确率。

目前已有697人学习或下载，适合需要搭建OCR项目或进行毕业设计开发的学生实践参考。

1. 自然场景OCR毕业设计：最花时间的不是识别，是让检测模型在真实环境里不翻车

先给一个反直觉结论：一套号称“端到端”的自然场景OCR中文识别系统，落地时最常见的形态并不是一个黑匣子大模型一次吐出文字，而是「文字检测 → 透视矫正 → 序列识别 → CTC解码」四个模块串成的一条流水线。这个题目在3到6个月里要啃的硬骨头，基本都在检测任务上：广告牌上的艺术字、玻璃反光下的招牌、弯曲的瓶身标签，每一个都在压低检测的召回率。这套方案适合正在做毕业设计的同学，也适合想给自己项目快速加一个“拍照识文字”能力的开发者。下面直接按框架选型、检测实现、中文识别、训练踩坑的顺序，把一条能演示、能交付的完整OCR管线搭起来。

2. 框架选型：TensorFlow+Keras 还是 PyTorch，按显卡和答辩需求定

2.1 两个生态的真实成本对比

做这个方向，第一步就是定框架。我见过太多人先下了一个开源项目，发现是 PyTorch 的，又去现学框架，最后三分之二的时间耗在移植上。先花半小时看这张表，按自己的环境选，比任何“哪个框架好”的争论都管用。

先说一个关键事实：TensorFlow 在 Windows 上从 2.11 开始不再提供原生 GPU 支持，只支持通过 WSL 使用，所以如果在 Windows 裸机上做毕设，2.10.0 是最后的舒适区。PyTorch 没有这个问题，CUDA 11.8 / 12.1 的轮子在官网按命令行下载即可。毕设场景不建议追新版本，稳定能跑比新特性值钱。

如果实验室里导师已经统一框架，直接跟；如果没人管这种事，我给的建议很实在：你更习惯 Python 面向对象和逐行 debug，就选 PyTorch；你想少写代码、把精力放在数据和调参上，用 TensorFlow + Keras。两个框架在检测和识别任务上能力几乎没差别，差别全在你能多快把环境搭起来并拿到第一张可演示的结果图。

2.2 TensorFlow 2 + Keras 的最小环境搭建

先说环境，因为这里翻车概率最高。假设你手上是一台 Windows 机器，用 nvidia-smi 查看显卡驱动版本，比如最近常见的 550.144.03，这类新驱动的 CUDA 版本足够向下兼容旧版本。下面这组命令是我验证过很多次的做法：

conda create -n tf_ocr python=3.9 conda activate tf_ocr conda install cudatoolkit=11.2 cudnn=8.1 pip install tensorflow==2.10.0 python -c "import tensorflow as tf; print(tf.test.is_gpu_available())"

这里有三件事需要解释。第一，TensorFlow 2.10.0 在 Windows 上依赖 CUDA 11.2 和 cuDNN 8.1，驱动版本只要不低于官方要求的 452.39 基本都兼容。第二，用 conda 安装 cudatoolkit 时不需要手动改系统 PATH，conda 会在激活环境时把库路径配好，这能省掉大量玄学问题。第三，is_gpu_available在后续版本里已经标记弃用，但 2.10 里还能用，输出 True 说明 GPU 已经被识别；如果你更习惯看日志，搜日志里的 “GPU” 关键字也行。

装完先跑一小段张量加法和 Conv2D，确认算子真的走 CUDA，这一步 30 秒就能过滤掉“装了半天发现还在用 CPU”的尴尬。如果检查不过，优先看 conda 装的是不是正好 11.2 而不是 11.8，TF 2.10 配 cuDNN 8.1 是最准的组合。血泪经验是：不要混用 conda 的 cudatoolkit 和 NVIDIA 官网独立安装的 CUDA，两者在 PATH 里打架时，报错信息完全看不出是驱动问题还是环境问题，只能一个个排除。

2.3 PyTorch 路线的等价配置

如果走 PyTorch，环境命令更短：

conda create -n pt_ocr python=3.9 conda activate pt_ocr pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 python -c "import torch; print(torch.cuda.is_available())"

要注意--index-url指定的是 CUDA 11.8 的 wheel 版本。PyTorch 官方索引页会根据驱动兼容性自动选版本，装自带 CUDA 12.1 的包在 550 系列驱动下也带得动。验证输出 True 之后再跑一句torch.randint(1, 10, (2, 2)).cuda()，确认设备真的可用。

这套配置下，后面要用的 DB、PAN 这类检测模型，开源仓库里多数是 PyTorch 复现版，你可以直接参考它们的训练配置来设 batch 和学习率。相比 TF 版需要自己解决 Keras 的序列化问题，PyTorch 的训练循环更直白。代价是需要手写训练循环和指标统计，代码量多出来那部分，对只求流程跑通的毕设来说，往往会变成新的 bug 来源。

2.4 Keras 快速验证一个最小 OCR 前端

在进入正式检测和识别之前，先用 Keras 验证框架链路是通的。下面这个最小例子只做一件事：随机生成 32×128 的灰度图，过一个小卷积网络输出序列长度为 32 的概率分布，让模型跑通 forward 和 CTC 损失的形状。这一步不为训练，而是确认“输入图像 → 序列特征 → 变长解码”这条数据流在你的环境里顺畅。

import tensorflow as tf from tensorflow import keras from tensorflow.keras import layers inputs = keras.Input(shape=(32, 128, 1)) x = layers.Conv2D(32, 3, padding='same', activation='relu')(inputs) x = layers.MaxPool2D((2, 2))(x) x = layers.Lambda(lambda t: tf.reduce_max(t, axis=1, keepdims=True))(x) x = layers.Reshape((-1, 32))(x) x = layers.Bidirectional(layers.LSTM(64, return_sequences=True))(x) logits = layers.Dense(10, name='logits')(x) model = keras.Model(inputs, logits) model.summary()

这里有一个常见误用：很多人直接把 CNN 特征图 reshape 成序列，忽略了高度维度。CRNN 的经典做法是先把高度用池化压到可接受范围，再在高度方向取最大值池化，这样每个时间步对应原图的一个水平切片，宽度方向和 LSTM 时间步一一对应。上面代码里 MaxPool2D((2,2)) 之后高度从 32 变 16，再用 reduce_max 压到 1，最终 Reshape 成 (batch, 64, 32)，宽度被压缩到 64。如果你把宽度也下采样过头，时间步太少，后面 CTC 会因为没有足够的序列长度而对不上标签，这是个隐藏很深的坑。

3. 文字检测实现：DB 模型如何在自然场景中框住文本行

3.1 为什么 YOLO 这类通用检测器在文字上经常翻车

自然场景文字和普通目标有一个决定性的差异：宽高比极端。店招牌可以是一行横跨整个画面，瓶身文字是环绕的弧线，而 YOLO 的锚框体系在设计时假设目标大致是方形或常规比例。你可以把锚框调宽，但横竖混合的场景、密集的小字区域、旋转的方向角，会让锚框匹配变得极不稳定。

另一条原因是文字行之间的相互遮挡。货架上的价签几十个文字紧挨着，通用检测器的 NMS 很容易把相邻的文字行合并成一个目标。所以自然场景文本的主流路线早就不是纯目标检测，而是基于分割的检测：预测每个像素属于文字的概率，再做连通域和最小外接矩形。代表模型是 EAST 和 DB。毕设选 DB 的理由很实在：它对旋转、弯曲、密集文字都好使，而且训练配置公开、复现难度低，踩坑记录也多。

3.2 DB 训练数据格式与最简标签转换

DB 网络输出的不是坐标框，而是一张与输入同尺寸的概率图。训练时标签不是 boxes.txt，而是一个每像素标记是否属于文字区域的 mask。从四边形标注转 mask 的常见做法是用 OpenCV 的 fillPoly 填充。数据可以取 ICDAR 系列公开数据集，也可以自己标；算法课设和自己标都能用，关键是先统一成四点坐标。

下面是把 ICDAR 格式（每行：x1,y1,x2,y2,x3,y3,x4,y4,text）转成 DB 训练标签的可复用脚本：

import cv2 import numpy as np def icdar_line_to_mask(line, img_w, img_h): coords = [float(v) for v in line.strip().split(',')[:8]] pts = np.array(coords, dtype=np.float32).reshape(-1, 2).astype(np.int32) mask = np.zeros((img_h, img_w), dtype=np.uint8) cv2.fillPoly(mask, [pts], 1) return mask

这里有一个关键细节：ICDAR 四个角点的常见顺序是左上、右上、右下、左下，fillPoly 不要求你严格排序，但如果你从标注工具导出时顺序乱了，二值图会出现自相交区域，训练时会产生大量误检。稳妥做法是先计算四边形的凸包：

pts = cv2.convexHull(pts)

这一行能救回很多标注工具导出的脏数据。顺便提醒，mask 里文字区域是 1、背景是 0，训练时概率图的监督信号就是这张 mask；阈值图（threshold map）的 GT 需要按 DB 论文的方法把文本框缩放 0.4 倍生成。如果图省事直接拿 mask 当 threshold GT 训练，模型输出的文字边缘会发灰，后处理时二值化非常不稳定。

3.3 DB 后处理：从概率图到文本框的代码实现

推理阶段拿到模型输出的概率图，常规流程是：二值化 → 找轮廓 → 计算最小外接旋转矩形 → 按面积过滤 → NMS。下面是核心代码，端点检测和识别都能复用：

def db_postprocess(prob, thr=0.3): binary = (prob > thr).astype(np.uint8) contours, _ = cv2.findContours(binary, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) boxes = [] for cnt in contours: area = cv2.contourArea(cnt) if area < 50: continue rect = cv2.minAreaRect(cnt) box = cv2.boxPoints(rect) boxes.append(box) return np.array(boxes)

这个后处理有 4 个参数值得反复调。第一是 thr，DB 论文默认 0.3，如果检测框碎或者漏检，降到 0.2；如果框太散太松，提到 0.4。第二是面积阈值 50，单位是像素平方，小字密集场景调到 20，大字场景调到 100，用来过滤噪声轮廓。第三是 NMS，上面代码没写，建议用旋转 NMS 或者通用 NMS，权重从 0.4 起步。第四是长文本被拆成两段的问题：这通常是轮廓断裂，不是 NMS 的问题，需要在二值化之后做一次水平方向的膨胀，把断开的笔画接起来，膨胀核在 640 分辨率下用 5×3 比较稳。

3.4 检测效果不佳时的三个调节点

检测模型最常见的问题有三种，对应的参数和逻辑完全不同。第一种是“字漏了”，通常不是模型问题，而是概率图阈值太高，或者推理输入分辨率不够。DB 训练常用 640，推理也应保持短边 640；图像最大边超过 2000 时，先缩小再推理，再按缩放比例还原坐标。不要直接让模型吃原图，上采样到 1000 以上并不会带来更多细节，只会让显存先爆掉。

第二种是“框偏了”，概率图没问题，但 minAreaRect 返回的角度定义和你的标注不一致。DB 的旋转框宽高没有严格规范，但一旦定下“宽是长边”这个约定，训练和推理必须保持一致，否则识别时裁剪出来的是旋转 90 度的文字，中文识别模型对这种输入几乎必翻车。

第三种是“同一个文本行断成好几节”，这属于轮廓断裂。可以在二值化后用cv2.dilate沿水平方向做膨胀，把断开的笔画连起来。这个操作会略微扩大框，但能显著提升整行识别通过率。膨胀核大小和输入分辨率绑定，640 输入用 5×3，分辨率更高时要同步放大。

3.5 用 F1 评估检测模块，不要只看准确率

检测模块的评估指标和识别不同，毕业设计里最好用 ICDAR 官方的 P/R/F1。P 是预测框和真实框 IoU 大于 0.5 的数量占预测框总数的比例，R 是这个数量占真实标注框总数的比例，F1 综合二者。很多同学在答辩 PPT 里只放一张检测结果图，说“效果不错”，导师一问“召回多少”就答不上来。

要避免这个情况，至少准备 100 张有标注的测试图，写一个脚本统计 P/R/F1。检测框如果旋转角度和标注差 5 度以内，IoU 可能还过得去；差 10 度以上，框的覆盖率骤降，识别再准也没用。检测模块 F1 低于 0.7，整套系统的识别正确率再高都是绣花枕头，因为文字根本没被框进来。

4. 端到端中文识别：CRNN+CTC 的 Keras 实现与流水线串联

4.1 CRNN 为什么是中文场景 OCR 的安全牌

CRNN 把卷积特征按水平切片拆成时间步，用双向 LSTM 编码序列关系，最后用 CTC 做变长对齐，让网络不需要逐字精确切分就能把整个文本行识别出来。这套结构在中文场景下的价值在于：中文没有空格分词，字符边界模糊，CTC 恰好容忍边界偏移，只要输出序列里包含的字符和顺序正确，解码时就能对齐。

这套结构训练稳定、显存占用低、推理速度快，从 2015 年至今依然是很多工业 OCR 的默认选择。虽然现在已经有 SVTR、TrOCR 这类 Transformer 识别器，但毕业设计的时间包里，CRNN 的生态资料和踩坑记录远多于新模型，遇到问题排查成本低一个等级。更合适的路线是先跑通 CRNN，再把 LSTM 部分替换成 Transformer Encoder 作为进阶。

4.2 中文词表与标签编码：从 7000 个字到 CTC 的必经之路

训练之前先决定词表大小。常见做法是：常用一级汉字 3755 + 二级汉字 3008 + 数字 + 中英文标点，合计约 6800 到 7000 个类别。生僻字可以先映射到一个专门的unknown槽位，否则词表太大会让 CTC 的类别分布极度稀疏，训练时间成倍增加。

CTC 的 label 编码有一个容易搞错的点：在 TensorFlow 的tf.nn.ctc_loss里，blank 索引默认在num_classes - 1，也就是输出维度的最后一类。所以词表里字符 id 从 0 开始编号，blank 永远占最后一位。训练标签里不能出现 blank 这个 id，padding 位置用 -1 填充，并在计算有效长度时用y_true >= 0来统计。把词表 dump 成 json 文件，同时保存char->id和id->char两个映射，训练和推理用同一份，能避免九成“识别出来全是乱码”的问题。

def ctc_loss(y_true, y_pred): batch_len = tf.shape(y_pred)[0] input_len = tf.fill((batch_len,), tf.shape(y_pred)[1]) label_len = tf.reduce_sum(tf.cast(y_true >= 0, tf.int32), axis=-1) return tf.reduce_mean(tf.nn.ctc_loss(y_true, y_pred, label_len, input_len))

这段代码有三个细节值得注意。其一，y_true是稠密张量 (batch, label_length)，-1 是无效填充，y_true >= 0统计有效字符长度。其二，y_pred的序列长度必须与模型输出一致，如果 CNN 部分是 4 倍下采样，input_len 就是图像宽度除以 4。其三，CTC loss 的 blank 索引在输出层是最后一维，不要在损失函数里再手动把第一个类别当作 blank，否则解码时错位严重。

4.3 用 Keras 搭建 CRNN：完整的模型骨架

下面给能跑的骨架代码。输入固定高度 32，宽度 160，训练时固定，推理时可以动态拉长：

import tensorflow as tf from tensorflow import keras from tensorflow.keras import layers def build_crnn(input_shape=(32, 160, 3), num_classes=7000): inputs = keras.Input(shape=input_shape, name='image') x = layers.Conv2D(64, 3, padding='same')(inputs) x = layers.BatchNormalization()(x) x = layers.ReLU()(x) x = layers.MaxPool2D((2, 2))(x) # 高度 32→16 x = layers.Conv2D(128, 3, padding='same')(x) x = layers.BatchNormalization()(x) x = layers.ReLU()(x) x = layers.MaxPool2D((2, 2))(x) # 高度 16→8 x = layers.Conv2D(256, 3, padding='same')(x) x = layers.BatchNormalization()(x) x = layers.ReLU()(x) x = layers.MaxPool2D((2, 1))(x) # 高度 8→4，宽度不变 x = layers.Lambda(lambda t: tf.reduce_max(t, axis=1, keepdims=True))(x) x = layers.Reshape((-1, 256))(x) # (batch, 40, 256) x = layers.Bidirectional(layers.LSTM(128, return_sequences=True))(x) x = layers.Dropout(0.4)(x) logits = layers.Dense(num_classes, name='logits')(x) return keras.Model(inputs, logits)

宽度 160 经过三次池化后变成 40，这就是时间步数。LSTM 按字符顺序编码，但 CNN 特征图的每一列可能包含多个字符的部分信息，CTC 天然处理这种对齐模糊。BatchNormalization 放在卷积和激活之间是实务选择，CRNN 训练时 BN 能显著提高稳定性，但推理阶段要使用 training=False 的统计量；后续转 ONNX 时，最好先冻结 BN 层再导出，否则同一套权重在不同框架里数值会对不上。

LSTM 单元数 128，双向后是 256，对中文任务算轻量配置。训练集上万张可以加到 256，千张级别保持 128 防止过拟合。Dropout 0.4 是常用值，验证集 loss 波动太大可以调到 0.5。

4.4 把检测和识别串成一条可演示的端到端流水线

检测模型输出旋转框后，不能直接把原图的旋转框裁出来丢给 CRNN，因为框是斜的。要先按框的角度做透视矫正，把文本行拉成水平，再等比缩放高度到 32，宽度按比例保留但不超过 250。下面这段串联代码是毕设里最常用的结构：

def crop_and_warp(img, quad, target_h=32): tl, tr, br, bl = quad[0], quad[1], quad[2], quad[3] width_a = np.linalg.norm(br - bl) width_b = np.linalg.norm(tr - tl) max_width = max(int(width_a), int(width_b)) dst = np.array([[0, 0], [max_width-1, 0], [max_width-1, target_h-1], [0, target_h-1]], dtype=np.float32) src = np.array([tl, tr, br, bl], dtype=np.float32) M = cv2.getPerspectiveTransform(src, dst) return cv2.warpPerspective(img, M, (max_width, target_h))

这一步有 3 个问题会在现场被放大。第一，长文本行的 max_width 可能超过 500，CRNN 训练时没看过这么长的序列，LSTM 在长序列上衰减很快，建议超过 250 就等比缩到 250。第二，矫正后的缩放要使用 INTER_CUBIC 或 INTER_LINEAR，默认的 INTER_NEAREST 会在小字号上出现明显锯齿。第三，不要在矫正后做形态学操作，CRNN 需要保留原始颜色和边缘信息来识别笔画。检测框到矫正图再到 CTC 解码，这条链路跑通，就是标题里说的端到端 OCR。

5. 训练避坑与排查：从标注乱码到模型导出的五个现场

5.1 中文标签乱码：数据集读取时最常见的翻车

现象：训练日志里出现“锟斤拷”之类字符，或者 loss 正常下降但最终识别全是乱码。

原因：Windows 下用记事本、Excel 编辑的标注文件默认 GBK 编码，Python 的 open 默认按 UTF-8 读，导致字符串解码出错。另一个隐蔽原因是文件带 BOM 头，UTF-8-BOM 会让第一个字符变成\ufeff，这个字符没被映射进词表，训练时会被当成人手一个的误标记。

解决：统一用 UTF-8 无 BOM 保存标注文件，在读取代码里显式指定编码：

with open('label.txt', 'r', encoding='utf-8-sig') as f: lines = f.readlines()

utf-8-sig会自动剥离 BOM，无论文件带不带 BOM 都能正确处理。处理中文数据集的人，建议把这个写法当成固定习惯，能省掉大量看起来找不到原因的识别乱码问题。

5.2 loss 不降：先查学习率和标签长度

现象：前 5 个 epoch loss 下降，之后在某个数值上震荡或完全不降；验证输出全是重复字符。

原因：最常见的是学习率过大。其次是 CTC 对输入序列长度和标签长度的关系非常敏感：如果输入图像宽度缩得过狠，比如 32×64 的输入最终特征序列只有 16 个时间步，而标签有 20 个字符，CTC loss 会发散但不会报错。你只会看到一个停滞不前的 loss 曲线，然后开始怀疑模型结构。

解决：初始学习率设 1e-3，配合余弦衰减或每 20 轮乘以 0.1；在训练循环里加一次防御性的梯度裁剪，Keras 优化器直接设clipnorm=1.0，能防止偶发的梯度爆炸把前几轮学到的特征冲掉。同时把标签最大长度和模型输出时间步做一次物理检查，确保label_length <= input_length，并打印一批实际形状确认。这个坑之所以花时间，是因为大家总在调模型，很少有人怀疑是特征图尺寸算错了。

5.3 检测框总是斜的：旋转框标注与输出规范不一致

现象：训练好的检测模型，在竖排文字、倾斜文字上输出的框是水平的，识别结果全部乱序。

原因：训练标注是四点旋转框，但后处理时minAreaRect返回的角度定义和训练标签不一致，或者在生成 mask 时用了轴对齐矩形补齐，让模型学到了“框就是水平的”错误监督。

解决：检查训练脚本里生成 mask 时是否严格用四边形而不是矩形；同时建立一条不可变规范：框的角度以长边为基准，长边与水平轴夹角定义为角度，推理端用同一规范输出。抽样打印 20 张检测热力图，确认文字区域覆盖正确，再继续训练。很多“看起来差不多”的框，放大后角度偏差 5 到 10 度，对识别模块是致命的。

5.4 GPU 显存不足：降 batch 还是切图？

现象：训练时 batch=16 配 640×640 输入在 8GB 显存下直接 OOM；推理时 4K 大图一张都放不下。

原因：DB 和 CRNN 的输入尺寸直接决定显存占用。batch=16 配 640×640 在 1080Ti 上本身就很紧张，更常见的是框架在调试模式下额外占用显存，或者输入图像没有统一 resize，导致 batch 内最大尺寸撑爆显存。

解决：三个策略按顺序试。第一个是 batch 降到 4 或 8，同时开启混合精度，Keras 里在训练前加一句tf.keras.mixed_precision.set_global_policy('mixed_float16')，显存占用通常减半；如果 loss 发疯就换回 float32。第二个是推理时按 3.4 节说的缩小再还原坐标。第三个是真正的大图做切片推理，检测完再把相邻切片的框合并。切片时各切片之间留 10% 重叠，避免文字正好被从中间切开。

5.5 模型保存与加载的后悔药

现象：训练好之后，换个机器演示，load_model 直接报错Unknown loss function: ctc_loss，或者自定义层无法序列化。

原因：保存了整个 model，但自定义的ctc_loss和 Lambda 层没有注册到 Keras 的可序列化对象表里。Keras 保存完整模型时会把损失函数名字写进 H5 文件，加载端找不到这个函数名就报错。

解决：保存权重而不是完整模型，这是最稳妥的方式：

model.save_weights('ocr_weights.h5')

推理时用同一份build_crnn代码重建模型，再load_weights进去。如果一定要保存完整模型，加载时传 custom_objects：

from tensorflow.keras.models import load_model model = load_model('ocr_full.h5', custom_objects={'ctc_loss': ctc_loss})

另外，转 ONNX 时导出后要在 ONNX Runtime 里跑一遍样例。Lambda 层里的reduce_max有时会转成不太常见的算子，不同版本的 ONNX Runtime 支持程度不同，这个验证步骤不要跳过。

6. 交付前一晚：用验证集设计与可视化让答辩少受质疑

6.1 合成数据 + 真实数据的双层验证集

训练集无论来自公开数据集还是自己标，验证集一定要保证两个来源：合成数据和真实标注数据。合成数据用中文字体渲染到随机背景上，自动生成 20 张；真实数据手动标注 30 张真实场景图。评价指标分两档看：行级准确率要求整行完全一致，字级准确率允许一个字符的容错。汇报时把两个指标同时写在 PPT 上，并主动解释“行级准确率 80% 不代表每个字都正确”，比被导师追问出来体面得多。

6.2 检测和识别结果的可视化实现

我习惯把“输入图、检测框、概率图、识别文本”四样东西拼成一张对比图，答辩时一页讲清楚全流程。做法非常直接：

vis = np.concatenate([img_with_boxes, prob_map_colored, img_with_ocr_text], axis=1) cv2.imwrite('demo.jpg', vis)

把检测热力图转成彩色，用cv2.applyColorMap即可。这样做的最大好处是，评委看到热力图能直观感受到中间过程是可解释的，而不是套了个隐形模型。在答辩场景里，这比讲十个“我们用了注意力机制”都更有说服力。

6.3 如果还有两周时间，把 CRNN 换成轻量 Transformer

CRNN 是安全牌，但要冲高分，常见进阶方向是替换掉 LSTM 部分：把 BiLSTM 换成一个 2 层的 Transformer Encoder，输入仍是 CNN 特征序列，输出走 CTC；或者参考 SVTR 的思路，在图像 patch 序列上做自注意力。这个改动不会破坏检测和后处理代码，只需要改识别模块内部。时间不够就别动，时间充裕且验证集上 LSTM 的序列建模明显成为瓶颈时再考虑。

最后说一个我自己的习惯：不管做毕设还是正式项目，我都会把“能保存权重、能一行命令推理、能输出可视化”作为完成标准。这个习惯救了我很多次——换机器演示、模型重训、导师临时要看效果，都是因为这三件事没缺，我才能在半小时内给出一个能跑通的演示。这套 OCR 管线也一样，检测、识别、后处理、可视化各留一个入口脚本，比任何花哨的 PPT 都有说服力。希望帮到你。

本文还有配套的精品资源，点击获取