古籍OCR用 RapidOCR 把线装书扫描件转成可检索文本的 6 个实操步骤【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR古籍OCR项目里最耗人力的环节往往不是调参而是让模型看懂版式。竖排、从右往左、字距不均、偶尔混一行日文史料——同一批书里版式五花八门在横排扫描件上表现稳定的OCR流程放到古籍上会成批翻车。RapidOCR 是把 PaddleOCR 模型转成 ONNX 格式的开源免费 OCR 工具包一条检测—方向分类—识别流水线默认中文另提供日文、韩文、阿拉伯文等十余种文字系统的识别模型。这篇文章写给第一次拿古籍扫描件跑批的开发者只讲装环境、跑通、看结果和边界这 6 件事。古籍版式里最容易翻车的其实是竖排和混合文字传统 OCR 工具的训练素材多为横排印刷品遇到一列竖下来的字要么整列漏检要么识别出来顺序是乱的。古籍还有两个衍生麻烦一页里夹着日、韩文字的外文史料以及纸面污渍造成的断字。这些版式差异决定了流水线必须有三个环节兜底——文本框检测、方向分类、识别缺一不可。RapidOCR 的三段对应三个可独立开关的模块后面每个环节都拆开讲。两步装好环境跑通第一张古籍扫描件pip install rapidocr onnxruntimefrom rapidocr import RapidOCR engine RapidOCR() result engine(scan_0001.jpg) # 图片路径、URL 或 numpy 数组 result.vis(vis_0001.jpg) # 存一张带标注框的图首次调用会自动下载模型并缓存到本地之后离线也能跑模型是懒加载的同一进程里反复调用 engine() 不会重复初始化。onnxruntime 引擎不挑显卡纯 CPU 就能推理批量扫描任务里这是最省心的组合。下面这张是仓库测试集里的日文样例RapidOCR 对日文这类 CJK 文字有专门的识别模型。竖排文字怎么被读对裁剪、自动转正和方向分类这一节能让你看懂竖排支持背后的机制。检测模型输出的多边形框既能圈住横排的文字行也能圈住竖排的文字列。关键在裁剪环节每个框做透视变换拉平之后如果片段的高宽比超过 1.5代码会自动旋转 90 度把竖着的文字摆正成横排再交给识别模型见 python/rapidocr/utils/process_img.py 里的 get_rotate_crop_image。换句话说古籍的整页竖排不需要你预先旋转图片直接丢进去就行。方向分类器只区分 0° 和 180° 两种状态负责把倒置的行翻正它解决不了 90° 的歪斜那种情况建议扫描阶段就摆正。另外检测前还有一层保护宽矮到宽:高超过 8 倍的图片会自动上下补白整图被限制在 30 到 2000 像素的尺度区间里避免极端比例的扫描页把检测打崩。拿到坐标和文本之后结果对象长什么样怎么验证调用 engine() 返回的对象里核心是三组平行数组boxes 是原文图坐标系下的四点框txts 是识别文本scores 是每行置信度三阶段各自耗时也一并给出排查瓶颈时直接看。识别为空的行会被自动过滤不会混进结果。最省事的验证方式是调用 result.vis() 存一张标注图肉眼核对框与文字是否对得上——比在 IDE 里翻坐标快得多。如果要做逐字对齐或细粒度校对初始化时传 return_word_boxTrue会额外返回词级或单字级的框用于把识别结果和原图字位对应起来。古籍场景必改的两处配置ch_doc 模型与阈值翻拍件的方向错乱EXIF 旋转、整行倒置是常见坑方向分类器兜住 180° 翻转但歪斜超限的图还是建议先转正。配置层面古籍场景有两个值得动的地方。第一是识别模型除了默认中文模型官方模型清单里还有一个面向古籍文档的繁体中文识别模型 ch_doc带独立的繁体字典繁体刻本、善本建议把 Rec.lang_type 指定为 ch_doc。第二是阈值box_thresh 决定多糊的框才收text_score 决定多低的置信度行才保留纸面脏损严重的扫描件默认值可能漏行可以把 box_thresh 适当调低代价是框会变大、置信度整体下降。所有参数集中在 python/rapidocr/config.yaml构造 RapidOCR 时也可以传 params 覆盖单字段不用改文件。三类边界情况和一套固定的验证动作整页纯黑或纯白这种无文字页面流水线返回空结果而不抛异常——批量脚本必须处理这一页什么都没有的分支否则一页卡死整批。方向类问题前面讲过补一句90° 旋转靠裁剪时的自动转正兜底180° 靠方向分类器翻拍歪斜则属于扫描质量责任事后修文本比事前修图贵。验证环节建议固化成三步每批样本先跑 result.vis() 出标注图抽检再统计三阶段耗时定位瓶颈检测慢还是识别慢最后挑漏检最集中的一页反复调参数而不是盲改全局配置。这套动作做完整批上线返工率会低很多。【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
古籍OCR：用 RapidOCR 把线装书扫描件转成可检索文本的 6 个实操步骤
古籍OCR用 RapidOCR 把线装书扫描件转成可检索文本的 6 个实操步骤【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR古籍OCR项目里最耗人力的环节往往不是调参而是让模型看懂版式。竖排、从右往左、字距不均、偶尔混一行日文史料——同一批书里版式五花八门在横排扫描件上表现稳定的OCR流程放到古籍上会成批翻车。RapidOCR 是把 PaddleOCR 模型转成 ONNX 格式的开源免费 OCR 工具包一条检测—方向分类—识别流水线默认中文另提供日文、韩文、阿拉伯文等十余种文字系统的识别模型。这篇文章写给第一次拿古籍扫描件跑批的开发者只讲装环境、跑通、看结果和边界这 6 件事。古籍版式里最容易翻车的其实是竖排和混合文字传统 OCR 工具的训练素材多为横排印刷品遇到一列竖下来的字要么整列漏检要么识别出来顺序是乱的。古籍还有两个衍生麻烦一页里夹着日、韩文字的外文史料以及纸面污渍造成的断字。这些版式差异决定了流水线必须有三个环节兜底——文本框检测、方向分类、识别缺一不可。RapidOCR 的三段对应三个可独立开关的模块后面每个环节都拆开讲。两步装好环境跑通第一张古籍扫描件pip install rapidocr onnxruntimefrom rapidocr import RapidOCR engine RapidOCR() result engine(scan_0001.jpg) # 图片路径、URL 或 numpy 数组 result.vis(vis_0001.jpg) # 存一张带标注框的图首次调用会自动下载模型并缓存到本地之后离线也能跑模型是懒加载的同一进程里反复调用 engine() 不会重复初始化。onnxruntime 引擎不挑显卡纯 CPU 就能推理批量扫描任务里这是最省心的组合。下面这张是仓库测试集里的日文样例RapidOCR 对日文这类 CJK 文字有专门的识别模型。竖排文字怎么被读对裁剪、自动转正和方向分类这一节能让你看懂竖排支持背后的机制。检测模型输出的多边形框既能圈住横排的文字行也能圈住竖排的文字列。关键在裁剪环节每个框做透视变换拉平之后如果片段的高宽比超过 1.5代码会自动旋转 90 度把竖着的文字摆正成横排再交给识别模型见 python/rapidocr/utils/process_img.py 里的 get_rotate_crop_image。换句话说古籍的整页竖排不需要你预先旋转图片直接丢进去就行。方向分类器只区分 0° 和 180° 两种状态负责把倒置的行翻正它解决不了 90° 的歪斜那种情况建议扫描阶段就摆正。另外检测前还有一层保护宽矮到宽:高超过 8 倍的图片会自动上下补白整图被限制在 30 到 2000 像素的尺度区间里避免极端比例的扫描页把检测打崩。拿到坐标和文本之后结果对象长什么样怎么验证调用 engine() 返回的对象里核心是三组平行数组boxes 是原文图坐标系下的四点框txts 是识别文本scores 是每行置信度三阶段各自耗时也一并给出排查瓶颈时直接看。识别为空的行会被自动过滤不会混进结果。最省事的验证方式是调用 result.vis() 存一张标注图肉眼核对框与文字是否对得上——比在 IDE 里翻坐标快得多。如果要做逐字对齐或细粒度校对初始化时传 return_word_boxTrue会额外返回词级或单字级的框用于把识别结果和原图字位对应起来。古籍场景必改的两处配置ch_doc 模型与阈值翻拍件的方向错乱EXIF 旋转、整行倒置是常见坑方向分类器兜住 180° 翻转但歪斜超限的图还是建议先转正。配置层面古籍场景有两个值得动的地方。第一是识别模型除了默认中文模型官方模型清单里还有一个面向古籍文档的繁体中文识别模型 ch_doc带独立的繁体字典繁体刻本、善本建议把 Rec.lang_type 指定为 ch_doc。第二是阈值box_thresh 决定多糊的框才收text_score 决定多低的置信度行才保留纸面脏损严重的扫描件默认值可能漏行可以把 box_thresh 适当调低代价是框会变大、置信度整体下降。所有参数集中在 python/rapidocr/config.yaml构造 RapidOCR 时也可以传 params 覆盖单字段不用改文件。三类边界情况和一套固定的验证动作整页纯黑或纯白这种无文字页面流水线返回空结果而不抛异常——批量脚本必须处理这一页什么都没有的分支否则一页卡死整批。方向类问题前面讲过补一句90° 旋转靠裁剪时的自动转正兜底180° 靠方向分类器翻拍歪斜则属于扫描质量责任事后修文本比事前修图贵。验证环节建议固化成三步每批样本先跑 result.vis() 出标注图抽检再统计三阶段耗时定位瓶颈检测慢还是识别慢最后挑漏检最集中的一页反复调参数而不是盲改全局配置。这套动作做完整批上线返工率会低很多。【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考