LoRA from Metadata
The LoRAs that made that style, auto-loaded
- model
- clip
- metadata
- model
- clip
You restored the checkpoint, you got the prompts back - and then the style is still wrong, because the image was made with three LoRAs stacked on top and nobody wrote them down for you. That's the gap LoRA from Metadata (ImageMetadataLoRALoader) closes. Drop the image on it and the pack's parser pulls the LoRA names out of the embedded workflow, matches them against your models/loras folder, and slots them into three sequential positions. It's the last piece of the "reproduce any image" puzzle from the Model and Prompt from Metadata pack.
This node doesn't load a checkpoint - it patches one you've already loaded. You chain it after a model loader (or after the pack's Model-Prompt from Metadata node) and it applies the detected LoRAs on top, exactly like a stack of LoraLoaders, just without you dragging three of them around.
How it works
On the front end it's the same drop-zone engine as the rest of the pack: parse PNG/WebP/JSON metadata, fuzzy-match, ✓/✗ badges, auto-assign when there's a clean single hit. On the Python side it's honest comfy.sd.load_lora_for_models called three times in sequence - slot 1, then 2, then 3 - each with its own model and CLIP strength. If a slot is None it's skipped entirely. One nice touch from the README: if the original workflow used the Lora Loader (LoraManager) node, entries with active: false are skipped, so your disabled experiments don't get resurrected.
Inputs and outputs that matter
model/clip- required. In from your checkpoint loader, out to your sampler.lora_1/lora_2/lora_3- the slots;Nonebypasses any of them. Only three, so if the metadata found more, pick the ones that mattered.strength_model_N/strength_clip_N- floats, default 1.0, range −100 to 100. One piece of advice: the default 1.0 is often too hot. For character and style LoRAs the community habitually lands around 0.5–0.8; treat 1.0 as "exactly as strong as the original," not "correct."metadata(optional) - a METADATA input so you can wire it to the same parsed data coming out of the pack's own checkpoint/prompt loaders and skip dropping the image a second time. Neat bit of internal wiring.
Outputs are just model and clip with the LoRAs applied. Wire those into your KSampler and you're done.
Installing it
Same pack, same two ways: ComfyUI Manager → search "Model and Prompt from Metadata", or
cd ComfyUI/custom_nodes
git clone https://github.com/ketle-man/model-and-prompt-from-metadata
then restart ComfyUI. Zero Python dependencies, zero model downloads - the pack ships pure JS + a thin Python layer over ComfyUI's own APIs.
Gotchas
The LoRAs that made an image aren't always installed, and when they're not you'll see the ✗ badge and an empty slot - the node can't invent weights it doesn't have, so you pick a stand-in or skip the slot. Related: only three slots. If the original workflow stacked five LoRAs, you're choosing the top three by hand. And the usual pack-wide caveat applies: this is built for SD1.5 / SDXL / Illustrious checkpoint-based metadata. UNet workflows (Flux, Qwen, Z-Image) are out of scope - detected names get shown, LoRAs don't load; for those the author points at his Workflow Studio pack. Nothing here is a crisis, but knowing the three-slot ceiling before you build around it saves you an afternoon.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| lora_1 | COMBO | Select 'None' to bypass this slot. | |
| strength_model_1 | FLOAT | 1.00-100–100 | — |
| strength_clip_1 | FLOAT | 1.00-100–100 | — |
| lora_2 | COMBO | Select 'None' to bypass this slot. | |
| strength_model_2 | FLOAT | 1.00-100–100 | — |
| strength_clip_2 | FLOAT | 1.00-100–100 | — |
| lora_3 | COMBO | Select 'None' to bypass this slot. | |
| strength_model_3 | FLOAT | 1.00-100–100 | — |
| strength_clip_3 | FLOAT | 1.00-100–100 | — |
| metadataopt | METADATA | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| clip | CLIP | — |