OCS ApplyFilterLatent

The OCS filter system is powerful and completely un-debuggable while it's buried inside a sampling loop. This node is the escape hatch: it applies the same filter language to a LATENT tensor, outside of any sampler, so you can see exactly what a filter does to a latent before you commit it to a workflow. Think of it as the test bench for the filter blocks you'd otherwise type into an OCS Sampler, OCS Group, or OCS Substeps node and cross your fingers.

What it is

A standalone filter application node. You feed it a LATENT, a seed, and a yaml_config containing an OCS filter definition; it runs the filter and returns the modified LATENT. Mechanically it loads your latent's samples, clones them, applies make_filter(filter_def), and hands back a fresh {"samples": ...} dict. The seed matters only if the filter generates noise. It's the direct sibling of OCS ApplyFilterImage - same code path, latent flavor.

The inputs that matter

• latent (required) - the latent to filter. Note the tooltip: "This node does not care about masks." Masked latents get filtered in full; don't rely on this for masked/inpaint-style workflows.
• seed (required, default 0) - seeds generated noise inside the filter.
• yaml_config (required) - the filter definition. Same shape as everywhere in OCS:

filter:
    filter_type: simple
    input: default
    output: default
    strength: 1.0

The config must be an object containing a filter key, and the filter definition must be an object, or you get a ValueError. Beyond that, "there is essentially no error handling" - the tooltip again, and it means it.

The single LATENT output plugs back into any latent consumer - or a VAE Decode if you want to look at the result.

Why you'd use it

Two reasons. The first is testing: build a filter here, decode the output, confirm it does what you think, then paste the filter: block into the sampler where it'll run on live sampling data. The second is applying a fixed transform to a latent outside sampling entirely - a one-off enhancement or a filter you want to run on a latent you already have. Either way, it's the safest way to interact with a system that fails loudly and unhelpfully.

Installing and gotchas

Part of the pack - ComfyUI Manager search "Overly Complicated Sampling" or git clone https://github.com/blepping/comfyui_overly_complicated_sampling into ComfyUI/custom_nodes, restart. No models, no mandatory deps.

The traps: masks are ignored, so don't use this where a masked operation is the intent. There's no error handling on the YAML, so validate incrementally - start with a trivial simple filter and layer on expression complexity. And remember that a filter that looks great on a static latent may behave differently on live sampling data, where variables like sigma, step, and denoised exist and your expression can use them. Those variables don't exist here, so a filter relying on them will fail - test those in-context instead.