Z-Image Images To LoRA (ae)

Z-Image Images To LoRA (ae) is a single node that turns a batch of images into a Z-Image LoRA while your workflow is running. It's a ComfyUI port of DiffSynth-Studio's Z-Image i2L (image-to-LoRA) pipeline - the thing the community called "a wild idea" when it shipped, and then noted there was no easy way to run locally. This node is that local port, and it's the reason the pack exists.

When do you actually reach for it? When you want a style LoRA for fast ideation - anime, cartoon, painting, drawing styles. Not for character accuracy: the consistent finding is that i2L bakes a general style, not a specific person, and quality is hit and miss. Realism photography in particular tends to do nothing useful. For one-off style and pose references it's great, but a production character LoRA still means proper training with captions and a real trainer. What you get in exchange: no captioning, no training run, no waiting for steps. Feed in 4-6 consistent images and a LoRA file drops out.

Here's the mechanism. The node loads DiffSynth-Studio's ZImagePipeline with three pieces - the SigLIP2-G384 and DINOv3-7B image encoders plus the Z-Image-i2L model itself - runs them in bfloat16 with CPU offloading so they don't crush your VRAM, and encodes your images into per-image LoRAs. Those get merged into one safetensors file with weighted averaging, so you can make one image count more than another if you want. There's also a strength-normalization step: if your LoRA only behaves at 1.75 strength when loaded, it can be baked so it works at 1.0. Auto-versioning means you never overwrite - files land in models/loras/Z-Image/ae/z-image_<name>_v000.safetensors, then _v001, and so on. The single output, lora_path, is the relative path, and it plugs straight into a LoraLoaderModelOnly lora_name input with no refresh needed. The repo's example workflow is exactly that chain: ImageSelector → this node → LoraLoaderModelOnly → KSampler.

Inputs that matter: images (a B×H×W×3 tensor batch) and lora_name are required. batch_size controls how many images process at once - higher is faster, but it's pure VRAM pressure, so drop it to 2 or 4 if you're tight. unload_models_before_running defaults to true, which evicts your loaded checkpoints from VRAM before the pipeline runs. And seed is the pack's signature trick: leave it fixed so the node runs once, change it to force a re-run with the same inputs.

Install is the fiddly part because there are two layers. First the pack: in ComfyUI Manager, Install via Git URL with https://github.com/by-ae/ae-in-workflow.git, or clone into custom_nodes and pip install -r requirements.txt, then restart. Second, and non-negotiable for this node, DiffSynth-Studio itself - the node raises an ImportError until you've cloned it and run pip install -e . (the README has the exact command for portable, venv, and conda ComfyUI). Then the first run downloads the i2L model plus both image encoders from HuggingFace, and DINOv3-7B is a 7B vision model - that's a multi-gigabyte download, not a snack. Budget disk and expect a slow first run.

Where people get burned: skipping DiffSynth-Studio entirely and hitting "DiffSynth-Studio is not installed yet"; blowing VRAM on a big batch (lower batch_size); and expecting character-accurate LoRAs from a tool that explicitly isn't one. One more thing worth internalizing: this produces LoRAs for Z-Image Base and Turbo - the 6B, Apache 2.0 model the community crowned "SDXL 2.0" - and Z-Image LoRAs are run at strength 1.0 and up, not the old SDXL 0.5-0.8 rule. Keep it as the fast ideation tool it is and it'll surprise you. Treat it as a trainer replacement and it won't.