cv2.ximgproc.qconj

One input, one output, no parameters, and a name that tells you nothing unless you already know quaternions. qconj negates the imaginary parts of a quaternion array - for the ones this module deals with, that's (real, B, G, R) becoming (real, −B, −G, −R). That's the whole operation.

Why it's in a vision library: conjugation is how you turn a multiplication into a correlation. In practice this is the step that makes matched filtering and phase-only filtering work in the quaternion domain - the colour-aware equivalents of "find this pattern in the image" and "keep only the phase, throw away the magnitude". If you're porting a quaternion colour-watermarking or quaternion colour-edge paper, this node will appear somewhere in the recipe, often right before a qmultiply.

What you feed it

qimg - a 4-channel quaternion image, which means the output of the generated cv2.ximgproc.createQuaternionImage wrapper (8-bit or float BGR in, (real, B, G, R) out). Feeding this node a normal 3-channel ComfyUI IMAGE will not do something sensible; it'll be rejected, because the whole family is defined over four planes.

Output is a single NPARRAY in the same quaternion layout. It stays in quaternion space - do not wire it into CV Array → Image, because the first plane is not an alpha channel and the result would look like a colour-shifted mess. If you genuinely want to look at it, slice a plane with CV Slice Array and convert that, or check shape and statistics with Inspect CV Data.

Where it sits in a pipeline

The realistic chain is: createQuaternionImage → qdft (forward) → qconj on the kernel side (or on the spectrum, depending on the recipe) → qmultiply → qdft (DFT_INVERSE, same sideLeft) → real part or magnitude → CV Array → Image. Quaternion multiplication does not commute, so which operand you conjugate is not cosmetic; it's the difference between correlation and convolution, and between "peak at the match" and "peak at the mirror image of the match".

If that sounds like a lot of ceremony for a colour edge map: it is. qconj is a five-line function wrapped as a node, and it exists in this pack because the pack auto-generates a wrapper for essentially every top-level cv2 and contrib function it can see. That's the pack's value proposition - completeness - and also its main hazard, since completing the set means shipping plenty of nodes for pipelines most people will never build.

Install

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

Restart ComfyUI, or install ComfyUI CV from ComfyUI Manager. Python ≥3.12, a recent ComfyUI built on the V3 node API, and opencv-contrib-python-headless~=5.0.0.93; nothing to download. qconj is a contrib function, so a plain opencv-python wheel installed over the contrib one silently empties the contrib submodules and the node vanishes from the menu - tools/repair_opencv_contrib.py --check reports that state and --apply repairs it.

Common issues

"It looks the same." For a real-valued input (a grey image stuffed into four channels with the imaginary parts at zero) the conjugate is identical. You only see an effect when the imaginary planes are non-zero.

Downstream wants a picture. Convert at the end of the chain, not in the middle. Every q* node expects quaternion data; a bridge node in the wrong place breaks the pipeline silently, not loudly.

No documentation to fall back on. OpenCV's page for this function is a signature and a sentence. The pack's own disclaimers matter here: these wrappers are generated, uncurated, built with heavy LLM assistance, and not recommended for production without your own review. Treat community tutorials on the quaternion domain - of which there are few - as the reference, and this node as the plumbing.