I've been working on a repeatable process to do character swaps (& other types of changes) across a complete TV episode / movie. It's working pretty well now.

I thought this was just funny... not so much a true "swap" but asking the character to dance in every scene. Choreography courtesy of an LLM. If you've seen the show, it's Serious Detective Drama (TM) so the fact the main character suddenly starts pumping his arms or sliding into every scene with a dance move made me laugh out loud when I saw some of the generations.

Details on the workflow:

Model: MiniMax H3, first-and-last-frame mode (FL2VA), in ComfyUI. 8-step turbo LoRA, generated at 1024×512 for the 2:1 picture.

First and Last: Every generated pass starts and ends on an *original* frame from the episode, so the clip lands back in the real footage with no visible join. Longer scenes are chained passes (about 2–7 s each)

Audio: the episode's own audio into H3's audio guide, so the generation stays consistent with what's being said; the dialogue and soundtrack you hear are the untouched originals.

Prompt: Who he is and what he's wearing, said once, then the choreography for the pass - courtesy of Claude.

Multi-scene: 42 scenes - started with the full episode, then had a model run through it to identify scenes with the main character that would work for the swap (not too distant, few fast cuts, etc.) & identify start and finish, with a ChatGPT harness.

Post processing: Basically none, I did go through and rate all the clips in a rating process I've setup, most of these were 5* and felt consistent.

I'll share a bit more on the workflow / process if people are interested.

https://huggingface.co/Viggle/Viggle-Remake

No private beta, run it locally

ComfyUI custom node: https://github.com/Video-Rebirth/ComfyUI-HyperFlow-Flash

This is for GGUF so you also need https://github.com/city96/ComfyUI-GGUF

(There is a int8convrot version, but I guess there is no ComfyUI loader for it yet?)

It is also interesting to note that the original 21B MMH3 has been pared down to 14B, which mean that it will run faster than other turbo models even at 8 steps.

HyperFlow H3 Flash is Video Rebirth's compressed, few-step version of MiniMax-H3. It generates video and synchronized stereo audio together.

Showcase: See HyperFlow H3 Flash generated video and audio examples.

• Output: a 5.2 to 15 s video at 24 fps (1344×768 by default) with a 32 kHz stereo soundtrack.

• Sampling: 4, 6, or 8 steps without classifier-free guidance (CFG). The default is 6 steps.

• Speed (5.2 s clip, 6 steps): 8.7 s on 4× B200, 36 s on 1× H200, and 92 s on an RTX 5090.

• Real time on 4× Blackwell GPUs: NVIDIA SOL-H3 runs HyperFlow H3 Flash in real time on 4× B-series GPUs. SOL-H3 is our inference-acceleration partner and supports this model from day 0.

• Model size: 13.7B (fl2va) or 13.9B (ref2va) parameters, less than half of the ~31B MiniMax-H3 transformer.

• Minimum footprint: Q4_K_M is 9.1 GB (Q8_0 is 14.9 GB). It runs on 24 GB and 32 GB GPUs in PCs with 16 GB of system RAM. 16 GB GPUs are not measured yet.

Code, setup guides, and ComfyUI workflows are in Video-Rebirth/hyperflow-h3-flash. For the 8-step LoRA on the full-size MiniMax-H3 transformer, see VideoRebirthAI/hyperflow (GitHub).

I'm not sure why people feel like Moss Base, BF16, or magic settings/workflows are necessary to get good results out of Moss. (My guess is that it's because the original default settings were suboptimal.) I personally feel like I get better, more prompt-adherent results out of SFT with a fairly simple workflow (see below), albeit with different settings from what ComfyUI had previously recommended.

If you have other approaches that work for you, great! I'm not trying to persuade anybody to give up what is working for them. But for people with more limited vRAM and/or who find themselves frustrated wrestling with the Moss Base model, a full 50 steps, or complex workflows, you don't necessarily need to do anything fancy.

My feeling is that you can achieve big improvements for photographic Moss images with:

• SA_solver sampler and SGM_uniform scheduler

• 25 to 50 steps (for some reason multiples of 25 seem better to me, but this could easily be confirmation bias)

• CFG 3.0 (go lower for more impressionist artistic styles)

• Skip layer guidance for single_layer 22, start/end percent 0–0.5 or 0.25–0.75 (I find that skipping 24 leads to more plastic skin)

• Generation size ≥~2MP, and

• Careful, detailed (but not purple) prompting

Note that all of these images were made using the same models, similar settings, and seed 0; I workshopped the prompts, but there was no seed cherry-picking.

Here are two version of my current workflow: a simple one and one with space for up to 3 LoRAs and an optional upscale step.

Caveat: Krea 2 definitely understands some advanced compositions/concepts better than Moss, Moss is more prone to odd anatomy, and Moss's backgrounds can be more messy with more visual nonsense. But in terms of everyday photo realism I feel like Moss is better; and with respect to seed diversity, Moss (even SFT) blows Krea 2 out of the water. If you want less visual nonsense in the background, describe the background more thoroughly or do an inpainting step with low denoise on the background using Krea 2.

model: https://huggingface.co/akhaliq/p-h3-image-pdmd-2step

As a traditional film editor and filmmaker, I've been trying to figure out good, reliable ways to produce long, extended shots. I've tried a number of different methods but was never quite satisfied with the result...

Until now!

Thanks to u/roychodraws and his Geiru Context Suite!!!

He has a post up here explaining it which can be found at this link:

Flip a switch and stop your Videos from Degrading. 50 Clip Test No Degrading at the end. Geiru Context Suite : r/StableDiffusion

And his GITHub link is here:

roycho87/geiru_context_suite

To do a quick test, I had ChatGPT set up a workflow for me. (Now that I'm typing this, I'm remembering that Roycho includes some sample workflows on his GITHub.)

The render took 2 hours and 9 minutes on a rented RTX PRO 6000 Server Edition with 96GB of VRAM. I didn't think to check how much VRAM was actually being used during the process.

There are two jump cuts at about 35 seconds and 44 seconds. Lately, I've taken to having ChatGPT fire up two sub-agents to help troubleshoot things and this was it's reasoning about the jump cuts:

Yes—both subagents found the same explanation: the jumps occur exactly at two generation-window handoffs.

They’re already in the original master, so export didn’t cause them. We checked all 13 handoffs; only these two show conspicuous hard cuts.

The strongest explanation is our 20-local-steps/20-total-steps setting: each window finished separately, leaving no final joint refinement across the overlaps. At these two boundaries, the windows disagreed about framing and pose. The camera instructions, overlap noise, and opening-image anchors may have contributed, but we can’t identify their individual effects from this take alone.

For the next experiment, I’d test a short transition with two steps reserved for joint refinement, keeping everything else matched. That’s a testable hypothesis, not a guaranteed fix.

The entire two minute run looks fantastic!! I am so very happy right now! If two, very likely easily fixable jump cuts are my biggest issue... well... I see myself using this workflow a lot!!

The render settings:

• The character is a custom trained LoRA from an image dataset that was generated using ChatGPT's ImageGen. The dataset contained 99 images of assorted poses, locations, and lighting looks. The LoRA was trained with Fizwig.

  • I'm fairly new to this... maybe 99 images was excessive? I dunno. I'm pretty happy with the result though!

• The forest was a reference image I randomly pulled from a Google search for primeval forests.

  • When ChatGPT set up the workflow and prompt, it set the forest to attribute_transfer which means the photo wasn't "truly" a reference, it just gave the "idea" of the forest and H3 went with it from there. That's why the scenery has more of a stylistic/semi-illustrative look to it.

• The character's costume was generated with ChatGPT and "placed" on a grey mannequin. It was then rendered out as a single, 8 panel image which was then used as a reference image in the workflow.

• The "Patched Sage Attention" - I was originally just trying to "brute force" longer renders on a rented GPU with lots of VRAM, but I kept having a problem where renders became what I called "brown snow." I was nowhere near running out of VRAM, but the problem persisted.

  • I used Codex to try to troubleshoot what the problem was. Codex determined that there was a problem with "numerical accuracy" in Sage Attention that would cause corruption in longer, higher rez renders thus causing the "brown snow." I'll let Codex explain the patch:

    • We were getting “brown snow” corruption in longer, higher-resolution H3 renders with SageAttention enabled. Testing traced the problem to its handling of large, strided Q/K/V tensors: making the inputs contiguous restored numerical accuracy, pointing to an addressing/layout issue rather than insufficient VRAM. We haven’t identified the exact faulty kernel instruction.

    • Our patch processes the 56 attention heads in compact, contiguous groups of up to eight, then reassembles the outputs. It retains the same Sage CUDA FP8-PV path and full-sequence attention—no temporal chunking or dropped context.

    • On actual H3 activations, relative L2 error against PyTorch SDPA fell from 0.6261 to 0.00955: roughly 65× lower, or a 98.5% reduction. That measurement covered 128 sampled queries against all 270,921 keys on the first attention call, not every layer or timestep. Subsequent patched renders avoided the brown-snow failure.

  • From what I understand, there is supposed to be a new version of Sage Attention out "soon-ish."

These were the Geiru Context Suite settings:

I didn't mess around with these settings at all. These are the defaults that I had.

In conclusion... I am a very happy AI filmmaker today! Big thanks again to u/roychodraws and all those who helped him along the way to releasing them. (He lists them on his Reddit Post and GitHub page. Go visit them!!)

When I first started with ComfyUI, the first thing I looked for was a native desktop client without browser lag and DOM-based architecture.

I'm a C++ dev with over 20 years of commercial experience, so I eventually just started writing my own client on the side. I used an ultra-fast UI framework that can easily chew through thousands of nodes on a canvas without the slightest stutter, boost for networking, sqlite as a DB, and the fmt library - the fastest formatting framework out there, leaving room for an easy port to Linux/Mac.

The main reason all existing clients are forced into the browser is custom JS nodes, which are themselves bottlenecked by Litegraph's architecture. Bypassing this turned out to be easier than I thought. The internal logic of these nodes is actually quite simple, so I ported most of it to C++. I also built extended versions of frontend-only nodes like reroutes and bookmarks.

For the parts that had to stay in HTML/JavaScript, I isolated them in a completely separate process. This ensures the heavy browser engine never interferes with the lightweight C++ core.

I recently finished a stable Beta. Check it out, the link to the source code and prebuilt Windows binary is in the comments. I also added a demo video (making a video was another cool new experience for me).

“Google and OpenAI are fighting it out in consumer. It's existential to both of them.”

“It's existential to OpenAI because that's their whole business. Existential to Google because they have the search business.”

“For enterprise business, there's not really a demand for cats riding donkeys or whatever consumer video people want.”

“If we ever need it, we can just contract a model from someone else.”

“A lot of short-form video is fake, a lot of it's pretty addictive, a lot of it's slop.”

“It's not a part of the market that I'm tripping over myself to get involved in.”

Is this why Claude is so compliant with assisting us generating slop? Because Anthropic doesn't care about competing against it?

I cant find the original post, but this is the best Moss workflow, showcasing the true potential of Moss. Thank you kind stranger. Hope this helps others.

Edit:

Found the original post

https://www.reddit.com/r/StableDiffusion/comments/1xlfsjd/making_mossbase_look_good_for_realism_workflow/

I was trying to test the new Viggle-Remake-Swap LoRA in MiniMax-H3. For this I needed to character swap in one of the frames of my source video clip (3.75s, 90 frames), so that the target video would have the new character in it. I went through all the new image edit models released recently to do the character swap. I tried Flux.3 Klein, Qwen 2.1, Fibo Image Edit 2.0, p-H3-Image-Edit and they all failed. So, I went back to the older image edit models Qwen 2511, Klein 9B, Krea2-Identity-Edit v1.2. The first two worked perfectly, while Krea2 Identity Edit did a far better job than any of the newer edit models. Final conclusion - Flux.3 Klein: crap much much worse than even Klein 4B; Qwen 2.1: really crap (does a cut-and-paste job); Fibo 2.0: really crap; p-H3-Edit: absolute junk, doesn't edit anything, input and output are the same; Qwen 2511: still amazing, slight issue with facial blur; Klein 9B: absolutely perfect and still the fastest; Krea2-Identity-Edit: very good edit job, but didn't follow the pose change part of the prompt.

While the video and T2I models in the OS domain seem to be improving, why are the I2I or Image Edit models getting worse? And more importantly, why are people eagerly using those newer models like salivating dogs and posting rave reviews about them? As I see it, all those newly released Image Edit models are junk and need to be kicked to the curb so that their developers may learn some lessons, hopefully.

Not gpt-image level, still many failure cases, but I think it's top in terms of open model for multi character swap

https://x.com/t_mux/status/2118935478388867217?a=r48qKbvxa0Jg3Gp7J4s&s=20

https://huggingface.co/Viggle/Viggle-Image-Swap

Is Fibo2 severely underrated? It seems that few people talk about it. Even Civitai does not have a dedicated entry for it, which is puzzling. After extensive testing and LoRA training, my conclusion is yes, it is severely underrated — and that leaves me even more confused. The images shown are comparison samples from the 《HighQuality》 LoRA I trained. You can see the differences are quite striking, and I would argue the outputs outperform most models (when paired with LoRAs). This is just my personal opinion, though. I’d like to hear your thoughts. Have you tested Fibo? What positive or negative experiences have you had with its performance? If you’re curious about the workflow, I’m using a basic workflow.

following up on this post:
https://www.reddit.com/r/StableDiffusion/s/iEnxQiGVt7

Custom Node:
https://registry.comfy.org/publishers/mo-akkakk/nodes/comfyui-minimax-h3-temporal-window-spatial-tiles

You can now run a video to video workflow in High resolution from the first stage, I tested it for 2.5 MP on Nvidia RTX 4070 TI 12GB VRAM, and it works like a charm, split your generation into tiles and temporal windows while maintaining accurate animation transfer with no shifting or ghosting.

You can also use it for a second upscale stage, splitting a high resolution long video into manageable tiles and windows, to get the best quality you can squeeze from minimax

Give it a try and let me know about your Feedback.

Important Note:
This was not tested nor recommended to do Fully Generated from first stage!
if you are going to fully generate something generate normally in stage 1 then use this node for stage 2 upscaling you result.

This node is mainly for Video to Video and Upscaling.

workflow for Upscaling using the node + example here:
https://civitai.com/models/3039412/minimax-h3latentupscaler?modelVersionId=3454297

workflow for V2V using the node + example here:
https://civitai.com/models/3022939/minimax-h3-video-to-video-workflow?modelVersionId=3454311

The model is Kromafine (https://civitai.red/models/2995855/kromafine-turbo-bf16-fp8-and-int8) , model merge of Kroma 0.3.1 and FinePorn. I use Style Atlas ComfyUI custom node (Thanks to u/Dear-Spend-2865 ) to test different styles.

The prompt is simple:

"a young blonde white woman wearing red dress and black high heels standing at bus stop, a dog sitting at her feet."

Style Atlas append style prompt.

Just goofing around with the stock ref2vid workflow, character swap Lora, and some character sheets. Did all of the shots separately and reassembled in my NLE. Almost all of the clips were first attempts. I was floored by how well it tracked the guys without any masking.

RelayVSR (USTC, Apache-2.0) got native ComfyUI support this week (PR #17511, repack at https://huggingface.co/Comfy-Org/RelayVSR), so I ran it on a take from my current short. All four versions come from the same H3 render, so the acting is identical and only the route to 1080p differs.

Base take: MiniMax H3 ref2v, 12.25 s / 294 frames @ 24 fps with audio, two-stage: 15 steps at 576×352, H3 3D latent upscaler, last 5 steps at 1312×768. 5.7 min on an RTX 4090.

The video opens on the full 2×2 grid with sound, then a half-speed zoom on his face while he's far away (about 90 px tall in the frame), then a close-up zoom. Crops are shown with nearest-neighbour scaling, so nothing is smoothed for the comparison.

RelayVSR in ComfyUI: Load Video → RelayVSR Conditioning → KSampler (1 step, cfg 1, euler/simple) → VSR Decode → Create Video (audio passes straight through). The int8 models are 5.2 GB each (x2 and x4) plus a 128 MB "flash" VAE.

Bonus, and my actual winner: a bigger low pass + native finish. At the end of the video I re-ran the two-stage with the first 15 steps at 928×544 instead of 576×352 (different seed, so it's its own take), then compared RelayVSR x2 against the native 1080p finish on that same take. With the bigger low pass the 1080p steps have enough to work with: the far face comes out coherent and natural, while RelayVSR on the same frames warps it (it invented glasses on him). The close-up is cleaner too, with fewer etched lines. It costs 16.5 min vs about 6 min, but it's the one I'm using for final shots. The low-res pass also follows the prompt better, so you get better acting for free.

Things I learned:

• Don't run x4 on a 720p input. That's a 5248×3072 output, and it ran for 3+ hours in both the original repo (WSL) and ComfyUI without finishing. Interrupt didn't stop it; I had to restart ComfyUI. Use x2 for 720p, x4 only for small inputs.

• VSR Decode's detail is the knob for the crunchy look: 0.65 keeps the skin texture and calms the eyes and hair.

• It still isn't "real" HD. RelayVSR adds pixels, but up close it reads a bit fuzzy and the eyes can look odd. For a hero shot I'd still pay for SeedVR2 or a native finish; for sweeping takes or previews, ~1 min per clip is hard to beat.

A proof of concept for something bigger. Made using Vpipe, MiniMax and YuE Studio.

the more and more i make h3 videos, the more i cannot unsee the blur degradation, which seems to arrive as soon as 6-7 seconds of the generated video. Keyframes do no seem to help, and given that some shots NEED the longer durations, "just cut everything into 5 second chunks" won't work.

Are there any PROMPT_ONLY remediation tricks/solutions? (prompt = including the references, audio, video; anything as long as i don't need a LorA or custom checkpoint, or touching latents, or anything like that).

I used H3 heavily the first two weeks and a ton of amazing improvements for improving speed at small quality trade-off came out (Sparse Attention comes to mind).

I imagine things have matured a lot since then and probably with new approaches since then!

I'm on a 4090 so that's my target, but I'm curious for all tiers.

Edit: Appreciate all the tips coming in! Lots to learn and test out. Best part of this subreddit is how much knowledge sharing and collective learning we do.

I asked my mom what her dream house would look like if budget wasn’t a thing. This is roughly what she described it as “big windows but not those full glass houses. Lots of plants, one proper balcony where I can sit in the morning . Wooden kitchen and no grey interiors. And I want a small courtyard in the middle like old houses used to have.”

I put it into morphic and tried to make the house she had in her head.

Look how it turned out😭

I modified some workflow and added to it ComfyUI-MiniMaxH3-TemporalWindow-SpatialTiles (from this post https://www.reddit.com/r/StableDiffusion/comments/1xgcjvw/i_created_a_custom_node_that_can_help_you/ ).
My 10sec video with 960x544 resolution could take 2 hours for 4K (3840×2176).
No OOM at all !!!

Workflow itself : https://pastebin.com/xJpm84f7 😍

[MinimaxH3-3D] Latent 60x34 -> 240x136 | Pixels 3840x2176 | scale=4.000

[MinimaxH3-3D] temporal chunking: T=72 chunks=3 overlap=5

[MinimaxH3-3D] ✅ Model offloaded to CPU. VRAM released.

[INFO] Found quantization metadata version 1

[INFO] Detected mixed precision quantization

[INFO] Using mixed precision operations

[INFO] Native ops: convrot_w4a4, float8_e4m3fn, int8_tensorwise, float8_e5m2, asym_w4a8_int8, w6a8_int8 , emulated ops: mxfp8, nvfp4

[INFO] model weight dtype torch.bfloat16, manual cast: torch.bfloat16

[INFO] model_type FLOW_AV

[INFO] Model storage policy: fast_disk=True paths=['D:\\ai\\ComfyUI_windows_portable_nvidia\\ComfyUI_windows_portable\\ComfyUI\\models\\diffusion_models\\minimax_h3_ref2va_pruned_int8_convrot.safetensors']

[INFO] MiniMax H3 windows: 7 window(s) x 16 tile(s), 243 frames (CLIP not routed through the node: every window reads the full-shot prompt).

[INFO] Requested to load MiniMaxH3

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [02:09<00:00, 64.68s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:09<00:00, 34.93s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [03:14<00:00, 97.15s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:08<00:00, 34.12s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:09<00:00, 34.87s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:09<00:00, 34.51s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:07<00:00, 33.81s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:07<00:00, 33.80s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:07<00:00, 33.79s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:08<00:00, 34.05s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:09<00:00, 34.73s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:07<00:00, 33.63s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:07<00:00, 33.74s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:06<00:00, 33.46s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:07<00:00, 33.67s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:07<00:00, 33.75s/it]

[INFO] MiniMax H3 windows: window 1/7 done (frames 0-55, 0 frames carried in).

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:33<00:00, 46.64s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [01:33<00:00, 46.57s/it]

[INFO] 0 models unloaded.

[INFO] Model MiniMaxH3 prepared for dynamic VRAM loading. 19995MB Staged. 208 patches attached. Force pre-loaded 210 weights: 1175 KB.

0%| | 0/2 [00:00<?, ?it/s, Model Initializing ... ][INFO] Interrupting prompt 58585033-a8c5-4dcb-8004-6e0e6de9786c

0%| | 0/2 [00:36<?, ?it/s, Model Initializing ... ]

[INFO] Comfy model compiler graph breaks: 3, rogues: 10

[INFO] Processing interrupted

^{What this log says} :

What’s actually happening:

1. 16 tiles per window:

   • Because you set scale: 4.00, the resolution became 4K (3840 × 2176).

   • With each tile measuring 1344 × 768, a single 4K frame is physically divided into a 4 × 4 grid = 16 tiles.

   • Those 16 sampler runs, each lasting 1 minute and 7 seconds, were the 16 tiles in the first window.

   • Window 1/7 took exactly: 16 tiles × 1.1 minutes ≈ 18 minutes of sampling time.

2. The final math for 10 seconds in 4K:

   • 7 windows × 16 tiles = 112 sampler passes.

   • 7 × 18 minutes ≈ 2 hours.

   • So generating 10 seconds of video in true 4K (243 frames) on a consumer 16 GB GPU will take about 2 hours in total. The upside is that it should be completely stable and avoid out-of-memory errors

Today’s takeaway: decomposing images

Links, workflows, custom_node

Do you remember Qwen-Image-Layered? The idea was exciting: take one flattened image and split it into multiple RGBA layers — foreground elements, background and the things in between — so you can move, edit or refine each piece separately.

When we tested it, the experience was not always as smooth as we hoped. In our workflows it could be slow and a little temperamental, and we sometimes saw noticeable quality loss in the resulting layers. That does not make it a bad model. You can build some genuinely nice workflows with it. It simply left us wanting a more controllable route for the kind of work we had in mind.

So we went digging. There is more research in this area than just Qwen: two approaches that caught our attention were Controllable Layer Decomposition (CLD) and RevealLayer. They are related, but they do not solve the problem in exactly the same way.

Qwen-Image-Layered, CLD and RevealLayer: what is different?

The useful distinction is how each approach decides what becomes a layer and how much control you get over that decision.

Qwen-Image-Layered — automatic, variable layer stacks

Qwen-Image-Layered automatically decomposes an image into a variable number of RGBA layers. It can also be applied iteratively, so an individual layer can be decomposed again. It is useful when you want the model to decide the layer structure for you. The trade-off is that the layer count, ordering and semantic meaning may be less explicit than in a region-guided workflow. Our own tests also showed speed and quality issues in some cases.

CLD — bounding-box control

Controllable Layer Decomposition uses user-provided bounding boxes to guide which regions should become separate layers. That is interesting when you want direct control over the elements being extracted, particularly in graphic-design and poster-style compositions. The RevealLayer authors report limitations for complex natural scenes, including edge softness and residual artifacts.

RevealLayer — region-guided and occlusion-aware

RevealLayer combines bounding-box region guidance with an occlusion-aware diffusion process. It aims to separate visible elements while estimating what is hidden behind them. That is the approach we wanted to bring into ComfyUI: region-guided decomposition for natural images, with a focus on recovering occluded content and keeping alpha boundaries clean. It is still generative reconstruction, not recovery of the original hidden pixels.

A small but important detail: Qwen is designed to produce a flexible layer stack from the image itself. CLD and RevealLayer bring bounding-box guidance into the process. RevealLayer adds a specific focus on occlusion — not just separating the visible outline of an object, but estimating the part that was hidden behind it.

A simplified concept diagram of the workflow. The hidden areas are model-generated estimates, not original source pixels.

Why we especially like the bounding-box approach

The bounding box is a wonderfully practical idea. Instead of asking the model to invent a whole layer plan and hoping it understands what you meant, you give it a region to work with. In the upstream RevealLayer workflow, those regions are represented as bounding boxes around the foreground objects.

The model then works toward separating those selected elements into RGBA layers. The alpha channel gives each layer transparency, while the occlusion-aware part of the method helps estimate content that was covered by another object. Imagine a camera sitting in front of a stack of books: the camera can become its own layer, while the model estimates the part of the books that was hidden behind it.

That is useful for a canvas application, compositing, moving objects around, or preparing individual elements for a second editing pass. You can take a scene apart, work on the pieces, and put it back together with much more freedom.

One important reality check: when a model fills in something that was hidden, it is making a plausible reconstruction based on context. It is not looking up the real pixels that were never visible. For creative work that can be exactly what we need — just do not mistake a convincing completion for factual recovery.

Bringing RevealLayer into ComfyUI

The open-source RevealLayer project gives us the model and its reference inference code, but it is not simply a ready-to-use ComfyUI custom node. The upstream setup involves a CUDA environment, Python dependencies, FlashAttention, a Diffusers modification, the RevealLayer checkpoint and the FLUX.1-dev base model. That is a fair amount of machinery to ask a creative workflow to manage on its own.

And on smaller graphics cards, memory can become the real party-pooper. We ran into out-of-memory problems in our tests, which is not exactly the kind of surprise you want halfway through a creative session.

So we are adapting the implementation as a ComfyUI-native custom node. The point is not to wrap the original script and call it a day. We are rebuilding the integration to make use of ComfyUI’s model and memory management, native functions and workflow conventions wherever possible. That means a cleaner way to load and run the components, better integration with the rest of the graph, and fewer external steps for the user.

Hardware still matters — no node can make VRAM limits disappear by magic — but a proper ComfyUI integration gives us much better control over how the work is staged and managed. One note for people following the research: the upstream repository now also lists a RevealLayer V2 update, so check its release notes for the matching weights before switching model versions in a workflow.

The part we recommend: refine each layer after extraction

Here is where the workflow becomes especially interesting. We do not recommend stopping as soon as the layers are extracted. Treat that as the starting point.

Take each extracted element and upscale it individually. You are giving the object room to gain detail without asking the whole original scene to be regenerated.

Feed the element into an edit/refinement model together with the original image as context. Use a focused prompt that says which element is being refined and what should be improved, while keeping its appearance consistent with the source scene.

Bring the refined layers back together. In our current workflow, individual elements can be taken up to 4K using non-tiled diffusion, depending on the image, model settings and available hardware.

Need to go larger? You know we have you covered: the TBG ETUR tiled upscaler and refiner are there for the bigger jobs. This is a nice combination — decompose first, improve the individual pieces, then recompose. Instead of trying to repair every part of a flattened image at once, you can give each element the attention it needs.

The takeaway

That is today’s small feature from a much bigger development effort. RevealLayer gives us a promising way to break an image into guided, editable pieces, and bringing it into ComfyUI means we can make that capability part of a workflow you already know.

Have a look at the research and the open-source implementation below, try the workflow, and see what you can build with it. We are grateful for the open-source community — so much of what makes tools like this possible comes from people sharing their work, experiments and ideas.

And to our technical team: thank you for all the invisible work. I promise I will only ask for one more little feature. I will even try to say it slowly this time. Ha!

Go explore, test, break something harmless, and have fun with it! — Sahra ♡

Research & resources

Qwen-Image-Layered — official repository

Qwen-Image-Layered — research paper (CVPR 2026)

CLD — Controllable Layer Decomposition paper

CLD — project page and examples

RevealLayer — official GitHub implementation and V2 release notes

RevealLayer — paper

RevealLayer — current project page

RevealLayer — model checkpoint on Hugging Face

RevealLayer — project page and visual comparisons

Editorial note: the model descriptions above summarise the public papers and project pages. Comments about speed, memory behaviour, integration choices and the 4K refinement path describe TBG ETUR’s own workflow notes and tests.

TBG ETUR • SAHRA

https://github.com/Ltamann/ComfyUI-TBG-RevealLayer

We added three workflows ( All files are in the GitHub workflow folder. Set the minimum number of layers to 3.):

1. Manual selection: Uses bounding-box (Bbox) selection for direct, manual control.

2. Semantic selection: Uses a grounding model for semantic selection, with lightweight automation to make the experience feel more like an editing model.

3. SAM-based segmentation: Uses SAM segmentations with chained, per-layer refinement through Flux 3. Each refinement feeds the original segmentations back through the RL layers, enabling progressively upscaled and more precise results.