_.filterObject

_.filterObject is the dict-flavored cousin of _.filter: it goes through an object's values and keeps the ones that pass a truth test. The author's description is terse - "Return all the items that pass a truth test" - but the intent is clear: when your data is a dict (like the config objects, metadata maps, or group results this pack loves to produce) and you want to drop the entries that fail a check, this is the node.

Where _.filter works on lists, _.filterObject is the one you reach for when you've got a {key: value} structure and the value is what decides. "Which settings still have non-empty values?", "which entries in this metadata dict are actually set?"

How it works

Generated wrapper around underscore3, the bundled Python port of Underscore.js. Same family logic as _.filter - iterate, test, keep the passing ones - applied to object values. The honest caveat, familiar from _.collect and _.detect: in this generated build only the primary obj input is exposed on the socket. The iteratee that defines the test isn't wired up as a separate input here, so in practice the node filters against the port's default behavior - which, with no predicate supplied, means keeping the truthy values. For a predicate-driven version, _.filter with a key selector is where the full controls live.

Inputs and output

• obj (any type) - the dict whose values get tested. Accepts a _.CHAIN to continue a chain.
• Output: * (any type) - the filtered object (the surviving key/value pairs).

No widgets.

Installing it

Part of sfinktah/comfy-ovum ("comfy-ovum"):

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

No model downloads; light dependencies; underscore3 bundled in the repo.

The honest take

_.filterObject is another of the family's partially-wired wrappers: the concept is sound (filter a dict's values), the input surface is thin (just obj). If you need "keep only truthy values out of this dict," it does the job in one node. If you need a real predicate - "only entries where the value equals X" - you'll get more mileage from _.filter or a key-selector approach. That's the pattern across this whole suite, and it's exactly why the author's README calls the underscore nodes a work-in-progress. Nice to have when the default behavior fits; don't contort a workflow to use it.