Rust製manga translator、LocalLLaMAが見たlocal OCR pipelineの手触り
Original: Local manga translator with LLM build-in, written in Rust with llama.cpp integration View original →
r/LocalLLaMAで注目されたRust製manga translatorは、単なるmodel demoではなくworkflowとして見えたことが強い。作者は、このprojectがmangaだけでなく一般のimage translationにも使え、object detection、visual LLM-based OCR、layout analysis、fine-tuned inpainting modelを組み合わせると説明した。LLM layerにはllama.cppを統合し、Gemma 4 familyとQwen3.5 familyをsupportする。さらにOpenAPI-compatible API経由でLM StudioやOpenRouterも使えるという。
面白いのは、ひとつのmodelが翻訳する話ではなく、複数のvision工程がeditor UXにまとまっていることだ。投稿ではbuttonを押すとpipelineが走り、結果をproofreadしてfont、size、colorを編集できるmini Photoshopのような流れが紹介された。manga translationではOCRの小さな誤りがspeech bubble、layout、redraw品質まで影響するため、完全自動よりも編集可能な結果が重要になる。repoは https://github.com/mayocream/koharu で公開されている。
- local OCRとlayout analysisが、text areaと再描画の問題を分けて扱う。
- llama.cpp integrationにより、cloud-onlyではなくlocal modelを主経路にできる。
- OpenAPI-compatible pathでlocal providerとhosted providerを同じUI内で切り替えられる。
community discussion noted that users want controls as much as automation. コメントではbrowser extension、manual textbox、font customization、video demoの改善などが求められた。これは良い反応だ。単発の驚きではなく、日常のreadingやfan-translation workflowにどう入るかを想像しているからだ。local LLMは、こうした狭く具体的なcreative toolに入ったときに説得力を増す。
元threadは r/LocalLLaMA にある。
Related Articles
Microsoft主導の書簡は、open-weight modelを守る主張だけでなく、署名した企業と不在の企業によって議論を呼んだ。
LocalLLaMAの投稿は、最近の llama.cpp 修正により Gemma 4 GGUF を再取得する価値があると指摘し、ローカル推論利用者が見るべき変更点をまとめている。
最近のr/LocalLLaMA投稿は、Qwen3.5 27Bがqualityとdeployabilityのバランスに優れたlocal modelだと主張する。投稿者はRTX A6000 48GBとllama.cppで約19.7 tokens/secを報告し、commentsではdense 27BとMoEのVRAM economicsが詳しく議論された。