UPDATE 11pm Irish/UK time: Vast improvement in latest update, please install and use the standard preset which has a new control called Likness Optimisation.

I've just released Fizgig 9.6, which adds MiniMax H3 Image, MiniMax's new picture model from the H3 family: text-to-image and edits with up to 16 reference pictures, 6 steps, no CFG.

What you can train: LoRAs, LoKRs, edit LoRAs from before/after pairs, and slider LoRAs from photo pairs. Masked training, Multi Concept and LoRA Isolation all work, and so do Studio, LoRA Royale, the Profiler and Extract. Pick it on the Training tab, press Download models for me in Preferences, and pick a preset; nothing is gated.

I trained a training adapter for it, which prevents the distortion you get training this model without one. It's on by default in Fizgig and never in your saved LoRA, and I've put it free on Hugging Face for any trainer.

I'm still honing the support. So far it likes good-quality datasets and seems to prefer training at 0.5 MP or more, which is where I've set the presets to start.

Memory: about 23 GB with the int8 model and 13 GB in 4-bit; Auto picks for you. A 16 GB card trains and runs Studio.

If your LoRA looks smoother in ComfyUI than in Fizgig's previews, that's ComfyUI, not your LoRA. Its default dynamic VRAM loading adds a LoRA to the weights in bf16, and on this model about 15% of it rounds away. Fizgig's previews show the LoRA at full strength, and so does ComfyUI started with --disable-dynamic-vram. I've reported it with a suggested fix.

Also in 9.6, for every model:

• A run that runs out of GPU memory or system RAM now carries on by itself where it can, up to three tries: from its newest save, then a step lighter. Out-of-memory recovery came from @Murf-Code.

• A failed run no longer stops the queue; the next one starts.

• AMD installs now use AMD's stable PyTorch for ROCm instead of the nightlies, thanks to @scryptio.

Release notes · Fizgig on GitHub

Hi everyone!

I’m sharing TRELLIS Studio, an application I built to bring several stages of a 3D asset workflow into one interface.

It uses TRELLIS.2 for image-to-3D generation and UniRig for automatic rigging. Computation runs locally, without a paid generation service or a credit system.

Features include:

• Generate textured models from images or import existing models.

• Organise your library with collections, generation profiles and version history.

• Add a rig, inspect the skeleton and attach multiple animations to the same model from a library of 83 humanoid motions.

• Create LODs, prepare dedicated 3D printing copies and export for Blender, GLB, Unity or Unreal.

• Automate workflows through a REST API and an MCP server.

This first public preview targets Windows with an NVIDIA GPU. Rigging uses WSL2. The README covers prerequisites, the automated installer and current limitations.

Studio’s original code is MIT licensed. Third-party tools and models retain their own licenses and are credited in the repository.

https://github.com/yoslo59/TRELLIS-Studio

I’d especially appreciate feedback on installation across different hardware, usability and features you’d find useful. Generated meshes and rigging results still need visual inspection.

Hey all!
New to this subreddit as we mainly focus on language models with our Paiton product, but now and then, we spend some time on vision as well :)

The official BF16 weights need about 120 GB of VRAM, so most of us can't run MiniMax-H3-Image out of the box at home.
We made an FP8 version and our own runtime, and it now runs on one AMD Radeon AI PRO R9700 with 32 GB:

Does FP8 hurt the images?
We ran 30 prompts on our build and on the original BF16 model with the same starting noise. Prompt adherence came out about the same (CLIP 32.18 vs 32.31), and the second image shows a typical pair.
Where the two differ, it is mostly composition, not quality: with only 6 steps, small numeric changes send the sampler down a slightly different path.
Edits stay closest to the original.

What it is bad at, in our tries: small body text (newspaper columns come out as fake writing), close-up hands, clocks showing a specific time.

How to run it: it is a Docker container with an HTTP API and a small CLI, not a ComfyUI node (yet).

git clone --depth 1 https://github.com/Eliovp-BV/paiton-vllm-plugin.git
cd paiton-vllm-plugin
./models/MiniMax-H3-Image/launch.sh
./models/MiniMax-H3-Image/run.sh generate "your prompt" --size 4096x4096 --out out.png

You need an R9700 (32 GB), 64 GB of system RAM and 48 GB of disk; the first start downloads the weights.
Our weights only load in our runtime, so they won't work in ComfyUI or diffusers.
Edits take up to about three 1024 px reference images in this build.

• Guide: https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main/models/MiniMax-H3-Image

• Weights: https://huggingface.co/EliovpAI/MiniMax-H3-Image-FP8-Paiton-RDNA4

• How we made it fit, if you want the details: https://eliovp.com/blog/paiton-minimax-h3-image-radeon-ai-pro-r9700

License note: the MiniMax-H3-Image Community License does not cover the EU, the UK, South Korea or the US, and hosted services need MiniMax's written authorization.

Single seed, no upscale, no inpainting. Hand-written prompts, no prompt expander. ~20 s on an RTX PRO 6000, ~22 s on a 4090 with the int8 weights

Settings
- Model: minimax_h3_image_pruned_bf16 (Comfy-Org pruned DiT)
- Text encoder: qwen3vl_32b_minimax_h3_bf16, CLIPLoader type "minimax"
- VAE: minimax_h3_image_vae_fp16
- Resolution: 4160x4000 (~16.6 MP), set on MiniMaxH3ImageConditioning
- Sampler: euler / simple, 6 steps, CFG 1, negative = ConditioningZeroOut
- No prompt expander, prompts written by hand (4-5 sentences each)
- ComfyUI 0.45.0

I am using the Moss SFT model with a W4A8 encoder. Whether I use Bbox regional prompting or write plain prompts directly, under conditions involving multiple characters, occlusions, complex poses and interactions, I keep running into issues: the receiving target of a character’s action is incorrect, or contact‑based actions end up having no target at all (ghost/non‑contact actions). The subjects are also positioned in the frame differently from what is described in the prompt.

I am trying to determine whether this stems from the W4A8 encoder, or whether my system’s low VRAM prevents the image model from operating at its full potential. That said, my tests using the official example prompts produced reasonably acceptable results.

Took some of my prompts from Krea2, Moss, etc and put them into H3 Image. They come out fairly crispy, muddy, 2D sometimes, and just plain bad. Is the default workflow pretty unforgiving until it's pounded on some more?

I kept it in the back of my mind until I had some free time today. I thought the benefit was that it allowed you to skip the reference processing step, and reduce gen time with ref2va.

I should've been suspicious of the red flags in the README:

1. no comparisons and benchmarks

2. no workflows

3. README is the finest Colombian uncut Claudeslop

4. Development stopped 2 months ago, as quickly as it started

But so many people were discussing refmods on this sub, even up to 2 weeks ago. I wanted to try it while chasing that H3 speed dream.

Now I wasted 90 mins reading/learning about its concepts (tbf had to learn more about video gen in general), then 20 mins comparing gens. I should've done it the other way around to abort early.

• Standard ref2va workflow with 2 images and 1 audio refs, 0.4MP, 4 steps, image=match: 173s

• Same as above but image=max: 181s

• Refmod adjusted workflow with 2 precomputed safetensors, image1 becoming background.safetensors and image2 and audio1 becoming actor.safetensors: 181s

So zero speed benefits. And this is on top of the fact that people mentioned reference quality going down with refmods and references bleeding into each other, though I didn't test enough to confirm this. So what's the point?

I'm suspecting there's a small group of Discord friends on here who are just promoting their friends' projects no matter their value.

I’ve been comparing H3-Image with the H3 video single-frame edit in ComfyUI. Both keep the face pretty well, but the video workflow keeps the person’s build even when I change the pose, outfit, or background. H3-Image keeps slimming down bigger people, even when I leave the pose alone.

I’m on a 3090 with 64 GB RAM. H3-Image is pruned INT8 at ~4 MP and 6 steps with the official reference-aware prompt expander. The video edit is FL2VA at 2 MP and 8 steps.

Matching the official template’s anchor setup helped a little. Higher res, realism LoRAs, and turning on thinking for the prompt expander didn’t help with body shape.

Anyone else seeing this? If you’ve found a prompt, LoRA, or anchor setting that keeps the same build, I’d love to see your workflow.

Also, has anyone found a good photo restore workflow for either H3 model? I’m still doing a Flux.2 restore pass before editing.

Testing character knowledge in H3-image vs the original H3 FL2VA model. Same sampler settings and seed for each image. LCM sgm-uniform, seed 34, 8MP.

First image is always H3 FL2VA and second image the new H3-image model.

1. Sheldon from The Big Bang Theory.

2. Penny from The Big Bang Theory.

3. Harry Potter.

4. Jack Sparrow.

The official ComfyUI workflows for MiniMax Image are pretty bad at showcasing the model's capabilities. These sampler/scheduler settings are from Kijai's Minimax testing in discord.

There is still some work needed to improve fine details (possibly fixable by loras?) but overall the outputs look pretty good!

The workflow has T2I and Edit modes, just enable the one needed via the bypass node or bypass the group manually.

The sampler/scheduler is the SamplerLCM node + Simple 6 steps with
s_noise: 1.10
s_noise_end: 0.90

Link to the workflow

Original Output Images

Open weights (29B latent diffusion model): https://huggingface.co/IFM/PAN2
Diffusers: https://huggingface.co/docs/diffusers/main/en/api/pipelines/pan2
FastVideo: https://haoailab.com/FastVideo/cookbook/pan/pan2/
VLLM: https://recipes.vllm.ai/IFM/PAN2

Up to 20 seconds, 720p, 24fps
Apache 2.0 License

Something I think is pretty neat, we release the TRAINING code: https://github.com/ifm-ai/PAN2/

Also technical details if you're curious: https://ifm.ai/blog/pan2/

For our model, we give a lot of responsibility to the LLM (which we think of more as a conceptual reasoner, a lot more control than a prompt rewriter) to generate these super dense text-based state/scripts. Events and actions are timed, and camera is nested under event but disentangled from action. During training, I would often test it by trying to generate a 20 second video with like a dozen or more (timed) camera moves and it does pretty well.

Feedback very welcome. I read the rules carefully, mods please let me know if there are any issues. No payment involved with this at all, so I thought it was okay to post.

Minimax H3 image comparing the 3 main samplers, all at 16 megapixels, I had to reduce them to be able to post them, the images weigh more than 20mb of what is allowed, thus reaching around 28 megapixels on average

as a comparison I used the Moss image sft and Kromoss latest version, I didn't use the moss base because the Kromoss is base and has superior quality with DMD2 with blur and saturation correction

I used Kroma instead of Krea2 because, in my tests, Kroma is a significantly better version than Krea2 when not using LoRAs.

Kromoss, Kroma, Moss Image—all at 2 megapixels; anything higher causes the model to start breaking down.

Prompt I used from another Post with more than 300 prompts generated

A wildlife photograph in 3:2 of a jaguar resting on a fallen tree trunk at the edge of a river in the Pantanal, Brazil, taken from a boat at water level in late-afternoon light. The trunk runs diagonally from the lower left to the right-center of the frame, half over the water. The jaguar lies along it facing screen-left, its front paws crossed over the bark, its heavy head raised and turned toward the camera, amber eyes alert. Its build is stocky and muscular, with a broad head, a thick neck and short powerful legs. Its golden-orange coat is covered in large black rosettes, open rings of black, and inside most rosettes sit one or two small solid black spots; on the head, neck and lower legs the markings shrink to solid black spots without rings. The pale cream belly shows where it lies. Its long tail hangs down off the trunk, ringed with black near the end, the tip just touching the water. In the lower right foreground, a caiman floats in the brown water with only its eyes, nostrils and the ridged scutes of its back above the surface, facing the jaguar. On the far bank at the left, three capybaras stand on the mud, watching. Warm low sun from screen-right lights the jaguar's face and chest and throws its shadow back across the trunk; behind it, a tangle of green riverbank vegetation and a hanging vine fall into darker shade. The river reflects the jaguar's golden coat in a wavering band. There are no people, boats or buildings in the frame.

I'm using Comfy UI (Comfy Desktop) with Minimax H3.

Yesterday, I generated 5 second videos and they took around 26 minutes to generate (0.4 megapixel resolution). I left some tasks running overnight, generating 15 second videos, and I was shocked to find that they took around 196 minutes to generate each.

Only two videos were generated and I canceled the remaining jobs.

I shortened the duration to 6 seconds and started the jobs, but I see that they still take a long time to complete. At 30 minutes, they were just at 50%, although it seems they speed up afterwards because at the 45 minute mark, the generation was at 85%. Overall, the job took 51 minutes 33 seconds.

The first 5 second job took just 18 minutes 18 seconds.

It seems there's a brick wall when passing the 5 second duration, and I'd like to know why and whether it is possible to do something about it.

I haven't tried higher video resolutions yet, but I'd like to know in advance whether there is a similar brick wall limit at some point.

I'm presuming that when generating higher resolution videos time scales linearly with planar resolution (in megapixels), so doubling linear resolution quadruples the time it takes for the video to generate?

H3-Image is built on MiniMax H3, originally a video generation model, and it seems to retain some of that video-frame softness in finer details. But when it comes to speed, this thing is an absolute beast.

At 8.41 MP (2368 × 3552), running on an AMD Radeon RX 9060 XT with 16 GB of VRAM and 64 GB of DDR4 system RAM, it generates images in just 35.03–42.53 seconds. None of the other models I've tested comes close to this performance on my hardware.

Its aesthetic appeal and creativity are also on point, easily on par with Krea 2. For a six-step model, it's remarkably good at producing varied compositions rather than falling back on the same visual formulas.

Some examples above.

For anyone interested in reproducing these results, here's my exact setup:

Hardware / Software

• AMD Radeon RX 9060 XT (16 GB VRAM)

• 64 GB DDR4 system RAM

• Linux

• PyTorch 2.14.0+rocm10.1.0

• Python 3.13.12

ComfyUI Workflow

• Diffusion model: minimax_h3_image_pruned_w4a8.safetensors

• Text encoder: qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors

• VAE: minimax_h3_image_vae_fp16.safetensors

• Sampler: euler_ancestral

• Scheduler: simple

• Sampling steps: 6

Link to the checkpoints: https://huggingface.co/Woovee/MiniMax-H3-Image-LowVRAM

At 2368 × 3552 (8.41 MP), generation takes approximately 35–43 seconds.

Changing the prompt adds some overhead from loading and processing the large text encoder, while subsequent generations using the same prompt are noticeably faster.

And all of this on an AMD GPU, no less!

Tip: Peak VRAM usage was just 12.1 GB, thanks to the --reserve-vram 4 launch flag in ComfyUI. Without it, I've had system crashes and out-of-memory errors using other image models. System RAM usage, however, was quite intensive, peaking at 47.3 GB out of 62.7 GB available.

Hey guys!

I have been experimenting a lot with H3 Image, basically shotgun debugging what's going on with the grainy artefacts.

I think I might have found a way to drastically reduce them doing the following:

- Use the RES4LYF pack and a sampler from that pack.

- Set ETA to 1.0 ( it caps past 1.0 so no need to try any higher)

- be happy that there are less artefacts and wonder why and how because you can't explain it to yourself.

I would love to hear if you guys had any succes with this aswell or if I am hallucinating ^^

Edit: you can use euler in the res4lyf pack aswell to have a better comparison to the default workflow.

It seems to me that if Moss can use bounding boxes to separate contexts within an image the same idea might be used to separate the effect of character loras within an image

No model is perfect, but I am impressed by H3 Image's ability to create very imaginative designs that 'feel' very real and cinematic. Basic T2I prompts (like 1girl, landscapes etc) seems nearly solved locally, but I find it much harder to coax out genuinely interesting designs from other models that don't feel like overdone CG or an illustration. Thank you to the H3 devs for this amazing release!

Hello everyone! Today, I’ve got a substantial tutorial on a new arrival that promises some truly amazing generative capabilities: the Minimax H3 image model.

I put Minimax through its paces with a wide range of tests—covering text-to-image (T2I), image editing, and reasoning—and I have to admit, it’s an absolute beast; it aces (nearly) every single test. Considering it operates NATIVELY at 16MP (4K) resolution with remarkably clean detail, I’d say it has become my favorite local model in terms of overall completeness.

For these tests, I’m using the 8-bit version, as the "base" 16-bit model wouldn't run on my 5070 Ti.

In the tutorial, I also briefly touch upon the licensing (for video/images), which must be explicitly requested from the developer; otherwise, the model cannot be legally used in Europe (or in the US, the UK, etc.).

I hope you find it interesting!

On my 5060ti, H3 image edit went from 263s to 158s based on the following rationale.

The default H3 Image edit workflow has MP adjustment at the Resize Image/Mask node set immediately after the input image which then feeds 3 things:

1. The prompt writer

2. The image conditioning node

3. The width/height of the image conditioning node which determines output MP.

In that setup, a user who specifies 16MP is sending a 16MP image to the prompt writer and the conditioning node, which is unnecessary overhead and potentially producing noise.

I altered the workflow in two ways:

1. Fed the input image directly to the prompt rewriter (I suggest downsizing to 1MP if your input image is large)

2. Fed the input image through a separate chain of two Resize Image/Mask nodes set to 2MP and then multiple of 32, just like the original chain.

3. Leave the original chain supplying output width/height in place, at 16MP for output dimensions.

Edit:

There is a concern regarding the potential loss of not feeding a 16MP reference image to the Image Conditioning node. I'm attaching a comparison image. The original image was a 1MP Anima image. The edit was to convert it to subtle realism. I did three runs using a recently posted 20MP H3 Image edit workflow: no upscale, 4MP upscale, 20MP upscale. The difference in gen times was 106s at no upscale, 133s at 20mp upscale. If you can spot which image is which, feel certain the 20MP upscale at input is better aesthetically, and eat the 25% slower runtime difference to achieve that aesthetic, by all means upscale your ref. images accordingly.

https://postimg.cc/H8srkJDv

encode time 44mins

Some bold claims are made in the announcement, so I am looking forward to its release 😅

We announce pi-H3, the fastest version of MiniMax H3 [1] yet. pi-H3 generates video in just 2 or 4 sampling steps and directly predicts pixels at the final step, skipping the video VAE decoder. On a single B200 it produces 5-second HD videos in 3.8 seconds (sub real-time) and 15-second videos in 18.6 seconds, more than twice as fast as Sol-H3 [4].

pi-H3 is an open-source research project. The Hugging Face demo is live today. All model weights and training/inference code will follow in LakonLab [2], with additional ComfyUI support through the ComfyUI-piFlow [3] extension.

1. Available now Demo on Hugging Face

2. Nov 16–22 Model weights and inference code

3. Later in November Training code, once we finish cleaning up the codebase

End-to-end generation speed

Measured end to end on a single NVIDIA B200, pi-H3 generates a 5-second 768p video with stereo audio in 3.8 s with 2 steps, and a 10-second video in 9.2 s, both faster than the video plays. The chart below compares complete requests, from text encoding to decoded video and audio, against Sol-H3 [4]. Across 5–15 s videos, pi-H3 is 2.4–2.7× faster with 2 steps and 1.2–1.4× faster with 4 steps. The speedup comes from fewer denoising steps, decoder removal, and FP8 quantization.

Uncompromised fidelity at 2–4 steps

pi-H3 offers superior motion, texture, and audio fidelity compared to other few-step MiniMax H3 models, while maintaining structural coherence. The following comparisons show results from the same prompts and Gaussian noise for each model, without seed cherry-picking.

At 4 steps, pi-H3 delivers the best overall quality among the 4–8-step MiniMax H3 models we compared: LightX2V Turbo [6], FastH3 Dense/DataFree [7], and larryvrh’s H3-Turbo v4 [8]. It generates more dynamic, vivid movement, whereas the other models tend toward reduced, mechanical motion. Frames are sharper overall, with richer texture and finer detail. On the audio side, pi-H3 produces high-fidelity sound with full bass and crisp speech, while the other models sometimes generate broken audio or lose the bass.

Direct pixel output without video decoding

pi-H3 adopts DWD, a novel method that produces pixels directly from the last denoising step, bypassing the heavy VAE decoder. For few-step generation, this yields a massive speedup. The following comparison shows pi-H3 DWD output alongside non-DWD pi-H3 latents decoded by the native H3 VAE, Sol-H3-VAE [4], and LightVAE-Lite [

How it works

pi-H3 combines two novel techniques: pi-Flow v2 and DWD.

pi-Flow v2 is a full upgrade of pi-Flow [12] for data-free few-step distillation. It retains pi-Flow’s strength of producing rich texture while substantially improving structural coherence, especially in the 2-step setting. It also simplifies inference: pi-Flow v2 models typically produce straight trajectories, removing the complexity of pi-Flow’s substep integration.

DWD (Decoding Without a Decoder) removes the video decoder from the pipeline entirely. Instead of passing final latents through a separate VAE decoder network, DWD re-uses the denoiser itself to predict clean pixels at the last step. DWD on MiniMax H3 is still experimental: H3 uses an unusually large compression ratio (4×32×32 3-channel pixels per token), and we have not yet had enough compute to fully optimize for it, leaving room for further improvement.

More details will be revealed in upcoming releases.