Public/automatic
1
0
Fork 0
mirror of https://github.com/vladmandic/automatic synced 2026-09-20 01:31:13 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: document merge() incompatibility with per-class prompts

Browse Source 
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.
This commit is contained in:
Claude
2026-08-16 16:49:26 +00:00
parent d2995d6311
commit d9f550d45a
1 changed files with 1 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DETAILER_CLASS_PROMPTS.md
+1
View File
@@ -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