cv2.solveLP (2/2)

If you landed here after finding cv2.solveLP (1/2) in the menu, the difference is small and worth stating once: OpenCV has two overloads of solveLP, and the pack generates one node per overload. This is the two-argument version. Its sibling exposes a third field, constr_eps.

Both do the same thing - solve a linear program by the simplex method - and both return OpenCV's SolveLPResult status code plus the solution vector. Same inputs otherwise, same outputs, same numerics. If you don't know which one you want, you probably want the one with the tolerance.

Inputs

• Func - the objective's coefficient vector c, as an NPARRAY. A row vector is what OpenCV documents; a column vector is accepted and read as cᵀ. Float32 or float64 only.
• Constr - the constraint matrix, m rows by n+1 columns: the last column is b, the first n are A.

And nothing else. No constr_eps, so feasibility is judged at exact tolerance - which means a system that is feasible only up to floating-point rounding can be reported as infeasible. That's the difference worth knowing about, not a bug in either variant.

Outputs

• int - the SolveLPResult status. It separates "solved" from "unbounded", "infeasible" and "multiple optima", and it's the output that tells you whether the other one is worth reading.
• nparray - the solution.

Which one should you wire?

Pick this node when your problem is exactly posed - integer-ish coefficients, a system you constructed rather than measured - or when you deliberately want strict feasibility so that an infeasible report is meaningful.

Pick (1/2) when the constraint rows come from measurements: fitted lines, detected points, calibrated parameters. Then a tiny allowed disparity is what stops the solver from failing on rounding, and constr_eps is the knob. The default there is 0, so if you switch variants and still get "infeasible", check that you actually raised it.

The two nodes have distinct ids and display names, so a workflow that uses one will not silently start using the other - which is the point of the (1/2) / (2/2) split. The same convention shows up elsewhere in the pack for functions where OpenCV exposes more than one signature (and for submodule functions, where sharing an id across cv2.inpaint and cv2.xphoto.inpaint would be actively dangerous, since their mask conventions are opposite).

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"

Then restart. Needs Python ≥ 3.12 and a recent ComfyUI built on the V3 node API.

Where people get burned

The m×n+1 shape. b goes in the last column. A matrix assembled the other way reports a shape problem, so this one fails loudly - which is the good failure mode. The quiet failure mode is the inequality sign convention, which this node doesn't police; OpenCV's documentation is the authority.

Reading the status code loosely. "Infeasible" and "unbounded" are different diagnoses with different fixes, and both look like "the output is nonsense" if you treat the int as decoration.

Assuming it's exercised. No shipped example workflow uses solveLP. It's one of the ~470 auto-generated wrappers - present because the generator walks OpenCV's function list, not because the author needed it. That's not a reason to distrust the algorithm; it is a reason to build a small problem with a known answer first, using Parse Matrix to type it, and check the result before you build anything on top.

Contrib wheel collisions, still the top support ticket for this pack: all four OpenCV distributions share one site-packages/cv2, and installing a non-contrib wheel over the contrib build leaves contrib nodes missing with no error in the log. tools/repair_opencv_contrib.py --check finds it.