PaddleOCR检测标注转识别数据集：坐标切割与透视矫正全流程

做OCR训练的都知道PaddleOCR把整条链路拆成了检测、方向分类、识别三个独立模型。检测模型输出的是一个个文本框而识别模型吃进去的是已经切好的文本行图。于是就有个很常见的问题你手里有一批检测标注数据——每张原图上有几个框、每个框带坐标带文本现在想拿这些数据去训识别模型却发现识别模型要的是另一套东西。我第一次做这个转换时也折腾了不少时间中间踩过坐标错位、方向翻转、标注文件解析错乱一堆坑。这篇就把我自己固定下来的处理流程完整写一遍检测数据长什么样、识别数据长什么样、怎么把前者转成后者以及转换完怎么检查。无论你是准备从零训一个识别模型还是想把别人给的检测标注转成自己的识别训练集这篇都能直接照着操作。1. 检测数据和识别数据到底差在哪坐标、文本行图与标注组织方式很多同学第一次看到两种数据集时都会懵一下不都是“图片 文本标注”吗为什么不能直接拿来用其实差得挺远。1.1 检测标注给的是“位置”识别标注给的是“内容”典型的检测标注长这样通常是一张图片对应一个同名txt文件txt里每一行代表一个文本区域# det_label.txt通常与图片同名每行一个文本框 [[86, 168], [346, 168], [346, 242], [86, 242]] 社区服务中心 [[102, 88], [495, 88], [495, 130], [102, 130]] XX银行储蓄卡而识别数据集的标注长这样每行一个样本图片路径和标签之间用\t分隔# rec_gt.txt一行一个样本图片路径 tab 文本标签 img_001.jpg 社区服务中心 img_002.jpg XX银行储蓄卡区别很明显检测标注的核心信息是“文字在哪”——四个点围起来的区域就是文本位置文本内容只是辅助信息甚至可以留空识别标注的核心信息是“这个图里是什么字”——训练时模型看到一张图片去预测对应的字符串。1.2 识别模型吃的是“一行字”不是“一整张图”检测数据里一张原图通常包含好几段文字分布在画面不同位置。识别模型不一样它默认输入是已经定位好的文本行图像高度一般会被缩放到固定值比如32像素宽度按原比例缩放。如果你直接把带坐标的整张图喂给识别模型模型就懵了它不知道该聚焦哪个区域。你可能觉得“那我把坐标传给模型不就行了”但PaddleOCR的识别模型结构里根本没有接收坐标信息的输入口它的核心是“图像 - 特征 - 序列 - 文本”定位这件事天然不属于识别模型的职责。所以这里的关键认知是所谓“格式转换”本质上不是改一行文本格式而是要把每个文本框从原图中切割出来变成一张张独立的“文本行图”再重新组织成识别模型要求的标注文件。1.3 检测框是倾斜的识别图必须要“正”另一个容易忽略的地方是坐标方向。检测框四点虽然标注了一个文本区域但实际场景里文字大概率是倾斜的拍照角度、印刷歪斜都会让框变成平行四边形甚至是任意四边形。识别模型虽然有一定的抗畸变能力但训练数据尽量规整模型学起来会快很多收敛也更稳。如果直接把倾斜四边形裁剪成矩形图就会把背景也切进来文字本身反而被压扁、拉斜。正确做法是把四边形区域做透视矫正perspective correction把倾斜的文字摆正成水平矩形。后面脚本部分我会详细给实现这里先记住一个结论转换流程是“解析坐标 - 切割区域 - 透视摆正 - 保存单字图 - 生成标注文件”而不是简单的格式替换。2. 转换前先做数据体检坐标合法性、空标注与小目标过滤别急着写转换脚本。我在实际处理中发现检测标注数据里“脏数据”的比例比你想象的要高不先做一轮体检转换出来的识别数据集也会带着一堆问题训练时Loss曲线飘到怀疑人生。2.1 坐标合法性越界框会直接切出黑图第一件事是检查坐标是否在图像边界内。比如说原图是 1280 x 720 的图片标注里却出现了 x 1300 的坐标这类越界框在切割时OpenCV会做边界填充切出来的图片边缘会出现大片黑色或者灰色填充区域。如果只混入少量还好数量多了之后识别模型很容易学到“文字周围带着黑边”的错误模式。我处理的时候会做一次全量扫描对每张图的每个框做判断# 判断四点坐标是否在图像范围内 def check_coords_in_image(coords, img_w, img_h, margin2): xs [p[0] for p in coords] ys [p[1] for p in coords] if min(xs) -margin or max(xs) img_w margin: return False if min(ys) -margin or max(ys) img_h margin: return False return True小范围的越界可以容忍超过边界的框建议直接丢弃。不要尝试“把坐标裁剪回边界内”因为框可能已经严重变形了裁剪回来得到的区域大概率不对。2.2 空文本标注识别训练必须有label检测数据里经常会出现文本内容为空的框比如[[86, 168], [346, 168], [346, 242], [86, 242]] 。这类数据在检测任务里可能是有意义的——它表示“这个位置有文字特征的区域但暂时无法确认内容”但在识别训练里完全没有意义。识别模型是监督学习每张图必须对应一个字符串标签。空标签有两种处理方式一种是直接丢弃这种方式最省事、最安全也是我推荐的做法另一种是把这类图像作为“难例”单独处理标成空格或特殊符号。做空格标签需要额外设计字典还要在后期预测时做后处理过滤灵活性高但坑也深除非你有明确业务诉求否则不建议第一版就这么搞。2.3 小目标过滤过小的框是噪声而不是样本检测标注里还会混入一些特别小的框比如一行高度只有4、5像素的文字。这种图放大之后全是锯齿识别模型很难学到有效的字符特征。我一般会设置两个阈值宽度小于5像素或者高度小于5像素的框直接过滤掉。实际操作时可以稍微宽松一点阈值设成“高度小于4像素”再过滤因为有些标注框确实紧贴着文字切出来高度只有10像素这种是可以用的。核心原则是保留稍微模糊但结构完整的文本行丢弃已经看不出字符结构的极小框。下表是我在数据体检阶段常用的处理策略可以直接对照执行脏数据类型判断方式处理策略坐标越界坐标超出图像宽高直接丢弃空文本标注文本内容为空字符串直接丢弃微小框宽度或高度小于阈值直接丢弃四点顺序混乱多边形自交或凹多边形重排或丢弃异常长宽比宽高比大于20:1检查是否是误标注通常丢弃文本与框不匹配抽样可视化确认人工修正或丢弃该条四点顺序混乱的问题在脚本里会专门解决。检测标注格式不同有的工具导出是按左上、右上、右下、左下有的工具导出是任意起点顺时针或逆时针如果直接按顺序取四个点做透视变换结果可能一塌糊涂。3. 自己写脚本批量转换四点框切割、透视纠偏与标注生成体检做完数据基本干净了接下来就是核心的转换脚本。我的实现思路分四步读取检测标注文件解析出每行的四个坐标点和文本标签根据四个坐标点从原图中切割出对应区域做透视矫正让倾斜的文字变成水平的矩形图保存图片写识别标注文件3.1 解析检测标注处理“坐标和文本混在一起”的麻烦不同标注工具产出的格式略有差异但最典型的有两种一种是每行纯数字加文本x1 y1 x2 y2 x3 y3 x4 y4 text另一种是 JSON 风格[[x1,y1],[x2,y2],[x3,y3],[x4,y4]], text。不管哪种格式最稳妥的解析方式都是先取前8个数值解析坐标剩下的部分整个作为文本。这里有个常见的坑文本内容里如果包含空格用最简单的line.split( )会把文本切碎。比如标签是XX银行 储蓄卡按空格切完了倒数两组就不是文本了。我写了一个比较健壮的解析函数import re import numpy as np def parse_det_line(line): 解析检测标注的一行数据返回(四坐标点, 文本标签) 兼容格式 1) x1 y1 x2 y2 x3 y3 x4 y4 text 2) [[x1,y1],[x2,y2],[x3,y3],[x4,y4]], text line line.strip() if not line: return None, None # 方式1简单空格/制表符分隔 parts re.split(r[\t ], line) coord_values [] for p in parts: # 去掉可能残留的括号引号逗号 cleaned p.strip([],()\) if cleaned: try: coord_values.append(float(cleaned)) except ValueError: break if len(coord_values) 8: nums coord_values[:8] text line[line.find(parts[7]) len(parts[7]):].strip() text text.strip([],()\ ) if text.startswith(,): text text[1:].strip() coords np.array(nums, dtypefloat32).reshape(4, 2) return coords, text # 方式2直接用正则抓取所有数字 nums re.findall(r\d\.?\d*, line) if len(nums) 8: coords np.array([float(n) for n in nums[:8]], dtypefloat32).reshape(4, 2) # 文本是在坐标之后的部分 text_part line for n in nums[:8]: text_part text_part.replace(n, , 1) text text_part.strip([],()\ ) return coords, text return None, None这个函数有点粗暴但胜在能覆盖大多数标注文件的格式变体。如果你的标注格式非常规整比如就是[[x,y],[x,y],[x,y],[x,y]] text可以简化成正则抓数字。3.2 四点重排保证透视变换不翻车拿到四个坐标点之后不要直接送入透视变换。原因我在前面提过四点顺序不统一。这里推荐先做一次“左上 - 右上 - 右下 - 左下”的重排。简单可靠的做法是先按坐标求和排序左上角点的 xy 最小右下角点的 xy 最大。然后按 x 和 y 的差值排序差值最小或最大的是右上角。代码如下def order_points(pts): 将四坐标点按 左上、右上、右下、左下 的顺序重新排列 pts np.array(pts, dtypefloat32) rect np.zeros((4, 2), dtypefloat32) s pts.sum(axis1) # xy diff np.diff(pts, axis1) # x-y注意是竖着看 rect[0] pts[np.argmin(s)] # 左上xy最小 rect[2] pts[np.argmax(s)] # 右下xy最大 rect[1] pts[np.argmin(diff)] # 右上x-y最小偏右上 rect[3] pts[np.argmax(diff)] # 左下x-y最大偏左下 return rect这段逻辑是基于凸四边形的几何特性写的对于正常的文字检测框完全够用。如果你碰到的是凹四边形比如标注工具画出一个自交叉的框重排解决不了根本问题体检阶段就应该把这类数据过滤掉。3.3 透视矫正裁剪并摆正文字切割区域一般有两种做法直接用cv2.boundingRect取外接矩形裁剪或者用cv2.getPerspectiveTransform做透视矫正。我强烈建议用后者。原因很简单直接用外接矩形裁剪相当于把倾斜的文字连同周围的大片背景一起切进来文字还是歪的高度和宽度也拿不准。透视矫正则是把四边形映射到一个标准的矩形文字会被“拉”成水平方向背景干扰也最小。import cv2 def crop_and_rectify(image, pts): 根据四个坐标点从图像中切割文本区域并做透视矫正 rect order_points(pts) (tl, tr, br, bl) rect # 计算输出矩形的宽高取两边距离较大值保证不裁掉内容 widthA np.linalg.norm(br - bl) widthB np.linalg.norm(tr - tl) maxWidth max(int(widthA), int(widthB)) heightA np.linalg.norm(tr - br) heightB np.linalg.norm(tl - bl) maxHeight max(int(heightA), int(heightB)) # 给一点白边 padding防止文字贴边 pad 4 maxWidth pad * 2 maxHeight pad * 2 dst np.array([ [pad, pad], [maxWidth - pad, pad], [maxWidth - pad, maxHeight - pad], [pad, maxHeight - pad] ], dtypefloat32) M cv2.getPerspectiveTransform(rect, dst) warped cv2.warpPerspective(image, M, (maxWidth, maxHeight)) return warped这里的 padding 是我后面实测后加上的不加上来会导致文字边缘紧贴图像边界识别模型偶尔会把边界锯齿也当成特征。加上4像素白边舒服很多。3.4 主流程批量处理并生成识别标注文件上面几个函数拼起来就是完整的转换主流程import os def convert_det_to_rec(det_root, img_root, rec_img_dir, rec_gt_path): det_root: 检测标注文件夹每张图对应一个同名txt img_root: 原图文件夹 rec_img_dir: 识别图片输出目录 rec_gt_path: 识别标注输出文件路径 os.makedirs(rec_img_dir, exist_okTrue) gt_lines [] img_id 0 for label_file in os.listdir(det_root): if not label_file.endswith(.txt): continue img_name label_file.replace(.txt, .jpg) img_path os.path.join(img_root, img_name) if not os.path.exists(img_path): # 尝试png等其他常见扩展名 img_name label_file.replace(.txt, .png) img_path os.path.join(img_root, img_name) if not os.path.exists(img_path): print(f[skip] 找不到图片: {img_path}) continue image cv2.imread(img_path) if image is None: print(f[skip] 图片读取失败: {img_path}) continue with open(os.path.join(det_root, label_file), r, encodingutf-8) as f: lines f.readlines() for line in lines: coords, text parse_det_line(line) if coords is None or text is None: continue if len(text) 0: continue # 简单过滤高度或宽度过小 rect order_points(coords) h np.linalg.norm(rect[1] - rect[0]) w np.linalg.norm(rect[2] - rect[1]) if h 4 or w 4: continue crop_img crop_and_rectify(image, coords) img_id 1 out_name frec_{img_id:06d}.jpg cv2.imwrite(os.path.join(rec_img_dir, out_name), crop_img) gt_lines.append(f{out_name}\t{text}) with open(rec_gt_path, w, encodingutf-8) as f: f.write(\n.join(gt_lines)) print(f转换完成共生成 {img_id} 张文本行图)几点说明图片扩展名我优先取 jpg找不到再试 png。你可以根据自己的数据情况改成先匹配os.listdir(img_root)里实际存在的图片名。输出文件名我用了数字编号避免和检测标注的原始图片名冲突。如果你需要跟原图关联可以在编号前加上原图名前缀。标注写入时用\t分隔这样即使文本里有空格也不会解析错位。如果你的检测标注不是“每张图同名txt”而是全量汇总在一个 gt.txt 里格式一般是图片路径 x1 y1 x2 y2 x3 y3 x4 y4 text。这种情况只需要把主循环的读文件逻辑改成按行解析路径和坐标即可切割函数完全复用。4. 不想写代码就用PPOCRLabel自带导出但有两个前提如果你不想自己写脚本PPOCRLabel 本身自带从检测标注导出识别数据的功能。4.1 现成工具怎么用用 PPOCRLabel 打开你已有的检测标注文件夹它能直接识别检测格式的标注文件并在界面里显示每个文本框。之后在菜单里找到“导出识别数据”相关的选项不同版本位置略有差异通常在文件菜单或工具栏附近指定一个输出目录工具会自动把每个文本框从原图切割出来对切割图做透视矫正保存为新的图片文件生成识别训练所需的标注文件整个过程不需要写一行代码界面操作几分钟就能完成。对于不熟悉编程或只有几万张数据的场景这个方式足够满足需求。4.2 自己写脚本和现成工具怎么选我的建议是数据量小、格式规整、只做一次用 PPOCRLabel数据量大、格式混乱、需要反复迭代写脚本。两者的对比我整理了一下对比维度手写脚本PPOCRLabel 导出学习成本需要懂一点Python和OpenCV基本零成本格式兼容性可自定义解析兼容各种脏数据对格式要求较严格批量处理速度全自动一次性跑完需要打开图形界面大数据量偏慢过滤规则可以自定义高度、宽度、空文本过滤过滤规则有限可复现性脚本保存后随时重新执行每次都要手动操作我自己的经验是第一版数据可以先直接用 PPOCRLabel 导出一部分快速验证识别模型能不能跑起来确认流程没问题后再写脚本处理全部数据。这样既能快速起步也能在正式大规模转换时保留足够的控制力。用现成工具还有一个要注意的点导出后的图片方向不一定全部正确。PPOCRLabel 的矫正算法基于标注框的形状如果原始检测框本身就比较歪矫正后可能仍然是斜的甚至出现上下颠倒。所以无论用哪种方式转换完的抽样质检都省不掉。5. 转换后的质检清单与高频踩坑记录转换完成不代表结束。一个识别数据集的真正质量必须通过质检来判定。我每转完一批数据都会花半小时做下面几件事这里也分享给大家。5.1 先看图片再谈训练抽样可视化检查打开识别图片输出目录随便抽几十张看一遍。重点检查几个方面图片里是否只有一行文字有没有残留多余背景文字是否水平有没有严重倾斜或者上下颠倒图片边缘是否被截断尤其是长文本的最后一个字经常被裁掉一半文本内容和文件名是否对应这种抽查没什么技术含量但比任何自动化指标都直观。我第一次转换的时候就是靠这一步发现了一个严重问题有大约20%的框因为原始标注里四个点的顺序混乱切出来的图全是倒着的。后来我补了一个半自动检查脚本对每一张切割图做简单判断如果图片的宽度远大于高度但平均像素值偏低就有可能是上下颠倒的暗色图。这种粗糙的启发式方法能筛掉一部分问题数据但最终还是要人工看。5.2 高频坑一中文路径导致读取失败Windows 环境下如果原图路径或者标注文件路径包含中文cv2.imread在某些版本里会直接返回None脚本就跑不动。我一开始也踩过处理办法有三个把数据集统一移动到纯英文路径下再处理用cv2.imdecode代替cv2.imread因为imdecode对中文路径的兼容性更好读取图片时先判断返回值是否为None是就打印路径并跳过避免脚本中断最省事的还是第一个数据统一放英文目录。5.3 高频坑二竖排文本被错误转正真实场景里会遇到竖排文字比如门店招牌上的竖排店名。检测框给的是整个竖排区域四点框是纵向的长条矩形。透视矫正后竖排文字会被“拉平”变成一行横躺的字符顺序全乱了。如果你知道自己数据里有竖排文本建议在体检阶段就把这类框单独识别出来——判断方式很简单框的高度明显大于宽度。识别出来后可以单独走竖排数据流程或者直接丢弃。不要把竖排文本和正常横排文本混在一起训练识别模型会被搞糊涂。5.4 高频坑三标注文件里面出现引号、逗号有些检测标注工具会把文本内容用引号包起来比如社区服务中心,。转换时如果没去掉引号识别模型会把引号当作文本的一部分来学。奇怪的是这种错误在训练早期几乎不影响Loss下降因为模型很快就能“记住”这些固定噪声等到准备上线做真实预测时才发现泛化特别差。所以解析函数里要主动去掉文本首尾的引号、逗号、括号。我一般在parse_det_line里做一次strip在生成标注时再做一次清理双重保险。5.5 用识别模型快速验证数据质量打分质检做完后还可以用一个简单粗暴的方式验证数据到底能不能用直接拿现有识别模型或者一个随便下载的通用识别模型对转换出的文本行图做预测对比预测结果和标注文件里的标签算一下字符准确率。如果准确率非常高说明数据质量没问题如果准确率很低但抽样检查图片又没啥问题那可能是你的文本行图风格和模型训练数据差异太大这个就另当别论了。这个方法在数据量大的时候特别有用能自动找出“人眼判断不出来的系统性错误”。我在实际转换中最后固定下来的流程是体检 - 脚本转换 - 抽样看一遍 - 预测验证四步走完再开始训练。第一次转换不要追求一步到位先转出来一批跑一次模型根据Loss和预测结果反推数据问题然后再调过滤规则和矫正参数。这个过程迭代两三轮之后你手里的数据集就会越来越可用比你闷头写一个“完美的转换器”要高效得多。