企业官网建设流程全解析

LunaTranslator OCR 接口设置全指南：在线 OCR、内置 PP-OCR 与 GPU/OpenVINO 加速实战

【免费下载链接】LunaTranslator视觉小说翻译器 / Visual Novel Translator项目地址: https://gitcode.com/GitHub_Trending/lu/LunaTranslator

导读

本篇技术指南围绕视觉小说翻译器 LunaTranslator 的 OCR（光学字符识别）接口设置展开，覆盖在线 OCR（百度、腾讯、有道、火山、讯飞、Google Cloud Vision、OCRSpace、大模型通用接口）与离线 OCR（内置 PP-OCR 系列模型、SnippingTool、manga-ocr、WeChat/QQ OCR、WindowsOCR、Tesseract 5）两大体系。读完本文，你将掌握各 OCR 引擎的适用场景与 API 配置方式，理解内置 PP-OCR 各模型档位的精度/速度取舍，并学会通过 GPU（DML）与 OpenVINO 推理加速高精度模型。文中所有结论均可在当前仓库源码（src/LunaTranslator/ocrengines/、src/LunaTranslator/defaultconfig/ocrsetting.json等）中逐行验证。

一、OCR 在 LunaTranslator 中的定位

LunaTranslator 是一款视觉小说翻译器，其核心工作流是"获取文本 → 翻译 → 展示译文"。对于无法通过 Hook 直接抓取文本的游戏（例如使用图片呈现对话、无法注入的游戏引擎），OCR 是唯一的文本获取手段。OCR 的结果会进入与 Hook 文本相同的下游管线：语言识别、分词、词典查询、翻译、后处理，最终以覆盖字幕或替换文本的形式展示。

从源码结构看，src/LunaTranslator/ocrengines/目录下每个文件对应一个 OCR 引擎，全部继承自 baseocrclass.py 中的baseocr基类，统一实现init()与ocr(imagebinary)两个接口，并共享OCRResult结果对象。这意味着无论使用哪个引擎，返回的文本块（含坐标框）都会经过统一的后处理管线（如竖排自适应、文本行合并），用户可以无缝切换引擎而无需关心下游差异。

在 textinput_ocr.py 的设置界面中，与 OCR 结果后处理相关的全局开关包括：

• verticalocr：竖排文本方向，可选横向 / 竖向 / 自适应（默认2即自适应）；
• ocrmergelines：是否合并邻近文本行（默认开启）；
• ocrmergelines_distance：行合并的间距阈值（默认0.4）。

这些参数在 baseocrclass.py 中被实际消费：OCRResult在构造时会根据verticalocr决定按横向还是竖向聚合文本块，若为自适应模式还会通过__guessvertial依据文本框宽高比自动推断排版方向；__nearmergeboxs则依据文本框之间的欧氏距离与阈值合并过近的行块，从而避免一句台词被拆成多行。

二、在线 OCR 引擎

在线 OCR 通过调用云端 API 完成文字识别，不需要下载模型、不占用本地算力，适合对识别精度要求高、且网络条件稳定的场景。缺点是需要注册对应平台账号、申请密钥，并且部分引擎按调用量计费。

所有在线引擎均在 ocrsetting.json 中声明了默认参数与参数类型（argstype）。密钥类参数一律标注"issecret": true，在设置界面会以密文输入框展示。多引擎共用接口时，LunaTranslator 还支持通过"多 API Key"机制（密钥以|分隔）实现轮询与故障转移。

1. 百度

百度在文档中提供了三条接入路径，在 ocrsetting.json 中对应baiduocr_X引擎的接口下拉项（共 6 个）：

| 接口序号 | 对应服务 | 说明 | | - | - | - | | 0 | 百度智能云 OCR · 通用文字识别（标准版） | 返回纯文本，不返回坐标 | | 1 | 百度智能云 OCR · 通用文字识别（标准含位置版） | 返回文本与位置框 | | 2 | 百度智能云 OCR · 通用文字识别（高精度版） | 纯文本，精度更高 | | 3 | 百度智能云 OCR · 通用文字识别（高精度含位置版） | 文本 + 位置框 | | 4 | 百度智能云 · 图片翻译 | 直接返回目标语言译文 | | 5 | 百度翻译开放平台 · 图片翻译 | 直接返回目标语言译文 |

配置参数：接口 0~3 使用百度智能云 OCR 的API Key与Secret Key（通过 OAuth 换取access_token，见 baiduocr_X.py 的get_access_token）；接口 4 复用同一对密钥；接口 5 使用百度翻译开放平台的app_id与app_key。

源码实现要点（baiduocr_X.py）：

• 标准版/高精度版的四个接口分别对应百度 REST 端点general_basic、general、accurate_basic、accurate；
• 请求体中的detect_direction直接取自全局配置verticalocr（!= 0时开启方向检测）；
• 接口 0/1 且源语言为"自动"时，会发送detect_language=True让百度自动检测语种；
• 接口 4/5 的图片翻译返回带坐标框的译文文本，源码中以OCRResult(boxs=..., texts=..., isocrtranslate=True)标记为"OCR 直译"结果，后续会走"不翻译"的展示路径。

2. 腾讯

腾讯云在文档中给出两个入口：OCR 通用印刷体识别与图片翻译，对应txocr引擎的接口下拉项。

配置参数（ocrsetting.json）：

• SecretId/SecretKey：腾讯云 API 密钥；
• ProjectId：仅图片翻译接口需要，对应腾讯云项目 ID；
• Region：区域节点，可选ap-beijing、ap-guangzhou、ap-hongkong、ap-seoul、ap-shanghai、ap-singapore（默认ap-beijing）；
• 接口：OCR_通用印刷体识别或图片翻译。

源码实现要点（txocr.py）：图片翻译走腾讯云 TMT（机器翻译）服务，使用 HMAC-SHA256 签名调用ImageTranslate动作，请求体包含Source/Target语言、Base64 编码的图片Data以及Scene: "doc"场景参数；通用印刷体识别则通过腾讯云 OCR 服务的语言映射表把 LunaTranslator 的Languages枚举映射为腾讯云语言代码（如中文→zh、日文→jap、韩文→kor）。

3. 有道

有道在文档中给出统一入口（网易有道 AI 开放平台），对应youdaocr引擎。

配置参数（ocrsetting.json）：

• APP_KEY：应用 ID；
• APP_SECRET：应用密钥；
• 接口：OCR_通用文字识别或图片翻译。

注意：有道 OCR 的密钥字段名与"有道词典本地 OCR"（youdaodictocr，无需密钥、通过有道词典客户端提供识别能力）不同，配置时不要混淆。

4. 火山引擎

火山引擎对应volcengine引擎，仅需两个参数（ocrsetting.json）：

• Access Key ID；
• Secret Access Key。

文档指向火山引擎官方文档（通用文字识别/翻译相关页面），实际能力覆盖文字识别与图片翻译。

5. 讯飞

讯飞对应xunfei引擎，配置参数（ocrsetting.json）：

• APPId/APISecret/APIKey：讯飞开放平台三要素；
• 接口：通用文字识别 intsig（内部值hh_ocr_recognize_doc）或印刷文字识别（多语种）（内部值ocr）。

6. Google Cloud Vision

对应googlecloudvision引擎，仅需一个参数key（Google Cloud API Key）。

源码实现要点（googlecloudvision.py）：调用vision.googleapis.com/v1/images:annotate，features指定TEXT_DETECTION，图片以 Base64 形式放入请求体；响应解析时逐block → paragraph → word → symbol重组文本，并取每段的boundingBox四角顶点构造坐标框，从而支持"OCR 后按坐标换行/合并"的完整后处理。

7. OCRSpace

对应ocrspace引擎，参数（ocrsetting.json）：

• apikey：OCRSpace API Key；
• 接口：pro或free（免费档有调用限额，pro 档更快更稳定）。

8. 大模型通用接口（OCR）

"大模型通用接口"与 翻译设置（国产大模型） 中的配置方式完全相同，即使用多模态大模型（如 GPT-4V 类）直接"看图识字"。对应chatgptlike引擎，其默认参数与含义（ocrsetting.json）：

• apiurl：API 接口地址，默认https://api.openai.com/v1，兼容 OpenAI 格式的各类国产/自建大模型网关；
• model：模型名，可在设置中通过list_models动态拉取；
• SECRET_KEY：API Key；
• max_tokens：最大生成 token 数（默认 1024，可调范围 1~1,000,000）；
• Temperature（默认 0）与top_p（默认 0.3）：采样参数，配Temperature.use/top_p_use开关；OCR 任务建议保持较低随机性以获得稳定识别结果；
• use_custom_prompt/custom_prompt：自定义提示词，默认提示模板为Recognize the {srclang} text in the picture.，可针对生僻字体或特殊版面改写；
• reasoning_effort：思考强度（none/minimal/low/medium/high/xhigh，默认medium），仅在支持推理的模型上生效；
• thinking.type：思考模式开关（disabled/enabled）；
• frequency_penalty：频率惩罚（0~2，默认 0）；
• customparams：透传其他自定义请求参数。

从 chatgptlike.py 看，该引擎还内置了智谱 GLM 的专用 OCR 端点（open.bigmodel.cn/api/paas/v4/files/ocr），可通过自定义接口地址接入。大模型 OCR 的最大优势是对复杂版面、手写体、竖排文本的鲁棒性远高于传统 OCR，代价是需要消耗 token 额度、延迟较高。

三、离线 OCR 引擎

离线 OCR 完全在本机执行，不依赖网络、无调用费用、隐私性最好，是本地单机使用的首选。离线引擎分为"内置 OCR"与"其他离线引擎"两类。

1. 内置 OCR（PP-OCR 系列）

内置 OCR 使用 PaddleOCR 生态的PP-OCR系列模型，通过 onnxruntime 推理。软件自带PP-OCRv5_mobile（面向简体中文、繁体中文、英文、日文的轻量级模型），开箱即用；若需识别其他语言或追求更高精度，可在设置中下载对应模型。

可用模型一览

设置界面提供多档模型，检测模块 Hmean 与识别模块 Avg Accuracy 均为官方基准数据，体积为模型包大小：

| 模型 | 检测模块 Hmean(%) | 识别模块 Avg Accuracy(%) | 支持的语言 | 体积(MB) | | - | - | - | - | - | | PP-OCRv6_small | 84.1 | 81.3 | 任意 | 25.2 | | PP-OCRv6_medium | 86.2 | 83.2 | 任意 | 99.7 | | PP-OCRv6_tiny | 80.6 | 73.5 | 任意 | 5.45 | | PP-OCRv5_mobile | 79.0 | 81.29 | 简体中文、繁体中文、英文、日文 | 17.7 | | PP-OCRv5_server | 83.8 | 86.38 | 简体中文、繁体中文、英文、日文 | 148 | | eslav_PP-OCRv5_mobile | 79.0 | 81.6 | 东斯拉夫语言 | 11.2 | | korean_PP-OCRv5_mobile | 79.0 | 88.0 | 韩语 | 12.2 | | latin_PP-OCRv5_mobile | 79.0 | 84.7 | 拉丁字母语言 | 11.3 |

选型建议：

• 追求速度与轻量：PP-OCRv6_tiny（仅 5.45MB，适合低配机器）；
• 中日英三语日常使用：自带的PP-OCRv5_mobile已够用；
• 追求极限精度、不介意速度与体积：PP-OCRv6_medium或PP-OCRv5_server（148MB），配合下文"GPU/OpenVINO 加速"手段使用；
• 韩语：korean_PP-OCRv5_mobile识别精度高达 88.0%；
• 俄语等东斯拉夫语言：eslav_PP-OCRv5_mobile；拉丁字母语言：latin_PP-OCRv5_mobile。

模型管理与下载机制

模型管理逻辑集中在 local.py 的localmodels类中：

• 模型存放于files/ocrmodel与cache/ocrmodel两个目录，每个模型目录必须包含det.onnx、rec.onnx、dict.txt三个文件（检测模型、识别模型、字典）以及info.json元信息（含name、languages等字段），否则不会被识别为合法模型；
• 设置界面的"选择模型"窗口会先请求远程Resource/ocr_models模型清单，若网络不可用则回退到本地已安装模型列表；
• 每个模型条目都会标记是否已安装（前缀√），未安装时可点击"下载"按钮在线拉取并解压到cache/ocrmodel，下载过程带进度条与 MD5 校验；
• 运行时checkchange()会监听模型目录变化与线程数/GPU 配置变化，自动热切换模型（local.py）。

内置 OCR 的运行参数

内置 OCR 的默认参数（ocrsetting.json）：

• model：默认PP-OCRv5_mobile；
• thread：推理线程数，默认 4，可在 1~16 之间调节（local.py 的线程数选择框）；
• gpu：是否启用 GPU 推理，默认false；
• luid：GPU 设备逻辑 ID（LUID），默认 0 表示自动选择最佳 GPU；
• device_type：推理设备类型，默认CPU。

提高高精度模型识别效率的两大手段

高精度模型（PP-OCRv6_medium、PP-OCRv5_server）识别更准但速度较慢，文档给出了两种加速方案：

手段一：使用 GPU（DirectML）推理

• 适用前提：软件版本为 Win10 版，或系统为 Windows 11；
• 操作：在内置 OCR 设置中开启"使用 GPU"，程序会自动枚举本机 GPU 并允许选择具体设备；
• 源码佐证：GPU 枚举逻辑在 localocr.cpp 中实现，通过CreateDXGIFactory2+EnumAdapters1遍历显卡，并用EnumAdapterByGpuPreference(DXGI_GPU_PREFERENCE_HIGH_PERFORMANCE)选出高性能 GPU；当luid == 0时自动绑定最佳 GPU，否则按AdapterLuid精确匹配用户选择的设备（localocr.cpp）。Python 侧通过GetDeviceInfoD3D12()探测 D3D12 设备列表，并把luid传入LocalOCR构造器（local.py）；
• 注意：GPU 加速依赖 DML（DirectML）执行提供程序，若当前系统/版本不支持，设置窗口会提示"当前软件或操作系统版本不支持使用GPU"。

手段二：使用 OpenVINO 推理

• 适用前提：Intel 的 CPU / NPU / GPU；
• 操作步骤：
  1. 下载 onnxruntime-openvino 包（版本 1.24.1）；
  2. 解压后将其runtimes/win-x64/native目录下的所有 DLL 覆盖到LunaTranslator/files/DLL64目录（即把 onnxruntime 的 OpenVINO 执行提供程序替换进软件）；
  3. 在内置 OCR 设置中选择 OpenVINO 推理设备即可；
• 源码佐证：local.py通过OcrIsProviderAvailable("OpenVINO")检测当前 onnxruntime 是否包含 OpenVINO 提供程序，并通过GetOpenVINODeviceTypes()枚举可用设备（CPU/NPU/GPU），随后以device_type参数传入LocalOCR完成推理引擎切换。

技术说明：onnxruntime 通过"执行提供程序（Execution Provider）"抽象不同硬件后端，DML与OpenVINO是其中两个常用选项。内置 OCR 默认仅携带 CPU 提供程序，因此 GPU/OpenVINO 加速需要"替换 DLL 或依赖系统自带 DML"两步中的至少一步，这也是文档中要求覆盖 DLL64 目录的原因。

2. 其他离线 OCR 引擎

SnippingTool

调用 Windows 自带"截图工具"（Snipping Tool）的 OCR 能力，无需额外模型。

• 系统要求：仅支持 Win10～Win11 操作系统；
• 使用前提：如果是最新版的 Windows 11 系统则可以直接使用，否则需要在设置中安装该模块；
• 适用场景：系统原生 OCR，安装零成本，适合临时使用；精度与可控性弱于 PP-OCR 系。

manga-ocr（mangaocr）

专为日文漫画优化的 OCR 引擎，对漫画手写体、拟声词等场景识别效果极佳。

• 注意事项：此 OCR 引擎对横向文本识别效果不佳（竖排文本是漫画主流排版，该引擎为此优化）；
• 使用方式：需要下载独立的 CPU 或 GPU 整合包（本地 HTTP 服务，默认端口 5665），LunaTranslator 通过http://127.0.0.1:{Port}/image接口把截图发送给该服务并取回识别文本（mangaocr.py）；
• 端口配置：设置中Port默认 5665，可调范围 1~65535（ocrsetting.json），需与整合包实际监听端口保持一致。

国内用户整合包无法启动的常见问题与解决：首次运行start.bat时整合包会尝试从 huggingface.co 下载模型，国内网络环境容易失败。解决方案有两种：

1. 代理上网：开启代理（可能需要在 TUN 模式下运行）以直连 huggingface；
2. 更换国内镜像：用 VS Code 打开整合包文件夹，利用全局搜索把其中所有huggingface.co替换为hf-mirror.com（替换项较多，需等待片刻），保存后重新运行start.bat，模型会从国内镜像站下载，无需代理。

无论哪种方式，启动成功的标志是控制台出现* Running on http://127.0.0.1:5665字样——首次运行需等待模型下载，之后每次启动需等待模型加载，加载完成后 LunaTranslator 即可正常调用。

WeChat/QQ OCR

复用本机安装的微信或新版 QQ 的 OCR 能力，无需注册任何 API。

• 使用前提：本机已安装微信或新版 QQ；
• 适用场景：零成本白嫖社交软件内置 OCR，适合预算为零的轻量需求；精度与稳定性受宿主程序版本影响。

WindowsOCR

调用 Windows 系统 OCR（对应 Windows 10/11 的文本提取能力）。

• 系统要求：仅支持 Win10～Win11；
• 官方评价：文档明确标注"效果太差，不推荐使用"；
• 语言包管理：查询、安装、移除 OCR 语言包需在 Windows 系统设置中操作（微软 PowerToys Text Extractor 的支持语言列表即为该系统 OCR 的语言覆盖范围），语言包缺失时某些语种会识别失败。

Tesseract 5

经典开源 OCR 引擎 Tesseract 5。

• 安装来源：官方 GitHub Releases 发布页下载对应版本；
• 官方评价：文档同样明确标注"效果太差，不推荐使用"——Tesseract 对游戏 UI 字体、日文竖排、艺术字等场景的鲁棒性不足，在 LunaTranslator 场景下建议优先使用 PP-OCR 系列。

四、OCR 引擎选型速查

| 场景 | 推荐引擎 | 理由 | | - | - | - | | 中日英三语、离线、无网络 | 内置 OCR（PP-OCRv5_mobile） | 开箱即用，零配置 | | 离线、追求最高精度 | PP-OCRv6_medium / PP-OCRv5_server + GPU/OpenVINO | 精度最高，配合加速手段 | | 韩语专精 | korean_PP-OCRv5_mobile | 识别精度 88% | | 俄语等东斯拉夫语言 | eslav_PP-OCRv5_mobile | 专用语言模型 | | 日文漫画（竖排为主） | manga-ocr | 漫画场景特化 | | 复杂版面/手写体 | 大模型通用接口（chatgptlike） | 多模态大模型鲁棒性最强 | | 无 API 预算的日常使用 | WeChat/QQ OCR | 复用已安装软件能力 | | 临时应急 | SnippingTool | 系统自带，安装零成本 | | 不推荐 | WindowsOCR、Tesseract 5 | 文档明确标注效果差 |

五、小结与进阶指引

OCR 引擎的选择本质上是精度、速度、成本、隐私四者的权衡：在线引擎精度高但依赖网络与密钥，离线引擎完全本地化但需管理模型体积；大模型 OCR 版面鲁棒性最强但延迟与 token 成本最高。内置 PP-OCR 体系则提供了从 5.45MB（tiny）到 148MB（server）的完整精度梯度，配合 DML/OpenVINO 加速可兼顾精度与帧率。

若需进一步深入：

• OCR 结果的后处理（竖排自适应、行合并阈值、文本纠错替换）实现在 baseocrclass.py 与 textinput_ocr.py，相关 OCR 参数界面可对照 OCR 参数说明；
• 大模型通用接口的详细参数说明与翻译设置完全一致；
• 各引擎默认参数与密钥字段声明见 ocrsetting.json；
• OCR 识别文本的进一步清洗可参考 文本处理 与 后处理配置。

【免费下载链接】LunaTranslator视觉小说翻译器 / Visual Novel Translator项目地址: https://gitcode.com/GitHub_Trending/lu/LunaTranslator