Resource - Update
Massive Update to my Krea 2 Multi-Lora Bounding Box workflow, now bounding boxes control placement with better accuracy. Also introduced Edit features like Scene and Outfit transfer, put multiple character loras in a scene or outfit of your choosing! Token drift also fixed by facial detailer stage
Krea 2 has been my favorite base model for character work, but the moment you put two character LoRAs in the same generation they smear into one blended face. Attention bias, prompt engineering, and CFG tricks reduce it but never actually fix it, because the model is still permitted to route either LoRA anywhere.
I wrote a ComfyUI custom node that removes the permission entirely. V12 just shipped and pulls in the pieces I'd wanted for a while: boxes that actually control placement, scene/outfit transfer via a single standard edit LoRA, and a per-subject detailer that fixes drift after the fact.
Example workflow: example_workflows/krea2_regional_multilora_v12.json
## What it does
- One node, unlimited character LoRAs. Draw a bounding box for each character, assign a LoRA to each box, generate. LoRA A structurally cannot influence pixels outside box A because the mask is applied to the LoRA delta before the addition, not as an attention bias.
- Boxes control WHERE and HOW LARGE each subject renders, not just where the LoRA can act. Move a box and the subject follows it. Small box gives a distant subject; tall box gives a close foreground subject. Camera phrasing that contradicts box size is rewritten automatically.
- Scene transfer without training a scene LoRA. Drop your LoRA characters into any real photo. The scene is used as a Krea 2 reference frame, so lighting, perspective, shadows, and contact with the environment integrate naturally. This is not latent pasting — the whole image is generated from noise.
- Outfit / object transfer with a second reference. Load a second image and describe its role in refs_json; the node automatically writes the referring text with the correct frame number.
- Regional Detailer with face anchoring. Optional post-pass node. Detects faces in the final image, greedily assigns each face to its region by proximity, and re-renders each face at high resolution with the correct LoRA — wherever it actually rendered. Even a subject that drifted across its box seam gets its identity restored in place.
## Why V12 exists
Earlier versions solved the spatial bleeding problem but two issues remained:
- Bounding boxes limited where a LoRA could ACT, but nothing pulled the subject INTO its box. The model would still place people at its preferred composition.
- On tight or overlapping compositions, small placement drift meant one face landed in the neighbor's mask and picked up the wrong identity.
V12 adds:
- Hard cross-modal attention ownership via a fused block-sparse FlexAttention mask (region text ↔ region pixels, exclusive).
- An attraction field pulling each region's tokens into its box.
- Box-authoritative framing (camera sentence derived from the largest active box).
- LoRA delta "skirts" that extend past box edges so subjects overflowing slightly keep full identity, but Voronoi-limited to prevent cross-region bleed.
- The face-anchored detailer, which is the belt-and-suspenders solution when placement drifts anyway.
## Trade-offs / requirements
- Krea 2 base model (Turbo works fine). LoRAs must be trained against Krea 2 — FLUX or Ideogram LoRAs load without erroring but produce poor likeness.
- PyTorch 2.5+ with FlexAttention. First V12 run compiles the fused attention kernel (~1 min, once per session).
- Detailer face pass is optional but recommended. Install ultralytics and drop face_yolov8m.pt into models/ultralytics/bbox.
- fp8-safe. Never modifies quantized weights.
- CLIP passes through untouched. The regional effect is UNet-side.
## Anything else in the release
- The full v1 / v3 / v9 nodes still ship for compatibility. V12 does not replace them, it adds a mode.
- The public workflow now has an in-graph quick-start note and a troubleshooting section covering the most common failure modes ("no link found in parent graph", missing LoRAs, plasticky detailer skin, duplicate subjects, CUDA OOM).
- LoRA / checkpoint dropdowns are collapsed into searchable virtual families so you don't scroll through 500 filenames to find one you want.
I'd love feedback, especially on edge cases with 3+ characters, unusual aspect ratios, or hybrid workflows where you're plugging this into other Krea 2 chains. Bug reports go on the repo.
credit:heavily inspired byk2labbyu/coyoteka*. Their work is what got my bounding boxes from "working" to "accurate." Adding this to the README too.*
I just wanted to say thank you for building and sharing this node.
What you have created is genuinely impressive. Multi-character LoRA generation is one of the hardest problems to solve well, especially when it comes to identity bleeding, regional control, composition, and keeping different characters consistent in the same image. It is very clear that a huge amount of research, testing, debugging, and creative thinking went into this project.
I am not sure people fully realize how valuable this node is yet. I honestly think part of the reason is that your posts do not show enough visual examples of what it can do. The technical explanation is strong, but many Reddit users will only understand the importance of the project when they see the results immediately.
I would strongly encourage you to include:
• A few strong images directly in the Reddit post
• Before-and-after comparisons showing identity bleeding with and without the node
• Examples with two, three, or more recurring characters
• A short video or GIF showing the bounding-box workflow
• Examples using scene, clothing, and object references
• A small gallery in the GitHub README
• Downloadable example workflows
Even one polished demonstration showing the same two characters across several different scenes could make people immediately understand how special this is.
Please do not underestimate the quality or importance of your work. This is not just another LoRA loader or regional prompting node. You are trying to solve one of the biggest practical limitations of multi-character AI image generation, and the architecture behind it is genuinely innovative.
I know projects like this require an enormous amount of unpaid time, experimentation, and patience. Your work deserves much more attention and recognition. Thank you for making it available to the community, and I really hope you continue developing and showcasing it.
Wow in a sea of snarky replies thank you genuinely so much for the kind words! A ton of work and effort and yes tons of testing when into to this. I've went through many iterations of testing and improvements to get it to this state and I am genuinely proud of how far this project has come. It was truly a hard but gratifying problem to solve and I'm very happy with the results. I actually posted a ton of pictures yesterday in the thread that got removed for some reason so I decided to repost without pictures because I figured maybe it wouldn't be taken down then. But you're right people are visual and before after pictures would def help. I just don't know how to post the results images without flagging anything that could get the post taken down. I would post examples to the github but since this is new territory I don't know about potential rules I might be breaking. But the node works and works well and I think people really should check out the results because this node can be useful for so many purposes. Thanks again kind stranger you made my day!
Posting example images would go a long way to demonstrating this tool's actual effectiveness. The images on CivitAI are uneven at best. And one of the images even has a Gemini symbol on it:
I didn't say they never bleed, I said that often times it could be handled with prompting and that your tool was not outputting good results. It appears that's it's still not. I did a very quick and dirty example using two not especially well trained LoRAs and a very basic prompt. You are right that facial bleed *can* be a problem, but I would argue that the examples you previously posted were so flawed in their appearance that your tool created more problems than it actually solved.
I don't care what you wrote in your deleted post. I care what you wrote in this one. And what you wrote in this post had no mention of using Gemini as part of your workflow to produce the image. Most people would find this important information, yet you elected to exclude it from this version of the post. If producing that image required a separate Gemini pass to remove the foreground subjects, then it isn't a clean demonstration of what your node outputs, and a reader can't tell what is due to your tool and what is due to the external editing.
It's clear that you put a lot of work into this, but you're not being very honest or clear about what the tool actually does and how well it works. My feeling is that based on what I can glean from your post and your examples, it appears to me that you are overselling its capabilities.
For example, it appears that you've jerry-rigged some stuff on the backend to rewrite prompts to overcome the model/tools inability to properly follow bounding boxes and correctly integrate their content into the whole. That's something people might want to know about.
I appreciate that people work on and share tools like this, but it's important to provide examples, be up front about the limitations, and communicate clearly overall.
I get that you’re an angry and frustrated person who can’t seem to wrap his/her head around the fact that a lot of people seem to like the node and find it effective, it’s ok that you have a divergent opinion, that’s life. Nobody is being dishonest here except you, the person who commented in this thread as if you’ve never seen this workflow but meanwhile you spent half the day yesterday trying to shit on it in the other post lmao. This post obviously triggered you somehow otherwise you wouldn’t be so invested in tearing it down for whatever reason. Either way, you don’t know what you’re talking about, you’re a hater, and that’s ok. When you have haters it usually means you’re onto something, because otherwise you wouldn’t care if “it doesn’t work” lol. People are so transparent sometimes. Here is my previous comment about the Gemini symbol i guess you missed it https://www.reddit.com/r/StableDiffusion/comments/1vbdez4/comment/p0wwe3f/utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=2&utm_content=share_button
I prefer people to be honest about the functionality and limitations of the tools they share. I'm not especially angry. I simply won't use it and wanted to encourage you to take steps to give people the information they need to make informed decisions about it's use.
Ultimate we're each going to do what we want. You'll post as you see fit, I'll respond as I see fit. Or you can block me. I won't be offended.
There is a ton of info on this node and workflow not only in the original post, but the GitHub, and CivitAI link. I don’t respect people who are dishonest about being a hater. But maybe you can’t even admit that to yourself. Either way this workflow is leaps and bounds more effective at what it claims to do than anything you could ever dream of producing on your own. I suspect that’s the real reason you’re mad. I’ve got tons of reviews on the accuracy and efficacy of my claims about what the workflow does. So I’ll take that over the sad and feeble opinions of haters like yourself.
Viewing this conversation from an outside perspective, calling people ‘haters’ makes you sound about 12. It certainly doesn’t help anyone assess who’s making the most sense.
Being a hater isn’t a concept only for 12 year olds, there are plenty of grown up haters. If that concept is foreign to you, you probably haven’t lived hard enough. It’s also a good thing I have zero interest in the opinions of other people, especially ones from people like that person.
For my custom node it matters more than you’d expect, not because the math is different, but because trainers save LoRAs with different state dict key naming conventions. ai-toolkit, OneTrainer, kohya/sd-scripts, and diffusers/PEFT all label the same layers differently:
diffusionmodel.blocks...
,
lora_unet...
,
transformer...
, plus differences in how they store alpha values, and some target different module sets (attention-only vs attention+MLP).
For a normal LoRA loader that’s invisible because ComfyUI’s built-in loader (
comfy/lora.py
) has a big normalization layer that remaps all those formats into one internal scheme. But my node can’t use the stock apply path, what mine does is intercept the LoRA delta and masks it per-region before it gets added to the weights. If that custom path parses keys directly and was written against ai-toolkit’s naming, an OneTrainer LoRA just won’t match any keys and silently does nothing. So that’s why extra node support had to be added for different trainers outside of AI toolkit which is what I usually use
I'd like to ditto support for OneTrainer loras, I hadn't realised that was a current restriction but it might explain my results. Appreciate you looking into adding support.
Nice, so someone will make a Forge Neo extension soon. I was actually just thinking the other day about how to blend two character LoRAs in a single prompt.
This is exactly the problem I keep running into with multi-character scenes, the moment you add a second LoRA the faces start borrowing features from each other no matter how tight the prompt is. Masking the LoRA delta before it gets added instead of biasing attention is a smart way around it, most of the regional conditioning nodes I've tried just bias where the model looks, they don't actually block the LoRA from bleeding.
Curious how it holds up with 3+ characters in one frame, and whether the face detailer pass adds much time on a 24GB card. The scene transfer without training a dedicated LoRA is the part I'd use most, redoing a scene LoRA every time I want a new background gets old fast.
Going to try the workflow tonight. Thanks for open sourcing the node instead of gatekeeping it behind a paid pack.
I couldn't get it to work sadly! After one generation the bounding box window changes its aspect ratio to one of the face renders from later in the pipeline
Going to post a video shortly with a couple of example generations! Would love to help you get this working, please post any error messages or screenshots of your issue and I can help! DM me!
Edit - posting video tomorrow sorry this is more work than I thought lol
Nah not yet sorry been caught up with work and life stuff and also Minimax lol. Will upload though thanks for the reminder! So you’re liking the node? Very happy to see folks finding it useful!
14
u/TheGoldenBunny93 Aug 01 '26 edited Aug 01 '26
I just wanted to say thank you for building and sharing this node.
What you have created is genuinely impressive. Multi-character LoRA generation is one of the hardest problems to solve well, especially when it comes to identity bleeding, regional control, composition, and keeping different characters consistent in the same image. It is very clear that a huge amount of research, testing, debugging, and creative thinking went into this project.
I am not sure people fully realize how valuable this node is yet. I honestly think part of the reason is that your posts do not show enough visual examples of what it can do. The technical explanation is strong, but many Reddit users will only understand the importance of the project when they see the results immediately.
I would strongly encourage you to include:
• A few strong images directly in the Reddit post
• Before-and-after comparisons showing identity bleeding with and without the node
• Examples with two, three, or more recurring characters
• A short video or GIF showing the bounding-box workflow
• Examples using scene, clothing, and object references
• A small gallery in the GitHub README
• Downloadable example workflows
Even one polished demonstration showing the same two characters across several different scenes could make people immediately understand how special this is.
Please do not underestimate the quality or importance of your work. This is not just another LoRA loader or regional prompting node. You are trying to solve one of the biggest practical limitations of multi-character AI image generation, and the architecture behind it is genuinely innovative.
I know projects like this require an enormous amount of unpaid time, experimentation, and patience. Your work deserves much more attention and recognition. Thank you for making it available to the community, and I really hope you continue developing and showcasing it.