OpenCV imdecode_0

imdecode_0 decodes an image from an in-memory buffer instead of from a file path. In normal OpenCV usage you'd call cv2.imdecode(buf, flags) where buf is a byte string or a numpy array of bytes - the raw encoded file contents (PNG, JPEG, WebP…) sitting in RAM, never written to disk. This node is the ComfyUI wrapper around that call.

When does that matter in a ComfyUI workflow? The honest answer: rarely, and only for specific plumbing situations. The cases that make sense:

• Some other node in your graph already holds the encoded bytes - you got them from an HTTP request, an API response, a database blob, or another custom node that fetches images - and you want to turn those bytes into an actual decodable image without a temp file in between.
• You're building a pipeline that should never touch the filesystem between source and result (cleaner for reproducible graphs, and it sidesteps permissions entirely).
• You want the decode half of a byte-handling pipeline. (The encode half, cv2.imencode, never got a node: its return type is a plain numpy array that the pack's generator doesn't support, so you won't find an imencode node here - a small preview of how this pack's coverage is uneven.)

If you just want to load an image from disk, imread_0 is the right node. If you want ComfyUI's own file dialog, Load Image is. imdecode is the "I have the bytes already" special case, and it's a real one - it's just not the common one.

How it works. The input buf (NPARRAY) holds the encoded image data as a byte array, and flags (INT) says how to decode it. Flags are the standard IMREAD_* codes: 1 (IMREAD_COLOR, the default 3-channel BGR decode), 0 (IMREAD_GRAYSCALE), -1 (IMREAD_UNCHANGED, keeps the file's original channel count, useful for PNGs with alpha or 16-bit data). 1 is the safe default; -1 is what you want if you care about the file's native depth/channels.

Output. One nparray (NPARRAY) - the decoded image, in the pack's BGR uint8 0–255 form. Convert to a ComfyUI IMAGE with Nparrays2Image.

Installing. Standard for this pack - ComfyUI Manager, search "opencv-comfyui", or:

cd ComfyUI/custom_nodes
git clone https://github.com/geroldmeisinger/opencv-comfyui
pip install opencv-python-contrib

Restart ComfyUI; it's under image/OpenCV.

Where people get burned. The buffer has to be actual encoded file bytes, not a decoded image array - feeding it a normal BGR image and expecting a round trip gives you an assertion error or None. If the decode fails, OpenCV returns None and the node will blow up downstream with something like the README's 'NoneType' object has no attribute 'shape' - that error is the pack's tell that an nparray wasn't really an image. And remember the pack's color conventions: the output is BGR, so if you mix this into a graph that expects RGB you'll get swapped channels. The batch-size-one rule also applies to any image tensor entering a pack node, though here the input is bytes, so that's mostly moot.

Why _0 and _1? OpenCV's stub lists imdecode twice; the generator emitted both. The two generated classes are identical - same cv2.imdecode(buf, flags) call, same inputs, same output. There is no practical difference; use whichever.