Koharu四阶段流水线实战：如何组合运行检测、OCR、翻译与图像修复（Inpainting）
【免费下载链接】koharuAI-powered manga translator, written in Rust.项目地址: https://gitcode.com/gh_mirrors/ko/koharu
Koharu 是一款用 Rust 编写的开源 AI 漫画翻译工具，其核心是一套固定的四阶段流水线：检测（Detection）→ OCR → 翻译（Translation），以及检测 → 图像修复（Inpainting）两条分支。本文带你完整跑通一次漫画翻译项目：从选择处理范围、组合四个阶段，到理解每个模型阶段何时运行、何时跳过，以及中途停止后已完成的成果为何不会丢失。
上图为 Koharu 主界面：左侧是项目页面列表，中间是漫画画布，右侧图层面板中可以看到文本图层、Cleanup 修复层与原画图层——这正是四阶段流水线运行后的产物。
🧭 先理解 Koharu 的流水线结构
Koharu 没有自由搭建的运行时计算图，而是采用小而明确的工作流：
检测 detection -> OCR -> 翻译 translation \-> 图像修复 inpainting- 检测：用布局模型找出文字区域、对话气泡与分镜，并生成文字擦除掩码（removal mask）；
- OCR：只读取检测出的文字区域，识别原文（如日语）；
- 翻译：调用语言模型把原文翻译为目标语言，写入语义文本组件；
- 图像修复（Inpainting）：用擦除掩码重建原画中被台词遮挡的画面。
这条工作流定义在 crates/koharu-pipeline/src/stages/mod.rs 中：Stages结构体持有 detection、ocr、translation、inpainting 四个命名处理器，每个阶段实现同一套生命周期契约（StageProcessor trait）：懒加载模型、处理恰好一页、产出一个语义化Patch。
各阶段的默认模型可在配置中查看（crates/koharu-pipeline/src/config.rs）：检测默认koharu-layout-rfdetr-seg-2xl，OCR 默认paddleocr-vl-1.6，修复默认lama。
🎯 选择处理范围与阶段组合
在画布上方的处理选择器中，Koharu 支持三种范围（docs/workflow/process-pages.md）：
| 范围 | 含义 |
|---|---|
| 当前页 | 仅画布中可见的这一页 |
| 选中页 | 页面栏（Page Rail）中选中的页面 |
| 整个项目 | 按项目顺序处理所有页面 |
阶段选择则对应 Operation 枚举：
- Full：四个阶段全跑，即完整工作流；
- Through 某阶段：例如"Run through Inpainting"= 检测 + 修复（注意它不会顺带跑 OCR 与翻译）；
- Only 某阶段：只跑一个阶段，适合精修重跑；
- Stages 子集：勾选任意非空组合，按固定工作流顺序执行。
⚠️ 一个关键规则：被省略的前置阶段不会自动补上。如果你要重跑翻译但没有新鲜 OCR 结果，请同时勾上 OCR；同理，重跑修复前通常需要新的检测结果。
🖼️ 各阶段实战要点
检测：给后续阶段"画地图"
检测阶段对输入页面做文字、气泡、分镜三类识别。下图是典型的输入漫画页：
检测模型Koharu Layout RF-DETR Seg 2XL提供 text / bubble / panel 三个置信度阈值：阈值越低，保留越多不确定区域（误报也越多）。官方建议先检查若干代表性页面再调高阈值，见 docs/models/vision-and-inpainting.md。
OCR：只读检测到的文字
Koharu 提供四种 OCR 模型：PaddleOCR-VL 1.6（默认通用视觉语言路线）、Manga OCR（日语漫画专精）、Baberu OCR、Hayai OCR（中日韩英）。识别器无法找回检测阶段遗漏的文字，因此如果 OCR 结果为空，应先到画布上检查检测区域，而不是怀疑翻译模型。
翻译：可插拔的 Provider 后端
翻译是流水线中的普通处理器，其模型选择、目标语言、指令与生成参数都放在[pipeline.translation]配置节中，与 Provider 连接配置（[providers]）解耦。翻译结果会替换每个文本实体的Translation组件，而分析区域与排版层仍保持独立可编辑——这意味着你可以人工改写译文而不影响源文本与版式。支持的 Provider 源码见 crates/koharu-translator/src/remote/（OpenAI、Gemini、DeepL、Claude 等）。
图像修复（Inpainting）：输出质量取决于掩码精度
Inpainting 用检测阶段生成的擦除掩码重建被台词遮挡的画面。下图是一张 4K 风景画测试图，正是 Inpainting 模型要在缺损区域重建周围画质的典型场景：
修复模型分两类：
- 直接修复：LaMa（默认）、AOT Inpainting——轻量快速；
- 生成式：FLUX.2 Klein、RORem Mixed——带正/负提示词控制，但运行时包更大、更耗时。提示词应聚焦"重建周围画面、排除文字"，不要让修复模型去做排版。
另外，你也可以不依赖自动掩码：选择Remove工具手动绘制擦除区域，再对当前页单独运行 Inpainting 阶段，见 docs/workflow/cleanup-and-inpainting.md。
⚡ 调度机制：为什么中途停止也不丢结果
Koharu 流水线的执行单位是"一页上的一个阶段"（crates/koharu-pipeline/README.md）：
- 逐阶段提交：某个页面阶段一完成立即提交，画布即时刷新，无需等待全项目屏障；
- 页面窗口调度：页面按项目顺序进入，调度器始终选最老的就绪页；加速卡上就绪任务共享一条执行通道，模型跨页保持驻留；
- 空输入即跳过：某页没检测到文字 → 自动跳过 OCR 与翻译；擦除掩码为空 → 跳过修复推理。这些是"正常完成"，不是失败；
- 协作式停止：
StopToken阻止新工作开始，进行中的推理会跑到安全边界后丢弃结果；此前所有已提交成果完整保留，执行返回Stopped状态； - OOM 自愈：某阶段显存不足时，加速门会卸载其他阶段的模型、让设备冷却并重试一次。
🛠️ 推荐的组合运行方式
| 场景 | 阶段组合 | 说明 |
|---|---|---|
| 首次处理新项目 | Full（四阶段全跑） | 首次运行含模型下载与加载，耗时较长 |
| 只做"去台词" | Through Inpainting | 检测 + 修复，不含 OCR/翻译 |
| OCR 识别不准 | Only OCR（限当前页/选中页） | 用窄范围重跑，避免覆盖人工修订 |
| 换翻译风格/语言 | Only Translation | 仅替换译文，不影响原画与检测区域 |
| 修完局部文字后补修复 | Only Inpainting（当前页） | 配合手动 Remove 掩码精修 |
💡 重跑派生阶段会替换该阶段的语义输出。重跑检测或 OCR 前，建议先检查已人工修订过的文本元素，并尽量用窄范围（单页或选中页）执行。
📚 延伸阅读
- 流水线模块文档：crates/koharu-pipeline/README.md
- 处理页面工作流：docs/workflow/process-pages.md
- 清理与图像修复：docs/workflow/cleanup-and-inpainting.md
- 视觉与 Inpainting 模型选型：docs/models/vision-and-inpainting.md
- 翻译 Provider 配置：crates/koharu-translator/README.md
模型是懒加载的，且 Koharu 会为每个处理器单独记忆配置档位（切回生成式修复模型时，其提示词配置会自动恢复）。建议先完整跑一轮、再在同一页面上横向对比模型质量，最后再调整项目默认配置。
【免费下载链接】koharuAI-powered manga translator, written in Rust.项目地址: https://gitcode.com/gh_mirrors/ko/koharu
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
