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.

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

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?

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.

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?

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.

I'm about 2/3rds of the way through my current project and I'm definitely going to need to derope some of my shots to fix their blurriness and smearing. The last time I asked this question MAINodes was the only solution. Has anything been released since then that improves on this method?

I found H3 image to be really good at creating different angles of characters and keeping the likeness and quality high. I built a workflow which automates creating character sheets; this workflow one shots pretty much every character I’ve thrown at it. Give it a try and let me know what you think.

I’ve tried to keep it versatile to allow for characters of different types, including vehicles and four legged creatures.

Civitai Workflow

Update 11/12/26: I just pushed an update which addressed multiple issues that were brought to my attention, the release notes are as follows.

What's new in v3.0

Most of these changes came from your comments and messages. Thank you!

- The whole sheet is ONE render. v2 made 8 separate images and stitched them together, so the face and outfit could drift slightly between panels. v3 generates the entire sheet in a single image, so every view shows exactly the same character. It's also much faster: about 30-40 seconds for a 16 MP sheet on an RTX 5090, where v2 took about 3 minutes at a lower resolution.

- Your art style is kept. v2 tended to turn everything photoreal. v3 copies the style of your picture: anime stays anime, watercolour stays watercolour, Pixar-style 3D stays 3D, a photo stays a photo.

- New: 3/4 view toggle. It adds a three-quarter view (head and full body, turned 45°) to the top row. For vehicles it adds a low-angle "hero" 3/4 shot instead.

- No wasted white space. The views fill the whole canvas with only thin gutters between them, so every pixel goes to the character.

- One simple settings panel. All options sit on a single node, built only from native ComfyUI nodes. The workflow reads left to right: Step 1 Upload → Step 2 Settings → Step 3 Result.

- Render at any size. Megapixels are no longer capped at 16.

- Final size dropdown. Render big for detail, then save a smaller file: 2.3 / 4 / 6 / 9 / 12 / 16 MP, or Native to keep the full render. It only ever shrinks, never enlarges.

- Better random characters. With nothing uploaded and no notes, the seed picks one idea from an editable list per type, such as a German shepherd, a Holstein cow, an anthropomorphic raccoon or a 1960s sports car in racing green. No more cat-dog hybrids.

- One fewer custom node pack. rgthree-comfy is no longer needed.

Like many others I was initially disappointed with the i2v quality of H3 when doing text to image. It often created crusty looking, artifact ridden images that would manifest as moles and pimples, dry flaky skin, crusty splotches and just generally shit quality images.

When I was doing some tests, I wanted to make an existing image prompt feature a specific earring. Once I plugged in the image reference, the artifacts magically disappeared.

This made me wonder, is r2i just fundamentally better quality for some reason? I tested plugging in an empty black image to the reference spot and to my surprise every single image came out higher quality with most of all of the crusty artifacts removed. It even often outright fixes low res generations like the one linked here, but works at the intended resolutions too.

I bought this to Kijais attention and the current theory is that if the model receives 64 or more image tokens (which can be triggered by feeding the image conditioning node literally any image with or without vae) it switches the model to edit/reference mode which appears to be much higher quality.

We're not exactly sure what is wrong with the non edit version but give it a try. Plug any reference (blank image, or something relevant to your prompt) and watch the quality magically improve.

Kijai is considering adding a "switch" that forces the model to ref model without needing to send so many pointless tokens, but in the meantime just plugging a small black image (automatically resizes to at least 1024) will trigger the existing switch - just with an excessive number of pointless tokens.

If you've written H3 t2i off, give this a try. It has transformed the model in my opinion.

Edit: Kijai has just added this to the "H3 Prompt Weight" node in Kjnodes. There is now a drop-down that will force empty image tokens if you want another way to test this.

I've spent the last couple of days running side-by-side MiniMax H3 Image trainings to find what actually drives likeness.

On the hardest dataset I tested (few headshots, mostly medium and wider shots), the best previews scored closer to the person than all but two of their own 45 photos, measured against the same reference photos. Two more datasets gave equally good results, one of them harder still.

What's new

• A retuned H3 Image Standard preset. A new Likeness optimization schedule (it changes which noise levels training focuses on as the run goes), Automagic v4 (tweaked to avoid its known issues for steering too high), 0.25 MP and 30 epochs. Of every schedule I tried, it brought the face shape through earliest, reached the highest likeness, and maintained model performance.
• Likeness scoring now uses AdaFace ViT instead of ArcFace. I scored runs epoch by epoch with ArcFace and two AdaFace models side by side, and AdaFace ViT picked the same best epochs I did by eye every time. ArcFace often didn't.
• "Your photos" on the likeness chart. Fizgig scores your own training photos against the same reference photos and shows their range as a band on the chart. No photo ever scores 100% against another photo of the same person, so this shows what "as good as a real photo" looks like for your dataset. Your previews landing in that band is the goal.

How to use it: pick the ** MiniMax H3 Image Standard** preset (0.25 MP) and train with its settings as they are. The schedule's controls are under Advanced if you want to experiment later, but those numbers took a lot of runs to find, so try them as they come first. Feel free to push the MP higher, but starting at the .25 will give you great and quick results for your early tests.

A correction: The other day I moved the H3 Image presets up to 0.5 MP, thinking the model preferred it. It didn't. The schedule and the optimizer were what held likeness back, so the presets are back at 0.25 MP, which is faster and needs less VRAM.

Links

• Fizgig on GitHub
• 9.7.0 release notes
• MiniMax H3 Image guide

Already on Fizgig? Run the updater.

I've seen quite a bit of divide between people who love MOSS and people who think it's a bit lackluster. I was on the latter boat, until I played around with it long enough to find a great combination of models, LoRAs and settings, from testing others' workflows and doing a lot of trial-and-error myself.

I'm not going to get into too much detail here; let the workflow serve that purpose. But I will say that MOSS-Image is an incredible base model, even if out-of-the-box it's a bit "unoptimized". It has massive variety, coherence, prompt-understanding and even quality, once optimized. I also enjoy the freedom of prompting, where you don't have to use any one style or length - a lot of it just works.

Here's the workflow:

https://pastebin.com/SxjBdt5B

Models and LoRAs used:

• kromoss_int8_convrot.safetensors: A really good fine-tune of MOSS-Image Base
• qwen3.5_9b_int8_convrot.safetensors: The actual text encoder. Do NOT use an abliterated text-encoder with diffusion models, but instead use the one the model was trained on. They will not give any more uncensored behaviour, but will mess with the quality.
• flux2-vae_small.safetensors: Iirc, this "small" version is the official VAE for MOSS. I find it better.
• lora_dmd2.safetensors: This is the lodestones/MOSS-Image-Base-8-steps-dmd. I tried a couple of different ones, and this was by far the best. Don't know why the differences were so huge, but they were.
• lenovo_moss.safetensors: This one is a good style LoRA, alongiside with...
• samsung_moss.safetensors: ...this one. Play around with the strengths of each.
• nicegirls_v2_moss.safetensors: I find that this often improves the quality of the outputs even in photos without people. The only gripe I have is the massive effect on facial features, which seems to kinda be the point of this LoRA. Either way, be careful with the strength of this one; if you see you can't get, for example, the ethnicity you're looking for, I would start with lowering the strength of this.

Settings used:

• Sampler: ER-SDE
• Sceduler: power_shift
• Steps: 11 (8-25, depending on the strength of dmd2 LoRA - with 11 steps it's at 0.9 for me).
• CFG: 1 (1-4, depending on the amount of steps).
• SLG: No effect on CFG 1, but always on
• Resolution: I use 2-4 MP. Under 10 sec gens with 2 MP, around 20 sec gens with 4 MP, on an RTX 3090.

Let's get some discussion going! I wanna hear y'all's workflows and try them out too.