技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

项目背景与痛点

漫画、韩漫、条漫的翻译长期是个半手工活。汉化组的典型流程是:解包、逐页 OCR、人工校对、Photoshop 擦字、按气泡重新排版嵌字、再打包回原格式。一套流程下来,一话 40 页可能要耗掉几个小时,而且极度依赖"嵌字"这个手艺活。

市面上的机器翻译工具大多面向文档或网页,默认输入是连续排版的一段文本。可漫画的版式恰恰相反——信息散落在分镜、气泡、旁白框、拟声词里,还存在竖排日文、手写体、气泡内换行、文字沿曲线排列这些情况。直接把整页丢进 OCR 再翻译,输出的结果往往是"每个字都认识,但位置全乱"。

comic-translate 的定位很明确:它不是又一个截图翻译工具,而是一条从"输入一个 CBZ"到"输出一个译好的 CBZ"的端到端管线,中间把检测、识别、翻译、擦除、排版、重打包全部串起来,并允许每个环节替换引擎。

核心技术揭秘

从架构看,这是一个典型的多阶段流水线 + 可插拔策略设计。整条链路拆成三道边界清晰的层:格式适配层、AI 处理层、版面重建层。层与层之间用统一的数据结构解耦——所有格式最终都被归一化成"页序列",每页再抽象成"文字块列表 + 渲染上下文",这样后续环节就不必关心输入是 PDF 还是 CBR。

几个技术难点值得单独说:

格式适配层其实不简单。CBZ/CBR 本质是 ZIP/RAR 压缩包,但要处理文件名乱序、非图像页、嵌套目录;EPUB 需要解析 OPF 与 XHTML 结构;PDF 还得区分是矢量文字还是扫描图。项目为每种格式写了独立的读写器,但对外暴露的是同一套 Reader/Writer 接口。

检测与 OCR 层是精度瓶颈所在。漫画文字检测比自然场景更难:气泡边界、网点背景、拟声词的夸张字形都会干扰模型。项目采用专门针对漫画训练的检测模型,OCR 端则按语言分流——日文走 manga-ocr 这类漫画语料微调过的模型,其他语言走 EasyOCR/PaddleOCR,还保留了 Google Lens 作为兜底通道。

翻译层用的是策略模式,云端 LLM、传统 MT、本地推理三条路线并存。LLM 在漫画场景里的真正价值不是翻译质量本身,而是上下文连续性——相邻气泡是对白回合,单句直译会丢失指代和语气。项目把同一页的文字块按阅读顺序拼成上下文再送翻译,这一点比很多工具只翻单行要靠谱得多。

版面重建是最被低估的部分。原文擦除用 inpainting 模型(LaMa / AOT-GAN 一类),难点不在擦字本身,而在于擦完之后气泡轮廓、网点、渐变背景不能被破坏。渲染阶段还要解决字体选择、字号自适应、横竖排切换、以及"文字不能溢出气泡边界"这个经典的排版约束问题。

graph TD A[输入:图片 / PDF / EPUB / CBR / CBZ] --> B[格式解包与页面栅格化] B --> C[文本区域检测] C --> D[OCR 文字识别] D --> E[文本清洗与预处理] E --> F{"翻译引擎选择"} F -->|"云端 LLM"| G[GPT / Claude / Gemini] F -->|"传统 MT"| H[DeepL / Google] F -->|"本地模型"| I[Ollama / 本地推理] G --> J[译文后处理与上下文校正] H --> J I --> J J --> K[原文擦除 Inpainting] K --> L[字体匹配与排版渲染] L --> M[页面合成] M --> N[按原格式重新打包]

功能亮点与差异

它真正的差异点有三个:

一是格式覆盖度。 同时吃图片、PDF、EPUB、CBR、CBZ,并且能吐回原格式,这个组合在开源方案里不多见。对下游用户来说,翻译完的文件可以直接丢进阅读器,不用再做二次转换。

二是引擎自由度。 云端 API、本地 Ollama、传统 MT 三档切换,意味着既能用 GPT-4o 追求质量,也能在完全离线、数据不出本机的场景下跑。这对隐私敏感的用户是硬性需求。

三是浏览器扩展形态。 除了桌面端,它还提供了浏览器扩展,能对在线漫画页面直接翻译。这条路走的是 DOM 注入而非截屏重绘,体验上更接近"原生阅读"。

应用场景与落地建议

个人阅读是最直接的使用场景,尤其是追日漫、韩漫但等不及汉化的读者。对汉化组来说,它更适合做初翻流水线:机器出稿,人工只做校对和润色,效率能提升数倍。

生产环境落地要注意几点:

  • 显存与内存。检测、OCR、inpainting 三个模型叠加,低配机器会很难受。批量处理时建议错峰加载,避免同时常驻。
  • 翻译成本。走云端 API 时,一话漫画的文字块数量不小,务必做 token 预算和缓存,同一页重复翻译没必要。
  • 字体授权。渲染环节用到的字体需确认商用许可,尤其是准备公开发布译制作品时。
  • 法律边界。工具本身中立,但翻译并分发受版权保护的作品存在风险,这一点必须提醒。
  • 质量兜底。竖排文字、拟声词、艺术字几乎必然出错,建议在管线里加入"置信度低于阈值则标记待人工处理"的机制。

综合评价

优点:架构分层清晰,各环节可替换,工程上留了足够的扩展点;格式覆盖广,端到端闭环做得完整;本地/云端双轨让它能适配不同隐私与成本诉求。

缺点:依赖链偏重,GPU 门槛把不少用户挡在门外;版面重建的质量高度依赖原图质量,遇到复杂气泡或手写体时渲染结果不稳定;项目处于快速迭代期,接口和模型版本变动频繁,二次开发的稳定性需要自己兜住。

一句话总结:它是目前开源生态里少有的、把"漫画翻译"当成一条完整工程管线而不是一个 demo 来做的项目。如果你在评估漫画本地化工具,它值得作为基线;如果你打算自建流水线,它的分层设计比它的翻译质量更值得借鉴。

关于

GitHub 原始描述(英文)

AI comic and manga translator app/browser extension for automatically translating comics, manga, manhwa, BDs, fumetti, and more in multiple languages and formats (Images, PDF, EPUB, CBR, CBZ etc).

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
3728
价值分
1904
活跃状态
活跃

语言占比

Python

Release