Since CivitAI is going down THE DRAIN

You are talking about the masks right? Now thinking about it, you are correct. I was thinking about compatibility, if for any reason a person input a mismatched mask it wouldn't error out. But since resizing the main image already makes it a multiple of 8 on node #732, it will crop, and using that already cropped width and height will cause it to stretch the masks in a different proportion, making a slight mismatch.

To keep it correct, I either need to also "keep proportions" on the mask resize, as you pointed out... or on the "resize image" node #732, not allow it to be a multiple 8 (or anything), so it resizes the image without cropping (since cropping will happen later)... anyway. I'll rethink it and correct it on the next version. It's a small thing that won't cause too much problem right now, but it should be corrected. Thanks!

I think the better solution is to make #732 a multiple of 1 always instead of 8 like it is now. Because the workflow will correct it anyway to a multiple of 8 later. And by doing this the masks will always stretch in a proportional way anyway on the #1832 and #1834 (if the image is proportional to begin with, and if it is not, it won't error out)... or I should leave it to error out, so the user knows their masks are not proportional... I'm not sure yet what is better.

@fruitpaster 
1- You are understanding it very correctly. There is a crop node right after the resize. The workflow calculates (#793, #794) what is the best resolution multiple of 8, and then it crops the image at #792 (on the "Make sure it's devisible by 8" group right after resize). And after that, In the end, right before saving, the workflow composite it backs so you end up with your original resolution. This is just to be a purist, because it would be better to just end up with the image divisable by 8, but it might confuse people to why their original image is being changed. This happens on the group called "Composite back the cropped divisible by 8 image to the original image"

2- If you set #732 (the main resize node) to make the image a multiple of 1 instead of 8, this is enough. You should keep #1832 and #1834 as it is (with stretch and multiple of 1 as it was originally). Why? Because it receives the width and height of the resized image on the #732, so it does not need to keep proportion anymore. The crop and making sure it is divisible by 8 happens after it, on #792 (for the image), #1631 for the mask, and #1782 for the context mask. This should not make any error if set this way.

3- There is something wrong, for sure. The workflow is big, but the flow is fast, after it loads it should take from 19-60 seconds at most using Fp8. It depends on how many steps, batch and resolution you choose. It's not that slow, specially for a 4090. You should not need to use Q8 on model for your GPU. Use the normal model loaded at FP8-Fast it should fit your memory.
Check if your GPU memory is completely full at generation (when it is stuck on the ksampler), and if it is using any of the "shared memory". You can check this on windows task manager. If it is full, lower your batch size and resolution (use localized area inpainting if you don't want to change your original image resolution). But there is something definitively wrong. You should not wait more than 2 minutes, even on the first run (when it loads the model)
One other tip, increase your shared memory on windows to something really large, specially if you have 64RAM (just like me). After I put 50GB of shared memory on windows (on the driver ComfyUI is installed) I never got a crash anymore when switching models.

4- What do you mean by "resize control node" not showing up? You mean node #732 ? I don't think I use comfyui-mixlab-nodes. Do you mean, you use it and it was making problems for you using another custom node on this workflow? This might be an useful information to warn other users if that is the case.

@fruitpaster Thanks so much, I love that you are actually interested in the workflow. I don't mind answering any of your questions.

The CFG being 1.01 on #1453 is definitively wrong! I saw it as well, I have no idea why it is changed. Please set it to 1.

But one bug I encounter on easy-use "float" nodes is it never set "1.0" it always changes the value to "1.0000000000000002". I don't know if it makes any practical difference, but it should be "1.0". This is a bug in many float nodes and I don't know why. I'll have to change it to another node, maybe using a core node like primitives (In the old days of ComfyUI primitives used to give a lot of problems, but I think they work ok now).

Now, about the mask and resize, your screenshot seams ok. That was my suggestion. #1832 should be "stretch" and scale of 1. #732 should be set to "Keep proportion" (this is important) and multiple_of 1 (this is what needs to be changed on the next version). With these settings it should not be giving any errors. If it is, could you please send me your image so I can test it?

This is how it should be: https://i.postimg.cc/6prDRMc3/Captura-de-tela-2025-05-21-182842.jpg

About the seed value: Yes, that is exactly it. The seed on the control-room is the seed applied to the ksampler. It uses the set and gets nodes to carry it there. Before, it was using the Anything Everywhere nodes, but I removed them. It does not need to be random, you can set a specific seed if you want (on the control room).

@fruitpaster That is weird, would you mind sharing me your exact json (export it so I can use it) and an image with directions on what you want to inpaint, so I can try to reproduce this error?

Also about the shared memory, from my understanding, if you have more RAM you might actually need to have more shared memory. IDK why, I think windows is just dumb with its resource handling. 64GB is enough, but windows still crashes ComfyUI if you don't have enough shared memory. That is my experience with it. With 50GB of shared memory on top of my 64GB Ram I finally got to switch models without comfyui crashing.

@fruitpaster Those are great questions. I’ll try to answer each one separately.

1-      By looking at your workflow I already identified a very important problem. You are loading model option 2, the gguf, but that is NOT supposed to be a Flux Fill model. The whole workflow deals with that as a normal Dev model and will load Alimama control-net with it. Which is probably what is causing you trouble, since Flux Tools LoRas won’t work with Flux Fill. The GGUF needs to be a normal Dev quantization, not Fill. IF you want to use a quantized Fill model (that I’ve personally didn’t even know it existed), you should delete the “Load Diffusion Model” #690 and add a Unet Loader (GGUF) there instead, since using Fill for the model needs to be Option 3. This Integer(index) "3" is an information passed to the whole workflow to allow it to choose between using Alimama or not, to disable Flux Tool Loras or not, and so on.

And that might be my fault. I need to make this more clear in the next versions. Maybe even add a 4th option meaning GGUF for Flux Fill, which right now, doesn’t exist.

2- Yes, Compact is meant to be the exact same thing, but with a more simpler look (and with less confusing options). Not necessarily worse. But it hides all the nodes. I don’t think this is a good practice. But for end users who don’t want to understand how things work, all the connections and nodes might be overwhelming. So using the compact makes it cleaner and easier for them... even for me sometimes I prefer to use it.

3- You are using a batch of 6! That will take a lot of your VRAM. Specially with Flux + Control-Net. I recommend doing a batch of 2 at most. That is probably why you are having slow generations.

4- I really don't think the seed being -1 on #1587 makes any difference. I doubt this would cause any problems at all. But I don't know I'll test it.

5- Adding Redux is probably feasible. It's just that I have never tried it yet. But after I end up adding loops (another used requested this) I might look into it.

6- Updating frontend is always a big gamble. It more often than not breaks some custom nodes... so yes it might be it. I'm still holding on to 1.18.10 for now.

Q1- Yes. Localized area inpainting size is determined by both the original mask and the context mask. But the real mask is just the one on the original image. Making a context smaller than the original area will never work, it won’t make a difference. It only expands the context, only, it does not make it smaller. So, if you want to inpaint a smaller area, just make a small mask on the main node and don’t use anything on the context node. Think of context mask as a way to increase the area to give the ksampler more knowledge of the surrounding areas around your main mask, while the mask that count’s is always the mask on the main load node. That is why you don’t need to make it accurate or anything because this mask is just used to expand the other mask unpainted area size but not the masked area itself. I hope this makes sense.

Q2- No. You can never use both LoRas on this workflow. I don’t remember anymore, but I’m pretty sure it is feasible, I don’t think I’ve tested it, but I don’t see why it wouldn’t work. I didn’t add that option though. You either use one or the other. To use both you would need to load both loras at the same time and probably use two InstructPixToPixCondutioning. My workflow always disables one LoRa if you choose the other on the control room. I have this video, I don’t know if you watched it: https://youtu.be/cPg49GoHpSI?t=689

I did it like that because I thought using both might be confusing and I don’t know if Start and End of conditioning would work. I was more interested in that option. But I might explore this in the future.

Q3- Node #1579 is used on the Canny or Depth control image, that was previously resized to 1024 resolution (to make things faster) by the pre-processors, so #1579 change it back to be the same size of the original image again. This is needed because it will be used again for outpainting as well, so it can’t be on the 1024 downsized resolution or else it would cause a mismatch. If not for outpaintining this wouldn’t matter as I think a 1024 resolution is better for instrucPixtoPix.

0 means basically the same of 1, as far as I know. No adjustments will be made on the image by choosing 0 or 1.

I'll look into it. But it looks hard to implement. Specially because the whole initial purpose of this workflow was to inpaint with batches. Meaning, you can inpaint with one mask and receives like 4 different inpaint variations at once.

Your proposal seam to be making sequential inpaintings for different masks, doing each mask inpainting one after the other. Problem I see with this:
1- I don't know any way of doing multiple masks at once in an image. The only thing I can think of is making like 4 "paintings" on the image with different colors and then separating each color as a different mask. This could be achieved. But that would need a "painting" node instead of an edit mask node. The original integrated mask solution of ComfyUI doesn't allow multiple masks at once.
2- Your idea would mean it would not work with batches anymore. Since it would need to go with 1 inpainting after the other. That kills the idea of this workflow, but could be an idea for a separate workflow.
3- Also, I never managed to get a good "loop" experience with comfyui... It works best to chain multiple Ksamplers one after the other instead of looping with multiple automatic runs.

Anyway, I'll check the suggested node and see what I can do and get back to you.

And to be honest, do you really feel like gambling with 4 different inpaintings in a row is such a great idea?
I mean, you can have a success on your 1 masked area, a mediocre result on the 2, the 3 might be fantastic, and the 4th might be a complete failure. So now you end up with an image that needs to inpaint the bad inpainted area...
Makes more sense to me to inpaint one at a time, analyze the results, and do the next manually. Don't you think?

There is also the possibility to apply multiple different prompts to different areas on a single inpaint. Like a "regional" inpainting. But that is not what you are asking for, is it?

OK After I studied ComfyUI-Loop-image I think it can be implemented somehow. It solves the problem of separating masks and the loop works. I don't know If I'll officially add it here or on another workflow just for it, but it's doable.

@noorhamadani I managed to implement it yesterday, but so far what I did is simply disable batch_size when using loops. So whenever you use loops you get one final image only. I'm having trouble now organizing the nodes in a non chaotic way... And comfyUI simply reset my unsaved workflow to hours of work back when I tried to save it yesterday 😭

Your idea to pick one from a batch and go from there to the next loop could work... the challenge will be to implement it only when using loops and not stopping the workflow when a person is not using it. I'll have to check to see if it is achievable....

But I never liked the "picker" node because it used to make the whole workflow restart always (even when you made no change to it)... from a user perspective it might not be a problem though. I'll look into it.

I might focus on releasing a loop version that disables batch size and then check if a picker node is feasible later.

@noorhamadani Just so you know, the loop inpaint workflow is coming out great! Your idea was really great and the implementation worked perfectly. I managed to also implement the "image choose" node and it is working way better than what I expected. It's very useful specially together with "area inpainting"

I'm just putting the final touches, but I won't publish it here anymore. I'm migrating out of Civitai.

I'll probably develop this workflow on GitHub, or maybe a discord channel, I'm not sure yet.

@noorhamadani Hi. Just to let you know. I've released v8 with loops with batches support as well. Thanks for the amazing idea. It's released on github. Check it out and let me know what you think of it on the Discord channel. Thanks! I won't be supporting this workflow here anymore. I hope you understand.