CV DCT Flags

What it's for

OpenCV's flag parameters are integers made of OR-ed constants - DCT_INVERSE, DFT_SCALE, that whole family - and if you've ever tried to configure one from memory you know how it goes. Was it DFT_COMPLEX_OUTPUT | DFT_SCALE, or does scale go with real output? Is it 16 or 32? The constants are also version-dependent, so the number you memorised from a tutorial may quietly mean something else.

This node authors the value as a flag builder: in the UI you get a base dropdown plus one toggle per flag, and each toggle ORs in its bit. Out comes a pipe-joined string of constant names - something like none (0) | DCT_INVERSE - plus the resolved integer.

Its actual job is fan-out. Wire the flags string into the flags input of any number of cv2_dct / cv2_idct nodes and they all share one configuration. Change the transform's mode in one place, and every consumer follows. That's the same discipline as the seed primitive and the shared size pair, and it's the reason the pack ships a dozen of these instead of one.

It's a type-bridge node in the pack's own taxonomy: it moves a value, it doesn't process pixels.

The outputs

• flags - the pipe-joined flags string. This goes into the flags input of the generated wrappers, which take flag parameters as text precisely so a node like this can drive them.
• value - the resolved integer. For a raw int flag parameter that isn't text-typed, or for use inside MathExpression where you need to do arithmetic on the bits.

Knowing which to use matters: the string format is the one the pack's wrappers read; the integer is the one you use when you're somewhere that just wants a number.

The flags input on this node is itself the authoring widget - in the UI it renders as the base dropdown and the toggles, and you can wire it from elsewhere if some other node is producing the selection.

The family

This isn't a one-off; it's a pattern with siblings across the pack, one per flag-taking API family:

• CV DFT Flags for cv2_dft / cv2_idft (things like DFT_COMPLEX_OUTPUT, DFT_SCALE | DFT_REAL_OUTPUT)
• CV Warp Flags for cv2_warpAffine / warpPerspective / warpPolar / remap
• CV Optical Flow Flags for the LK and Farneback wrappers - note each ignores the other's bits
• CV Chessboard Flags, CV GEMM Flags, CV SVD Flags, CV Region Property Flags

If you're configuring two or more nodes with the same flag semantics, this is how you keep them honest. CV Region Property Flags exists for a slightly different reason - a promoted subgraph input can't carry a toggle grid, so the widget has to live in a node - which tells you the design intent: the value belongs on a wire, not duplicated in a dozen widget states.

Install

ComfyUI Manager, search ComfyUI CV. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv

Restart, then:

pip install "opencv-contrib-python-headless~=5.0.0.93"

Python ≥ 3.12, plus a ComfyUI recent enough for the V3 node API.

Where people get burned

"none (0)" is a real setting, not an empty one. A forward DCT with no bits set is the normal case - it's only the inverse-ish modes that need something. Don't turn bits on looking for an "enabled" switch.

Flags set on the wrong node. The flags live on the node that authors them; downstream wrappers just read the string. If a transform isn't behaving, check whether it's actually wired from the flags node or still holding its own stale default.

Integer versus string. Pasting the pipe-joined string into something that wants an int gets you a parse error or, worse, a silent zero. Use value there, and use flags for the pack's own wrappers.

The wrapper might not exist in your build. The ~470 raw cv2_* nodes are generated from whatever OpenCV exposes in your install, so on a lean build a flags node can be sitting in your graph pointing at a wrapper that isn't there. If a node you saw in a workflow is missing, that's usually why - and a non-contrib wheel installed over a contrib one empties the contrib submodules and removes a whole tier of nodes. tools/repair_opencv_contrib.py --check will diagnose it.