From d9f550d45ade9787b66908624142932ca3970a1b Mon Sep 17 00:00:00 2001 From: Claude Date: Sun, 16 Aug 2026 16:49:26 +0000 Subject: [PATCH] docs: document merge() incompatibility with per-class prompts Detailer.merge() (pre-existing, unrelated to this patch) collapses all detections from a model pass into one box and keeps only the first detection's label, order-dependent. Verified with the real merge() code: tagging two classes on a model that can report both in one pass, with "Merge detailers" enabled, silently drops one class's prompt and the surviving one flips between runs. Conceptually incompatible with per-class tagging, not something to "fix" here. --- DETAILER_CLASS_PROMPTS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/DETAILER_CLASS_PROMPTS.md b/DETAILER_CLASS_PROMPTS.md index 2618b3ede..1954f16ad 100644 --- a/DETAILER_CLASS_PROMPTS.md +++ b/DETAILER_CLASS_PROMPTS.md @@ -127,6 +127,7 @@ Tested with SDXL inpainting through a two-model detailer chain: a single-class f - This is a parsing convention layered on top of the existing flat `detailer_prompt`/`detailer_negative` strings — there's still no per-model or per-class field in the request schema. Anyone driving the API directly (not through the WebUI textbox) gets the same syntax for free, since it's resolved server-side regardless of how the string arrived. - No validation against the model's *known* class list at parse time (i.e. no warning the moment you type a bad tag) — the warning only fires after a generation actually runs and the mismatch is confirmed empirically. +- **Incompatible with "Merge detailers".** `Detailer.merge()` (pre-existing, unrelated to this patch) collapses every detection from a model's pass into a single bounding box, and keeps only `items[0].label` — the first detection's class, decided by whatever order the model happened to return them in. If a single multi-class model detects e.g. `face` and `hand` in the same pass with merge enabled, they become one box with one label, and whichever `[CLASS=...]` tag matches that surviving label is the only one applied — the other class's tag is silently dropped, and which one survives can flip between runs. This is conceptually the inverse of what class-tagging is for: don't use "Merge detailers" together with per-class tags on a model that can report more than one class per pass. - Not upstreamed. If there's community interest, the diff is small (~130 lines across 3 files) and could be proposed against `vladmandic/sdnext` directly. ## Files changed