HDR LoRA Apply

An HDR LoRA is a strange beast compared to the character LoRAs most people are used to. It isn't teaching the model a face; it's teaching it to produce a different HDR response - and that only works if the encoder downstream is compressing at the same strength the LoRA was trained against. Which is why this node returns two things and you need both.

HDR LoRA Apply patches a diffusion MODEL with a Radiance HDR LoRA, and hands you back the matching compression_ratio so the rest of the graph stays in sync. Skip the second output and the LoRA fights your encoder, which shows up as either washed-out highlights or clipped ones, depending on which direction you drifted.

How it works

The delta is computed as strength × alpha/rank × B@A - the standard low-rank decomposition - and then recorded on a clone of the incoming MODEL via ComfyUI's own ModelPatcher.add_patches().

That cloning detail is the good part. The upstream loader's cached model is never mutated, so re-queueing the same graph doesn't pile deltas on top of each other, and the same loaded model can feed two branches with different LoRA strengths. It also means chaining works predictably: apply two HDR LoRAs in series and each accumulates its own deltas rather than one overwriting the other.

If none of the LoRA's tensors match a weight in the model you gave it, the node raises an error rather than silently passing through. That's deliberate and it's the right call - a silently-ignored LoRA is a nightmare to debug.

Inputs and outputs

Required: model (a ComfyUI MODEL, from a checkpoint loader or a prior apply), lora_dict (the LORA_DICT from HDR LoRA Loader - they're a matched pair), and strength (1.0 = trained weight, 0 = no effect, above 1 amplifies).

Optional: model_hint. This is a cross-check only - give it the model family name and the node warns if the LoRA was trained on something else. It doesn't block. That's a reasonable design (you might be intentionally trying something), but it means a warning in the console is your only signal.

Outputs: MODEL (the patched model - it replaces the input MODEL in your graph) and compression_ratio (FLOAT, straight out of the LoRA's metadata). Wire that second one to the encoder/diagnostics side. That's the whole point of the node existing separately from a generic LoRA loader.

Install

Manager → search Radiance → Install → restart ComfyUI → refresh your browser.

cd ComfyUI/custom_nodes
git clone https://github.com/fxtd-studios/radiance.git
cd radiance
python -m pip install -r requirements.txt

Windows portable users need ComfyUI's bundled python_embeded\python.exe for that pip line. The pack's dependencies are heavy (OpenImageIO, OpenColorIO, OpenEXR, diffusers, accelerate) but this node itself is pure patching.

Where people get burned

Ignoring the compression_ratio output. It's a bonus FLOAT sitting next to a MODEL output, so it's easy to leave dangling - and then your encoder uses its own default while the LoRA expects something else. The whole reason to use the Radiance LoRA pair instead of a generic loader is that this number travels with the weights. Use it.

model_hint mismatch is silent-ish. You get a console warning and the run continues. If the LoRA was trained for a different architecture, tensor names may partially match and you'll get a subtly wrong model rather than an error - the error only fires when nothing matches.

Strength above 1 is not a free boost. Like any LoRA, the deltas are linear; push it and you'll get artefacts before you get more of the effect you wanted.

And, from the LoRA-training side of the KB: a LoRA is ~20% the size of a full fine-tune for a similar output on a narrower target. HDR-response LoRAs are firmly the "narrow target" case - that's the design that suits them.