Downloads · 30 days
2K
18% of all-time downloads
oumoumad/LumiPic
LumiPic is a image-to-image model from oumoumad. Use it when you need one image transformed into another. It is set up for diffusers. The card lists the license as mit.
Converts standard dynamic range (SDR) images to high dynamic range (HDR) EXR files — float-valued, with range well beyond what an 8-bit SDR output can carry.
Downloads · 30 days
2K
18% of all-time downloads
All-time downloads
11.2K
Public
Repo size
5.6 GB
Likes
79
Trending 1
Click a slice to open those files.
.safetensors5.2 GB · 100%
From the Hugging Face model README
Converts standard dynamic range (SDR) images to high dynamic range (HDR) EXR files — float-valued, with range well beyond what an 8-bit SDR output can carry.
Based on LumiVid (paper) — the Lightricks research that introduced log-encoded diffusion for HDR generation. LumiPic is the same technique adapted to single-image diffusion transformers; the technique is base-model agnostic. Two trained LoRA families are published here, across three base models.
2026-10-03 — V11 ACEScct added (Qwen-Image-Edit-2511). A new LoRA trained to output ACEScct instead of ARRI log, on camera-style SDR inputs (hard-clipped sRGB, as real photos and generated images are) rather than display-rendered ones. It needs two Gear nodes — an ACEScct encode on the input as well as the decode on the output — and its own workflow. See V11 ACEScct below.
2026-05-24 — V10 LogC4 added (alpha). Six new checkpoints (two per model family) trained on ARRI LogC4 instead of LogC3, giving ~3 extra stops of highlight headroom (linear ceiling ~470 vs LogC3's ~55). Testing so far is limited; see the V10 caveats section below.
Same 20 HDR outputs, viewed at two extreme exposure offsets — highlights still hold structure at EV+6, shadows still hold information at EV-6.
Exposure +6 (highlights pulled down):

Exposure -6 (shadows pushed up):

| Curve | Linear ceiling | Stops above 0.18 mid-gray | Decode node |
|---|---|---|---|
| LogC3 (V1 / V5b / V9 / klein_alpha_*) | ~55.2 | ≈ 8.3 | Gear · LogC3 Decode + Save EXR |
LogC4 (V10 / *_logc4_*) | ~470 | ≈ 11.3 | Gear · LogC4 Decode + Save EXR |
ACEScct (V11 / *_acescct_*) | ~223 | ≈ 10.3 | Gear · ACEScct Decode + Save EXR and Gear · ACEScct Encode on the input |
⚠️ Picking the wrong decode curve silently produces wrong absolute linear values. The EXR will look plausibly tonemapped but the absolute luminance will be off. Match the decode node to the LoRA's filename:
_logc4_*→ LogC4 node;_acescct_*→ ACEScct nodes; everything else → LogC3 node. The ACEScct LoRA additionally expects its input image ACEScct-encoded (Gear · ACEScct Encode,srgb_display); feeding it a plain sRGB image is the same class of mistake as the wrong decode.
The LogC4 family adds about 3 extra stops of highlight headroom — important for shots with direct sun, fire, specular reflections, or window-blown highlights that were hitting the LogC3 ceiling. For lower-DR content (interior, overcast, night), the two curves produce very similar outputs and LogC3 is fine.
5+ training iterations, 563 MB per LoRA. Best quality, larger base (~54 GB).
LogC3 (stable):
v5b_step2000.safetensors — Qwen default. Most robust overall; best on stylized/AI-generated SDR inputs.v9_step1500.safetensors — alternative. LumiVid-aligned augs (joint HDR+SDR EV shifts, luminance blur p=1.0). Slightly better on natural photos.hdrdit_v1_QE2511.safetensors — original v1 release.ACEScct (V11 — 2026-10-03):
v11_acescct_step3000.safetensors — ACEScct in, ACEScct out; EXR is linear ACEScg (AP1). Trained on camera-style SDR with a cosine LR schedule and EMA. Use with SDR_To_HDR_acescct_QE11.json; LoRA strength 1.0.LogC4 (V10 alpha — 2026-05-24):
v10_logc4_step1500.safetensors — recommended V10 candidate by stats (highest mean p99 = 17.96 across 10 golden scenes).v10_logc4_step3000.safetensors — final (full training run completion).Single training iteration, 88 MB per LoRA. Apache 2.0 base, 5× smaller than Qwen, fastest end-to-end.
LogC3:
klein4b_alpha_step1750.safetensors — klein-4B default. Faithful HDR look; well-balanced.klein4b_alpha_step1000.safetensors — alternative. Aggressive HDR (higher p99) but tends to blow out bright highlights.LogC4 (V10 alpha):
klein4b_v10_logc4_step1500.safetensors — strongest V10 performer in early ComfyUI testing (better than the Qwen V10 — see caveats).klein4b_v10_logc4_step2000.safetensors — final.Single training iteration, 158 MB per LoRA. Larger klein variant — more capacity, more nuanced HDR. Base model is gated on HF (request access at the base model page before first run).
LogC3:
klein9b_alpha_step2000.safetensors — klein-9B default. Stable, well-behaved (mean p99 9.1, no scenes saturated in our 20-image benchmark).klein9b_alpha_step1250.safetensors — most "good" scenes (13/20 in 5-50 p99 range, 0 saturated). Practically the best by per-scene quality count.klein9b_alpha_step1000.safetensors — most aggressive (mean p99 20.6, but 4 scenes saturated). Pre-overfit peak HDR range.klein9b_alpha_step{250,500,750,1500,1750}.safetensors — intermediate snapshots, available for experimentation.The training overfit curve was steep on klein-9B (mean p99: 1000=20.6 → 1250=11.1 → 1500=9.3 → 1750=9.6 → 2000=9.1). Step 2000 is the safest default; step 1250 is the practical sweet spot.
LogC4 (V10 alpha):
klein9b_v10_logc4_step1500.safetensors — recommended V10 candidate.klein9b_v10_logc4_step2000.safetensors — final.LoraLoaderBypassModelOnly at strength 1.0: the regular loader merges the delta into rounded bf16 weights and loses most of it. Use TextEncodeQwenImageEdit (not the Plus node) with the ACEScct-encoded image on both the positive and the negative, prompt Convert this image to HDR. The released workflow keeps the 4-step Lightning setup of the LogC3 workflow; the ground-truth numbers above were measured at 20 steps without it — bypass the Lightning LoRA and set 20 steps to match.Testing has been limited. Notable observations so far:
klein4b_v10_logc4_step1500.safetensors has been the strongest LogC4 candidate in early ComfyUI runs. If you're picking one V10 to try first, start there.Treat all V10 ckpts as alpha for community testing, not as drop-in replacements for V9 in production. Share any useful feedback for improvement — open an issue on the GitHub repo with examples, observations, or pipeline differences you spot. Especially valuable: anything that helps explain the Qwen diffusers-vs-ComfyUI mismatch.
Qwen-Image-Edit-2511:
from diffusers import QwenImageEditPipeline
import torch
from PIL import Image
pipe = QwenImageEditPipeline.from_pretrained("Qwen/Qwen-Image-Edit-2511", torch_dtype=torch.bfloat16)
# LogC3 default:
pipe.load_lora_weights("oumoumad/LumiPic", weight_name="v5b_step2000.safetensors")
# LogC4 (V10 alpha):
# pipe.load_lora_weights("oumoumad/LumiPic", weight_name="v10_logc4_step1500.safetensors")
pipe = pipe.to("cuda")
image = Image.open("photo.jpg").convert("RGB")
output = pipe(prompt="Convert this image to HDR", image=image,
num_inference_steps=40, guidance_scale=3.0, output_type="pt")
# Decode LogC3 → linear HDR (see logc3.py in GitHub repo)
# Decode LogC4 → linear HDR (see logc4.py — same interface, different curve constants)
FLUX.2-klein-base-4B / 9B (requires bleeding-edge diffusers: pip install "git+https://github.com/huggingface/diffusers.git"):
from diffusers import Flux2KleinPipeline
import torch
from PIL import Image
# 4B (Apache 2.0, ungated)
pipe = Flux2KleinPipeline.from_pretrained("black-forest-labs/FLUX.2-klein-base-4B", torch_dtype=torch.bfloat16)
# LogC3:
pipe.load_lora_weights("oumoumad/LumiPic", weight_name="klein4b_alpha_step1750.safetensors")
# LogC4 (V10 alpha — recommended starting point for V10 testing):
# pipe.load_lora_weights("oumoumad/LumiPic", weight_name="klein4b_v10_logc4_step1500.safetensors")
# 9B (gated — accept license on HF first)
# pipe = Flux2KleinPipeline.from_pretrained("black-forest-labs/FLUX.2-klein-base-9B", torch_dtype=torch.bfloat16)
# pipe.load_lora_weights("oumoumad/LumiPic", weight_name="klein9b_alpha_step2000.safetensors")
# or LogC4: weight_name="klein9b_v10_logc4_step1500.safetensors"
pipe.enable_model_cpu_offload() # or pipe.to("cuda") if you have 32GB+
image = Image.open("photo.jpg").convert("RGB")
output = pipe(prompt="Convert this image to HDR", image=image,
num_inference_steps=25, guidance_scale=3.0, output_type="pt")
See the GitHub repo for complete inference code with EXR output (inference.py for Qwen, inference_klein.py for klein).
git clone https://github.com/oumad/LumiPic.git && cd LumiPic
pip install -r requirements.txt
python inference.py --image photo.jpg # Qwen path (production)
python inference_klein.py --image photo.jpg # klein path (alpha)
The base model and LoRA weights download automatically on first run.
Ready-to-use workflows:
LogC3 (stable):
SDR_To_HDR_QE11.json — Qwen-Image-Edit-2511SDR_To_HDR_klein4b.json — FLUX.2-klein-base-4BSDR_To_HDR_klein9b.json — FLUX.2-klein-base-9BACEScct (V11):
SDR_To_HDR_acescct_QE11.json — Qwen-Image-Edit-2511 + v11_acescct_step3000.safetensors. Same graph as the LogC3 Qwen workflow with Gear · ACEScct Encode added on the input and the decode swapped for Gear · ACEScct Decode + Save EXR.LogC4 (V10 alpha):
SDR_To_HDR_logc4_klein9b.json — FLUX.2-klein-base-9B + V10 LogC4 LoRA (the strongest V10 configuration in current testing)The LogC3 workflows use the Gear · LogC3 Decode + Save EXR node; the LogC4 workflow uses Gear · LogC4 Decode + Save EXR (added in ComfyUI_Gear v0.2.0). Same node API, different curve — never mix them. The ACEScct workflow uses Gear · ACEScct Encode and Gear · ACEScct Decode + Save EXR; update ComfyUI_Gear to a build that includes them.
Drop the JSON onto your canvas, place the matching LoRA file in ComfyUI/models/loras/{qwen,flux-2}/hdr/, install ComfyUI_Gear ≥ v0.2.0, queue with prompt "Convert this image to HDR".
.npy targets (npy-float32-targets branch); klein LoRAs use upstream + a 4-line VAE-on-GPU patch to flux2_model.py.