CMK Pipe Peek KSampler Refiner Source

There is a specific annoyance in two-stage SDXL work that this node solves, and if you've built a base+refiner graph by hand you already know it.

Your first pass ran on a seed. Your refiner needs to know that seed, the latent it produced, how many steps the first pass took, and - if you're using them - the prompts and the LoRA stack that were active. In a hand-wired graph that's five or six wires you copy from the sampler's inputs to the refiner's inputs, and every one of them is a chance to typo a seed and silently get a different image than the one you liked.

CMK Pipe Peek KSampler Refiner Source is the one-socket version. Input: SAMPLED, a CMK_SAMPLED_PIPE. Output: seven wires, ready for CMK Pipe Create Refiner.

Why the input type is unusual

CMK_SAMPLED_PIPE is a CMK invention, and it's one of the more opinionated choices in the pack. The README explains: between the SDXL sampler, InstantID and the refiner, the pack uses a proprietary latent-carrying type called SAMPLED instead of a plain IMAGE.

That choice costs you interoperability - you can't just wire SAMPLED into an arbitrary node and expect it to work. What it buys is that the intermediate stage keeps information an IMAGE would have destroyed. A decoded image has pixels; it doesn't have a seed, a step count, an active-LoRA list, or a LoRA stack. The SAMPLED pipe carries all of it, which is precisely why this node can hand the refiner a first pass's identity.

The outputs

Seven, in order:

latent_image (LATENT) - latent_1st_pass if present, otherwise latent_image.
seed (INT)
steps_1st_pass (INT) - same fallback pattern, steps_1st_pass else steps.
prompt_pos (STRING)
prompt_neg (STRING)
active_loras (STRING) - a text summary of what was applied.
lora_stack (LORA_STACK)

Compare that list against CMK Pipe Create Refiner's optional inputs and you'll see the design: prompt_pos, prompt_neg, active_loras and lora_stack are exactly its four optional forceInput sockets, plus latent_image, seed and steps_1st_pass from its required set. One node's outputs are the other node's inputs. That's not a coincidence - it's the intended handoff, and it's the shortest way to get a refiner stage running with the first pass's actual settings instead of retyped ones.

The defaults are forgiving: prompt_pos and prompt_neg come back as "" and active_loras as "" if the pipe doesn't carry them, and lora_stack can be None. So a pipe from a LoRA-free workflow still produces a usable refiner source.

Validation

One check, and it fails loudly: if SAMPLED isn't a dict, you get "CMK Sampler Refiner Source: SAMPLED must be a CMK sampled pipe". Empty values inside are fine; the wrong kind of thing is not. Same philosophy as the rest of the Peek family - the pack would rather throw at the boundary than let a wrong-typed value travel five nodes before it detonates.

Where the pipe comes from

You get a CMK_SAMPLED_PIPE out of CMK's sampler-side modules - the ones that represent the moment between "latent produced" and "image decoded." In the reference flow that's the region between module 10 KSampler and module 20 Refiner, with 15 InstantID able to sit in the middle.

If you're inside the guided flow you'll rarely wire this by hand - the modules do it. It becomes useful when you're building a standalone base+refiner pipeline on CMK's parts, or debugging a refiner stage that's producing something subtly different from the first pass.

Install

Part of CMKFlow/cmk_nodes. ComfyUI Manager → search CMK Flow → install the CMKFlow entry → restart ComfyUI. Manual route, ComfyUI closed:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

CMK dependency check: OK is the finish line. This node needs nothing but the pack; your refiner checkpoint is a separate matter, and scripts/check_cmk_resources.py --models-root ... will tell you which refiner LoRAs the shipped workflows expect.

Traps

LoRA stack semantics travel with the pipe, not with you. active_loras is a string describing what was applied and lora_stack is the stack itself. If you feed lora_stack to a refiner but the refiner ignores it, the LoRAs aren't secretly doubling - the pipe just carries them forward for whoever wants them.

Tap early and you get planned values, not actual ones. Same fallback behaviour as CMK Pipe Peek KSampler: what you receive depends on where in the flow you attached. Attach after the first pass if you want the numbers that actually produced the image.