BlehLatentOps

This is the "I know exactly what I want to do to this latent, let me just write it" node. Instead of a fixed set of widgets, BlehLatentOps takes a LATENT and a block of YAML rules and applies whatever scaling, slicing, or filtering operations you describe. It's the same rule engine behind the pack's BlehBlockOps node (which patches a model mid-sampling), just aimed at a plain latent tensor instead of a live sampling pass - which is why the README calls it "basically the same as BlehBlockOps, except the condition type will be latent." Because there's no sampling step or percentage to key off, anything BlockOps does with timesteps just doesn't apply here - you're operating on one static tensor.

Why you'd reach for this instead of a dedicated node

The pack ships purpose-built nodes for the common latent operations (BlehLatentBlend for mixing two latents, BlehLatentScaleBy for resizing), but those only cover the well-trodden cases. If you want to slice out specific channels, run a frequency filter, or chain a handful of operations together in one step without wiring five nodes in sequence, this is the escape hatch. It trades a friendly UI for flexibility - you're writing a small script instead of clicking widgets.

The tradeoff is real: this is an advanced node, the pack calls the underlying BlockOps system "very experimental" and "still under development," and the extended documentation for the rule syntax lives in a separate doc in the repo (docs/blockops.md) rather than in the main README. Don't reach for this as your first stop.

Inputs and outputs

• samples (required) - the LATENT you're operating on.
• rules (required) - a multiline string field where you write your YAML rule set. Each rule has a condition (here, type: latent) and a list of ops to run.
• samples_hsp (optional) - a second LATENT input. The schema doesn't spell out exactly which ops consume it, so treat it as available-if-your-rule-needs-a-second-latent rather than something every rule set requires.
• Output: a single LATENT, transformed by whatever your rules did.

For a feel of the op vocabulary, the pack's README shows two worked examples for the sibling BlockOps node (patching a model, not a plain latent, but the ops themselves - scale, unscale, slice, ffilter, target_skip - are the same engine LatentOps draws from):

# Deep Shrink-style: downscale then upscale back
- if:
    type: input_after_skip
    block: 3
    to_percent: 0.35
  ops: [[scale, bicubic, bicubic, 0.5, 0.5, 0]]
- if:
    type: output
  ops: [[unscale, bicubic, bicubic, 0]]

For LatentOps you'd swap the condition to type: latent and drop anything block- or percentage-specific, since none of that exists outside a live sampling pass.

Installing it

Same pack as every other Bleh node - one install covers all of them:

• ComfyUI Manager - search "ComfyUI-bleh", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/blepping/ComfyUI-bleh, restart ComfyUI.

No extra Python dependencies or model downloads needed for this specific node.

Common issues

You have no idea what to write in rules. That's expected - this node has no widget-based fallback, so if the YAML syntax and op vocabulary aren't already familiar to you from BlockOps, read docs/blockops.md in the repo before trying to freehand it. This isn't a beginner-friendly node and the pack doesn't pretend otherwise.

A rule silently does nothing. Double check the condition - since this node only ever sees type: latent (there's no timestep, no block index, no sampling percentage to match against), any condition field borrowed from a BlockOps example that references those will never match here.

It errors on load or on run. The pack flags this whole system as experimental and still under development, so syntax and available ops can shift between versions. If a rule set that used to work breaks after updating the pack, check the changelog before assuming your YAML is wrong.