docs: reflect new models

README.md

@@ -20,7 +20,7 @@ Under the hood, Koharu uses [candle](https://github.com/huggingface/candle) and
 
 ## Features
 
-- Automatic speech bubble detection and segmentation
+- Automatic text block detection, speech bubble detection, and segmentation masks
 - OCR for manga text recognition
 - Inpainting to remove original text from images
 - LLM-powered translation
@@ -124,15 +124,22 @@ Koharu uses a mix of computer vision and language models rather than trying to s
 
 Koharu uses several pre-trained models for different parts of the pipeline:
 
-- [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) for text detection and layout analysis
-- [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector) for text segmentation
+- [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) for joint text block and speech bubble detection
+- [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector) for text segmentation masks
 - [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5) for OCR text recognition
-- [lama-manga](https://huggingface.co/mayocream/lama-manga) for inpainting
+- [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting) for default inpainting
 - [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) for font and color detection
 
+Optional built-in alternatives available in **Settings > Engines** include:
+
+- [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) as an alternative detector and layout-analysis engine
+- [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation) as a dedicated speech bubble detector
+- [Manga OCR](https://huggingface.co/mayocream/manga-ocr) and [MIT 48px OCR](https://huggingface.co/mayocream/mit48px-ocr) as alternative OCR engines
+- [lama-manga](https://huggingface.co/mayocream/lama-manga) as an alternative inpainter
+
 The models are downloaded automatically when you run Koharu for the first time.
 
-We convert the upstream weights to safetensors format for better compatibility and runtime behavior in Rust. The converted weights are hosted on [Hugging Face](https://huggingface.co/mayocream).
+Some models are consumed directly from upstream Hugging Face repos, while Rust-friendly safetensors conversions are hosted on [Hugging Face](https://huggingface.co/mayocream) when Koharu needs a converted bundle.
 
 For a closer look at the pipeline, see [Models and Providers](https://koharu.rs/explanation/models-and-providers/) and the [Technical Deep Dive](https://koharu.rs/explanation/technical-deep-dive/).
 

docs/en-US/explanation/how-koharu-works.md

@@ -4,19 +4,20 @@ title: How Koharu Works
 
 # How Koharu Works
 
-Koharu is built around a page pipeline for manga translation. The user-facing workflow is simple, but the implementation intentionally separates layout, segmentation, OCR, inpainting, translation, and rendering into different stages.
+Koharu is built around a page pipeline for manga translation. The user-facing workflow is simple, but the implementation intentionally separates joint detection, segmentation, OCR, inpainting, translation, and rendering into different stages.
 
 ## The pipeline at a glance
 
 ```mermaid
 flowchart LR
     A[Input manga page] --> B[Detect stage]
-    B --> B1[Layout analysis]
+    B --> B1[Text blocks and bubble regions]
     B --> B2[Segmentation mask]
     B --> B3[Font hints]
     B1 --> C[OCR stage]
     B2 --> D[Inpaint stage]
     C --> E[LLM translation stage]
+    B3 --> F
     D --> F[Render stage]
     E --> F
     F --> G[Localized page or PSD export]
@@ -32,8 +33,8 @@ At the public pipeline level, Koharu runs:
 
 The important implementation detail is that `Detect` is already a multi-model stage:
 
-- `PP-DocLayoutV3` finds text-like layout regions and reading order.
-- `comic-text-detector` produces a per-pixel text probability map.
+- `comic-text-bubble-detector` finds text blocks and speech bubble regions.
+- `comic-text-detector-seg` produces a per-pixel text probability map that becomes the cleanup mask.
 - `YuzuMarker.FontDetection` estimates font and color hints for later rendering.
 
 That split is why Koharu can use one model to decide where text belongs on the page and another to decide which exact pixels should be removed.
@@ -42,9 +43,9 @@ That split is why Koharu can use one model to decide where text belongs on the p
 
 | Stage | Main models | Main output |
 | --- | --- | --- |
-| Detect | `PP-DocLayoutV3`, `comic-text-detector`, `YuzuMarker.FontDetection` | text blocks, segmentation mask, font hints |
+| Detect | `comic-text-bubble-detector`, `comic-text-detector-seg`, `YuzuMarker.FontDetection` | text blocks, bubble regions, segmentation mask, font hints |
 | OCR | `PaddleOCR-VL-1.5` | recognized source text for each block |
-| Inpaint | `lama-manga` | page with original text removed |
+| Inpaint | `aot-inpainting` | page with original text removed |
 | LLM Generate | local GGUF LLM or remote provider | translated text |
 | Render | Koharu renderer | final localized page or export |
 
@@ -57,20 +58,20 @@ Manga pages are harder than plain document OCR:
 - text can overlap artwork, screentones, speed lines, and panel borders
 - reading order is part of the page structure, not just the raw pixels
 
-Because of that, one model is usually not enough. Koharu first estimates layout, then runs OCR on cropped regions, then uses a segmentation mask for cleanup, and only then asks an LLM to translate the text.
+Because of that, one model is usually not enough. Koharu first finds text blocks and bubble regions, then runs OCR on cropped regions, then uses a segmentation mask for cleanup, and only then asks an LLM to translate the text.
 
 ## The implementation shape
 
-In source terms, the pipeline entrypoint runs in `koharu-app/src/pipeline.rs`, while the vision stack is coordinated in `koharu-app/src/ml.rs`.
+In source terms, the engine registry and pipeline execution live in `koharu-app/src/engine.rs`, while the default engine selection lives in `koharu-app/src/config.rs`.
 
 Some implementation details that matter:
 
-- the detect stage uses `PP-DocLayoutV3` first and converts text-like layout labels into `TextBlock` objects
-- overlapping boxes are deduplicated before OCR
-- text direction is inferred from region aspect ratio so vertical manga text can be handled earlier
+- the default detect engine is `comic-text-bubble-detector`, which writes `TextBlock` values and bubble regions in one pass
+- `comic-text-detector-seg` runs after text blocks exist and stores the final cleanup mask as `doc.segment`
 - OCR runs on cropped text regions, not on the full page
 - inpainting consumes the current segmentation mask, not just a rectangular box
 - when you choose a remote LLM provider, Koharu sends OCR text for translation, not the full page image
+- individual stages can be swapped in **Settings > Engines** without changing the rest of the pipeline
 
 ## Why the stack matters
 
@@ -92,6 +93,6 @@ If you configure a remote LLM provider, Koharu sends only the text selected for
 
 ## Want the deep technical version?
 
-See [Technical Deep Dive](technical-deep-dive.md) for model types, segmentation mask theory, FFT-based inpainting, and background references to Wikipedia diagrams plus official model cards. See [Text Rendering and Vertical CJK Layout](text-rendering-and-vertical-cjk-layout.md) for the renderer internals, vertical writing-mode behavior, and current layout limits.
+See [Technical Deep Dive](technical-deep-dive.md) for model types, segmentation mask theory, AOT inpainting, and background references to official model cards. See [Text Rendering and Vertical CJK Layout](text-rendering-and-vertical-cjk-layout.md) for the renderer internals, vertical writing-mode behavior, and current layout limits.
 
 

docs/en-US/explanation/models-and-providers.md

@@ -12,33 +12,42 @@ If you want the architecture-level explanation of how these pieces fit together,
 
 Koharu automatically downloads the required vision models when you use them for the first time.
 
-The default stack includes:
+The current default stack includes:
 
-- [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) for text detection and layout analysis
-- [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector) for text segmentation
+- [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) for joint text-block and speech-bubble detection
+- [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector) for text segmentation masks
 - [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5) for OCR text recognition
-- [lama-manga](https://huggingface.co/mayocream/lama-manga) for inpainting
+- [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting) for default inpainting
 - [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) for font and color detection
 
-Converted model weights are hosted on [Hugging Face](https://huggingface.co/mayocream) in safetensors format for Rust compatibility and performance.
+Some models are used directly from upstream Hugging Face repos, while converted safetensors weights are hosted on [Hugging Face](https://huggingface.co/mayocream) when Koharu needs a Rust-friendly bundle.
 
 ### What each vision model is
 
 | Model | Model type | Why Koharu uses it |
 | --- | --- | --- |
-| `PP-DocLayoutV3` | layout detector | finds text-like regions and reading order |
+| `comic-text-bubble-detector` | object detector | finds text blocks and speech bubble regions in one pass |
 | `comic-text-detector` | segmentation network | produces a text mask for cleanup |
 | `PaddleOCR-VL-1.5` | vision-language model | reads cropped text into text tokens |
-| `lama-manga` | inpainting network | reconstructs the image after text removal |
+| `aot-inpainting` | inpainting network | reconstructs masked image regions after text removal |
 | `YuzuMarker.FontDetection` | classifier / regressor | estimates font and style hints for rendering |
 
-The important design choice is that Koharu does not use a single model for every page task. Layout, segmentation, OCR, and inpainting all need different output shapes:
+The important design choice is that Koharu does not use a single model for every page task. Detection, segmentation, OCR, and inpainting all need different output shapes:
 
-- layout wants regions and order
+- joint detection wants text blocks and bubble regions
 - segmentation wants per-pixel masks
 - OCR wants text
 - inpainting wants restored pixels
 
+### Optional built-in alternatives
+
+You can swap individual stages in **Settings > Engines**. Built-in alternatives include:
+
+- [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) as an alternative detector and layout-analysis engine
+- [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation) as a dedicated bubble detector
+- [Manga OCR](https://huggingface.co/mayocream/manga-ocr) and [MIT 48px OCR](https://huggingface.co/mayocream/mit48px-ocr) as alternative OCR engines
+- [lama-manga](https://huggingface.co/mayocream/lama-manga) as an alternative inpainter
+
 ## Local LLMs
 
 Koharu supports local GGUF models through [llama.cpp](https://github.com/ggml-org/llama.cpp). These models run on your machine and are downloaded on demand when you select them in the LLM picker.

docs/en-US/explanation/technical-deep-dive.md

@@ -4,19 +4,20 @@ title: Technical Deep Dive
 
 # Technical Deep Dive
 
-This page explains the technical side of Koharu's manga pipeline: what each model does, how the stages fit together, and why layout analysis, segmentation masks, OCR, inpainting, and translation are handled separately.
+This page explains the technical side of Koharu's manga pipeline: what each model does, how the stages fit together, and why text and bubble detection, segmentation masks, OCR, inpainting, and translation are handled separately.
 
 ## The page pipeline in implementation terms
 
 ```mermaid
 flowchart TD
-    A[Input page] --> B[PP-DocLayoutV3]
-    A --> C[comic-text-detector]
-    B --> D[Text blocks]
+    A[Input page] --> B[comic-text-bubble-detector]
+    A --> C[comic-text-detector-seg]
+    B --> D[Text blocks + bubbles]
     C --> E[Segmentation mask]
     A --> F[YuzuMarker font detector]
+    D --> C
     D --> G[PaddleOCR-VL crop OCR]
-    E --> H[LaMa inpainting]
+    E --> H[AOT inpainting]
     G --> I[Local or remote LLM]
     F --> J[Renderer style hints]
     H --> K[Renderer]
@@ -27,7 +28,7 @@ flowchart TD
 
 At the code level, the public pipeline steps are `Detect -> OCR -> Inpaint -> LLM Generate -> Render`, but the detect stage is already doing three distinct jobs:
 
-- page layout analysis
+- text and bubble detection
 - text foreground segmentation
 - font and color estimation
 
@@ -37,22 +38,24 @@ That design is deliberate. A manga translation tool needs both page structure an
 
 | Component | Default model | Model type | Main job in Koharu |
 | --- | --- | --- | --- |
-| Layout analysis | [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) | document layout detector | find text-like regions, labels, confidence, and reading order |
+| Text and bubble detection | [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) | object detector | find text blocks and speech bubble regions |
 | Segmentation | [comic-text-detector](https://github.com/dmMaze/comic-text-detector) | text segmentation network | produce a dense text mask for cleanup |
 | OCR | [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5) | vision-language model | read cropped text regions into Unicode text |
-| Inpainting | [lama-manga](https://huggingface.co/mayocream/lama-manga) / [LaMa](https://github.com/advimman/lama) | image inpainting network | fill masked regions after text removal |
+| Inpainting | [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting) / [manga-image-translator](https://github.com/zyddnys/manga-image-translator) | image inpainting network | fill masked regions after text removal |
 | Font hints | [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) | image classifier / regressor | estimate font family, colors, and stroke hints |
 | Translation | local GGUF model via [llama.cpp](https://github.com/ggml-org/llama.cpp) or remote API | decoder-only LLM in most local setups | translate OCR text into the target language |
 
-## Why layout analysis matters on manga pages
+Optional built-in alternatives remain available. The main ones are [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) as an alternative detector and layout-analysis engine, [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation) as a dedicated bubble detector, and [lama-manga](https://huggingface.co/mayocream/lama-manga) as an alternative inpainter.
 
-Layout analysis is not just "find boxes around text". On manga pages it has to answer several structural questions:
+## Why text and bubble detection matters on manga pages
+
+Detection is not just "find boxes around text". On manga pages it has to answer several structural questions:
 
 - which regions are text-like at all
-- where the reading order probably is
+- where speech bubbles are
 - whether a block is tall enough to behave like vertical text
 - which boxes should be deduplicated before OCR
-- which parts of the page are captions, bubble text, titles, or other layout categories
+- which regions should become editable `TextBlock` records
 
 This matters because manga is visually dense:
 
@@ -61,17 +64,16 @@ This matters because manga is visually dense:
 - vertical Japanese and horizontal Latin text can coexist on the same page
 - the region that should be read is not always the same shape as the pixels that should be erased
 
-Koharu uses layout output to create `TextBlock` records first, then uses those blocks to drive OCR and later rendering.
+Koharu uses the detector output to create `TextBlock` records first, then uses those blocks to drive OCR and later rendering. Bubble regions are kept as separate geometry so the UI and later tooling can still reason about the speech-balloon area.
 
-In the current implementation, the layout stage:
+In the current implementation, the default detect stage:
 
-- runs `PP-DocLayoutV3::inference_one_fast(...)`
-- keeps regions whose labels look text-like
-- converts them into `TextBlock` values
-- deduplicates heavily overlapping regions
-- infers vertical vs horizontal source direction from aspect ratio
+- runs the Candle port of `ogkalu/comic-text-and-bubble-detector`
+- converts text detections into `TextBlock` values
+- converts bubble detections into `BubbleRegion` values
+- sorts text blocks into manga reading order before OCR
 
-So layout analysis is the structural backbone of the rest of the pipeline.
+If you prefer a document-layout-style detector, `PP-DocLayoutV3` is still available as an alternative engine. It is just no longer the default.
 
 ## What a segmentation mask is
 
@@ -96,24 +98,22 @@ flowchart LR
 In Koharu, the segmentation path is intentionally separate from layout:
 
 - `comic-text-detector` produces a grayscale probability map
-- Koharu refines that map with post-processing
-- the refined result becomes `doc.segment`
-- LaMa then uses `doc.segment` as the erase and fill mask for inpainting
+- Koharu thresholds and dilates that map with lightweight post-processing
+- the resulting binary mask becomes `doc.segment`
+- `aot-inpainting` then uses `doc.segment` as the erase and fill mask for inpainting
 
-The refinement step matters because raw segmentation probabilities are usually soft and noisy. Koharu thresholds the prediction, tries block-aware refinement, and dilates the final binary mask so the cleanup covers text edges and outlines instead of leaving halos behind.
+The cleanup step still matters because raw segmentation probabilities are usually soft and noisy. Koharu thresholds the prediction and dilates the final binary mask so the cleanup covers text edges and outlines instead of leaving halos behind.
 
 ## How the vision models work in theory
 
-### Layout analysis: detector plus reading-order reasoning
-
-[PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3) is a layout model built for document parsing under skew, warping, and other non-planar distortions. Its model card highlights two properties that are especially relevant to manga-style pages:
+### Joint detection: text blocks and bubble regions in one pass
 
-- it predicts multi-point geometry instead of only axis-aligned two-point boxes
-- it predicts logical reading order in the same forward pass
+[ogkalu/comic-text-and-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) is the default detector because it directly predicts the two region types the rest of the pipeline cares about most:
 
-Koharu's Rust port mirrors that shape: the `pp_doclayout_v3` module contains an `HGNetV2` backbone plus attention-based encoder and decoder blocks, and the inference result exposes `label`, `score`, `bbox`, `polygon_points`, and `order`.
+- text-like regions that should become `TextBlock`s
+- speech-bubble regions that should stay available to the editor and downstream tooling
 
-Conceptually, this is closer to object detection plus layout parsing than to OCR itself.
+Koharu's Candle port maps those detections into document data structures and then sorts the text blocks into manga reading order before OCR. Conceptually, this is closer to page object detection than to OCR itself.
 
 ### Segmentation: dense per-pixel text prediction
 
@@ -123,9 +123,9 @@ Koharu's `comic-text-detector` path is a segmentation-first design. The Rust por
 - a U-Net decoder for mask prediction
 - an optional DBNet head for full detection mode
 
-The default page pipeline uses the segmentation-only path because Koharu already gets layout boxes from `PP-DocLayoutV3`. That means Koharu combines:
+The default page pipeline uses the segmentation-only path because Koharu already gets text blocks from `comic-text-bubble-detector`. That means Koharu combines:
 
-- one model that is good at page structure
+- one model that is good at page-level region detection
 - one model that is good at pixel-level text foreground
 
 This is a better fit for cleanup than relying on boxes alone.
@@ -152,34 +152,24 @@ Koharu's implementation follows that pattern closely:
 
 So OCR in Koharu is not a classic CTC-only recognizer. It is a small document-oriented VLM being used in a tightly scoped OCR task.
 
-### Inpainting: why LaMa uses Fourier convolutions
+### Inpainting: why the default is now AOT
 
-[LaMa](https://github.com/advimman/lama) is an inpainting model designed for large masked regions. Its paper title is explicit about the key idea: *Resolution-robust Large Mask Inpainting with Fourier Convolutions*.
+The default inpainter is the AOT model from [manga-image-translator](https://github.com/zyddnys/manga-image-translator), exposed in Koharu as `aot-inpainting`. It is a masked-image inpainting network built around gated convolutions and repeated context-mixing blocks with multiple dilation rates.
 
 The important intuition is:
 
-- ordinary convolutions are local
-- text removal often needs long-range context from the rest of the bubble or background
-- frequency-domain operations can capture wider context efficiently
-
-This is where FFT comes in.
-
-#### What FFT means here
-
-FFT stands for **Fast Fourier Transform**. It is a fast algorithm for moving between:
+- text removal needs more than a rectangular crop fill
+- the model needs both local edge detail and wider context from the bubble or background
+- repeated multi-dilation blocks are a practical way to mix that context without changing the rest of the pipeline contract
 
-- the spatial domain, where pixels live
-- the frequency domain, where repeating patterns and large-scale structure are easier to manipulate
+Koharu's Candle port follows the upstream inference shape closely:
 
-In Koharu's LaMa port, the `FourierUnit` does exactly that:
+1. resize large pages down to a configurable max side
+2. pad the working image to a multiple-of-8 shape
+3. feed the masked RGB image plus a binary text mask into the network
+4. composite the predicted pixels back into the original image size
 
-1. apply `rfft2` to feature maps
-2. process the real and imaginary channels with learned `1x1` convolutions
-3. apply `irfft2` to return to image space
-
-Koharu even implements custom `rfft2` and `irfft2` ops for CPU, CUDA, and Metal backends so the same spectral block can run across hardware targets.
-
-For manga cleanup, this matters because the missing region is often not just a tiny scratch. It may be an entire speech bubble interior with gradients, screentones, and inked edges. Fourier-style global mixing helps the model preserve larger structures while filling the hole.
+`lama-manga` is still available as an alternative engine if you want LaMa's Fourier-based behavior, but it is no longer the default.
 
 ## Local LLMs and model type
 
@@ -203,21 +193,26 @@ Koharu keeps the image understanding steps local even when you choose a remote t
 
 Some details that are easy to miss if you only read the high-level docs:
 
-- the detect stage currently loads `ComicTextDetector::load_segmentation_only(...)`, not the full DBNet-backed detection mode
-- the segmentation mask is refined against the current detected text blocks before inpainting
+- the default detect stage is `comic-text-bubble-detector`, not `PP-DocLayoutV3`
+- `comic-text-detector-seg` still loads the segmentation-only `comic-text-detector` path for `doc.segment`
+- the segmentation mask is currently built from thresholding plus dilation, not the older block-aware refinement path
 - OCR runs on cropped text-block images, not the original whole page
 - the OCR wrapper uses the multimodal llama.cpp path and the task prompt `OCR:`
 - inpainting consumes `doc.segment`, so bad masks lead directly to bad cleanup
+- the default inpainter is `aot-inpainting`, while `lama-manga` remains selectable as an alternative
 - font prediction is normalized before rendering so near-black and near-white colors snap to cleaner values
 
 ## Recommended reading
 
 ### Official model and project references
 
-- [PP-DocLayoutV3 model card](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3)
+- [comic-text-and-bubble-detector model card](https://huggingface.co/ogkalu/comic-text-and-bubble-detector)
 - [PaddleOCR-VL-1.5 model card](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5)
 - [PaddleOCR-VL architecture docs in Hugging Face Transformers](https://huggingface.co/docs/transformers/en/model_doc/paddleocr_vl)
 - [comic-text-detector repository](https://github.com/dmMaze/comic-text-detector)
+- [manga-image-translator repository](https://github.com/zyddnys/manga-image-translator)
+- [YuzuMarker.FontDetection model card](https://huggingface.co/fffonion/yuzumarker-font-detection)
+- [PP-DocLayoutV3 model card](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3)
 - [LaMa repository](https://github.com/advimman/lama)
 - [llama.cpp](https://github.com/ggml-org/llama.cpp)
 

docs/en-US/index.md

@@ -494,7 +494,7 @@ hide:
         </div>
         <div class="kh-download-hero">
           <a class="kh-download-button" href="https://github.com/mayocream/koharu/releases/latest">
-            Download for Windows&nbsp;&nbsp;<span class="kh-download-button__version">0.40.1</span>
+            Download for Windows&nbsp;&nbsp;<span class="kh-download-button__version">0.42.1</span>
           </a>
           <div class="kh-download-hero__subtext">
             Koharu is free and open source.

docs/ja-JP/explanation/how-koharu-works.md

@@ -4,19 +4,20 @@ title: Koharu の仕組み
 
 # Koharu の仕組み
 
-Koharu は、漫画翻訳のためのページパイプラインを中心に設計されています。ユーザーから見た操作はシンプルですが、実装ではレイアウト解析、segmentation、OCR、inpainting、翻訳、レンダリングを意図的に別段階に分けています。
+Koharu は、漫画翻訳のためのページパイプラインを中心に設計されています。ユーザーから見た操作はシンプルですが、実装では joint detection、segmentation、OCR、inpainting、翻訳、レンダリングを意図的に別段階に分けています。
 
 ## パイプラインの全体像
 
 ```mermaid
 flowchart LR
     A[Input manga page] --> B[Detect stage]
-    B --> B1[Layout analysis]
+    B --> B1[Text blocks and bubble regions]
     B --> B2[Segmentation mask]
     B --> B3[Font hints]
     B1 --> C[OCR stage]
     B2 --> D[Inpaint stage]
     C --> E[LLM translation stage]
+    B3 --> F
     D --> F[Render stage]
     E --> F
     F --> G[Localized page or PSD export]
@@ -32,8 +33,8 @@ flowchart LR
 
 重要なのは、`Detect` がすでに複数モデルから成る段階だということです。
 
-- `PP-DocLayoutV3` はテキストらしいレイアウト領域と読み順を見つけます
-- `comic-text-detector` はピクセル単位のテキスト確率マップを作ります
+- `comic-text-bubble-detector` はテキストブロックと吹き出し領域を見つけます
+- `comic-text-detector-seg` はクリーンアップ用の per-pixel mask を作ります
 - `YuzuMarker.FontDetection` は後段のレンダリングに使うフォントや色のヒントを推定します
 
 この分割によって、Koharu は「ページ上のどこにテキストがあるか」を決めるモデルと、「どのピクセルを実際に消すべきか」を決めるモデルを分けて使えます。
@@ -42,9 +43,9 @@ flowchart LR
 
 | 段階 | 主なモデル | 主な出力 |
 | --- | --- | --- |
-| Detect | `PP-DocLayoutV3`, `comic-text-detector`, `YuzuMarker.FontDetection` | テキストブロック、segmentation mask、フォントヒント |
+| Detect | `comic-text-bubble-detector`, `comic-text-detector-seg`, `YuzuMarker.FontDetection` | テキストブロック、吹き出し領域、segmentation mask、フォントヒント |
 | OCR | `PaddleOCR-VL-1.5` | 各ブロックの認識済み元テキスト |
-| Inpaint | `lama-manga` | 元の文字を消したページ |
+| Inpaint | `aot-inpainting` | 元の文字を消したページ |
 | LLM Generate | ローカル GGUF LLM またはリモートプロバイダ | 翻訳済みテキスト |
 | Render | Koharu renderer | 最終的なローカライズ済みページまたは export |
 
@@ -57,20 +58,20 @@ flowchart LR
 - テキストが作画、スクリーントーン、スピード線、コマ枠に重なる
 - 読み順は単なるピクセル情報ではなく、ページ構造そのものの一部
 
-そのため、1 つのモデルだけでは足りないことが多くなります。Koharu はまずレイアウトを推定し、次に切り出し領域へ OCR をかけ、segmentation mask を使ってクリーンアップし、その後で初めて LLM に翻訳を依頼します。
+そのため、1 つのモデルだけでは足りないことが多くなります。Koharu はまずテキストブロックと吹き出しを見つけ、次に切り出し領域へ OCR をかけ、segmentation mask を使ってクリーンアップし、その後で LLM に翻訳を依頼します。
 
 ## 実装の形
 
-ソースコード上では、パイプラインの入口は `koharu-app/src/pipeline.rs` にあり、vision スタックの調整は `koharu-app/src/ml.rs` で行われています。
+ソースコード上では、エンジンの登録とパイプライン実行は `koharu-app/src/engine.rs` にあり、既定エンジンの選択は `koharu-app/src/config.rs` にあります。
 
 実装上、重要な点は次の通りです。
 
-- detect 段階では先に `PP-DocLayoutV3` を走らせ、テキストらしいラベルを `TextBlock` に変換する
-- 重なりすぎた box は OCR 前に重複除去される
-- テキスト方向は領域の縦横比から推定され、縦書き漫画テキストを早い段階で扱える
-- OCR はページ全体ではなく、切り出したテキスト領域に対して実行される
-- inpainting は単なる矩形ではなく、現在の segmentation mask を使う
-- リモート LLM プロバイダを選んだ場合でも、送るのはページ画像ではなく OCR テキスト
+- 既定の detect エンジンは `comic-text-bubble-detector` で、1 回の推論で `TextBlock` と吹き出し領域を書き込みます
+- `comic-text-detector-seg` は text block が揃った後に走り、最終 mask を `doc.segment` として保存します
+- OCR はページ全体ではなく、切り出したテキスト領域に対して実行されます
+- inpainting は単なる矩形で��なく、現在の segmentation mask を使います
+- リモート LLM プロバイダを選んだ場合でも、送るのはページ画像ではなく OCR テキストです
+- **Settings > Engines** では他の段階を差し替えても残りのパイプラインはそのまま使えます
 
 ## このスタックが重要な理由
 
@@ -92,6 +93,4 @@ Koharu は次を使っています。
 
 ## もっと技術寄りの説明が欲しい場合
 
-モデル種別、segmentation mask の理屈、FFT ベースの inpainting、Wikipedia 図表と公式 model card への参照を含む詳細説明は [技術的な詳細解説](technical-deep-dive.md) を参照してください。レンダラ内部、縦書き挙動、現在のレイアウト上の限界については [テキストレンダリングと縦書き CJK レイアウト](text-rendering-and-vertical-cjk-layout.md) にあります。
-
-
+モデル種別、segmentation mask の理屈、AOT inpainting、公式 model card への参照を含む詳しい説明は [技術的な詳細解説](technical-deep-dive.md) を参照してください。レンダラ内部、縦書き挙動、現在のレイアウト上の限界については [テキストレンダリングと縦書き CJK レイアウト](text-rendering-and-vertical-cjk-layout.md) にあります。

docs/ja-JP/explanation/models-and-providers.md

@@ -4,41 +4,50 @@ title: モデルとプロバイダ
 
 # モデルとプロバイダ
 
-Koharu は vision モデルと language モデルの両方を使います。vision スタックはページを整え、language スタックは翻訳を担当します。
+Koharu は vision モデルと language モデルの両方を使います。vision スタックがページを整え、language スタックが翻訳を担当します。
 
-これらがアーキテクチャ上どう組み合わさっているかを知りたい場合は、このページのあとに [技術的な詳細解説](technical-deep-dive.md) を読んでください。
+これらがアーキテクチャ上でどう組み合わさっているかを知りたい場合は、このページのあとに [技術的な詳細解説](technical-deep-dive.md) を読んでください。
 
 ## Vision モデル
 
 Koharu は、必要な vision モデルを初回利用時に自動でダウンロードします。
 
-既定のスタックには次が含まれます。
+現在の既定スタックには次が含まれます。
 
-- テキスト検出とレイアウト解析用の [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors)
-- テキスト segmentation 用の [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector)
+- テキストブロックと吹き出しを同時に検出する [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector)
+- テキスト segmentation mask を作る [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector)
 - OCR テキスト認識用の [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5)
-- inpainting 用の [lama-manga](https://huggingface.co/mayocream/lama-manga)
+- 既定の inpainting 用の [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting)
 - フォントと色検出用の [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection)
 
-変換済みのモデル重みは、Rust での互換性と性能のために、[Hugging Face](https://huggingface.co/mayocream) 上で safetensors 形式で公開されています。
+一部のモデルは upstream の Hugging Face リポジトリをそのまま使い、Rust で扱いやすい safetensors 変換が必要なものは [Hugging Face](https://huggingface.co/mayocream) で配布しています。
 
 ### 各 vision モデルの役割
 
 | モデル | モデル種別 | Koharu で使う理由 |
 | --- | --- | --- |
-| `PP-DocLayoutV3` | レイアウト検出器 | テキストらしい領域と読み順を見つける |
+| `comic-text-bubble-detector` | object detector | テキストブロックと吹き出し領域を 1 回で見つける |
 | `comic-text-detector` | segmentation network | クリーンアップ用の text mask を作る |
 | `PaddleOCR-VL-1.5` | vision-language model | 切り出したテキストを文字列へ読む |
-| `lama-manga` | inpainting network | 文字除去後の画像を補完する |
+| `aot-inpainting` | inpainting network | 文字除去後の masked 領域を補完する |
 | `YuzuMarker.FontDetection` | classifier / regressor | レンダリング用のフォントやスタイルのヒントを推定する |
 
-重要なのは、Koharu がページ上の全作業を 1 つのモデルに任せていないことです。レイアウト、segmentation、OCR、inpainting はそれぞれ出力形が異なります。
+重要なのは、Koharu がページ上の全作業を 1 つのモデルに任せていないことです。検出、segmentation、OCR、inpainting はそれぞれ欲しい出力が異なります。
 
-- レイアウトが欲しいのは領域と順序
+- joint detection が欲しいのはテキストブロックと吹き出し領域
 - segmentation が欲しいのはピクセル単位の mask
 - OCR が欲しいのは文字列
 - inpainting が欲しいのは補完されたピクセル
 
+### 組み込みの代替エンジン
+
+**Settings > Engines** では段階ごとにエンジンを差し替えられます。主な代替候補は次の通りです。
+
+- 代替の検出 / レイアウト解析エンジンとしての [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors)
+- 専用の吹き出し検出エンジンとしての [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation)
+- 代替 OCR としての [Manga OCR](https://huggingface.co/mayocream/manga-ocr) と [MIT 48px OCR](https://huggingface.co/mayocream/mit48px-ocr)
+- 代替 inpainter としての [lama-manga](https://huggingface.co/mayocream/lama-manga)
+
 ## ローカル LLM
 
 Koharu は [llama.cpp](https://github.com/ggml-org/llama.cpp) を通じてローカル GGUF モデルをサポートします。これらのモデルは手元のマシンで動き、LLM ピッカーで選んだときに必要に応じてダウンロードされます。

docs/ja-JP/explanation/technical-deep-dive.md

@@ -4,19 +4,20 @@ title: 技術的な詳細解説
 
 # 技術的な詳細解説
 
-このページでは、Koharu の漫画翻訳パイプラインを技術面から説明します。各モデルが何をしているのか、各段階がどうつながるのか、そしてなぜレイアウト解析、segmentation mask、OCR、inpainting、翻訳を分けて扱うのかをまとめます。
+このページでは、Koharu の漫画翻訳パイプラインを技術面から説明します。各モデルが何をしているのか、各段階がどうつながるのか、そしてなぜテキストと吹き出しの検出、segmentation mask、OCR、inpainting、翻訳を分けて扱うのかをまとめます。
 
 ## 実装ベースで見たページパイプライン
 
 ```mermaid
 flowchart TD
-    A[Input page] --> B[PP-DocLayoutV3]
-    A --> C[comic-text-detector]
-    B --> D[Text blocks]
+    A[Input page] --> B[comic-text-bubble-detector]
+    A --> C[comic-text-detector-seg]
+    B --> D[Text blocks + bubbles]
     C --> E[Segmentation mask]
     A --> F[YuzuMarker font detector]
+    D --> C
     D --> G[PaddleOCR-VL crop OCR]
-    E --> H[LaMa inpainting]
+    E --> H[AOT inpainting]
     G --> I[Local or remote LLM]
     F --> J[Renderer style hints]
     H --> K[Renderer]
@@ -27,7 +28,7 @@ flowchart TD
 
 コード上の公開パイプライン段階は `Detect -> OCR -> Inpaint -> LLM Generate -> Render` ですが、detect 段階の中で既に 3 つの別作業をしています。
 
-- ページのレイアウト解析
+- テキストと吹き出しの検出
 - テキスト前景の segmentation
 - フォントと色の推定
 
@@ -37,22 +38,24 @@ flowchart TD
 
 | コンポーネント | 既定モデル | モデル種別 | Koharu での主な役割 |
 | --- | --- | --- | --- |
-| レイアウト解析 | [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) | document layout detector | テキストらしい領域、ラベル、信頼度、読み順を見つける |
+| テキスト / 吹き出し検出 | [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) | object detector | テキストブロックと吹き出し領域を見つける |
 | Segmentation | [comic-text-detector](https://github.com/dmMaze/comic-text-detector) | text segmentation network | クリーンアップ用の dense text mask を作る |
 | OCR | [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5) | vision-language model | 切り出したテキスト領域を Unicode 文字列として読む |
-| Inpainting | [lama-manga](https://huggingface.co/mayocream/lama-manga) / [LaMa](https://github.com/advimman/lama) | image inpainting network | 文字除去後の masked 領域を埋める |
+| Inpainting | [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting) / [manga-image-translator](https://github.com/zyddnys/manga-image-translator) | image inpainting network | 文字除去後の masked 領域を埋める |
 | フォントヒント | [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) | image classifier / regressor | フォント系統、色、縁取りヒントを推定する |
 | 翻訳 | [llama.cpp](https://github.com/ggml-org/llama.cpp) 経由のローカル GGUF モデル、またはリモート API | ローカルでは主に decoder-only LLM | OCR テキストを対象言語へ翻訳する |
 
-## なぜ漫画ページでレイアウト解析が重要なのか
+組み込みの代替エンジンも残っています。主なものは、代替の検出 / レイアウト解析エンジンとしての [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors)、専用の吹き出し検出エンジンとしての [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation)、代替 inpainter としての [lama-manga](https://huggingface.co/mayocream/lama-manga) です。
 
-レイアウト解析は、単に「テキストの周囲に box を置く」だけではありません。漫画ページでは、少なくとも次の構造的な問いに答える必要があります。
+## なぜテキストと吹き出しの検出が重要なのか
 
-- そもそもどの領域がテキストらしいか
-- おおよその読み順がどうなっているか
+検出は、単に「文字の周囲に box を置く」だけではありません。漫画ページでは少なくとも次の問いに答える必要があります。
+
+- どの領域がテキストらしいか
+- どこが吹き出しか
 - そのブロックが縦書きとして扱うべき縦長領域か
-- OCR 前にどの box を重複除去するべきか
-- その領域が caption、吹き出し本文、タイトル、その他レイアウト要素のどれに近いか
+- OCR 前にどの box を重複除去すべきか
+- どの領域を編集可能な `TextBlock` に変換すべきか
 
 漫画は視覚的に密度が高いので、ここが非常に重要です。
 
@@ -61,17 +64,16 @@ flowchart TD
 - ���書き日本語と横書きラテン文字が同じページに混在する
 - 読み取るべき領域の形と、消すべきピクセルの形が一致しないことがある
 
-Koharu はまずレイアウト出力から `TextBlock` を作り、それを OCR や後段のレンダリングの基盤にします。
+Koharu は検出結果から `TextBlock` を作り、それを OCR や後段のレンダリングの基盤にします。吹き出し領域は別のジオメトリとして保持し、UI や後段処理で参照できるようにしています。
 
-現在の実装では、レイアウト段階は次のように動きます。
+現在の既定 detect 段階では、次のように動きます。
 
-- `PP-DocLayoutV3::inference_one_fast(...)` を実行する
-- テキストらしいラベルの領域を残す
-- それを `TextBlock` に変換する
-- 大きく重なった領域を重複除去する
-- 縦横比から縦書き / 横書き方向を推定する
+- Candle 版の `ogkalu/comic-text-and-bubble-detector` を実行する
+- テキスト検出を `TextBlock` に変換する
+- 吹き出し検出を `BubbleRegion` に変換する
+- OCR 前に text block を漫画向けの読み順へ並べる
 
-つまり、レイアウト解析はパイプライン全体の構造的な背骨です。
+文書レイアウト寄りの検出器を使いたい場合は、`PP-DocLayoutV3` も代替エンジンとして利用できます。ただし既定ではありません。
 
 ## segmentation mask とは何か
 
@@ -87,33 +89,31 @@ segmentation mask は、各ピクセルが対象クラスに属するかどう
 
 ```mermaid
 flowchart LR
-    A[Speech bubble] --> B[Layout box]
+    A[Speech bubble] --> B[Detected block]
     A --> C[Segmentation mask]
     B --> D[Crop for OCR]
     C --> E[Erase exact text pixels]
 ```
 
-Koharu では、segmentation 経路はレイアウトとは意図的に分離されています。
+Koharu では、segmentation 経路は検出と意図的に分離されています。
 
 - `comic-text-detector` がグレースケールの確率マップを出す
-- Koharu がそれを後処理で洗練する
-- 洗練後の結果が `doc.segment` になる
-- その後 LaMa が `doc.segment` を消去・補完用の mask として使う
+- Koharu がそれを threshold と dilation で軽く後処理する
+- 結果が `doc.segment` になる
+- `aot-inpainting` が `doc.segment` を消去・補完用の mask として使う
 
-この洗練工程が重要なのは、生の segmentation 確率がたいていソフトでノイジーだからです。Koharu は予測を threshold し、text block を意識した refinement を試み、最終的な 2 値 mask を dilation して、文字の縁や輪郭が残って halo になるのを防ぎます。
+この後処理が必要なのは、生の segmentation 確率がソフトでノイジーだからです。Koharu は予測を 2 値化し、最終 mask を dilation して、文字の縁や輪郭が残って halo になるのを減らします。
 
 ## Vision モデルは理論上どう動くのか
 
-### レイアウト解析: detector と読み順推定の組み合わせ
-
-[PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3) は、傾きや湾曲など平面ではない歪みを含む文書解析向けのレイアウトモデルです。model card には、漫画ページでも重要な性質が 2 つあります。
+### Joint detection: テキストブロックと吹き出しを 1 回で取る
 
-- 軸平行な 2 点 box だけでなく multi-point geometry を予測する
-- 同じ forward pass で論理的な読み順も予測する
+[ogkalu/comic-text-and-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) を既定にしている理由は、後段が欲しい 2 種類の領域を直接返してくれるからです。
 
-Koharu の Rust 実装もそれに沿っており、`pp_doclayout_v3` モジュールには `HGNetV2` バックボーンと attention ベースの encoder / decoder があり、推論結果として `label`、`score`、`bbox`、`polygon_points`、`order` が得られます。
+- `TextBlock` にしたいテキスト領域
+- エディタや後段ツールで使いたい吹き出し領域
 
-概念的には、これは OCR そのものというより object detection と layout parsing に近い処理です。
+Koharu の Candle 版は、この検出結果をドキュメント構造へ変換し、OCR の前に text block を漫画向けの読み順へ並べます。概念的には OCR というよりページ object detection に近い処理です。
 
 ### Segmentation: ピクセル密度の高いテキスト予測
 
@@ -123,10 +123,10 @@ Koharu の `comic-text-detector` 経路は segmentation-first な設計です。
 - mask 予測用の U-Net デコーダ
 - フル検出モード向けのオプション DBNet head
 
-既定のページパイプラインでは segmentation-only 経路を使います。Koharu はすでに `PP-DocLayoutV3` からレイアウト box を得ているから��す。つまり Koharu は次の組み合わせを取っています。
+既定のページパイプラインでは segmentation-only 経路を使います。Koharu はすでに `comic-text-bubble-detector` から text block を得ているからです。つまり Koharu は次の組み合わせを取っています。
 
-- ページ構造に強いモデル
-- ピクセル単位のテキスト前景抽出に強いモデル
+- ページ全体の領域検出が得意なモデル
+- ピクセル単位のテキスト前景抽出が得意なモデル
 
 これは、box だけに頼るよりクリーンアップに向いた構成です。
 
@@ -150,36 +150,24 @@ Koharu の実装もかなりこの形に近いです。
 - `OCR:` をプロンプトに使う
 - 各 crop に対して greedily に文字列をデコードする
 
-つまり、Koharu の OCR は古典的な CTC 専用 recognizer ではなく、小型の document-oriented VLM を狭い OCR タスクに使っている形です。
-
-### Inpainting: なぜ LaMa は Fourier convolution を使うのか
-
-[LaMa](https://github.com/advimman/lama) は、大きな mask 領域向けに設計された inpainting モデルです。論文タイトルでも、重要な発想は明示されています。*Resolution-robust Large Mask Inpainting with Fourier Convolutions* です。
-
-直感的には、次の違いがあります。
-
-- 通常の convolution は局所的
-- テキスト除去では、吹き出しや背景の遠い文脈が必要になる
-- 周波数領域の演算は広域文脈を効率よく扱える
+### Inpainting: なぜ既定が AOT なのか
 
-ここで FFT が出てきます。
+既定の inpainter は [manga-image-translator](https://github.com/zyddnys/manga-image-translator) 由来の AOT モデルで、Koharu では `aot-inpainting` として公開しています。これは gated convolution と複数の dilation rate を持つ文脈混合ブロックを中心にした masked-image inpainting network です。
 
-#### ここでの FFT とは
+直感的には、次のことが重要です。
 
-FFT は **Fast Fourier Transform** の略です。これは次の 2 つの表現の間を高速に行き来するアルゴリズムです。
+- 文字除去は単純な矩形塗りつぶしでは足りない
+- モデルには局所的なエッジ情報と、吹き出しや背景全体からの広めの文脈が必要
+- 複数 dilation のブロックを繰り返すのは、その文脈を混ぜる実用的な方法
 
-- 画素が存在する空間領域
-- 繰り返しパターンや大域構造を扱いやすい周波数領域
+Koharu の Candle 版は upstream の推論形にかなり忠実です。
 
-Koharu の LaMa 実装では、`FourierUnit` がまさにこれを行います。
+1. 大きなページを設定された max side まで縮小する
+2. 作業画像を multiple-of-8 にそろえる
+3. masked RGB image と binary text mask をネットワークに入れる
+4. 予測したピクセルを元サイズの画像へ合成する
 
-1. 特徴マップに `rfft2` を適用する
-2. 実部と虚部チャネルに対して学習済み `1x1` convolution をかける
-3. `irfft2` を適用して画像空間へ戻す
-
-Koharu は CPU / CUDA / Metal 向けに独自の `rfft2` と `irfft2` 演算も実装しているので、同じ spectral block を複数ハードウェアで走らせられます。
-
-漫画のクリーンアップでは、欠損領域は小さな傷ではなく、グラデーションやスクリーントーン、線画端を含む吹き出し内部全体になることがあります。Fourier 系の大域混合は、穴を埋めながらより大きな構造を保つのに有利です。
+`lama-manga` も代替エンジンとして選べますが、既定ではありません。
 
 ## ローカル LLM とモデル種別
 
@@ -191,33 +179,32 @@ Koharu のローカル翻訳経路は、`llama.cpp` 経由で GGUF モデルを
 - 増えていく token 列に対して masked self-attention を実行する
 - 出力が終わるまで次 token を繰り返し予測する
 
-実用上のトレードオフも一般的です。
-
-- 大きいモデルほど翻訳品質は高くなりやすい
-- 小さい量子化モデルほど VRAM と RAM を節約できる
-- リモートプロバイダは、ローカルのプライバシーと引き換えに大きなホスト型モデルを使いやすい
-
 リモートのテキスト生成プロバイダを使う場合でも、Koharu は画像理解段階をローカルで行います。リモート側が必要とするのは OCR テキストだけです。
 
 ## Koharu 固有の実装メモ
 
 高レベルの説明だけでは見落としやすい点を挙げると、次の通りです。
 
-- detect 段階では現在 `ComicTextDetector::load_segmentation_only(...)` を使っており、DBNet 付きフル検出モードではない
-- segmentation mask は inpainting 前に現在の text block に対して refinement される
+- 既定の detect 段階は `PP-DocLayoutV3` ではなく `comic-text-bubble-detector`
+- `comic-text-detector-seg` は `doc.segment` 用に segmentation-only の `comic-text-detector` 経路を使う
+- segmentation mask は現在、古い block-aware refinement ではなく threshold と dilation で作る
 - OCR は元ページ全体ではなく、切り出した text block 画像に対して実行される
 - OCR ラッパーは multimodal llama.cpp 経路と `OCR:` プロンプトを使う
 - inpainting は `doc.segment` を消去 mask として使うので、mask が悪いとそのままクリーンアップ品質に出る
+- 既定の inpainter は `aot-inpainting` で、`lama-manga` は代替として選択可能
 - フォント予測結果はレンダリング前に正規化され、黒や白に近い色はよりきれいな値へ寄せられる
 
 ## 推奨読み物
 
 ### 公式モデル / プロジェクト資料
 
-- [PP-DocLayoutV3 model card](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3)
+- [comic-text-and-bubble-detector model card](https://huggingface.co/ogkalu/comic-text-and-bubble-detector)
 - [PaddleOCR-VL-1.5 model card](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5)
 - [PaddleOCR-VL architecture docs in Hugging Face Transformers](https://huggingface.co/docs/transformers/en/model_doc/paddleocr_vl)
 - [comic-text-detector repository](https://github.com/dmMaze/comic-text-detector)
+- [manga-image-translator repository](https://github.com/zyddnys/manga-image-translator)
+- [YuzuMarker.FontDetection model card](https://huggingface.co/fffonion/yuzumarker-font-detection)
+- [PP-DocLayoutV3 model card](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3)
 - [LaMa repository](https://github.com/advimman/lama)
 - [llama.cpp](https://github.com/ggml-org/llama.cpp)
 

docs/ja-JP/index.md

@@ -494,7 +494,7 @@ hide:
         </div>
         <div class="kh-download-hero">
           <a class="kh-download-button" href="https://github.com/mayocream/koharu/releases/latest">
-            Windows 版をダウンロード&nbsp;&nbsp;<span class="kh-download-button__version">0.40.1</span>
+            Windows 版をダウンロード&nbsp;&nbsp;<span class="kh-download-button__version">0.42.1</span>
           </a>
           <div class="kh-download-hero__subtext">
             Koharu は無料のオープンソースソフトウェアです。

docs/zh-CN/explanation/how-koharu-works.md

@@ -4,19 +4,20 @@ title: Koharu 的工作方式
 
 # Koharu 的工作方式
 
-Koharu 围绕一条漫画翻译页面管线构建。用户看到的流程很简单，但实现上会刻意把版面分析、分割、OCR、修复、翻译和渲染拆成独立阶段。
+Koharu 围绕一条漫画翻译页面管线构建。用户看到的流程很简单，但实现上会刻意把联合检测、分割、OCR、修复、翻译和渲染拆成独立阶段。
 
 ## 管线总览
 
 ```mermaid
 flowchart LR
     A[输入漫画页面] --> B[Detect 阶段]
-    B --> B1[版面分析]
+    B --> B1[文本块和气泡区域]
     B --> B2[分割掩码]
     B --> B3[字体提示]
     B1 --> C[OCR 阶段]
     B2 --> D[修复阶段]
     C --> E[LLM 翻译阶段]
+    B3 --> F
     D --> F[渲染阶段]
     E --> F
     F --> G[本地化页面或 PSD 导出]
@@ -32,19 +33,19 @@ flowchart LR
 
 关键实现细节在于，`Detect` 本身已经是一个多模型阶段：
 
-- `PP-DocLayoutV3` 负责找出类似文本的版面区域和阅读顺序
-- `comic-text-detector` 生成逐像素的文本概率图
+- `comic-text-bubble-detector` 负责找出文本块和气泡区域
+- `comic-text-detector-seg` 生成逐像素文本概率图，并将其变成清理掩码
 - `YuzuMarker.FontDetection` 估计后续渲染要用到的字体与颜色提示
 
-正因为如此，Koharu 才能让一个模型负责“文字应该属于页面哪里”，另一个模型负责“究竟哪些像素应该被擦掉”。
+正因为如此，Koharu 才能让一个模型负责“文字在哪里”，另一个模型负责“哪些像素应该被擦掉”。
 
 ## 每个阶段产出什么
 
 | 阶段 | 主要模型 | 主要输出 |
 | --- | --- | --- |
-| Detect | `PP-DocLayoutV3`, `comic-text-detector`, `YuzuMarker.FontDetection` | 文本块、分割掩码、字体提示 |
+| Detect | `comic-text-bubble-detector`, `comic-text-detector-seg`, `YuzuMarker.FontDetection` | 文本块、气泡区域、分割掩码、字体提示 |
 | OCR | `PaddleOCR-VL-1.5` | 每个文本块识别出的原文 |
-| Inpaint | `lama-manga` | 去除原文后的页面 |
+| Inpaint | `aot-inpainting` | 去除原文后的页面 |
 | LLM Generate | 本地 GGUF LLM 或远程提供商 | 译文 |
 | Render | Koharu renderer | 最终本地化页面或导出内容 |
 
@@ -53,24 +54,24 @@ flowchart LR
 漫画页面比普通文档 OCR 更难：
 
 - 气泡形状不规则，经常弯曲
-- 日文可能是纵排，旁边的注释或 SFX 又可能是横排
+- 日文可能是竖排，旁边的注释或 SFX 又可能是横排
 - 文本会压在背景、网点、速度线和分镜边框之上
 - 阅读顺序本身就是页面结构的一部分，不只是像素问题
 
-因此通常不能指望一个模型把所有事情都做好。Koharu 会先估计版面，再对裁剪出的区域做 OCR，再用分割掩码做清理，最后才把文本交给 LLM 翻译。
+因此通常不能指望一个模型把所有事情都做好。Koharu 会先找出文本块和气泡区域，再对裁剪区域做 OCR，再用分割掩码做清理，最后才把文本交给 LLM 翻译。
 
 ## 实现结构
 
-从源码结构看，管线入口在 `koharu-app/src/pipeline.rs`，视觉栈的协调逻辑主要在 `koharu-app/src/ml.rs`。
+从源码结构看，引擎注册和管线执行在 `koharu-app/src/engine.rs`，默认引擎选择在 `koharu-app/src/config.rs`。
 
 一些重要的实现细节：
 
-- detect 阶段先跑 `PP-DocLayoutV3`，再把文本类标签转换成 `TextBlock`
-- OCR 之前会先去重高度重叠的框
-- 文本方向会基于区域长宽比推断，这样纵排漫画文本能更早进入正确路径
+- 默认 detect 引擎是 `comic-text-bubble-detector`，会在一次推理里写入 `TextBlock` 和气泡区域
+- `comic-text-detector-seg` 会在已有 text block 后运行，并把最终掩码保存为 `doc.segment`
 - OCR 运行在裁剪后的文本区域上，而不是整页图像
 - 修复阶段使用的是当前分割掩码，而不是简单矩形框
-- 当你选择远程 LLM 时，Koharu 发送出去的是 OCR 文本，而不是整页图像
+- 当你选择远程 LLM 时，Koharu 发出去的是 OCR 文本，而不是整页图像
+- 你可以在 **Settings > Engines** 中替换单个阶段，而无需改动整条管线
 
 ## 为什么这套技术栈很重要
 
@@ -92,6 +93,4 @@ Koharu 使用：
 
 ## 想看更深的技术版本？
 
-请参见 [技术深潜](technical-deep-dive.md)，了解模型类型、分割掩码理论、基于 FFT 的修复，以及维基百科图示和官方模型卡的背景说明。关于渲染器、纵排写字模式和当前版面限制，请参见 [文本渲染与纵排 CJK 布局](text-rendering-and-vertical-cjk-layout.md)。
-
-
+请参见 [技术深潜](technical-deep-dive.md)，了解模型类型、分割掩码理论、AOT 修复，以及官方模型卡的背景说明。关于渲染器、竖排写字模式和当前版面限制，请参见 [文本渲染与竖排 CJK 布局](text-rendering-and-vertical-cjk-layout.md)。

docs/zh-CN/explanation/models-and-providers.md

@@ -12,32 +12,41 @@ Koharu 同时使用视觉模型和语言模型。视觉栈负责准备页面，
 
 Koharu 会在首次使用时自动下载所需的视觉模型。
 
-默认栈包括：
+当前默认栈包括：
 
-- [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors)：文本检测与版面分析
-- [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector)：文本分割
-- [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5)：OCR 文本识别
-- [lama-manga](https://huggingface.co/mayocream/lama-manga)：图像修复
-- [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection)：字体与颜色检测
+- 用于同时检测文本块和气泡的 [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector)
+- 用于生成文本分割掩码的 [comic-text-detector](https://huggingface.co/mayocream/comic-text-detector)
+- 用于 OCR 文本识别的 [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5)
+- 作为默认修复器的 [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting)
+- 用于字体与颜色检测的 [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection)
 
-为兼容 Rust 运行时并获得更好的性能，转换后的模型权重以 safetensors 格式托管在 [Hugging Face](https://huggingface.co/mayocream) 上。
+有些模型直接使用上游 Hugging Face 仓库，另一些则因为 Koharu 需要 Rust 友好的 safetensors 版本，而由 [Hugging Face](https://huggingface.co/mayocream) 托管转换后的权重。
 
 ### 每个视觉模型是什么
 
 | 模型 | 模型类型 | Koharu 使用它的原因 |
 | --- | --- | --- |
-| `PP-DocLayoutV3` | 版面检测器 | 找出文本类区域与阅读顺序 |
+| `comic-text-bubble-detector` | object detector | 一次推理同时找出文本块和气泡区域 |
 | `comic-text-detector` | 分割网络 | 生成清理用的文本掩码 |
 | `PaddleOCR-VL-1.5` | 视觉语言模型 | 把裁剪图像读成文本 token |
-| `lama-manga` | 修复网络 | 在去字后重建底图 |
+| `aot-inpainting` | 修复网络 | 在去字后补全被掩码覆盖的区域 |
 | `YuzuMarker.FontDetection` | 分类 / 回归模型 | 为渲染估计字体与风格提示 |
 
-最重要的设计点是：Koharu 不会用一个模型硬扛所有页面任务。版面、分割、OCR 和修复需要完全不同的输出形式：
+最重要的设计点是：Koharu 不会用一个模型硬扛所有页面任务。检测、分割、OCR 和修复需要完全不同的输出形式：
 
-- 版面要区域与顺序
-- 分割要逐像素掩码
-- OCR 要文本
-- 修复要恢复后的像素
+- 联合检测需要文本块和气泡区域
+- 分割需要逐像素掩码
+- OCR 需要文本
+- 修复需要恢复后的像素
+
+### 内置可选替代引擎
+
+你可以在 **Settings > Engines** 中按阶段替换模型。内置替代项包括：
+
+- 作为替代检测 / 版面分析引擎的 [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors)
+- 作为专用气泡检测器的 [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation)
+- 作为替代 OCR 的 [Manga OCR](https://huggingface.co/mayocream/manga-ocr) 和 [MIT 48px OCR](https://huggingface.co/mayocream/mit48px-ocr)
+- 作为替代修复器的 [lama-manga](https://huggingface.co/mayocream/lama-manga)
 
 ## 本地 LLM
 

docs/zh-CN/explanation/technical-deep-dive.md

@@ -4,19 +4,20 @@ title: 技术深潜
 
 # 技术深潜
 
-本页解释 Koharu 漫画处理管线的技术侧面：每个模型做什么、各阶段如何拼在一起，以及为什么漫画翻译必须把版面分析、分割掩码、OCR、修复和翻译拆开处理。
+本页解释 Koharu 漫画处理管线的技术侧面：每个模型做什么、各阶段如何拼在一起，以及为什么漫画翻译必须把文本与气泡检测、分割掩码、OCR、修复和翻译拆开处理。
 
 ## 从实现角度看页面管线
 
 ```mermaid
 flowchart TD
-    A[输入页面] --> B[PP-DocLayoutV3]
-    A --> C[comic-text-detector]
-    B --> D[文本块]
+    A[输入页面] --> B[comic-text-bubble-detector]
+    A --> C[comic-text-detector-seg]
+    B --> D[文本块 + 气泡]
     C --> E[分割掩码]
     A --> F[YuzuMarker font detector]
+    D --> C
     D --> G[PaddleOCR-VL 裁剪 OCR]
-    E --> H[LaMa 修复]
+    E --> H[AOT 修复]
     G --> I[本地或远程 LLM]
     F --> J[渲染样式提示]
     H --> K[Renderer]
@@ -27,7 +28,7 @@ flowchart TD
 
 从公开 API 看，Koharu 的主要流程是 `Detect -> OCR -> Inpaint -> LLM Generate -> Render`，但 detect 阶段本身已经同时做了三类工作：
 
-- 页面版面分析
+- 文本和气泡检测
 - 文本前景分割
 - 字体与颜色估计
 
@@ -37,41 +38,42 @@ flowchart TD
 
 | 组件 | 默认模型 | 模型类型 | 在 Koharu 中的主要任务 |
 | --- | --- | --- | --- |
-| 版面分析 | [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors) | 文档版面检测器 | 找出文本类区域、标签、置信度与阅读顺序 |
+| 文本 / 气泡检测 | [comic-text-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) | object detector | 找出文本块和气泡区域 |
 | 分割 | [comic-text-detector](https://github.com/dmMaze/comic-text-detector) | 文本分割网络 | 生成用于清理的高密度文本掩码 |
 | OCR | [PaddleOCR-VL-1.5](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5) | 视觉语言模型 | 将裁剪文本区域识别为 Unicode 文本 |
-| 修复 | [lama-manga](https://huggingface.co/mayocream/lama-manga) / [LaMa](https://github.com/advimman/lama) | 图像修复网络 | 在去字后填补遮挡区域 |
+| 修复 | [aot-inpainting](https://huggingface.co/mayocream/aot-inpainting) / [manga-image-translator](https://github.com/zyddnys/manga-image-translator) | 图像修复网络 | 在去字后填补遮挡区域 |
 | 字体提示 | [YuzuMarker.FontDetection](https://huggingface.co/fffonion/yuzumarker-font-detection) | 图像分类 / 回归模型 | 估计字体、颜色与描边提示 |
 | 翻译 | 通过 [llama.cpp](https://github.com/ggml-org/llama.cpp) 运行的本地 GGUF 模型，或远程 API | 大多数本地场景下是 decoder-only LLM | 将 OCR 文本翻译到目标语言 |
 
-## 为什么漫画页面特别需要版面分析
+内置替代引擎仍然可用。主要包括：作为替代检测 / 版面分析引擎的 [PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3_safetensors)、作为专用气泡检测器的 [speech-bubble-segmentation](https://huggingface.co/mayocream/speech-bubble-segmentation)，以及作为替代修复器的 [lama-manga](https://huggingface.co/mayocream/lama-manga)。
 
-版面分析不只是“给文本画框”。在漫画页里，它还要回答：
+## 为什么文本和气泡检测在漫画页上很重要
 
-- 哪些区域根本像文本
-- 大致的阅读顺序是什么
-- 某个文本块是否高到足以被当成纵排
+检测不只是“给文字画框”。在漫画页里，它还要回答：
+
+- 哪些区域看起来像文本
+- 哪些区域是气泡
+- 某个文本块是否高到足以被当成竖排
 - 哪些框应该在 OCR 前先去重
-- 哪些区域是气泡、旁白、标题或其他版面类别
+- 哪些区域应该被转换成可编辑的 `TextBlock`
 
 这是因为漫画页面本来就结构复杂：
 
 - 气泡常常弯曲或倾斜
 - 文本可能压在网点、速度线和复杂背景上
-- 纵排日文和横排拉丁文本会同时存在
+- 竖排日文和横排拉丁文本会同时存在
 - 应该“读”的区域，与应该“擦掉”的像素，形状往往并不一样
 
-Koharu 先根据布局输出创建 `TextBlock`，再用这些块驱动 OCR 和后续渲染。
+Koharu 先根据检测结果创建 `TextBlock`，再用这些块驱动 OCR 和后续渲染。气泡区域会单独保留下来，供 UI 和后续工具继续使用。
 
-在当前实现里，布局阶段会：
+在当前默认实现里，detect 阶段会：
 
-- 运行 `PP-DocLayoutV3::inference_one_fast(...)`
-- 保留看起来像文本的标签区域
-- 将它们转换成 `TextBlock`
-- 去除高度重叠的候选框
-- 根据长宽比推断横排还是纵排
+- 运行 Candle 版 `ogkalu/comic-text-and-bubble-detector`
+- 把文本检测结果转换成 `TextBlock`
+- 把气泡检测结果转换成 `BubbleRegion`
+- 在 OCR 前按漫画阅读顺序整理 text block
 
-因此，版面分析是整条漫画处理管线的结构骨架。
+如果你更想用偏文档版面的检测器，`PP-DocLayoutV3` 仍然可以作为替代引擎使用，只是不再是默认选择。
 
 ## 什么是分割掩码
 
@@ -87,33 +89,31 @@ Koharu 先根据布局输出创建 `TextBlock`，再用这些块驱动 OCR 和
 
 ```mermaid
 flowchart LR
-    A[气泡区域] --> B[布局框]
+    A[气泡区域] --> B[检测框]
     A --> C[分割掩码]
     B --> D[OCR 裁剪]
     C --> E[擦除精确文本像素]
 ```
 
-在 Koharu 中，分割路径有意和布局路径分开：
+在 Koharu 中，分割路径有意和检测路径分开：
 
 - `comic-text-detector` 生成灰度概率图
-- Koharu 对概率图做后处理和细化
-- 细化结果存入 `doc.segment`
-- LaMa 再用 `doc.segment` 作为擦除与填补掩码
+- Koharu 对它做阈值化和膨胀等轻量后处理
+- 结果保存到 `doc.segment`
+- `aot-inpainting` 再把 `doc.segment` 作为擦除与填补掩码
 
-这个细化步骤很重要，因为原始分割概率通常是软的、带噪声的。Koharu 会对其阈值化、结合文本块做细化，并对最终二值掩码做膨胀，尽量覆盖文字边缘和描边，减少残影。
+这个后处理步骤仍然重要，因为原始分割概率通常是软的、带噪声的。Koharu 会先二值化，再对最终掩码做膨胀，尽量覆盖文字边缘和描边，减少残影。
 
 ## 这些视觉模型在理论上如何工作
 
-### 版面分析：检测器加阅读顺序推断
-
-[PP-DocLayoutV3](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3) 是一个面向文档解析的布局模型，擅长处理倾斜、形变和非平面失真。它的模型卡中有两个对漫画页尤其重要的点：
+### 联合检测：一次得到文本块和气泡区域
 
-- 它预测的是多点几何，而不只是轴对齐矩形框
-- 它会在同一次前向中同时预测逻辑阅读顺序
+[ogkalu/comic-text-and-bubble-detector](https://huggingface.co/ogkalu/comic-text-and-bubble-detector) 成为默认检测器，是因为它直接预测了后续最关心的两类区域：
 
-Koharu 的 Rust 端口保留了这种结构：`pp_doclayout_v3` 模块包含 `HGNetV2` 骨干以及注意力式编码器 / 解码器块，推理结果会暴露 `label`、`score`、`bbox`、`polygon_points` 和 `order`。
+- 应该转换成 `TextBlock` 的文本区域
+- 应该继续保留给编辑器和后续工具使用的气泡区域
 
-从概念上说，这更接近“目标检测 + 版面解析”，而不是单纯 OCR。
+Koharu 的 Candle 端口会把这些检测结果映射到文档结构里，并在 OCR 前按漫画阅读顺序排序文本块。从概念上说，这更接近页面目标检测，而不是 OCR 本身。
 
 ### 分割：密集逐像素文本预测
 
@@ -123,10 +123,10 @@ Koharu 的 `comic-text-detector` 路径本质上是以分割为核心的设计
 - 用于掩码预测的 U-Net 解码器
 - 可选的 DBNet 检测头
 
-默认页面管线使用“仅分割”路径，因为 Koharu 已经从 `PP-DocLayoutV3` 获得了布局框。也就是说，Koharu 组合了：
+默认页面管线使用“仅分割”路径，因为 Koharu 已经从 `comic-text-bubble-detector` 获得了 text block。也就是说，Koharu 组合了：
 
-- 一个擅长页面结构的模型
-- 一个擅长像素级文本前景的模型
+- 一个擅长页面级区域检测的模型
+- 一个擅长像素级文本前景抽取的模型
 
 对于图像清理来说，这比只靠边界框更合适。
 
@@ -150,36 +150,24 @@ Koharu 的实现非常接近这种模式：
 - 使用 `OCR:` 作为提示
 - 对每个裁剪块贪心解码文本
 
-因此，Koharu 里的 OCR 并不是传统的纯 CTC 识别器，而是一个被限定在 OCR 任务上的小型文档 VLM。
-
-### 修复：为什么 LaMa 使用傅里叶卷积
-
-[LaMa](https://github.com/advimman/lama) 是一个面向大面积遮挡区域的图像修复模型。它论文标题就点明了核心思路：*Resolution-robust Large Mask Inpainting with Fourier Convolutions*。
-
-直觉上：
-
-- 普通卷积擅长局部信息
-- 去字修复往往需要从更大范围背景中借上下文
-- 频域操作可以更高效地建模大尺度结构
+### 修复：为什么默认改成了 AOT
 
-这里就会用到 FFT。
+默认修复器是来自 [manga-image-translator](https://github.com/zyddnys/manga-image-translator) 的 AOT 模型，在 Koharu 中叫 `aot-inpainting`。它是一种 masked-image inpainting network，核心是 gated convolution 和带有多个 dilation rate 的上下文混合块。
 
-#### 这里的 FFT 是什么意思
+直觉上，关键点在于：
 
-FFT 是 **Fast Fourier Transform（快速傅里叶变换）**，它是一种在以下两个空间之间快速切换的算法：
+- 去字修复不是简单的矩形填充
+- 模型既要看到局部边缘细节，也要借用更大范围的气泡或背景上下文
+- 多膨胀率上下文块是一种务实的上下文混合方式
 
-- 像素所在的空间域
-- 更容易表达重复模式和大尺度结构的频域
+Koharu 的 Candle 端口基本遵循上游推理流程：
 
-在 Koharu 的 LaMa 端口里，`FourierUnit` 会：
+1. 把过大的页面缩到设定的 max side
+2. 把工作图像补齐到 multiple-of-8
+3. 将 masked RGB 图像和二值文本掩码送入网络
+4. 再把预测像素合成回原尺寸图像
 
-1. 对特征图做 `rfft2`
-2. 对实部与虚部通道应用学习得到的 `1x1` 卷积
-3. 再用 `irfft2` 回到图像空间
-
-Koharu 甚至为 CPU、CUDA 和 Metal 实现了自定义 `rfft2` / `irfft2` 操作，因此同一套频域块可以跨硬件运行。
-
-对于漫画清理来说，这很关键，因为缺失区域往往不是一个小洞，而可能是整个气泡内侧，里面还带着渐变、网点和边缘线稿。频域的全局混合能力更有利于保留大结构。
+`lama-manga` 仍然可以作为替代引擎选择，但已经不是默认项。
 
 ## 本地 LLM 与模型类型
 
@@ -191,33 +179,32 @@ Koharu 的本地翻译路径通过 `llama.cpp` 使用 GGUF 模型。实际中，
 - 在不断增长的 token 序列上执行 masked self-attention
 - 反复预测下一个 token，直到完成输出
 
-实际取舍也很标准：
-
-- 模型越大，通常翻译越好
-- 更小的量化模型占用更少的 VRAM 和 RAM
-- 远程提供商可以提供更大模型，但会带来隐私与依赖外部服务的权衡
-
 即使你使用远程文本生成提供商，Koharu 也会把图像理解步骤留在本地。远端拿到的只是 OCR 文本。
 
 ## Koharu 实现中特别值得注意的点
 
 如果你只看高层文档，下面这些实现细节很容易被忽略：
 
-- detect 阶段当前加载的是 `ComicTextDetector::load_segmentation_only(...)`，而不是启用 DBNet 的完整检测模式
-- 分割掩码会结合当前检测出的文本块做精细化，再进入修复阶段
+- 默认 detect 阶段是 `comic-text-bubble-detector`，而不是 `PP-DocLayoutV3`
+- `comic-text-detector-seg` 仍然走 segmentation-only 的 `comic-text-detector` 路径来生成 `doc.segment`
+- 分割掩码现在是通过阈值化加膨胀构建的，不再走旧的 block-aware refinement 逻辑
 - OCR 运行在裁剪后的文本块图像上，而不是整页原图
 - OCR 封装使用的是 `llama.cpp` 的多模态路径，并采用 `OCR:` 提示
 - 修复阶段直接消费 `doc.segment`，所以糟糕的掩码会直接导致糟糕的清理结果
+- 默认修复器是 `aot-inpainting`，`lama-manga` 仍可作为替代方案
 - 渲染前会对字体预测做归一化，让接近纯黑或纯白的颜色更稳定
 
 ## 推荐阅读
 
 ### 官方模型与项目参考
 
-- [PP-DocLayoutV3 model card](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3)
+- [comic-text-and-bubble-detector model card](https://huggingface.co/ogkalu/comic-text-and-bubble-detector)
 - [PaddleOCR-VL-1.5 model card](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5)
 - [Hugging Face Transformers 中的 PaddleOCR-VL 架构文档](https://huggingface.co/docs/transformers/en/model_doc/paddleocr_vl)
 - [comic-text-detector 仓库](https://github.com/dmMaze/comic-text-detector)
+- [manga-image-translator 仓库](https://github.com/zyddnys/manga-image-translator)
+- [YuzuMarker.FontDetection model card](https://huggingface.co/fffonion/yuzumarker-font-detection)
+- [PP-DocLayoutV3 model card](https://huggingface.co/PaddlePaddle/PP-DocLayoutV3)
 - [LaMa 仓库](https://github.com/advimman/lama)
 - [llama.cpp](https://github.com/ggml-org/llama.cpp)
 

docs/zh-CN/index.md

@@ -494,7 +494,7 @@ hide:
         </div>
         <div class="kh-download-hero">
           <a class="kh-download-button" href="https://github.com/mayocream/koharu/releases/latest">
-            下载 Windows 版&nbsp;&nbsp;<span class="kh-download-button__version">0.40.1</span>
+            下载 Windows 版&nbsp;&nbsp;<span class="kh-download-button__version">0.42.1</span>
           </a>
           <div class="kh-download-hero__subtext">
             Koharu 免费且开源。