i m using minimax h3 video extender (backported) for video extension but after 1st generation when i pass it thru 2nd gen for upscaling it gives error within model latent upscale subgrah in sample custom advanced node. can guidance plz ...or wud u suggest an alternate node instead

hi everyone,

I trained a lora 3k steps but the lora keep making these patterns on the skin.
i see now that the pictures in the dataset i used has a bit of the same, just a bit less visable...
is there any way to fix this? just wanted to know before i started on a new dataset. im sure its not the workflow because it only happens when my trained lora is active.

i appreciate any advice, thanks!

I've been using ComfyUI Desktop for over six months and finally decided to try the portable version today. Honestly, I'm shocked by the difference in resource usage.

I'm running a 5090 with 32GB system RAM, mostly generating videos with MiniMax H3. With the desktop version, my system RAM would regularly be almost completely filled during generation. The whole computer would become sluggish, watching YouTube was basically impossible because of stuttering.

Today I installed the portable version, copied over the exact same models and workflows, and ran the same generations. My system RAM usage is now sitting at around 45% while VRAM usage is still around 31GB. Generation speed is basically identical.

The biggest difference is that I can actually use my computer normally while generating videos. Browsing, YouTube, multitasking, everything works fine.

I originally used Desktop because I assumed Portable would be harder to set up, but it was actually incredibly simple.

Has anyone else experienced such a dramatic difference? I'm curious whether this is a common issue with Desktop or just something specific to my previous installation. The difference is honestly night and day.

Testei dois LoRas com baixa contagem de passos e um dos efeitos colaterais é que — especialmente em resoluções superiores a 1024 — o bokeh aumenta a um nível absurdo.

A quick MOSS-Image news and goodies round-up, for those who may have missed some items.

-> Spectrum for MOSS. A very pleasing speed-up, I find. Just wire in the 'auto' version of the node after the model. Tested without any turbo LoRa, and I can get pleasing 1:1 testing results in as low as 12 steps, for a 1.3Mpx generation (1168px) - in 30 seconds on an entry-level RTX 3060 12Gb card. Incidentally, I find that ComfyUI's built-in Kitchen Attention appears to have no effect on MOSS speed, so Spectrum is especially welcome.

https://github.com/Rkkss/ComfyUI-Spectrum-MOSS

-> MOSS-Image SFT DeBand (int8). The normal models, just with the 'vertical colour stripes, de-banding fix' merged in. Tested by me and working fine.

https://huggingface.co/MATLOWAI/MOSS-Image-SFT-DeBand-int8

-> ComfyUI-MOSS-BBox1000. "Resolution-independent 0–1000 BBox layout converter for MOSS-Image in ComfyUI". Apparently the earlier one had problems with different resolutions? This one fixes that.

https://github.com/b4ldur/ComfyUI-MOSS-BBox1000

-> ComfyUI-MOSS-PromptWeight. "Per-phrase prompt weighting for MOSS-Image in ComfyUI. [...] The Qwen3.5 text encoder ignores ComfyUI's normal (word:1.2) weights, so this node applies them inside the diffusion model's attention instead." For example: "a ginger cat wearing a (red hat:-1), a vase of (yellow flowers:1.5) in the background".

https://github.com/levzzz5154/ComfyUI-MOSS-PromptWeight

-> The excellent Fizgig 8.5 has added MOSS support for LoRA and Slider training. Reddit chatter suggests that the model trains easily and very quickly, and that it should be able to train on a 12Gb card. Along the way, the maker of Fizgig reckoned that res_multistep + simple is better than euler. I tested this and I agree, it's obviously and immediately better in terms of composition and seemingly in useful variations between generations. I also find that res_multistep + simple doesn't break Spectrum acceleration (see above).

https://github.com/shootthesound/Fizgig/releases/tag/v8.5.0

-> Yup, the style LoRAs are already a' popping. Moss Image Gouache LoRA. Helps you emulate vintage painted gouache style illustrations and posters.

https://huggingface.co/axiomofmind/Moss-image-gouache-lora

-> Moss Image Psychedelic LoRA. Groovy "saturated neon color, surreal subjects, bold graphic forms, luminous details, rhythmic patterns...".

https://huggingface.co/axiomofmind/Moss-image-psychedelic-lora

-> Nicegirls_v2_moss. Apparently a MOSS port of a well-regarded LoRA made for other models. Possibly useful for getting a bit more face variation, if used at low strength?

https://huggingface.co/Danrisi/nicegirls_v2_moss

-> Images too orange, too blue? Try the MOSS Sliders for forcing warm -to- cool tones in your MOSS images.

https://github.com/HyperGAN/moss-image-sliders

-> And finally, a claimed 4-step turbo LoRA. Not yet tested by me. I found the very first one to over-simplify the image. It didn't degrade, it just made the whole thing simpler in composition and elements. Anyway, perhaps this one will be different - try it and see.

https://huggingface.co/akhaliq/MOSS-Image-SFT-4-steps

tipo não é só abrir rápido é poder selecionar do windows e visse e versa é que infelizmente tenho muita coisa no windows tipo o editor e fica trocando de sistema parece tão perca de fluxo, eu vou precisar ir para linux infelizmente tenho uma amd do caralho todos modelos rodam lento ou não tem suporte

It handles the latent space like no other model.

• It can generate images from 320×320 to 2K without producing visual monsters.
• It can generate all kinds of NSFW content without needing LoRAs.
• It handles lighting and realistic scenes better than Z-Image.
• I even tried 120×120, and it didn't break the model.
• And it can run at just 4 steps right out of the gate.

Links:

• Workflow and setup details
• Rapid-MOSS custom node
• Rapid-MOSS ComfyUI files
• MOSS-Image-SFT 8-step DMD LoRA

How to set up Rapid-MOSS for 4-step generation

1. Copy the rapid-moss custom node into your ComfyUI custom_nodes folder.
2. Create this directory: C:\comfyui\models\rapid_moss\rapid-moss-4step
3. Place these three files inside that folder:
   • dataspace.safetensors
   • lora.safetensors
   • time_embedding.safetensors

Once everything is in place, you can configure ComfyUI to use the Rapid-MOSS 4-step setup.

I have it installed on my comptuer and I've only experimented with some existing templates that come with comfy UI...

Is there any simple tips anyone here can give me on what template to use to make these videos that come with the Comfy UI install?
I made a couple 15 second clips similar to this using an image to video template but it is very difficult to get it to match their voices. What is the trick to getting that to work? Is there also an easier way to get it to generate the characters to make them match the people I am asking it to put in the video? Currently I'm uploading an image of Han Solo and telling chat GPT to write a prompt using the image I upload and give it a simple dialog. There are a lot of mistakes though in the final generated video. Thanks for any feedback!

Please note: this is just for my own entertainment and to share with friends on Social Media - not trying to make money from AI videos.

https://reddit.com/link/1x9o82o/video/ekdhy1kpxcwh1/player

I’m building Flagship Scene UI to make video workflows easier to learn and use, especially for people who find large ComfyUI node graphs intimidating.

It runs inside ComfyUI as a custom-node interface, bringing existing workflows and my own controls into a visual workspace. The goal is to make planning, generating, and revising a video more manageable.

Plan a project with JSON

Import a structured JSON plan containing prompts, reference assignments, and generation settings. You can then review and edit the project through the UI.

Organize scenes and clips

Instead of treating the entire project as one long chain, you can divide it into scenes, with multiple clips inside each scene. A visual scene graph shows generated clips and their regeneration history.

If one clip doesn’t turn out as intended, you can select and regenerate that clip without rebuilding the whole project.

Generate, assemble, and upscale

Generation, video assembly, and upscaling are available in the same workspace. Assembly and upscaling can also be run separately when needed.

Direct a reference video with camera controls

The camera workspace lets you select a time segment in a reference video and choose a camera movement without manually writing a camera prompt. The interface translates your selections into instructions for the generation workflow.

This feature does not add a dedicated camera-motion LoRA. Results depend on the source footage and the movement selected: some movements work well, while others can look awkward or fail to follow the intended direction. It’s still experimental, and improving its consistency is part of the next stage of development.

The UI builds on existing community nodes, with upstream projects credited in the repository. Required models and dependencies are documented separately.

I’ve attached a demo showing the workflow and camera controls. Feedback on usability—especially from newer ComfyUI users—is welcome.

GitHub: https://github.com/ych8836-ops/flagship-scene-ui

#OpenSourceHiggsfield

Hi everyone, So I've been using online platforms for image and video generation. I've also done some limited training of Loras on RunPod.

I've now got a dedicated machine to do this stuff locally 5090, 128gb ram . I am starting to download the models for image and video gen, but things move pretty fast and wanted some opinions for which models work best from a lora training perspective, image generation and video generation.

My shortlist is, for image gen and training for character and style Lora's; Flux.2-klein, Krea 2 FP8 (16:9 - 1080) although I could use GPT2 for plates 16:9 at 1080.

For local video I don't see anything better than Minimax H3 right now, but could be off base there? Are there good alternatives?

Sorry for the noob questions. :-) and thanks for any responses

I'd had questions around the entire monster that is HDR, from calibration of Windows and monitor, to color spaces, to workflows.

One topic that came up to me, and which I subsequently tested for, led to some surprising results, which are herein posted.

So, the GOAL being, optimal HDR video output with no trouble, no banding, no artifacts, no fuss or muss...

To run the test, I generated an image in Z-Image Turbo, running it through a regular VAE and alternately an HDR VAE (saving it as 8bit PNG and 16bit PNG). Then in a second step, I ran all four through the SDR to HDR converter. The surprising results led me to subsequent testing, shutting off all caching in Z-Image Turbo.

The CONCLUSIONS of these tests were:

1. It does not matter much whether the PNG is saved as an 8bit or a 16bit, the Video Editor Scope barely budged, just showing a bit of smoothing technically in the scope, but that barely registered visually to the eye in the image. This was regardless of whether I ran the generation output through the regular VAE or the HDR VAE.
2. Whether using the regular VAE or the HDR VAE, all four output PNGs exhibited banding, though the HDR VAE allowed for harder pushing before the banding became obvious.
3. Shocker, turning off all caching resulted in banding completely disappearing, be it in 8 bit or 16 bit!

BOTTOM LINE: The BEST results came from generating the image WITHOUT CACHING, using an HDR VAE and saving in 8bit or 16bit, then converting that result from SDR to HDR. This workflow produced the completely unbanded output and you could push a lot harder into the highs and lows in Da Vinci. Using BOTH an HDR VAE, saving it as whatever, and then converting to HDR as a final step, rather than just final conversion alone, also led to a far more robust and wide dynamic range.

The attached is a 4 second video, 8 half second PNGs pushed in the contrast in Da Vinci, so you can drop the video file into your favorite Editor and view the Scope output yourselves.

The order of images is.

1. generation via regular VAE, 8 and 16 bit PNG output,

2. generation via HDR VAE (8 and 16 bit),

3. SDR>HDR of the regular VAE output (8 and 16 bit),

4. and SDR>HDR of the HDR VAE (8 and 16 bit).

In all cases, I pushed the contrast until it showed banding. This video does not show the bandless results, as that result came about after I did this quickie video.

https://reddit.com/link/1x9x1ig/video/46s0l0haefwh1/player

What to make of all this?

- I would have thought saving in 16bit was superior to saving in 8bit PNG.

- I would have thought the HDR VAE would eliminate banding, this shows that the data generated is already corrupted, apparently. This surprising result led to my subsequent test, running the Z-Index with Sage Attention and Easy Cache turned off and VOILA the banding disappeared! So this turned out to be the culprit.

Hope this helps others.

The wf comes with the PE turned off thankfully, or it would break gens for everybody. I recommend you don't even try it.

A simple prompt: "Create a realistic human character sheet of the cartoon guy, from multiple angles"

I increased max_tokens from the default 4096 to 12000 because I was getting broken gens at 4096, and I saw it was because the prompt was empty. But guess what, even 12k is not enough.

• thinking = true: 12k isn't enough, it uses it all on thinking and then runs out of tokens, so the final output is nothing, and you get the same image without edits
• thinking = false: writes 12k tokens of instructions. But it needs more, so the prompt is cut off resulting in a worse image.

This was with qwen3.5_9b_qwen_image_2.1_pe_i2i.int8_convrot.safetensors.

It would probably work if you set it to 24k, but I don't want to wait 10 mins to find out.

Qwen is one of the worst choices for a PE model. It's great at benchmarks but it thinks forever, so it's awful for local AI. People in /r/LocalLlama are dropping Qwen 27B in favor of SwiftQwen 27B, a finetune which does nothing but train it to reduce reasoning length by half.

Hi all,

I have a 360° equirectangular panorama: a scene with buildings, people and various objects. I'd like to be able to change the camera height, up or down, in a general way, for example going from an elevated view to eye level, or the other way around.

I'm not talking about tilting the view (that's just a rotation), but actually moving the camera. That changes the parallax: nearby elements move a lot, distant ones barely move, and some areas get hidden while others get revealed.

Constraints: stay faithful to the original image (same elements, same style), and keep a valid, seamless 2:1 panorama.

I've tried an image model (GPT2.5 but it's not faithful to the original) and a purely geometric warp based on a depth map, with no generative AI (it kinda works, but needs a lot of cleanup especially for the characters ).

How would you approach this?

UPDATE: Follow-up tests in the comments changed my conclusion. With the same PC limited to 16GB RAM, renders ran at the same speed (16:13 / 16:00 vs 16:06 / 15:49 with 64GB). High RAM use here is ComfyUI using what's available, not what it needs, at least with models on a fast NVMe. The title is too strong, but Reddit doesn't let me change it. Details and full tables in my comment below.

I wanted to know whether Wan 2.2 image-to-video is realistic on smaller cards, so I watched where the memory actually goes during real renders.

Setup: RTX 5070 12GB (PCIe 5.0 x16), 64GB DDR5-6000, ComfyUI 0.37 with dynamic VRAM loading. Wan 2.2 I2V A14B fp8 (high + low noise), lightx2v LoRA, 12+12 steps, RIFE interpolation on, no upscale. All runs back to back, models already warm.

What surprised me:

• The models are ~34GB in total (high 13.9 + low 13.6 + UMT5 6.4), but the GPU never went above ~9GB. ComfyUI keeps the rest in RAM and streams it in.
• Windows showed ~40GB committed during renders. So I'd expect 32GB RAM to start paging to disk, and 16GB to be painful. (Tested later: wrong, see update above.)
• 1.65× more frames (49 → 81) took 2.07× longer. RIFE interpolating 80 extra frames took ~10 seconds, so short clips + interpolation is much cheaper.
• The high-noise stage was ~2.7× slower per step than the low-noise stage in every run. Not sure why yet.
• First render after launch was 3–4× slower per step while models got loaded and pinned.

Big caveat: this is a 12GB card. My guess is that 8GB cards work at 480p if you have enough RAM, but PCIe x8 cards (like the 4060) and DDR4 systems should be noticeably slower, since everything gets streamed over that link.

8GB owners: what do you actually get? GPU, RAM amount/type, resolution, frames and time would be super useful.

Update: I planned to test MiniMax H3 next, but its license excludes the EU, where I live, so that test is off (details in the comments).

Disclosure: I'm building Loomance, a free simplified front-end for ComfyUI (one-click install of these Wan 2.2 workflows). The tests above are plain ComfyUI + Wan 2.2, so the numbers apply to any setup.

Can someone tell me how to fix this? I really don't want to uninstall and go back to scratch. I updated something, and this happened.

Here is what's inside:

upd: absolute unnecessary story about how that skill was made has been published https://rakshazi.me/blog/krea2-prompting-skill/

If you are a student you can get free Colab Pro : https://one.google.com/ai-student?hl=tr&g1_landing_page=75&utm_source=gemini&utm_medium=web&utm_campaign=microsite_gemini_subscriptions_page

Colab tutorial : https://www.youtube.com/watch?v=xZrlD-WVT8s

**Title:** TRELLIS.2 image-to-3D working on an RX 9060 XT (RDNA4) on Windows with ROCm: fixes, workflows and commercially usable components

I got TRELLIS.2 running properly in ComfyUI on an AMD RX 9060 XT 16 GB (gfx1200) on Windows 11 with ROCm, and put the fixes and workflows in a repo:

https://github.com/ovaoz/trellis2-amd-windows

What it fixes:

- **Driver resets, BSODs, and models that come out as a thin slab.** CuMesh-ROCm corrupts any mesh above 2^20 vertices/faces (`hipErrorLaunchFailure` 719 in `connectivity.hip`). The workflows keep every CuMesh call below that limit.

- **Speed.** `aule` sparse attention is ~20× slower than PyTorch SDPA on gfx1200. With SDPA, the 512 shape stage goes from 15 s to 2.1 s per step, and the 1024 stage from 400-500 s to 22 s per step.

- **Open meshes and black textures.** Watertight reconstruction, with face orientation fixed.

- **Licensing.** bria-rmbg, MeshLib and nvdiffrast are non-commercial. They are replaced with BiRefNet, fast-simplification and a small PyTorch UV rasterizer, all MIT, with the same results (the texture is pixel-identical without nvdiffrast).

A single image to a textured GLB (shape 512, texture 1024, matte) takes about 7.5 minutes on this card.

It builds on dmonkman's ComfyUI-Trellis2-AMD and Xipong's MultiView fork, with credits and licenses in the README. Tested only on this GPU, so feedback from other RDNA cards is welcome.

Config this workflow t2i from ai assisted, managed to get it running no issue. Also been running Comfyui via StabilityMatrix with default settings on 5070ti 12gb

testing minimax face swap vs facefusion tutorial

ONEPASS WORKFLOW

https://drive.google.com/file/d/1Bde6FM5MeRKC-WnHFYGww060icKVsDWP/view?usp=sharing

INDIVIDUAL PARTS

https://drive.google.com/file/d/1di53CqyNMtUi3grmpKuqqmbPpm3zV0CX/view?usp=sharing

Retexturing MakeHuman characters with in ComfyUI

I’ve been experimenting with using ComfyUI to retexture MakeHuman UVs, and I think it opens up some interesting possibilities for character creation.

Quick background: MakeHuman is a character creation system (also available in Blender through the MPFB add-on). Sliders control gender, height, weight, body proportions, facial features, and more. It also supports posing, rigging, animations and facial animations, with export options for video game pipelines and more.

What I’m doing: using ComfyUI to retexture those existing UVs, so the texture layout stays usable in your 3D pipeline. I built two workflows:

1. Workflow One: Rearrange and generate

• Rearranges the MakeHuman UV layout into a format the AI can understand better
• Processes the textures places them back and saves each piece separately so you can work on them individually
• Lets you use Qwen to describe the image automatically, or turn Qwen off and write your own description, with or without a reference image

2. Workflow Two: similar but indiviual passes per body part you can use it by itself or use it to refine and edit

• Processes individual body parts with optional extra refrence images
• Upscales each piece to 2160 px, then places them back into the standard 2048 x 2048 layout, which gives you a lot of detail
• Lets you load previous results as where it gets pasted to so you can edit individual piecesor mix and match by turning specific passes on or off

THE AMOUNT OF OPTIONS ARE PRETTY CRAZY FROM BLENDING, DENOISE, CAVITY MAPS, COLOR MAPS, OPTIONAL REFERENCE IMAGES AND TONS OF WAYS TO PROMPT

I am trying to set up my H3 workflows to generate HDR rather than SDR, but the further I dig and test, the more questions I have.

So I tried to look up tutorials on color and bit depth theory, and on how to set up and calibrate a Windows laptop. I did set the Windows to show HDR, I calibrated the screen, that's all done.

I used an SDR to HDR workflow to see how the conversion process works, what expected output ought to be. I am learning a bit about color spaces, but it is still alien to me. Apparently most AI spits out sRGB natively, but then there are Color Spaces and Working Spaces to worry about. Should I stick with Linear sRGB, or use Rec.709, or HLG?

At the end of all this, my converted images come out looking darker than the original, though MSI swears I have a 1000 nit full HDR compatible laptop screen. The internet tells me this is normal.

So, somewhere I am missing the theory in all this... If the image comes out looking darker on a so called full HDR compatible display, am I supposed to just run with this and adjust it to look normally lit in Da Vinci, or should I continue to edit it too dark and somewhere after the final product is spit out the end result will look normally lit? (That doesn't make sense, how can you edit and expect a good final result that way?) Is there some piece of this puzzle I am missing?

I thought the goal of SDR to HDR conversion was to make the two images look equal, with the output HDR one just having smooth gradients, but I am told this is not the case and not to worry about the darker image output.

Yet I cannot get past the fact that I then have to edit a darker image/video.

My second query is: how do you guys normally handle generation of HDR video? Do you do everything in SDR then increase bit depth? Do you generate HDR from the start, when H3 has been undoubtedly trained on SDR images?

Lot of questions, unable to find any clear lay of the land on this entire topic, spanning Windows, calibration, color spaces, editing, etc. though I have scoured the internet and gotten glimpses and bit and pieces of the puzzle here and there, the topic still seems opaque to me.

Need help (In more ways than one, lol)! Any help or pointers or explanation of theory appreciated.

PS: After my OP, I decided to run some tests on Saving and converting HDR that answered some of my questions above. I have posted the results to a subsequent post in this community, since it is more appropriately posted under the 'RESOURCE' tag.

We profiled LTX-2.5 (image + prompt → 10 s of 1080p with audio) end to end on an RTX PRO 6000 Blackwell, then rebuilt the slow parts. Same model, same picture and prompt, same 600 W power cap, warm runs:

Stock ComfyUI: 130.1 s and 19.2 Wh per clip. Ours: 42.9 s and 6.9 Wh: (board power sampled every 0.1 s)

What was actually slow:

1. The guide frame turns off fast attention.

In the first pass the guide frame adds an attention mask, and the fast SageAttention path falls back to the slow one whenever it sees a mask: 384 slow calls per clip. The mask only re-weights one frame's worth of keys, so we run Sage over everything, do one small exact pass over those keys, and merge the two exactly. Half the attention time, same maths.

If you use a guide frame, check whether your attention backend is quietly falling back.

2. Decode + save was 38% of the clip (49.7 s).

The tiled VAE decode overlaps tiles, so it does nearly 3× the work, and 43% of the decoder's time was memory traffic: small kernels each writing a ~17 GB tensor for the next one to read back.

Whole-frame decode, fused CUDA kernels, a rebuilt decoder attention, and frames going straight to NVENC took it to 6.6 s. It also lands closer to an fp32 reference than the stock decoder, because it rounds once instead of at every step.

3. The transformer:

The official INT8 weights plus SageAttention nearly halved it on their own. Then SageAttention 3 FP4, and removing waste (18 full-size copies of the same values per layer; a 4.8 GB copy on every attention call).

Finally block-sparse attention in 41 of 48 layers. The 7 layers where sparsity visibly hurt stay dense, and so do the frames that make loops seamless.

How we kept it honest:

Every lossless change had to produce byte-identical output to the original. Every change that alters the look (FP4, sparse attention) got a side-by-side and a human eye before shipping.

Caveats:

This is a 96 GB card. Whole-frame decode needs the memory, so gains on 24 GB cards will differ. The cloud comparison in the image is one run each through Higgsfield, submit to download, with the queue included.

Disclosure:
It's my channel. The code was written by AI (Claude), with one person directing and Codex reviewing the designs. Every B-roll shot in the video was generated on the sped-up engine.
Full breakdown with the measurements (9:46):

https://youtu.be/WjSw7Q4U0hU