CMK Flow · 30 PostProcess Setup
The Node That Declares Your Generation Finished
- MODEL ZIT
- PROCESS ZIT
- IMAGE ZIT
- LOG ZIT
- VISUAL ZIT
- MODEL SDXL
- PROCESS SDXL
- IMAGE SDXL
- LOG SDXL
- VISUAL SDXL
- MODEL
- PROCESS
- IMAGE
- LOG
- VISUAL
Nothing in this node touches a pixel. Despite the name, it is not a sharpening node, not a color-grade node, not an "apply some post-processing" filter. It's the seam where the generation section of a CMK workflow ends and everything that happens afterwards begins - and if you went looking for it because you wanted to fix a washed-out image, you're in the wrong place. The finish work lives in the modules it opens the door to: FaceRebuild, FaceSwap, FaceProcess, Detailer, MaskDetailer.
So why does a seam need a node at all? Because CMK runs SDXL and Z-Image Turbo as technically separate paths through generation - and HYBRID builds with SDXL then hands the finish to ZIT. Everything downstream of the sampler shouldn't have to care which of those happened. This node is how it stops caring. The 30 in the display name is the slot: 20 Refiner → 30 PostProcess Setup → postprocess zone → Visualizer and/or Upscale & Save.
How the handoff works
You get two optional input groups, MODEL/PROCESS/IMAGE/LOG/VISUAL suffixed SDXL, and the same five suffixed ZIT. Connect the branch you actually generated on. The node resolves the active generation mode, and then - this is the part worth understanding - only pulls the inputs belonging to that branch. The other group's inputs are lazy, so the nodes feeding them don't execute. You can leave a full ZIT chain wired and still run an SDXL image without paying for it.
At the point it runs, it does the actual boundary work: it releases the generation model (the log line reads GENERATION MODEL : UNLOADED, with the cleared cache entry count next to it) and builds a new model spec for the postprocess zone. That's the family-neutrality, expressed as a type change: PROCESS comes out as CMK_RESULT_PROCESS, not the SDXL or ZIT pipe you fed in. That output type is your proof the transition happened.
The three widgets and the five outputs
postprocess_checkpoint is the one that confuses people, because its default is None and that's usually correct. With None the log says MODEL LOAD : DISABLED - no checkpoint gets loaded, and any postprocess module that genuinely needs a model fetches one when it gets there. Pick a checkpoint here only when you want the finish zone to work from a different model than the one you generated with; a face-friendly SDXL checkpoint for the detailer passes is the usual reason. use_checkpoint_vae at its default true takes the VAE baked into whichever checkpoint is in play - turn it off and the separate postprocess_vae dropdown is used instead.
Outputs are MODEL, PROCESS, IMAGE, LOG, VISUAL: straight into the postprocess modules, and from there into CMK Flow · Visualizer and/or Upscale & Save. The IMAGE here is the finished generation frame, not a re-render.
Install
Nothing extra is needed for this node specifically - it's pure plumbing. The pack install is the usual one: ComfyUI Manager, search CMK Flow, install from CMKFlow, restart. Manually:
cd /path/to/ComfyUI
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, because a manual clone never runs pip on its own. You also want Vue Nodes / Nodes 2.0 enabled - CMK's dynamic node UI falls back to old LiteGraph without it, and the author's nodes lean on it harder than most.
Troubleshooting
CMK Active Family Result received two active PROCESS paths is the one you'll earn by wiring both branches and leaving both upstream gates open. The node refuses rather than guessing, which is the right call - you generated on exactly one path, even if both are connected.
The mirror error, received no active PROCESS path, usually means the gate feeding your PROCESS input is switched off or the family selection upstream resolved to neither. Check module 01 first.
If it complains that a family "is selected but MODEL, PROCESS, IMAGE … is not connected", the message names the family it picked - so it's telling you which branch it thinks you ran. That's usually enough to spot the swapped wire.
One more naming trap worth knowing: a Visualizer already fed by direct generation roots is a second thing claiming to own completion. Don't stack completion owners; feed the Visualizer from this node's outputs and let it be the only one.
And if a run appears to skip the boundary, remember CMK caches completed boundaries under ComfyUI/temp/cmk/ within a session - a restart clears them. A cache HIT on the second run is the feature working, not the node being ignored.
Inputs (13)
| Name | Type | Default | Description |
|---|---|---|---|
| postprocess_checkpoint | COMBO | 1 options: None | |
| postprocess_vae | COMBO | 0 options: | |
| use_checkpoint_vae | BOOLEAN | true | — |
| MODEL ZITopt | CMK_MODEL_PIPE | — | |
| PROCESS ZITopt | CMK_PROCESS_Z_IMAGE | — | |
| IMAGE ZITopt | IMAGE | — | |
| LOG ZITopt | CMK_LOG_PIPE | — | |
| VISUAL ZITopt | CMK_VISUAL_PIPE | — | |
| MODEL SDXLopt | CMK_MODEL_PIPE | — | |
| PROCESS SDXLopt | CMK_PROCESS_SDXL | — | |
| IMAGE SDXLopt | IMAGE | — | |
| LOG SDXLopt | CMK_LOG_PIPE | — | |
| VISUAL SDXLopt | CMK_VISUAL_PIPE | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| MODEL | CMK_MODEL_PIPE | — |
| PROCESS | CMK_RESULT_PROCESS | — |
| IMAGE | IMAGE | — |
| LOG | CMK_LOG_PIPE | — |
| VISUAL | CMK_VISUAL_PIPE | — |