cv2.solvePoly

solvePoly finds the real roots of a polynomial of arbitrary degree - where the curve crosses zero, for any polynomial you can write down. For degree three there's a closed form (cv2.solveCubic handles that exactly and instantly); past four there isn't, so OpenCV builds the companion matrix, computes its eigenvalues, and then polishes the result iteratively. That last part is why this node has a maxIters field, and it's the honest signal that this is a numerical method rather than an exact one.

Where does a high-degree polynomial come from in a vision graph? Camera and lens models are the usual answer: distortion corrections and inverses, radial mappings, the rational-map model behind the pack's remap nodes, fits to a response curve, and geometric intersection problems where a line meets a fitted curve. If you've fit a polynomial to data with another node, this is the node that finds where it hits a threshold or a zero.

Inputs

• coeffs - the polynomial's coefficients, as an NPARRAY. OpenCV's convention is highest degree first, matching solveCubic. Order matters and getting it backwards doesn't raise - it quietly solves a different polynomial.
• maxIters (optional) - the iteration cap for the refinement stage; default 300, matching OpenCV. Raise it if a high-degree polynomial comes back short of roots; it costs time, not accuracy.

No IMAGE or MASK link is accepted - this is numeric data. Coefficients usually arrive from Parse Matrix, CV Scalar, CV Array To Numbers, or a fit computed upstream; CV Cast Array is worth reaching for to make sure you're in float64 before you start, since higher-degree roots are where float32 starts to hurt.

Outputs

Two sockets, and reading them correctly is the whole skill:

• float - how many real roots were found. Complex roots are not returned.
• nparray - the roots.

The array is sized for the degree, but only the first float entries are meaningful - the rest are whatever was in memory. Read the count first. That's the same contract as solveCubic, and on this node the count matters even more, because a degree-8 polynomial with two real roots gives you six irrelevant slots you must not wire anywhere.

Install

Manager → search ComfyUI CV, or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv
pip install "opencv-contrib-python-headless~=5.0.0.93"

Restart ComfyUI. Python ≥ 3.12 and a recent ComfyUI with the V3 node API. No model files involved.

Where people get burned

Coefficient order. Highest degree first. This is the single error that produces a confidently wrong answer with no warning, and the easiest place to check when a result looks like noise.

Real roots only. A polynomial that genuinely has two real roots can have six complex ones, and this node's count will be 2. If you expected a specific number of solutions, the missing ones are complex and the polynomial isn't the one you thought you built.

Iteration-dependent accuracy. The companion-matrix step is a good first estimate; the iterative polish is what makes it accurate. maxIters too low (or a very high degree with ill-conditioned coefficients) leaves you with near-roots. Compare against cv2.solveCubic on a degree-3 case to see what "converged" looks like on your machine.

Degree limits. OpenCV caps the degree it accepts. If you're building a polynomial from a long fit, check how many terms you actually have before assuming arbitrary degree means arbitrary.

Ill-conditioning. Wildly-scaled coefficients - 1e12 next to 1e-3 - wreck any root finder. Normalise the polynomial (divide through) before feeding it in; that's your job, not the node's.