Resumen ejecutivo
De un catálogo de personajes a packs de contenido
El motor y los personajes ya están resueltos. El trabajo actual es convertir metadatos de Danbooru en temas, combinar esos temas con un banco de poses validadas y producir packs completos sin repetir la misma postura ni el mismo encuadre en todas las imágenes.
Qué funciona hoy
- Forge Neo + Illustrious generando por API.
- 216 personajes con LoRA y línea curada.
- Eje A completo: seeds → bloques → temas → packs.
- 51 imágenes de piloto en 17 temas, 0 fallos.
- Banco ampliado a 37 poses útiles (fase 1 +21, fase 2 +5).
- Primer pack real: 45/45 imágenes, aceptado.
Qué falta para publicar
- Probar un pack completo con el pipeline de 5 stages (dry-run validado).
- Filtro de clones y duplicados.
- Auditoría automática de anatomía y composición.
- Cola de trabajos y base de datos de packs.
- Integración de publicación (Patreon / X).
Principio de trabajo
Nada se aprueba por tener los tags correctos. La imagen generada es el único test válido: se audita a ojo, se aparta lo descartado con su motivo y se documenta lo medido.
El proyecto
Qué es PlumLoom
Un generador de imágenes anime para contenido de personajes. El catálogo
vive en Archivos/personajes.txt: una línea por personaje, con
su LoRA, triggerwords y rasgos de identidad. La línea base nace desnuda y
solo conserva accesorios de cabeza (sombrero, lazos, aretes), porque el
outfit lo decide el tema.
Encima de eso hay dos capas: el banco de poses (poses que ya se validaron visualmente) y los temas (escena, luz y props). Un pack combina personaje + tema + pose + cámara y genera 45 imágenes en cinco stages de intensidad, con un outfit base único y modificadores por stage.
Ficha técnica
| Motor | Stable Diffusion WebUI Forge Neo |
| Modelo | waiIllustriousSDXL_v170.safetensors |
| Estilo | 5 LoRAs fijos (IFL, add-detail, bwl, scara2b, Add_color) |
| Personajes | 216 líneas / 389 LoRAs |
| Resolución | 832×1216 |
| Sampler | DPM++ 2M Karras · 28 steps · CFG 5 · clip_skip 2 |
Arquitectura
Pipeline canónico
El Eje A añade metadatos de Danbooru al pipeline de bloques WD14. La composición
del prompt mantiene la estructura fija con BREAK: identidad, hombre
(si hay), pose y entorno.
personajes.txt · danbooru_seeds.txt · pose_bank.jsonl
danbooru_harvest · WD14 tagger · themes.json · snapshot.json
pack_builder · PromptBuilder · assemble_prompt · BREAK
txt2img 832×1216 · seed · LoRAs · negative
pilots/ · packs/ · manifest · metrics · revisión visual
BREAK.
Sin esa separación compite con el pelo y la ropa del personaje y la postura se pierde.
Avance
Estado por fases
Números que importan
| Seeds | 126 · 50 / 40 / 36 |
| Bloques | 118 · 50 / 34 / 34 |
| Etiquetas snapshot | 31.175 |
| Aceptadas | 3.854 |
| Temas | 26 · 18 curados + 8 auto |
| Poses útiles | 37 de 39 |
| Piloto | 51 imágenes · 17 temas |
| Pack | 45 imágenes · 9/stage · 5 stages |
Los 17 temas pilotados
azotea · baño · biblioteca · cafetería · callejón · cocina · dormitorio · escuela · fiesta · gimnasio · invierno · noche_ciudad · oficina · onsen · piscina · templo · tren
Stack actual
Con qué está construido hoy
Un stack deliberadamente simple: Python + Forge Neo + ficheros. Funciona y se audita a mano, pero no está pensado para volumen ni para trabajo en equipo.
| Capa | Hoy | Estado |
|---|---|---|
| Hardware | PC Windows con RTX 5050 (8 GB VRAM); inferencia ONNX en CPU | LÍMITE |
| SO / shell | Windows · PowerShell 5.1 | OK |
| Runtime | Python 3.12 · requests · PyYAML · Pillow · python-dotenv · onnxruntime (CPU) | OK |
| Motor de imagen | Forge Neo en 127.0.0.1:7860 con --api · SDXL | OK |
| Modelos | waiIllustriousSDXL_v170 · 5 LoRAs de estilo · 389 LoRAs de personaje | OK |
| Metadatos | API anónima de Danbooru + caché local · CSV de 192k tags · snapshot de 31k | OK |
| Tagger | SmilingWolf/wd-swinv2-tagger-v3 · ONNX | OK |
| Datos | TXT / CSV / JSON / JSONL · manifests por pack | DISPERSO |
| Notificaciones | Bot de Telegram (.env) con avisos por tanda | OK |
| Calidad | Auditoría visual manual + dry-run + manifiestos | NO ESCALA |
| Ops | Sin git, sin tests, sin linter, sin cola de trabajos | DEUDA |
Stack ideal
Hacia dónde queremos ir
El objetivo no es cambiar de motor: Forge Neo se queda. Lo que falta es envolverlo con una capa de producto: datos, cola, control de calidad y publicación.
| Capa | Ideal | Por qué |
|---|---|---|
| Versionado | git + ramas + revisión + releases | Poder volver atrás y comparar cambios de prompt/código |
| Secretos | .env fuera del repo + gestor de secretos | Evitar claves de Telegram/API en disco y en logs |
| Runtime | Python 3.12 + uv/venv + dependencias fijadas | Reproducibilidad entre máquinas |
| Datos | SQLite/Postgres: personajes, LoRAs, temas, poses, jobs, manifests | Consultas, integridad y una sola fuente de verdad |
| Orquestación | Cola de trabajos con workers, reintentos e idempotencia | Packs de 45+ imágenes sin bloquear la terminal |
| Render | Forge Neo API + 1-2 workers · GPU 24 GB+ o cloud para picos | Bajar de ~25 s/img y escalar lotes |
| Tagger | onnxruntime-gpu con CUDA | ~5-10× más rápido en WD14 |
| Prompt | Hash de prompt + seed + manifest + A/B | Saber exactamente qué generó cada imagen |
| QA automática | VLM local + detector de anatomía + hash perceptual | Detectar clones, dedos y duplicados antes de publicar |
| UI | Dashboard web de revisión: aprobar, descartar, puntuar | La auditoría visual deja de ser una carpeta de PNG |
| Assets | Almacenamiento organizado + watermark + metadatos + backups | Publicación y trazabilidad por pack |
| Publicación | Integraciones Patreon / X + calendario + analítica | Cerrar el ciclo contenido → audiencia |
| Calidad de código | pytest + ruff + mypy + CI | Dejar de depender de "funciona en mi máquina" |
| Observabilidad | Logs estructurados + métricas + alertas Telegram | Saber qué falló y cuánto costó |
| Hardware ideal | RTX 5090 32 GB o A100 cloud · 64 GB RAM · NVMe | Packs completos y vídeo sin cuellos de botella |
Decisiones y mediciones
Lo que ya no se discute
Prompt
- BREAK separa identidad, hombre, pose y entorno.
- 1girl / 1boy una sola vez: repetido lo lee como dos personas.
- El LoRA manda: si hay ropa horneada, se baja a 0.6-0.8 y se refuerza el negative.
- Nunca "no X" en el positive: refuerza X. La negación va al negative.
- Accesorios de cabeza = identidad; los de cuerpo se limpian.
Banco y packs
- Seed aleatoria por imagen (implementada); fija solo para corregir una concreta.
- Blacklist por línea normalizada: editar la línea la invalida.
on_bedno es escena: se quita del banco.pb0012dibuja dos hombres: fuera hasta nuevo render.- 5 stages + outfit base único: modificadores por stage, no un outfit distinto por nivel. Diseño de stages.
spicy2es explícito para X;explicit1bloquea cum/orgasm.- Cámaras por stage;
from sideno se fuerza. Los warnings pose↔escena no añaden props. - Props del tema van al slot de entorno, después de la escena.
Riesgos
Qué puede romper el pipeline
Un solo Forge
Si Forge se cae, todo el pipeline se detiene. No hay worker secundario ni cola persistente.
Auditoría manual
45 imágenes por pack a ojo no escala a 17 packs. Los clones y las anatomías rotas se detectan tarde.
Datos dispersos
Temas, poses, manifiestos y personajes viven en formatos distintos. Cambiar una línea puede invalidar una blacklist.
Sesgo del LoRA
Yelan ignora el vestido incluso a 1.3; Boa tiende a bikini. El personaje condiciona el outfit más que el tag.
WD14 desactualizado
Las wildcards de harvest se generaron con regex viejos y no se han regenerado.
Sin red de seguridad
No hay git, tests ni backups automáticos de personajes, temas y banco.
Roadmap
Próximos pasos
Ahora
- Renderizar un pack completo con el pipeline de 5 stages.
- Filtro de clones y duplicados.
- Cerrar el caso de fiesta.
30 días
- Packs para los 17 temas.
- QA automática con VLM + hash perceptual.
- SQLite de personajes, temas, poses y jobs.
- Dashboard mínimo de revisión.
90 días
- Publicación Patreon / X.
- Vídeo con Wan 2.2 (I2V).
- Texto natural → tags Danbooru.
- Segundo worker o GPU cloud.
Referencias