OpenCV hasNonZero_1

hasNonZero_1 is, byte for byte, the same node as hasNonZero_0. Same inputs, same outputs, same underlying cv2.hasNonZero call. The _1 suffix isn't a different feature - it's the author's auto-generator numbering every overload of the OpenCV function, and hasNonZero has two Python bindings that turned out to be identical. So if you've already read the article for hasNonZero_0, you've read this one; both do one thing: return True if any pixel in the input nparray is non-zero.

What it's for

The same gate logic as the _0 variant. You've got a mask or a processed image and you want to know whether it's all zeros before you let the workflow continue. If the mask is empty you can skip the expensive downstream step; if it's not, you route the image into it. One input (src, NPARRAY), one output (bool), and that's the whole node.

Why two copies exist

The generator behind this pack parses OpenCV's .pyi type stubs and produces a node per function overload. Some overloads differ meaningfully - Canny_0 through Canny_3 handle different parameter shapes. Others, like this one, collapse to the same signature and the generator happily emits both anyway. You get a duplicate. It's harmless; pick whichever, they're interchangeable. ComfyUI's search will show both under "OpenCV hasNonZero_0/1" and there's no reason to prefer one.

Install

Identical to the rest of the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/geroldmeisinger/opencv-comfyui

or "OpenCV" via ComfyUI Manager, plus:

pip install opencv-contrib-python

The one honest caveat

It's the same trap as _0: hasNonZero isn't a threshold. A single stray bright pixel makes it True. If you want "does this mask have enough content to be worth processing", count first with countNonZero_0 and compare the integer to a cutoff - that's a two-node pattern that behaves the way beginners expect hasNonZero to behave on its own.