Koharu: a local-first manga translation pipeline in Rust

What Koharu replaces in a manga translation workflow

Translating a manga chapter by hand is a chain of separate tasks: find the text regions, read the Japanese, erase the original lettering, translate, then typeset the result back into the balloons. Most people assemble that chain from unrelated tools (an image editor, an OCR script, a translation site, a font). Koharu's claim is that all of it belongs in one application, with the intermediate results kept as editable state rather than thrown away between steps. The README describes the project as an ML-powered manga translator written in Rust and frames the goal as a local-first workflow. The audience is therefore narrow and specific: people who translate manga pages on their own hardware and care that the source images and the extracted dialogue never leave the machine. The README states plainly that vision models and LLMs run locally to keep data private. If you only need a one-off translation of a single page, the setup cost described below is hard to justify.

The four-stage pipeline and what each stage hands to the next

Koharu is organised as a pipeline of detection, OCR, translation and inpainting, and the README says each stage can be run selectively at page scope or project scope. The order matters. Detection finds text regions, speech bubbles and segmentation masks, and the project ships a dedicated detection model, Koharu Layout RF-DETR Seg 2XL. OCR then reads source text out of those detected regions; the README lists PaddleOCR VL 1.6, Manga OCR, Baberu OCR and Hayai OCR as interchangeable choices. Translation takes the recognised text and produces the target language, either through a local GGUF model or a hosted provider. Inpainting runs against the same regions to reconstruct the artwork behind the source lettering before the translated text is rendered, with FLUX.2 Klein, RORem mixed, LaMa and AOT GAN listed as options. The separation is the interesting design decision. Detection, OCR and inpainting models are selected independently, and translation has its own separate model settings, so you can pair a fast OCR model with a heavier inpainting model without reconfiguring the whole application. It also means the quality of the final page is a product of four independent choices, and a weak link in any one of them shows up in the output.

Getting it running and the settings that matter

The README points to an installation page at koharu.rs/en/installation for getting started, and the project publishes release assets under koharu-rs/koharu on GitHub, so the normal route is a prebuilt binary rather than a cargo build. The repository does not include the exact install commands in the material available here, so treat the installation page as the source of truth for your platform. What the README does specify is the hardware side. Koharu supports CUDA and ROCm/HIP on Windows and Linux, Metal on Apple silicon, and Vulkan on Windows and Linux as an alternative to CUDA and ROCm. A full CUDA or ROCm SDK installation is not required, but the graphics driver must be current. For CUDA, the README states CUDA 13.0 requires an NVIDIA Turing-class or newer GPU and an R580 or newer driver. For ROCm, it states that ROCm 10.0 support depends on the exact AMD GPU, operating system and driver combination, and directs you to AMD's compatibility matrix. The editor canvas itself uses WebGPU and, per the README, requires a current graphics driver even when inference runs on the CPU. Model selection is split across two settings areas: vision and inpainting on one side, translation and generation on the other. Local translation models are GGUF files, and the README names families including LFM 2.5, Ministral 3, Gemma 4 and several Qwen 3.x sizes, alongside a separate list of uncensored Gemma 4 variants.

The proofreading and typesetting layer is where the work actually lands

Automated OCR on manga is not clean, and Koharu does not pretend otherwise: the README lists proofreading for correcting OCR and translation output as a feature, which is an admission that the pipeline produces drafts. The typesetting side is more developed than a naive text overlay. The README describes multilingual text shaping and layout with automatic fitting, font fallback, vertical CJK and right-to-left text, and a WebGPU-based canvas for manual cleanup, text placement and page composition. Export is layered PSD, which the README frames as supporting both flattened delivery and layered editing. That combination tells you who the tool is really for. If you deliver to a scanlation group that edits in Photoshop or Krita, layered PSD output means the automated pass becomes a starting document rather than a finished product. If you expected a one-click translated page, the proofreading step is the part that will surprise you.

Where Koharu is the wrong tool

The hardware requirements are the first real constraint, and they are not soft. CUDA 13.0 needs Turing-class or newer, so older NVIDIA cards are out. ROCm support is conditional on a three-way match between GPU, operating system and driver, which the README explicitly refuses to guarantee. CPU inference exists but the README says it is substantially slower for supported workloads. The WebGPU canvas requirement is the subtler trap: even a CPU-only inference setup still needs a current graphics driver for the editor, so a headless server or a minimal VM is not a viable host. The second constraint is that this is a desktop application with a GUI, not a batch tool you drop into a CI pipeline. The README describes an agent-based workflow for project inspection, editing and pipeline control, which suggests scripting is possible, but the primary interface described throughout is the application itself. The third is model management. You are choosing and supplying detection, OCR, inpainting and translation models, and the quality of your output depends on those choices. Anyone expecting a fixed, tuned default that just works will find the model settings area to be a research task.

How it differs from a hosted translation API

The obvious alternative is a hosted translation service combined with a general image editor. The difference is not speed or accuracy; it is where the intermediate data lives and who controls the models. A hosted API receives the extracted Japanese text, and often the page image, and returns a translation with no visibility into how it was produced and no ability to swap the underlying model. Koharu inverts that: the README states the vision models and LLMs run locally, the translation model is a GGUF file you choose from a published list, and the OCR model is likewise a selection rather than a fixed dependency. The trade is real in both directions. You gain control over the model, offline operation and privacy for the source material. You lose the zero-setup experience, and you take on driver compatibility, model downloads and the disk and VRAM cost of running several models on one machine. For a scanlation group processing licensed material, or for anyone working on pages they would rather not upload, the local model is the point. For occasional use, the hosted route is less work.

Maintenance, release cadence and licence

The release history shows three versions within roughly two days in September 2026 (0.81.8, 0.81.9, 0.81.10), and the last push to the repository is dated 2026-09-10. A cadence that tight on patch numbers suggests active iteration, which cuts both ways: fixes arrive quickly, and so do changes you may need to track. The 0.81.x versioning implies the project has not declared a 1.0, so expect the model lists, hardware guidance and settings surface to keep moving. The repository is licensed Apache-2.0, which permits commercial and private use and modification, and it includes a patent grant. That covers the Koharu code. It does not automatically cover the model weights: the README links to checkpoints hosted on Hugging Face under several different publishers, including mayocream, PaddlePaddle, unsloth, LiquidAI, mistralai and others, and each of those repositories carries its own licence terms. If you plan to distribute translated output or ship Koharu inside a product, read the licence on every checkpoint you select, not just the one on the application repository. Nothing here is legal advice; the point is that the Apache-2.0 label on the code is not the whole licensing picture.

Editorial conclusion

Adopt Koharu if you translate Japanese manga on your own machine and want the vision models and the language model under your control, and if you have an NVIDIA, AMD or Apple GPU with a current driver. Skip it if you need a hosted service with no local model downloads, or if you are working on a machine where the WebGPU canvas cannot get a current graphics driver. Before committing, verify your GPU against the CUDA or ROCm compatibility matrix linked from the hardware page, confirm that the specific detection, OCR and inpainting checkpoints you intend to use are listed under the model settings, and run one chapter end to end to see how much proofreading the OCR and translation steps actually leave you.

Official sources

1. koharu-rs/koharu on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases