CMK Pipe Peek Preprocess Detailer
Everything a Detailer Needs, Pulled Out of a Pipe
- pipe
- image
- model
- clip
- vae
- opt_seed
- opt_prompt_pos
- opt_prompt_neg
- opt_active_loras
- opt_lora_stack
There are two Peek nodes with "Detailer" in the name and they are not interchangeable. This is the one that reads a CMK_PIPE and pulls out the ingredients for a detail pass. The other one (CMK Pipe Peek Detailer) reads a finished CMK_DETAILER_PIPE. If you wired the wrong socket and got a confusing type error, that's why.
CMK Pipe Peek Preprocess Detailer is the "I want to build my own detailer out of CMK's flow state" node.
What comes out
Nine outputs, and the naming tells you which are guaranteed and which aren't:
Required, validated: image (IMAGE), model (MODEL), clip (CLIP), vae (VAE).
Optional, prefixed opt_: opt_seed (INT), opt_prompt_pos (STRING), opt_prompt_neg (STRING), opt_active_loras (STRING), opt_lora_stack (LORA_STACK).
That opt_ prefix is genuinely helpful design. Four outputs are guaranteed non-None, five might be empty, and the node tells you which is which in the socket names rather than in a wiki.
The image source selection is the smart bit
The image output doesn't just read pipe["image"]. It walks a priority list:
image_detailer → image_refiner → image_1st_pass → image → image_original
So it gives you the most processed image available at that point in the flow. If a detail pass already ran, you get its result; if a refiner ran, you get that; otherwise you fall back to the raw sample. That's almost always what you want when you're inserting a secondary detail pass - you want to detail the current best image, not re-detail the original.
It's also a subtle trap. If you're expecting the pristine base image and you get a post-refiner one, your detail pass will compound whatever the refiner did. Tap the pipe earlier if that's not what you want.
The contract check
Unlike its Face counterpart's sibling and unlike CMK Pipe Peek Detailer, this node validates before returning. It assembles a contract of image, model, clip, vae, seed, prompt_pos, prompt_neg, active_loras, lora_stack, then requires ["image", "model", "clip", "vae"]. Miss one and you get a named error rather than silent Nones.
Which makes sense: model, clip and vae are the difference between "a detail pass" and "a stack trace two nodes later." seed and the prompt strings can legitimately be empty - a flow that never set a prompt is still a valid pipe - so they're read with "" defaults.
What you'd actually build with it
The canonical use is grafting an external detailer onto a CMK flow. You've got CMK handling the front half - prompting, resolution, LoRA bundling, sampling - and you'd rather run the masked re-render through a detailer node from somewhere else. This node hands you the model stack, the image and the prompt strings, in plain ComfyUI types, with no pipes involved.
Second use: a standalone detail stage. Take the pipe at the end of a flow, peek it, and drive a detailer you control node-by-node instead of using CMK's module. You keep the flow's cache behaviour upstream and get full manual control of the detail loop.
Third, and this is the sneaky one: debugging. Nine outputs is a fast answer to "does this flow even have a prompt set at this point?"
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 means the imports all resolved. Detectors and SAM models are separate downloads; the pack's own resource checker handles the ones with verified public sources and tells you honestly about the rest.
Traps
Denoise is not here. The pipe carries the image, the model stack and the prompts, but denoise, mask_expand and mask_feather live on the detailer nodes. When you build your own detail pass from these outputs, you're responsible for the numbers - and denoise is the one that decides whether you're sharpening or redrawing.
opt_lora_stack is a LORA_STACK, not a string. If you only need to know which LoRAs were active for naming or metadata, use opt_active_loras; feeding the stack itself into a node that doesn't expect it will fail on type.
Developer-category node (CMK/Developer/Pipe/Peek), so it's the plumbing the reference workflows use, not a beginner's on-ramp. That's not a criticism of it - but if you're just trying to get a detail pass running, Mask Detailer · Prepare and · Process will get you there with far fewer wires.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| pipe | CMK_PIPE | — |
Outputs (9)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| model | MODEL | — |
| clip | CLIP | — |
| vae | VAE | — |
| opt_seed | INT | — |
| opt_prompt_pos | STRING | — |
| opt_prompt_neg | STRING | — |
| opt_active_loras | STRING | — |
| opt_lora_stack | LORA_STACK | — |