LucidFlux_SM_Pid_Model

What it is

LucidFlux_SM_Pid_Model is the loader for the 4K leg of this pack - NVIDIA's PiD, the "Pixel Diffusion Decoder" that the author bolted on as the pack's headline super-resolution feature. If you want the 4K path, this node loads the PiD model; its sibling, LucidFlux_SM_Pid_Decoder, runs it. The README's own verdict, translated: "added PiD 4K super-resolution, choose 2kto4k and the matching model; the 2k mode is mediocre, used for 512 to 2048."

What PiD is

So what is PiD? NVIDIA's PiD is a learned pixel-space diffusion decoder. Where a normal Flux pipeline does latent → VAE decode → image, PiD does latent → pixel-space diffusion decoder → larger image. It replaces the VAE-decode step with a fast, 4-step-distilled Flux-family diffusion model that decodes and upscales in one shot. It's an established thing on its own - people run PiD checkpoints for Flux.1, Flux.2, SD3, Z-Image, SDXL and Qwen-Image as a fast 4x detail/decode stage. In this pack it's the bridge from the restored latent up to 2K or 4K, and it's the stage where the example workflow's resolution ambitions actually pay out.

The mechanism, from the source: the node builds a PiDFluxDecoder with a scale of 2 (pid_type 2k) or 4 (pid_type 2kto4k), loads the checkpoint you picked from models/diffusion_models/, and automatically loads the Gemma caption embeddings from models/LucidFlux/gemma_prompt_embedding.pt (it needs that file or it raises - the README lists it under "PID use"). After loading, the model is parked on CPU; the PiD decoder streams layers to the GPU during decode, which is how a 4K-scale diffusion decode runs on a single consumer card at all.

The inputs

The inputs:

• pid_model: a combo of files in models/diffusion_models/ - the .pth files from NVIDIA's PiD repo on Hugging Face. The 4K one is PiD_res2kto4k_sr4x_official_flux_distill_4step.pth; the lesser 2K one is PiD_res2k_sr4x_official_flux_distill_4step.pth.
• model_type: bf16 or f32. bf16 is the default and the right call; PiD decode is heavy.
• pid_type: 2k or 2kto4k. Match it to the checkpoint you loaded, and note the author's own advice - the 2k path is the weak one, basically only for pushing a 512px source to 2048.

Output: model, which goes straight into LucidFlux_SM_Pid_Decoder. In the example workflow the KSampler runs first (9 steps), so the chain is Model → KSampler → Pid_Decoder, with this loader hanging off the Pid_Decoder's pid_model input.

Install

Install is the pack's shared routine (clone into custom_nodes, pip install -r requirements.txt, restart), plus the PiD-specific downloads: the checkpoint into models/diffusion_models/, and gemma_prompt_embedding.pt + null_caption_embs.pt into models/LucidFlux/. The README calls null_caption_embs.pt "PID use" too, so grab it from the smthem/LucidFLUX-connector repo even though it's not obviously part of that repo's name.

Where people get burned

Where people get burned: mismatched pid_type vs checkpoint - a 2kto4k .pth with pid_type set to 2k and the decoder silently uses the wrong scale, giving you a half-res image. And be honest about the VRAM: the 4K decode is the single heaviest stage in this pack. On a 12GB card the 2kto4k path is slow-but-runnable thanks to layer streaming; on 8GB you'll want to stick to the 2K path. This is a "nice card" feature, not a "everyone" feature.