⚠️ CV ZeroStride Like

The ⚠️ in the name isn't decoration, and the node's own description starts shouting at you in capitals about halfway through. CV ZeroStride Like is the oddest thing in the pack, and it's worth understanding precisely because it's a trap you can walk into by accident.

What it is

It emits a 0-stride broadcast view. In source terms, that's np.broadcast_to(np.array([value], dtype), shape) - one single element, stretched over the shape of whatever you wired in. Every pixel in that "array" is the same underlying byte. It allocates almost nothing.

The idea is legitimate. OpenCV has a pile of functions that write into a destination array you hand them: cv2.randu, cv2.randn, cv2.accumulate, and every drawing primitive. If you're going to hand cv2 a canvas and it's going to overwrite it entirely, allocating and filling a full-size array first is pure waste. That's the optimisation this node offers - a destination that costs one element.

The part the author is honest about, and you should believe him

This pack's low-level wrappers copy every array you connect before it reaches cv2, deliberately, so that a cached upstream output never gets mutated in place. The destination array included. So the full-size allocation happens anyway - it just happens inside the wrapper instead of inside this node.

The node description says it plainly: the saving is only this node's own allocation. Which means, in a real workflow, the saving is close to nothing. If you want a constant canvas, reach for its sibling CV Constant Like, which fills a real array with np.full and has effectively the same inputs minus the landmine. This one is a plumbing experiment you're allowed to play with, and the pack's own docs table files it under "advanced/diagnostic".

Inputs and output

• nparray - only its width and height are read, plus its channel count and dtype if you choose "same as input" for the two combos below.
• value - the single backing element that gets broadcast. Default 0. Remember it doesn't set the content of anything cv2 writes; it only sets the view.
• channels - grayscale (single channel) or same as input.
• dtype - same as input, uint8 (the default, matching CV Constant Like), uint16, int32, float32 or float64.
• nparray (output) - the broadcast view itself, typed as NPARRAY.

How not to get hurt

Use the output only as the dst of a cv2 node that writes over it. Never as a source. Not into a preview, not into a mask consumer, not into anything that turns it into a tensor - those read every element, and a broadcast view has nothing to read. At best you get an array where every row is identical; at worst the consumer rejects the non-contiguous strides.

One more caution: don't read "0-stride" as "cheap random field". It is not noise, it is not a canvas with useful contents, and it is not a drop-in replacement for a real array in a chain you didn't write.

Install

Same as the rest of the pack:

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

Or search comfyui_cv in ComfyUI Manager. It needs Python ≥ 3.12 and a ComfyUI on the V3 node API, and the OpenCV wheel has to be the contrib build - swapping in plain opencv-python empties the contrib submodules and nodes disappear.

So when would you actually use it?

Honestly? Rarely, and deliberately. It shows up in the pack's own example graphs as a disposable stand-in array - a "nothing" canvas a later cv2 call is expected to overwrite - which is the safe pattern. If you find yourself wiring it into anything that reads pixels for a decision, stop and use CV Constant Like instead. The five seconds you save are not worth a silent bug.