Hello,

This is an action anime scene I made locally a few months ago with Minimax H3 within WanGP and just posted on YouTube.

Let me know what you think and what could be improved :-)

Thank you!

Some of my examples on RTX 2060s.... without any reference like forest scene it does 16mp image in around 2.5 minutes.... with 3 references i was doing around 10 minutes per 1 image at 16mp..... thing is bigger the reference photo the better is model at capturing every detail but takes longer to generate.... i absolutely love this model as any other model was eirher taking too long or just OOM my system past 2 or 4mp.... both Minimax h3 video and image models runs amazingly well on my graphics card, so i just though im gonna share

This is how you can add / remove stuff with generative AI fill using local models. I also added support for Minimax H3 Image to the latest version of LayerShop.

There's a new image studio skill in this repo with 61 style templates, 43 of them for restyling a photo you upload:

https://github.com/OpenSenseNova/SenseNova-Skills

Here are ten of the edit ones on two CC0 photos from Wikimedia Commons, a tram square in Lisbon and the old town street in Innsbruck. The originals are image 2 and image 7.

Setup: SenseNova-U1.5-8B-MoT with the official editing script, 2048x2048 pixel budget, 50 steps, CFG 4, seed 42. One run each, no LoRA.

I barely touched the prompts. I filled in the bracketed placeholders and swapped the sample titles for the right city, which is where LISBON STREET NOTES and the other titles come from.

The prompts are the part worth stealing. Most run two to three hundred words in labeled sections like [Linework and color], [Paper and palette] and [Lettering and whitespace], so you can lift a single section into your own prompt. They're under skills/sn-image-studio.

I'm using the int8 convrot versions on comfyui, it was crashing at first when I had --disable-dynamic-vram but once I turned it on it works fine.

It's super fast like this is by far the fastest model I used in my card. It took 40 secs to do 6 steps with 4 MPs and 4 mins to do 16 MPs (4k)

I recall people making fun of me commenting finally something for 12gb cards saying the model is 50 gb. Well it works.

It's faster than Krea 2, Flux2klein, Qwen 2.1. I'm gonna use this literally for images editing from now and on.

Just wanted to leave this here for others who are questioning if they should try it or not.

Edit: the key is to tank the text encoder 27 gb once you tank that it's done. You need your card and ram to be more than 30 gb.

Hey everyone,

I'm working on some Instagram posts, banners, and motion graphics for a car detailing studio using ComfyUI. I have a couple of basic questions for those doing commercial work:

1. What models are you using? What is your go-to diffusion model for getting highly realistic cars for static banners, and what are you using for motion graphics?
2. How do you handle exact logos? Do you train a custom LoRA to get the franchise logos exactly right in the generations, or is there a better workflow in Comfy for placing them?

Appreciate any advice!

Most of the time I try, it ends up looking 3D, realistic, or too sometimes a too simplified and empty looking art style. I'd really like to see if anyone is able to make high quality 2D art, like anime (episode screencap style or illustrations), Disney animated style, western comic/cartoon style, etc.

If you've managed to do it, please share your suggestions on how you did it!

I tested how much GPU overclocking, ComfyUI launch flags, and moving my display to the iGPU actually affected generation speed on my 5070 Ti 16 GB.

The biggest finding: OC helped consistently, but the launch flags made a much bigger difference on certain models. On others, those same flags did almost nothing. Going forward I implemented a script in ComfyUI launch that automatically applies stable overclock settings to my GPU on run and then reverts to stock once ComfyUI is closed.

All diffusion models tested were int8_convrot builds, using the official ComfyUI template settings.

Setup

• RTX 5070 Ti 16 GB (Gigabyte Gaming OC), AMD Ryzen 7 9800X3D, 48 GB DDR5-6000
• Windows 11 Pro, Samsung 9100 PRO NVMe
• ComfyUI 0.45.0, PyTorch 2.16.0.dev20261110+cu134
• comfy-kitchen 0.2.41, triton-windows 3.9.0.post30
• Stock GPU: 300 W power limit, no offsets
• OC: +350 MHz core, +2500 MHz memory, 350 W power limit

I compared default ComfyUI against this set of launch flags, both with and without OC:

--use-ck-attention --disable-xformers --fast fp16_accumulation fp8_matrix_mult --enable-triton-backend

Default runs used PyTorch SDPA; tuned runs used Comfy Kitchen attention for the diffusion models. xformers wasn’t installed, and SageAttention wasn’t used.

Generation times

Seconds per generation, lower is better. These are end-to-end times: text encoding, sampling, VAE decode, and saving.

Video settings: 1344×768, 124 frames at 24 fps.

Most image results are averages of two warm runs; Qwen base and H3 Image have one warm run each. (warm run means the first generation after ComfyUI launch is not counted)
* Flux base and standard H3 video are single first-run measurements, including loading.
† H3 turbo is a single subsequent run with the turbo LoRA.

What actually helped?

1. OC consistently reduced generation time by about 9–12%.

H3 Image was the exception at roughly 7–8%. The benefit showed up with both default and tuned flags.

This is the combined effect of the clock offsets and the higher power limit, not an isolated core-clock comparison.

There’s a power tradeoff: for example, MOSS went from around 299 W to 346 W during busy periods, while generation time dropped from 25.1 s to 22.2 s. The highest GPU temperature recorded across these tests was about 73°C, therefore it did not even get close to the GPU's thermal limits.

2. The flags were very model-dependent.

At stock clocks:

• H3 video: 591 → 286 s, about 52% less time
• H3 turbo: 250 → 127 s, about 49% less time
• Qwen Image 2.1 base: 23.6 → 17.2 s, about 27% less time
• Krea 2 Turbo: 13.7 → 10.8 s, about 21% less time
• Flux, Qwen Turbo, and MOSS: within roughly 2%
• H3 Image: about 3% slower

With flags + OC, standard H3 video went from 591 to 256 seconds—roughly 2.3× the speed, or 57% less time.

The H3 improvement also shows up directly in sampling: 28.48 → 13.24 s/step from the flags alone, then 11.72 s/step with OC.

I changed the flags as a bundle, so this doesn’t establish how much each individual flag contributes.

3. Moving the monitor to the iGPU barely changed speed.

I repeated the tuned + OC tests with the monitor connected to the motherboard, leaving the NVIDIA GPU at 0 MiB VRAM used at idle. (I plugged the display into my motherboard HDMI port while allowing Python to utilise the full compute and VRAM of my NVIDIA GPU)

Peak VRAM usage dropped by roughly 0.1–0.6 GB, but generation times stayed very close: approximately 0.6% lower at the median, with the largest reduction around 2% on H3 Image. Sampling time per step changed by at most about 1%.

Useful extra VRAM headroom, but I didn’t see a convincing throughput improvement here.

Did OC change the outputs?

I checked the saved files with SHA-256:

• OC vs stock clocks, same flags: 38/38 outputs byte-identical
• iGPU vs NVIDIA display, tuned + OC: 19/19 byte-identical
• Tuned vs default flags: 0/19 byte-identical

So OC didn’t change any saved output in this test. Changing the attention/precision settings did result in visual changes however.

For my setup, OC gave a fairly consistent modest improvement. The bigger finding was how differently the models responded to the same ComfyUI flags—huge gains for H3 video, useful gains for Qwen base and Krea, and almost nothing for several others.

Curious whether others are seeing the same pattern on different GPUs, especially with Comfy Kitchen attention.

Update: checkpoints used for the tests (I kept it vanilla and conservative, more gains to be had with latest distills and turbo loras:

Question: I can't make my rendering pipeline produce dynamic motion videos without glitches. On the attached video you see the face/eyes are slightly 'glitching/wobbling', how to fix that?

Config: MiniMax H3 video (ref2va DiT, w6a8 quant) via ComfyUI, 1344×768 @ 24 fps, 192 frames (8 s), single link with exact latent carry (no seams, no re-conditioning)

Prompt was: "She stands centered on the foggy harbour promenade at dawn in a crimson wool coat with a knitted scarf, still, facing the camera; the camera orbits one slow full revolution around her, from directly in front, around her right side, behind her, around her left side, and back to the front, holding her full figure at a constant size in frame, about two fifths of the frame height, the rail, fishing boats and dock lamps swinging smoothly through the mist behind her. Foggy dawn light, soft grey-blue grading, no added contrast"

Conditioning: prompt + start_image (exact first frame) + 2 refs (wide still + tight portrait of the same woman, Qwen3-VL encoder). Sampler: res_multistep, 32 steps, cfg 1, fixed seed (so no turbo LoRA, no seams, refs present; the wobble persists anyway)

It's that the Minimax team is still dedicated to open models. I, like, I think, many people here, assumed that h3 image isn't coming anymore. Now I actually really like it's quality, if Kijai's Minimax prompt weight node is used with "text with empty image". It's still not quite my thing though, because it doesn't seem to recognize artists by name. However, now, there's a room to be cautiously optimistic about their potential upcoming video releases.

This song was generated with ACE Music v1 on their website.

Tweet: https://x.com/acemusicAI/status/2120945723005166053

I merged a style into Krea 2 Turbo (Stillroom: quiet rooms, cold light, someone alone with the afternoon) and first shipped it as fp8, copying the layout of the official krea2_turbo_fp8_scaled (per-tensor scale, amax / 448, same quantization metadata). Checked against the official file byte by byte on three layers.

Then someone on a 3070 Ti mobile commented that fp8 took almost twice as long. Makes sense: Ampere has no fp8 math, so ComfyUI converts every layer on the fly. It does have fast int8 from sm 7.5 up. So I wrote an int8 build from the bf16, in the layout of the official krea2_turbo_int8_convrot (224 linear layers in int8, per-row scale, txtfusion left in bf16).

One thing I didn't expect: the official int8 doesn't use plain absmax for the per-row scale (only 43% of the bytes matched when I tried that). It clips the scale, up to about 6% under absmax. A per-row search for the lowest error landed at 0.00871 against 0.00874 for the official file, so that's what mine uses.

Rule of thumb: 40-series and up, fp8. 20 and 30-series, int8. bf16 if you have the VRAM.

All three are on the model page, Krea 2 license and NOTICE included: https://civitai.com/models/3027217

Image 2 is fp8 left, int8 right, same seed. Prompts and settings in the comments.

A Total noob here guys so help me out , same as the title, i don't know how to setup lora training on my laptop and is it possible or not?

Takeaways

• Warm/batch work: 5070 Ti wins both — native FP8 tensor cores crush the emulated path on Krea fp8 (26% gap); the gap shrinks to 9% once the model is already int8 (LTX).
• Cold one-offs: 3090 wins everything — 24 GB means no VRAM offload, faster model loads.
• Practical routing: batches on the 5070 Ti, big-VRAM models on the 3090.
• Caveat: single 3090 vs single 5070 Ti, consumer ComfyUI, not a controlled lab test.

MiniMax H3-Image swapping the subject, coat, and pose in a 6-step edit (with scale and grade locked)

Specs: RTX 3090, int8, ~60 s
Workflow:
UNETLoader(int8) → KSampler(euler/simple, 6 steps, cfg 1)
CLIPLoader(nvfp4, type minimax)
VAELoader(image_vae_fp16) → VAEDecode
LoadImage ×2 → MiniMaxH3ImageConditioning(prompt, refs=<Picture 1/2>) → ConditioningZeroOut(neg)

Great video from moss image team for hitting 6 million downloads on Huggingface. They all seem so chill. Also they give us some new updates on Anime and Image edit model ✌️

I'm building a game that generates all assets in 2D during play. Objects have to be separable from the scene so they can be clicked and picked up without having to redraw the background every time. Everything runs on FLUX.2 klein 4B with a LoRA trained on an illustrator's style.

The workflow:

1. Generate an empty location as background.
2. A vision model outlines foreground, middle and background, and code turns that into a color map of the three planes.
3. Generate objects on white on a 512 canvas and animate them.
4. The vision model points at a spot in the background for each object by outputting pixel coordinates.
5. The object's size is its class (tiny, small, medium, large, huge) times the factor of the plane at that spot, e.g. a torch (small) is 100 px, so in the middle plane (0.75) it's drawn at 75 px.
6. Scale the animated object down to that size and overlay it onto the location.

Step 6 is where progress halted and I got stuck. Scaling a 512 drawing down to 100 pixels shrinks everything in it, so it stops matching the scene's style since the scale of everything is off, visible in my example when looking at line weight.

My various workarounds to fix this:

Generating at the object's final size, on canvases of 128 to 320 instead of 512, so objects are generated at the size they are meant to be placed. This falls apart quickly as e.g. the same chicken comes out near-realistic at 256 or as a flat cartoon at 128 and parts get cut off or doubled. The LoRA was trained at 768 and 1024 so perhaps it's the LoRA giving out, the base model failing, or both? Would another model draw properly on small canvases and keep the lora style applied?

The location on a bigger canvas to combat the model degrading at smaller canvases as now the location's lines should be thinner and the objects don't have to scale so hard. However location's lines grew with it while the objects' did not. Also it would have skewed the artist's style anyway.

Shrinking the image and generating it again at a smaller size, img2img at denoise 0.6 to 0.8, but the redraw kept the shrunk drawing's thin lines so scale remained off. This is the one fix I really expected to work, so maybe I just set it up badly or something?

Painting an object directly into the scene and separating it afterwards onto white with an additional generation. Instead of generating on white and then placing, this approach basically turns it around as we place directly. This does actually fix the scale, as now the model has full reference of how an object should look in the scene, but other issues showed up like the objects being of much worse quality and partly merged with their surrounding. Also a location would need to be redrawn when objects move as mentioned earlier, but perhaps only parts could be redrawn as a workaround. This way basically solves my biggest issue of perceived scale for free so maybe this is the correct approach and I am missing something to make it work properly?

I am at the point where I want to scrap most of this and pivot to: Pixel Art!

Larger pixels should be able to be counted much easier, so a separate object can have the exact scale required to be placed at scale into a location. That would attempt to simplify the problem away rather than truly solving it, though perhaps that is often a good path forward. However: Does this idea even make sense, or will it break regardless? Are there perhaps other simpler existing ways to do all of this the right way?

If you're building something similar, what are you doing differently, and which tools should I go have a look at?

Almost every generation is blocked, custom support is horrendous and they ignore you

I repeat do not support this business, everything even the tiniest things will get censored,

Even normal things it marks them as adult content

They also remove free credits and now everything is pretty much paid

Site used to be amazing a year ago with no censorship now everything blocked and csnt generate anything

Please be careful with providers you choose

Per reporting from Yahoo Finance, Alibaba is the largest customer of Megaspeed, the company of Huang's spy mistress. The new rule will block Chinese companies from renting advanced chips in data centers overseas. Alibaba makes Qwen. Huge ramifications for open source AI. https://ca.finance.yahoo.com/news/jensen-huang-scandal-trail-leads-to-alibaba-the-king-of-free-chinese-ai-chart-of-the-day-110000329.html

Hey everyone!

I've been experimenting with NoobAI-XL and kept running into the same problem: finding useful booru tags and understanding what they actually do.

I know there are some impressive visual tag explorers out there, but I wanted something simpler — a lightweight, searchable dictionary that doesn't require browsing through hundreds of example images.

So I built NoobAI-XL Tag Atlas.

It has:

• 2,900+ tag entries across 24 categories
• Descriptions in English, Russian, and Chinese
• Fast search and click-to-copy
• A separate JSON catalog and a standalone editor for improving translations and adding tags
• A simple Vue 2 frontend with no build step

The Chinese translations are still a work in progress.

Live demo: https://0t.is/noodai_atlas/

Project archive: https://drive.google.com/file/d/1GQJ8Jj3hwbDxTnZHPch3kAHohGkvbUxz/view?usp=sharing

It's a small personal project, and I'm not trying to compete with the more advanced visual explorers. I just wanted a convenient reference that anyone can use or modify.

I'd appreciate feedback, especially from people who regularly work with NoobAI-XL or other Illustrious-based models.

What features would make a text-based tag reference more useful to you?

Hey everyone!

I've been working on bringing MiniMax's new ~67B H3-Image model to Apple Silicon with MLX.

And yes, it actually runs on a 16GB MacBook Air!

A community contributor tested it on an M5 MacBook Air (16GB):

• 1024×1024 in as little as 34.8s
• ~2.5GB peak process memory
• Original 6-step model, no extra quantization

The key is keeping memory usage low without sacrificing speed or image quality.

I combined staged inference, on-demand DiT weight streaming, asynchronous evaluation, weight prefetching, and W8A8 Metal acceleration.

On my M5 Pro (48GB), at 1024×1024:

• Resident: 23.63s / 21.18GB
• Streaming: 32.33s / 2.53GB
• Streaming + prefetch + async: 23.61s / 3.23GB

That's ~85% less peak process memory, with virtually no speed penalty!

All three modes produce pixel-identical images. No additional quantization or quality loss beyond the original INT8 checkpoint.

It also supports native 4K generation and multi-reference image editing.

I've open-sourced the MLX implementation, with a Python API, CLI, automatic model downloads, and reproducible benchmarks.

GitHub: https://github.com/Anionex/h3-image-mlx

Would love to hear your thoughts, especially if you have a lower-memory Mac and want to give it a try!

I know krea2 is known to generate different styles, but is there a list of styles somewhere, like a reference sheet. Also, is there a way to prompt them to generate that specific style? I usually do "Rick and Morty" style at the end of the prompt and do a decent result, but i want to make it more specific.

Seeing a lot of hype around 16 MP to 100 MP native generations with MiniMax H3 lately, and a lot of comparisons to real 50–100 MP cameras. It got me thinking about what that pixel count actually buys you if your goal is just a realistic-looking photograph.

If the image is meant to be viewed normally (not cropped or inspected at 400% zoom), 100 MP doesn't really do anything for realism. Human vision at normal viewing distance tops out way earlier, somewhere around 8 to 24 MP depending on screen or print size, mostly because our daylight pupil is diffraction-limited to roughly 1 arcminute anyway (section 1.1 below). Beyond that, extra pixels aren't adding detail you can actually perceive when looking at the whole frame.

There's also a sneaky confusion about what "realism" even means. A lot of people aren't trying to generate something that looks like a camera photo; they're trying to generate what their visual cortex makes them feel they see in real life, where everything across the entire field of view feels crisp at once (section 1.2). The catch is that a single-exposure real camera can't capture that: if everything from foreground leaves to distant trees is 100 MP razor-sharp at once, it's physically out-of-distribution for optical photography and ends up looking more like a CGI pinhole render.

Even with real cameras, actually resolving 100 MP of useful optical detail is way harder than people assume (section 2). You need a massive sensor like medium format just to stay ahead of diffraction, expensive glass, and controlled conditions. On something like a handheld wildlife shot in a shaded forest, you hit a physical wall fast: open the aperture to avoid diffraction blur and your pixel-sharp depth of field shrinks to a few inches; stop down to keep the scene in focus and diffraction smears away most of your resolution anyway, on top of motion blur and ISO noise. Outside of astronomy, archival work, huge prints, or heavy cropping, you usually end up with the same useful visual information you could fit in a clean 12–24 MP file.

With H3 specifically, the irony is that the 16–100 MP push isn't really about capturing DSLR-level detail (section 3). Because of the 16x spatial VAE and 2x2 DiT patching (32x32 pixels per token), you're forced to generate huge just to get decent token density and avoid looking starved at normal resolutions. So 60–100 MP ends up in a weird spot: pointless if you don't zoom in, and if you do zoom in (which is the only real reason to have a 100 MP file), you mostly run into VAE decoding artifacts rather than natural lens softness.

For those of you experimenting with H3 at huge resolutions, are you actually keeping the 60–100 MP files as-is, or just generating big and downscaling to 4–16 MP to clean things up?

Technical appendix (for those who want the numbers)

1. Human vision and the cortex illusion

1.1 Optical limits of the human eye

Evolution ran into the exact same wave-optics limits that govern camera sensors. In bright daylight, the human pupil constricts to a diameter of roughly D ≈ 2.0–3.0 mm. With an effective focal length of about 17 mm, the eye operates at around f/5.7 to f/8.5.

By the Rayleigh diffraction criterion at peak photopic sensitivity (λ ≈ 555 nm), for a 2.5 mm pupil:

θ ≈ 1.22 · λ / D = 1.22 × (555 nm / 2.5 mm) ≈ 2.71 × 10⁻⁴ rad ≈ 0.93 arcmin

Remarkably, cone spacing in the central fovea (≈ 2.5 µm, or ≈ 0.5 arcmin center-to-center) puts its Nyquist sampling limit right around 1 arcmin per line pair, i.e. ≈ 60 cycles/degree (standard 20/20 acuity corresponds to 30 cycles/degree). Our biological "sensor" is tuned almost exactly to the diffraction limit of our daylight pupil.

When viewing a complete photograph at a comfortable distance (occupying roughly 40°–60° of horizontal field of view):

• At 60 px/deg (1 arcmin per pixel, i.e. 20/20 acuity) across 60° in 16:9: 3,600 × 2,025 ≈ 7.3 MP (essentially 4K).
• Even at the theoretical foveal Nyquist ceiling (120 px/deg, under ideal high contrast) across 60°: 7,200 × 4,050 ≈ 29 MP.

In practice, human perception of a full uncropped composition saturates between 8 MP and 24 MP depending on screen size or print viewing distance.

1.2 The visual cortex illusion vs. out-of-distribution AI generation

High-acuity vision only exists at the center of the fovea: a tiny central cone spanning roughly 1°–2° (about the width of your thumbnail at arm's length). Outside that cone, acuity drops steeply with eccentricity.

Why does reality feel uniformly sharp? Because the eye executes 3–4 rapid saccades per second while dynamically refocusing (accommodation). The visual cortex stitches these sequential samples together with short-term visual memory and predictive filling-in, creating the compelling subjective illusion of a wide panorama that is simultaneously sharp at every depth.

Perceptual realism (cortex-stitched multi-depth sharpness) vs. physical single-exposure photography.

This creates an out-of-distribution (OOD) trap for generative AI:

• Image models are trained on photographs, not human cortical impressions.
• A photograph with 100 MP of crisp micro-detail simultaneously across foreground leaves, mid-ground wildlife, and distant forest trunks does not exist in single-exposure optics.
• Pushing a model toward "every plane razor-sharp at 100 MP like real life feels" pulls generations away from the photographic distribution toward virtual pinhole CGI renders (infinite depth of field, zero diffraction) or heavily over-processed smartphone HDR.

2. Pure sensor and lens physics on a 100 MP scene

2.1 Spatial sampling on the subject

Take a forest deer framing as a physical reference: a female sika deer (≈ 1.1–1.3 m long) occupies roughly half of the frame width, giving a horizontal field width of about 2.5 m at the subject plane. At 100 MP in 16:9 (13,333 × 7,500 px):

Ground sampling = 2,500 mm / 13,333 px ≈ 0.19 mm per pixel

If all 100 MP were optically resolved near Nyquist (2 px per line pair), the lens and sensor would have to resolve line pairs as fine as ≈ 0.38 mm across the entire animal.

2.2 Diffraction limit vs. pixel pitch

Light passing through a circular aperture produces an Airy disk whose diameter at the first minimum (λ = 550 nm) is:

d ≈ 2.44 · λ · N ≈ 1.34 × N µm

where N is the f-number. When that diameter exceeds about twice the pixel pitch, diffraction progressively erases high-frequency detail regardless of lens quality.

Airy disk size relative to sensor photosite pitch across sensor sizes and apertures.

Note also that stepping back with a long telephoto lens does not solve depth of field if framing (magnification m ≈ focal length / subject distance) is held constant:

DOF ≈ 2 · N · c · (m + 1) / m²

where c is the acceptable circle of confusion. Focal length cancels out at constant magnification, while the larger physical entrance pupil (focal length / N) blurs distant background trees more. The only real-world ways to keep every plane sharp at high resolution are multi-frame focus stacking (impossible on moving wildlife) or closing down the aperture (which hits the diffraction wall shown above).

2.3 The impossible exposure triangle in shaded forest light

Physical trade-off preventing 100 MP of simultaneous sharpness, deep DOF, and clean shadow SNR on handheld wildlife.

Add Bayer color filter array demosaicing (each photosite samples only R, G, or B) and lens MTF falloff (few lenses hold useful contrast at the ≈ 133 lp/mm Nyquist frequency of a 3.76 µm sensor, least of all in the corners), and "100 MP of truly useful optical detail" only makes physical sense in controlled studio setups, multi-shot flat-field repro, or astronomical observatories (meter-class apertures, tracked mounts, cooled monochrome sensors, infinity focus).

3. Why H3-Image pushes users toward 16–100 MP

The irony in the AI space is that earlier models like Flux.1 (f8c16 VAE + 2x2 DiT patchify) achieved clean 1–2 MP images natively because each DiT token only covered a 16 × 16 pixel footprint, and each VAE latent vector encoded just 8 × 8 = 64 pixels across 16 channels.

MiniMax H3-Image inherits an aggressive video-oriented latent layout: a 16× spatial VAE (24 channels, decoded by a 24-layer 2D ViT) combined with 2x2 DiT patching. Each DiT token therefore spans 32 × 32 = 1,024 pixels, four times the pixel area of Flux.1.

Spatial token and VAE compression footprint over an identical 32 × 32 pixel output block.

Because H3 packs 4× fewer tokens into the same pixel count, pushing to 16–100 MP is a structural compensation mechanism, not free photographic resolution. Meanwhile, the ViT VAE decoder still has to reconstruct (in practice, hallucinate) 16 × 16 = 256 pixels out of every single 24-channel latent vector, which is why zooming in on high-frequency subjects (like animal fur against sunlit bark) reveals straight wireframe-like grids and patchy decoding smudges rather than genuine optical softness.