CV Array → Image

What it's for

You've run the filter. The array looks right in a preview node. Now you need it to be an actual image so the rest of the graph - a save, an upscaler, a detailer, an img2img pass - can use it.

That's this node. One ndarray in, one ComfyUI IMAGE out, with the boring parts handled: grayscale, BGR, RGB, BGRA, uint8, uint16 and float all land somewhere sane. It's the single-frame counterpart of CV Batch → Image Batch, and the exact inverse of the pack's CV Image → CV.

How it works

The input accepts a grey [H,W] array, a [H,W,3] colour array or a [H,W,4] with alpha. Dtype is handled automatically - uint8 and uint16 go through the usual 8-bit path, floats get scaled. If there's a fourth channel, the alpha also comes back as a separate MASK output, which is how you get transparency out of a BGRA result.

The channel_order dropdown is the only real decision:

• BGR (OpenCV default) - the standard cv2→IMAGE conversion: channels swapped to RGB and scaled to 0..1. Correct for anything a normal OpenCV function produced.
• RGB - for data that's already RGB-ordered.
• RAW - no conversion at all. Float32 values pass through as-is, with no uint8 conversion and no clamping to 0..1. This is for HDR radiance maps and similar float data where the 0..1 squeeze would destroy the information you spent the pipeline collecting. But read the next section before you pick it.

Where people get burned

RAW does not convert channels. This is stated plainly in the node's own description and it still catches people: in RAW mode the input must already be RGB-ordered to be an IMAGE, because ComfyUI's image format is RGB. Feed it BGR data and you get swapped colours with no scaling to hint that something's wrong. If you need BGR→RGB, do it explicitly upstream with a cv2.cvtColor node, and then decide about the scaling.

Red and blue swapped means you converted twice. BGR in, BGR mode here (swap #1), plus a cvtColor somewhere upstream (swap #2) equals an image that looks like a bad camera preset. Count your conversions. Exactly one swap belongs in the chain.

Floats get clipped without complaint. If your float data ranges past 1.0 and you didn't choose RAW, you've just clamped it. That's fine for a display path and fatal for a data path.

Single frame only. Hand this a genuine batch and you're in the wrong node - CV Batch → Image Batch is the other one, and it has its own subtlety about 3-D arrays being read as grey batches.

Not sure what you have? The node's own advice is to check first: run it into Inspect CV Data and look at the shape and dtype. Guessing at a four-channel array is how you end up with a red image and no idea why.

Install

ComfyUI Manager, search ComfyUI CV. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv

Restart, then:

pip install "opencv-contrib-python-headless~=5.0.0.93"

Python ≥ 3.12, and a ComfyUI recent enough to be on the V3 node API.

A note on the pack

comfyui_cv is bmad4ever's GPL-3.0 fork of geroldmeisinger's opencv-comfyui. It exposes ~470 auto-generated cv2.* wrappers plus a few hundred curated nodes, and the README is unusually frank about it: LLM-assisted development, test-driven overfitting in places, patches that are deliberately tuned to sample datasets, "not recommended for production without a thorough independent review of the used source code". For a bridge node like this one, the review is quick and worth doing - a dozen lines, and you'll know exactly what it does to your range and your channel order, which is more than you can say for the average node in a ComfyUI graph.