easyOCR图片文字提取：CRAFT+CRNN批量OCR与参数调优避坑

简介：这是一份面向64位Windows用户的离线图片文字提取工具包，基于Python与easyOCR实现，可用于批量处理扫描文档、截图、发票等图像中的文本，适合需要快速完成OCR识别或进行二次开发的办公人员与开发者。压缩包共4862个文件、约808.61MB，内含py与pyc脚本、pyd与dll运行库、h/hpp等源码头文件，以及txt、enc、ttf等配置和语言资源，基本覆盖easyOCR运行所需依赖。已有1308人学习下载，说明该工具在批量文字识别场景中具有一定参考价值。借助包内脚本与完整依赖，读者可省去繁琐的环境配置，直接体验多语言识别、批量处理与结果输出流程，也可据此调整识别参数、补充异常处理或集成到自有项目中。

1. 六十张手机拍的表格，和一个解压就能跑的 OCR 包

上周有人甩过来一个压缩包，里面是六十多张手机拍的纸质表格，要求两小时内变成可编辑文字。手工抄一遍大概要三小时，于是我把图片文字提取工具.zip解压、装了依赖、跑了一遍批量脚本，四十分钟收工。这个包处理的就是这种场景：把图片丢进去，输出一段可复制的文本；它底层用的是 easyOCR，也就是用 CRAFT 做文本检测、用 CRNN 做文字识别的那套组合，内置简体中文、英文等多语种模型，完全本地推理，不依赖网络。

它适合谁？经常要处理扫描件、发票截图、纸质文档拍照、PDF 转图后提取文字的人，尤其是需要批量跑、不想一张张上传到在线服务的人。不适合谁？需要还原版面结构（表格线、多栏、图文混排位置）的人——纯 OCR 只返回文字和框坐标，拿不到“这是第几行第几列”的语义，那得上版面分析模型。

2. 为什么选 easyOCR：三种环境的装法与模型落盘位置

2.1 Tesseract 与 easyOCR 到底差在哪：一张对比表说清

老牌的 Tesseract 走的是传统图像处理路线：二值化、连通域、特征匹配，识别前得先把图“洗干净”。它对光照均匀、字体规整的扫描件表现稳定，但一旦碰上手机拍的图——背景有阴影、纸张有折痕、字被拍歪——识别率掉得很难看，而且中文需要额外挂chi_sim训练数据，参数调起来相当玄学。easyOCR 是深度学习流水线，检测和识别两个网络都是训练好的权重，开箱即用，中英混排的场景明显更稳。

如果手里的资源已经是 easyOCR 封装的，换成 PaddleOCR 或 Tesseract 意味着整个调用层重写——输入输出结构、参数名、返回值全不一样。所以选型这一步不必纠结“谁更准”，纠结的是“这个包里已经绑定了谁”。绑定 easyOCR 的代价是首次装包体积大、CPU 上慢，收益是省掉一整套预处理调参。

2.2 装完就卡住：模型权重落在哪、离线机器怎么搬

很多人第一次跑会以为装完 pip 就完事，结果 import 之后程序卡在终端不动，以为死机了。其实是在往下拉模型权重。easyOCR 的检测模型和识别模型不在 pip 包里，首次Reader(...)初始化时才会去模型仓库取，默认落到用户目录下的.EasyOCR/model。

# 建一个干净虚拟环境，避免和系统里的 torch / numpy 打架 python -m venv ocr-env source ocr-env/bin/activate # Windows 换成 ocr-env\Scripts\activate # 装 easyOCR，会连带拉取 torch、torchvision、opencv 等依赖 pip install easyocr # 手动触发一次模型下载，把权重提前落盘 python -c "import easyocr; easyocr.Reader(['ch_sim','en'], gpu=False)"

这三步的意义：第一步隔离环境，是因为 easyOCR 依赖 torch 和 opencv，而这两个库对 numpy 版本相当敏感，系统 Python 里往往已经装了别的项目的旧版本，冲突起来报错信息完全看不出根因；第二步装包；第三步单独跑一次 Reader 初始化，把权重下载这件事从业务代码里剥离出来，失败了能立刻定位，不会等到处理到第 30 张图才断。

内网机器没法下载，就把已经跑通过的机器上~/.EasyOCR/model整个目录拷过去，然后在代码里显式指定路径并关掉下载：

import easyocr reader = easyocr.Reader( ['ch_sim', 'en'], gpu=False, model_storage_directory='./models', # 权重目录，和上面拷贝过来的目录对齐 download_enabled=False, # 关掉自动下载，缺文件直接报错而不是卡住 )

model_storage_directory建议用相对路径指向项目内，别用绝对路径，否则换台机器就得改代码。download_enabled=False这一项看着多余，实际是给自己上保险：缺权重时它会立刻抛异常，而不是安静地等待网络超时，排错时间从半小时缩到十秒。

2.3 CPU 与 GPU 两条路线，以及开机自检脚本

pip 装下来的 torch 默认是 CPU 版，gpu=True会直接抛错说没有 CUDA 设备。所以第一步永远是自检，别猜：

import torch, easyocr, cv2 print("torch:", torch.__version__) print("cuda available:", torch.cuda.is_available()) print("device count:", torch.cuda.device_count()) print("easyocr:", easyocr.__version__) print("opencv:", cv2.__version__)

torch.cuda.is_available()返回 False，说明装的是 CPU 版 torch，或者驱动和 CUDA 版本对不上。这时候要么老老实实gpu=False，要么按显卡对应的 CUDA 版本重装 torch——注意是重装 torch，不是重装 easyOCR，easyOCR 本身对设备无感。torch.cuda.device_count()能看出是一张卡还是多张，多卡时 easyOCR 默认只吃第一张，别指望它自动并行。

两条路线的实际差别：CPU 上单张 A4 扫描件，检测加识别大概几秒到十几秒；GPU 上能压到一秒以内。批量六十张图，CPU 跑十几分钟，GPU 一两分钟。但如果只是偶尔提一张图，配 GPU 环境的折腾成本远高于省下来的时间，先跑 CPU 版确认效果再决定要不要上卡，这个顺序更划算。

3. 拆包与链路：一张图从像素到字符串要过几道手

3.1 解压后先确认三样东西

这类工具包结构大同小异，解压后先别急着双击运行，按下面三样过一遍，能省掉后面大半的困惑。

第一样是入口。常见命名是main.py、app.py、ocr_gui.py之类，有的包会同时存在命令行入口和图形入口。图形入口多半是 tkinter 或 PyQt 写的，功能就是选文件夹、点按钮、出文本框；命令行入口接受路径参数，适合批处理。想接进自己的流水线，就看命令行入口，别去改 GUI 逻辑。

第二样是依赖说明。有requirements.txt就照着装，没有就去翻 import 区，把第三方库挑出来。这一步容易漏的是图像相关的库，比如Pillow、opencv-python、numpy，easyOCR 会带一部分，但包里的预处理脚本可能额外用了别的。

第三样是模型目录或下载脚本。有的包会把权重一起打包进去（体积大几百 MB），有的只放一个下载脚本。前者解压即用，后者第一次运行需要联网或手动搬权重，按 2.2 的做法处理。

3.2 CRAFT 检测 + CRNN 识别：链路拆到每一层

搞清楚这条链路，后面调参才有方向。一张图进来，先过检测网络 CRAFT。它输出两张得分图：一张是“文本区域得分”，标出每个像素属于字的概率；一张是“链接得分”，标出相邻字块属于同一段文本的概率。这两张图分别按text_threshold（也有版本管它叫文本置信度阈值）和link_threshold二值化后，做连通域分析，得到一堆候选文本框。

接着是后处理：对每个框做仿射变换，把倾斜的文本条“掰正”成水平长条，再按框的高度裁剪、缩放到识别网络的输入尺寸。识别网络是 CRNN 结构——卷积层提特征，循环层（双向 LSTM）建模字符间的序列关系，最后用 CTC 解码出字符序列。用 CTC 而不是逐字分类，是因为文本框里到底有几个字事先不知道，CTC 能把变长对齐这件事在训练时就解决掉，推理时直接输出序列。

理解这一层结构，几个现象就顺了：框没检测出来，后面识别再准也没用，所以小字漏检要先调检测端参数；框出来了但字识别错，那是识别端的问题，调decoder和语言列表；框被切碎了（一个词变成三个框），那是link_threshold太低，链接得分没把它们连起来。

3.3 readtext 的返回值：bbox 四点、置信度与 paragraph 的坑

工具包里的核心调用基本就是readtext，返回值结构决定了后面怎么处理。

import easyocr reader = easyocr.Reader(['ch_sim', 'en'], gpu=False) result = reader.readtext('demo.png', detail=1, paragraph=False) for bbox, text, conf in result: xs = [p[0] for p in bbox] ys = [p[1] for p in bbox] print(f"{conf:.3f}\t({min(xs)},{min(ys)})\t{text}")

detail=1返回三元组列表，bbox是四个点的坐标，顺序是左上、右上、右下、左下，坐标基于原图——即使内部按canvas_size缩过，返回时会映射回来，不用自己换算。conf是识别置信度，0 到 1，实测里 0.3 以下的多数是噪声或过度切分的碎片。detail=0只返回文本列表，方便但丢掉了位置和置信度，做过滤时就用不上了。

paragraph=True是另一个高频坑：它会把相邻的框合并成段落，返回结构变成(bbox, text)二元组，置信度没了。如果你的代码写死了三元组解包，打开这个开关就直接崩。要不要开取决于需求——纯提取连续正文，开；要做逐行对照、保留位置，关。

4. 参数调优：检测阈值、放大倍数与解码器的取舍表

4.1 检测端三个阈值：text_threshold、low_text、link_threshold

这三个参数直接决定“有多少字被框住”。text_threshold控制文本区域得分图的二值化阈值，调低召回更多小字和浅色字，但同时把纸纹、边框、污渍也框进来；调高只保留高置信区域，漏字风险上升。low_text是文本区域的下限，低于它的像素不参与连通域，遇到淡色印刷体时可以往下压一点。link_threshold管的是“相邻字块算不算同一段”，表格线密集、字间距大的场景下要调低，否则一个词会被切成好几个框。

实操顺序建议：先固定其他参数，只动text_threshold，从 0.7 开始往 0.5 走，看漏检的字有没有被捞回来、噪声有没有暴涨；再动link_threshold，从 0.4 往 0.2 走，观察碎片框是否被合并。两个一起改，出问题就说不清是谁的锅，这是血泪经验。

4.2 小字、倾斜、低对比度：canvas_size、mag_ratio、rotation_info

canvas_size是检测网络输入的长边上限，默认 2560。它的作用是先把图缩放到这个尺寸再检测。手机拍的整页文档，字本来就小，再缩一轮，笔画糊成一团，检测网络根本认不出来——这是长图漏检最常见的原因。调大canvas_size能救回来，代价是显存和内存占用按平方增长。

mag_ratio是整体放大倍数，1.5 到 2.0 对手机拍摄的小字有效，但它放大的同时也放大了噪声，且耗时线性上升。它和canvas_size的区别在于：canvas_size是“缩到多大”，mag_ratio是“先放大多少再处理”，小字场景下mag_ratio更直接，大图场景下先调canvas_size更稳。

rotation_info=[90, 180, 270]处理方向不确定的图——比如一批图里混着横拍和竖拍。打开后每个角度都跑一遍检测，取最优，耗时直接翻到四倍。我的做法是先用 EXIF 方向信息或简单的宽高比判断批量做一次摆正，实在判不出来再开这个开关，别默认打开。

4.3 用时间换精度：decoder、beamWidth 与 batch_size

decoder='greedy'是贪心解码，每步取概率最大的字符，快；decoder='beamsearch'配合beamWidth保留多条候选路径，对形近字（比如“己”和“已”、“0”和“O”）区分更好，慢一些。金额、编号这类不能错的字段，值得开 beamsearch；大段正文用 greedy 就够。

batch_size和workers是吞吐参数，不是精度参数。batch_size在批量推理时提高 GPU 利用率，workers走多进程，但每个进程都会独立加载一份模型——四核机器开 4 个 worker，内存占用是单进程的四倍，机器直接跪。稳妥的起点是workers=0、batch_size=1，跑通了再往上加，一次加一档。

下面是封装好的一份参数组合，可以直接抄：

def ocr_page(path, reader): return reader.readtext( path, detail=1, paragraph=False, canvas_size=2560, # 检测输入长边上限，整页小字调到 3000~3500 mag_ratio=1.0, # 手机拍摄小字可调到 1.5~2.0 text_threshold=0.7, # 文本框置信度，漏字就往下调 low_text=0.4, # 文本区域下限，淡色字往下压 link_threshold=0.4, # 相邻块连接阈值，碎片多就往下调 contrast_ths=0.1, # 低于该对比度触发自动增强 adjust_contrast=0.5, # 增强强度，过高会吃掉细笔画 min_size=10, # 小于该像素高度的框直接丢弃 rotation_info=None, # 方向已知就别开，耗时翻四倍 decoder='greedy', # 关键字段换成 beamsearch beamWidth=5, batch_size=1, workers=0, allowlist=None, # 只提数字时传 '0123456789.' )

min_size值得单独说一句：它按框的像素高度过滤，默认 10。整页文档缩过之后，原本 8 像素高的小字会被直接丢掉，看着像“识别不到”，其实是过滤掉了。整页扫描件场景把它设成 5 或更低，配合canvas_size一起调。

5. 避坑与排查：五条踩坑记录和一套固定的排错顺序

5.1 五条踩坑记录

现象一：import easyocr 直接报错，提示 numpy 的 ABI 不兼容或 opencv 找不到符号。原因通常是系统 Python 里已经装了一份别的项目留下的旧版 numpy，和 easyOCR 依赖的 opencv 编译时用的版本对不上。解决方式是别在全局环境折腾，建虚拟环境重装，装完先跑一遍 2.3 的自检脚本，确认五个版本号都打印出来再写业务代码。

现象二：程序运行后终端一动不动，等了几分钟才出结果，或者干脆超时退出。这是在拉模型权重，默认落到~/.EasyOCR/model。内网或网络受限的机器上这一步会一直等。解决方式是提前在有网机器上跑一次 Reader 初始化，把 model 目录整个拷过来，代码里指定model_storage_directory并设download_enabled=False，缺文件立刻报错，不会假装在干活。

现象三：中文全变成英文乱码或者一串不相干的字符。语言列表写错了。只传['en']时中文会被强行映射到英文字符集，结果就是乱码；传['ch_tra','ch_sim']顺序反了，繁体会抢在简体前面匹配。正确写法是简体优先、英文兜底：['ch_sim', 'en']。数字和符号不需要单独加，识别网络自带基础字符集。

现象四：一整张长截图或整页扫描件，最后只出来几行字。两个原因叠在一起：canvas_size把长边缩到 2560 后小字糊了，min_size又把缩完的小框过滤掉了。解决是先按高度把长图切成两三段分别识别，或者把canvas_size提到 3500、min_size降到 5，同时观察内存占用，别把机器跑爆。

现象五：GPU 跑到一半报显存不足。常见于batch_size和canvas_size同时调大，或者开了多个 worker 各自加载一份模型。先降batch_size到 1，再把workers设回 0，还不行就按图像尺寸分块处理。显存是硬约束，参数调优必须先确定这条边界，再谈精度。

5.2 排错顺序：先看图、再看框、最后看字

排错最忌讳一上来就改参数。我一般按三段走，每段有明确的判据。

第一段看输入图。把图读进来打印尺寸、通道数、均值，确认不是全黑、不是四通道带 alpha、不是 CMYK 的 JPEG。四通道图直接喂进去，opencv 读出来和 PIL 读出来通道顺序不一样，颜色反了检测网络就懵了。这一步用几行代码就能排掉一大半“玄学”问题。

第二段看检测框。把readtext返回的 bbox 画回原图存成一张调试图，肉眼扫一遍：字有没有被框住？框有没有把一个词切成三段？整页是不是只框了下半部分？框不对就只调检测端参数（canvas_size、mag_ratio、text_threshold、link_threshold、min_size），别去动识别端的。

第三段才看字。框对了但字错，问题在识别端：语言列表、decoder、allowlist。形近字错得多就开 beamsearch；某些字符被系统性地认错（比如把“O”全认成“0”），用allowlist或blocklist直接约束字符集，比调参快得多。

6. 进阶落地：批量流水线、置信度过滤与 CER 自检

单张跑通只是开始，真正省时间的是批量。下面这段把目录里的图逐张识别、按置信度过滤、落盘成同名 txt，顺便记录每张图的平均置信度，方便事后挑出可疑结果人工复核。

import pathlib, easyocr reader = easyocr.Reader(['ch_sim', 'en'], gpu=False, download_enabled=False, model_storage_directory='./models') src, out = pathlib.Path('input_images'), pathlib.Path('output') out.mkdir(exist_ok=True) summary = [] for p in sorted(src.glob('*.jpg')) + sorted(src.glob('*.png')): lines = reader.readtext(str(p), detail=1, paragraph=False, canvas_size=3000, mag_ratio=1.5, min_size=5) # 置信度低于 0.3 的多为碎片框，直接丢弃，避免脏字污染正文 keep = [(t, c) for _, t, c in lines if c >= 0.3] (out / (p.stem + '.txt')).write_text("\n".join(t for t, _ in keep), encoding='utf-8') avg = round(sum(c for _, c in keep) / max(len(keep), 1), 3) summary.append((p.name, len(lines), len(keep), avg)) for row in summary: print(row)

这段的关键不在循环，在三个决策点。sorted()保证处理顺序稳定，出问题能复现；置信度 0.3 这条线是可调的，宁可丢几个字也别让噪声混进正文，需要高召回时降到 0.15 再人工过一遍；summary里同时记原始框数和保留框数，比值低于 0.5 说明这张图检测质量差，值得单独看一眼原图。

批量的意义还在于能算指标。抽十张图人工校对一遍，用字级编辑距离算 CER，就能判断这套参数到底够不够用，而不是凭感觉说“还行”。

def cer(ref, hyp): """字级编辑距离 / 参考串长度，越小越好""" m, n = len(ref), len(hyp) dp = list(range(n + 1)) for i in range(1, m + 1): prev, dp[0] = dp[0], i for j in range(1, n + 1): cur = dp[j] dp[j] = min(dp[j] + 1, dp[j - 1] + 1, prev + (ref[i - 1] != hyp[j - 1])) prev = cur return dp[n] / max(m, 1)

CER 低于 0.05 基本可以直接用；0.05 到 0.15 之间，错的多半是形近字和标点，开着 beamsearch 再跑一轮能压下去一截；超过 0.2 就别在参数上磨了，回头查图像质量——分辨率、对焦、光照，这三样决定了 OCR 的天花板，参数只能在天花板下面腾挪。我吃过一次亏：花了两小时调text_threshold，最后发现那批图是拍照时手抖糊掉的，重新拍一遍 CER 直接从 0.28 掉到 0.04。从那以后我每次拿到新的一批图，都强制先抽三张跑一遍、算出 CER、看一眼调试图，再决定要不要调参——顺序反了，全是白工。希望帮到你。

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