CMK Mask Detailer · Prepare

Every detailer is secretly two nodes wearing one name: the part that assembles the job, and the part that runs it. Impact Pack splits them too - DetailerForEach takes a basic_pipe you're expected to build yourself. CMK does the same split, and this is the assembly half.

CMK Mask Detailer · Prepare collects the checkpoint, the image, the painted mask, a LoRA and a prompt addition, and packs them into a CMK_MASK_DETAILER_PROCESS family object. It renders nothing. It is the boring node that makes the interesting node possible, and because it's boring, it's where things go wrong quietly.

What goes in

Five required fields:

• MODEL - a CMK_MODEL_PIPE, i.e. from CMK Checkpoint VAE Loader -Pipe-. It must carry model, clip and vae; the node raises if any is missing.
• lora_name / lora_strength - populated from your loras folder, default None, strength range -20 to 20. This is a detailer-specific LoRA, applied to the model for the masked pass only, and it's a real trick: a face-focused LoRA at low strength while detailing a face will do more than a prompt tweak.
• prompt_pos - a prompt addition, not a replacement. The code concatenates it onto the source's positive prompt, so the detail pass keeps the context of the original render.
• fill_mask_holes - closes interior gaps in a painted mask before the pass runs. Turn it on for scribbled masks with unpainted islands.

Optional: MASK DETAILER SOURCE (the terminal token from Mask Detailer · Intake), PROCESS, IMAGE, LOG, VISUAL. You can feed it either the Intake token or a plain IMAGE stream - the node checks which it got and reads the mask off the right one.

What comes out

MODEL passes through (the pack's architecture doc forbids modules mutating MODEL, so this is by design, not laziness), plus MASK DETAILER PROCESS, LOG and VISUAL.

That middle output is the only thing Mask Detailer · Process will accept. It contains the model/clip/vae, the encoded positive and negative conditioning, the image, the mask tensor, the LoRA tag, and model_family, which is pinned to "sdxl" here. If you were hoping to mask-detail a Flux or Z-Image render with this, that's your answer: not in this node's contract.

Why the split exists

The pack's own framing is that this is "deliberately not a Flow module" - it starts a standalone MASK DETAILER PROCESS family from either an independent image source or a terminal handoff. Practically that means you can bolt this onto any workflow. Generate in Flux, upscale, save the PNG, then load it here, paint a mask, and detail it with an SDXL checkpoint. That is a genuinely useful escape hatch and it's the reason the README advertises standalone use of the post-process modules rather than forcing you through the numbered flow.

Install

Same pack, same steps. Manager → CMK Flow → install → restart. Manual:

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

Wait for CMK dependency check: OK before starting ComfyUI. If LoRAs are what brought you here, note that the LoRA Stack subgraphs need comfyui-lora-manager installed - this node's own single-LoRA dropdown does not.

Where people get burned

Nothing here loads a model. If your MODEL is empty, the error says "MODEL must come from CMK Checkpoint & VAE" and that is literal. Run a checkpoint loader first.

A mask-less IMAGE input silently produces a zero mask, and a detail pass over a zero mask means Process has nothing to bite on. The Visualizer will show you a before/after that looks identical, and you'll spend twenty minutes blaming the denoise. Paint the mask, or route the Intake token.

lora_strength accepts negatives down to -20. That range is real, and inverting a LoRA on a detail pass is a legitimate (if strange) move. Don't assume the default 1.0 is the only sane value here.