CV Points
Type coordinates, get geometry the cv2 nodes accept
- points
- count
Most of this pack's point inputs come from something that detects or clicks them. This one is the opposite: you type the numbers. It is the general-purpose authoring node for point arrays, and it is how you get a shape into a CV graph that nothing is going to find for you.
What it's for
Three nodes in comfyui_cv make points from scratch: CV Scalar makes one vector, CV Grid Points makes a regular grid, and this one makes whatever you write. Your points widget takes a Python list literal:
[[x, y], ...]→ an Nx1x2 array - image points, a polygon, the four corners a warp wants[[x, y, z], ...]→ an Nx1x3 array - 3D object points in world units, the thingcv2.solvePnPandcv2.projectPointsconsume- a single
[x, y]or[x, y, z]is accepted as one point
That last form is the one people underestimate. The classic use is augmented reality: define a virtual cube's eight corners in the model's own coordinate system, solve the pose of a cube against a photo, then project those same points back through the pose to draw the wireframe. The camera does the hard part; you only had to write eight lines of coordinates.
It also fills a gap you hit constantly in a graph environment: a polygon you measured off a reference, a bounding box you typed, corner points for CV Quad Warp or CV Points To Contour - anything where the answer is "I know where it is, I just can't detect it reliably." Because the layout comes out as the same Nx1xD shape the detector and grid nodes emit, the literal version drops into any socket those feed, so you can prototype with hand-typed points and swap in a detector later without rewiring.
Inputs and outputs
Two inputs. points is the literal, and dtype is the element type - leave it on float32, which is what the cv2 geometry functions expect for points. The alternative matters mainly when you're feeding something that wants integer coordinates.
Outputs are points (your Nx1x2 or Nx1x3 array) and count (how many points you wrote). count is the cheap sanity check to wire into a text preview: if it says 6 when you expected 8, you mistyped a row and the node happily parsed what you gave it.
Installing
Standard for the pack - ComfyUI Manager, search "ComfyUI CV", or:
cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv
# restart ComfyUI
Python ≥ 3.12, a recent V3-API ComfyUI, and opencv-contrib-python-headless~=5.0.0.93 (plus numpy and torch). This particular node needs nothing else - no models, no downloads.
Gotchas
The literal has to be well-formed. It's parsed, not evaluated as an expression, so a stray trailing comma inside the inner list, or a [x y] missing its comma, will not do what you meant. When a shape-dependent node downstream starts throwing, check count first.
Watch the dimensional mismatch between conventions. 3D points here come out Nx1x3, which is what this pack's own nodes want; some raw cv2.* wrappers in the same pack are happier with an Nx3 array. If a generated wrapper complains about shape, an array reshape node will fix it faster than debugging the numbers.
And remember points are in pixels for the 2D case. They are not normalized 0–1 like the widgets on CV Annotate Points store internally - if you are hand-authoring corners for an annotation-style node, you are writing pixels, and the node that produced them is the one that knows the image size.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| points | STRING | [[0, 0, 0], [1, 0, 0], [1, 1, 0], [0, 1, 0]] | List of points as a literal: [[x, y], ...] for 2-D or [[x, y, z], ...] for 3-D. A single [x, y[, z]] is also accepted. |
| dtype | COMBO | float32 | Element type. float32 is what cv2 geometry functions (solvePnP / projectPoints) expect for points. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| points | NPARRAY | Nx1x2 or Nx1x3 point array. |
| count | INT | — |