CV Image Corners

Four numbers per axis. That's the whole node. It takes an image - actually it only reads the shape, the pixels are never touched - and emits the four corners as a 4x1x2 float32 array in a fixed order: top-left, top-right, bottom-right, bottom-left.

Why would you want the corners of your own image? Because they're the reference outline that lets you project the frame into a different view. Send the array through cv2.perspectiveTransform with a homography and you get back where those corners land after the warp - the quad you'd need to draw, mask, or paste into. Same matrix, so the projected outline and the warped image agree by construction instead of agreement-by-eyeball, which is how overlays usually get built and usually get wrong.

The mechanical detail that matters: the input socket accepts an NPARRAY, or a ComfyUI IMAGE/MASK directly, in which case you get frame 0 of the batch. So it's happy sitting right next to Image → CV Array or downstream of any of the pack's other nodes, and it doesn't care what the image contains - a black frame and a photo yield the same corners.

When it's the right node

Concretely: warp an image into another view and you also need to know where its boundary went (draw it with the pack's segment/polyline drawing nodes, or use it as the source quad for a composite). Project an object's footprint from model space into the camera view. Build a quad from the frame and then feed that quad to a warp-to-quad routine. In all of those, you'd otherwise be typing corner coordinates by hand and silently baking in an assumption about image size - this node reads the actual size, so the graph survives a resolution change upstream.

If you're working with detected features rather than the frame boundary, this isn't the node - that's CV Detect Features / CV Detect Corners territory. And if you're after the four corners of a detected quad in the image, CV Find Quadrilateral is what you want. This one is deliberately dumb: your image's own outline, exactly.

Install

ComfyUI Manager, search the pack title comfyui_cv (repo bmad4ever/comfyui_cv). Or:

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

Restart afterwards. Requirements are unusual enough to be worth repeating: Python ≥ 3.12 and a recent ComfyUI on the V3 node API. This pack declares nodes as io.ComfyNode with an io.Schema and has no NODE_CLASS_MAPPINGS anywhere, so an older ComfyUI will not load it - and you won't get a missing-node error, you'll get nothing.

One Python dependency:

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

The pin is the build the pack is curated against. The contrib part is mandatory: all four OpenCV wheel distributions share a single site-packages/cv2, so installing a non-contrib wheel over a contrib one silently empties the contrib submodules and contrib nodes drop out of the menu with no log line to explain it. The pack ships tools/repair_opencv_contrib.py - run it with --check to diagnose, --apply to repair.

Failure modes worth knowing

There isn't much to break here, which is the nice thing about small nodes. The realistic mistakes are downstream: expecting the output to be a ComfyUI-native type (it's an NPARRAY, and most core nodes won't accept it), assuming the corner order, or feeding a batch to a function expecting one image and wondering why you only ever see frame 0's geometry. Order is top-left, top-right, bottom-right, bottom-left - clockwise from the origin - and yes, it matters when you hand it to something that treats the four rows as a polygon.

The pack's README, as with everything under bmad4ever/comfyui_cv, asks you to read its disclaimers: heavy LLM assistance in the codebase, example workflows tuned to specific sample data, updates not planned, and an explicit warning against production use without your own review. For a node that emits four coordinates, that's cheap advice to follow.