CMK Log Export Text

Every CMK module writes a block into a log pipe - what it detected, which resolution it worked at, whether it bypassed, which masks came out where. That's a data structure on a wire. CMK Log Export Text is where it becomes prose: it renders the whole pipe to an ordered text report and gives you it as a STRING, plus a preview panel so you can read it without leaving the canvas.

Inputs and outputs

| | name | type | |---|---|---| | in | log_pipe | CMK_LOG_PIPE or CMK_RESULT_LOG | | out | STRING | STRING |

Note the dual type on the input: it accepts either the log pipe that the Toolbox chain passes around, or the log result that comes out of the pack's flow/result modules. If you've been following a LOG socket around a CMK subgraph, this is the node that terminates it.

It's marked as an output node, so you can hang it off the end of a log chain with nothing downstream and it will still execute. That's the intended use - a report you read, not a value you consume.

What the rendered report looks like

Blocks render in append order, not by the order number they carry. For each block you get the title, a line of dashes the same length as the title, then the lines, then a blank line before the next block. It's plain text, deliberately, and it reads like a procedure log rather than a table.

Blocks marked as disabled, and blocks whose lines are all whitespace, are dropped. If nothing survives that filter - an empty pipe, or a pipe that only carried disabled blocks - you don't get a blank text output, you get the literal string CMK log_pipe is empty. That's a deliberate friendly touch and it'll show up in your saved file as a sentence, not as silence.

Alongside the STRING, the node renders the same text into a small preview image panel titled CMK Log Export Text and pushes it to the UI. So you can queue a run, open the panel, and read what every module did without scrolling console output or grepping anything.

Why you'd wire this up

Two honest reasons. First, sharing: a CMK workflow's behaviour depends on a lot of interacting flags, and a text dump is far more useful in a bug report than a screenshot of a log panel. Second, comparison: save the report next to the image, and six months later you can tell which module bypassed and what the working resolution was.

Feed the STRING into ComfyUI's Save Text or Show Text and you're done.

Install

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

Or ComfyUI Manager → search CMK Flow (registry cmk-flow, publisher CMKFlow) → install → restart. The node needs nothing beyond the pack's base install, but that base install is not small - insightface, onnxruntime, ultralytics, segment-anything, nudenet==3.4.2 and opencv-python come along for the ride, and a plain git clone never runs pip for you.

CMK was verified against ComfyUI 0.38.2 with frontend 1.53.6 and expects Vue Nodes / Nodes 2.0; it warns at startup if that's off. The pack also ships a resource checker that prints the pack's own log of model files as FOUND or MISSING - same philosophy, different subject:

python3 custom_nodes/cmk_nodes/scripts/check_cmk_resources.py --models-root "/path/to/ComfyUI-Shared"

One caveat

This exports what CMK's nodes put into the log pipe - not ComfyUI's console, and not your sampler's internal decisions. If a node isn't a CMK module and doesn't accept a LOG input, its behaviour isn't in the report. For anything that is a CMK module, though, the log is usually the fastest way to answer "what did it actually do?", because CMK's nodes are unusually willing to write down their own parameters.