cv2.colorChange

The honest pitch

cv2.colorChange shifts the colour of the region your mask selects, using per-channel multipliers. That's it. It's the cheap, deterministic alternative to "recolour this bit" via img2img or a controlnet repaint - and if the change you want is "make the jacket read more blue and less orange", doing it with a diffusion pass is like using a chainsaw to cut a sandwich. The whole deterministic layer (post-processing.md has the argument) exists so you don't re-roll a face to fix a hue.

It's a raw wrapper from ComfyUI CV (bmad4ever/comfyui_cv), category image/CV/low-level/cv2 C. Same function signature as Python's, same caveats.

How it works

You supply an 8-bit 3-channel source and, optionally, a mask. Where the mask is non-zero, the red / green / blue multipliers are applied; where it's zero, the image is untouched. Practically it's a gain, not a hue wheel: red_mul=1.4 pushes the region red-ward, 0.7 pulls it away. The author's own tooltip names the useful band - between .5 and 2.5 - and that range is a hint about what the operation physically is. Push past it and you're not shifting colour any more, you're saturating one channel to clipping and calling the result a style.

Because it's a mask-gated gain, the mask is the whole game. Get a clean region from anywhere - cv2.inRange, CV Color Range from this same pack, a SAM mask, a hand-painted one - because the results are only as tidy as the mask boundary. No feathering happens here. The pack's curated CV Color Range and CV GrabCut are the usual upstream neighbours, and everything masking-detection-detailing.md says about how you obtain a mask applies unchanged.

Inputs and outputs that matter

• src - required, 8-bit 3-channel. The socket takes an IMAGE or an NPARRAY; it is colour-semantic, so a MASK is not accepted here.
• mask - optional. Leave it unconnected and OpenCV treats the whole frame as selected (the wrapper passes None, which is not an error). Takes NPARRAY / IMAGE / MASK.
• red_mul, green_mul, blue_mul - FLOAT, default 1.0 each. These are preset to OpenCV's own defaults, so an untouched node is a no-op copy. Remember the order: OpenCV is BGR, but these multipliers are named after the colour, not the plane.
• result - echoes the format of src. An IMAGE link comes back as IMAGE, ready for preview.

Optional inputs sit under "show advanced inputs".

Installing the pack

Through Manager, search ComfyUI CV; by hand:

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

Restart ComfyUI. Requirements: Python ≥ 3.12, a ComfyUI new enough for the V3 node API, and opencv-contrib-python-headless~=5.0.0.93. That single OpenCV wheel is the pack's only real dependency - which is also the pack's single biggest failure mode.

Where people get burned

• cv2 install collisions. Custom-node dependency conflicts are the daily complaint in the ecosystem (comfyui-ecosystem.md has the thread titles to prove it), and OpenCV sits right in the middle of the worst of them: the "insightface wants numpy 1.x, opencv wants numpy 2.x" class of deadlock. Worse, the cv2 namespace is shared by every OpenCV wheel - if a later pip install drops plain opencv-python on top of a contrib build, contrib submodules silently vanish. tools/repair_opencv_contrib.py --check diagnoses it; --apply repairs it.
• Broken cv2 in the Windows portable build. ImportError: DLL load failed while importing cv2 takes out every cv2-based pack at once. If this node refuses to exist, check whether anything OpenCV-shaped loads before debugging the node.
• Mask edges are hard. No blending, no blur. If the recolour looks like a sticker, blur the mask upstream - that's an inpainting-layer problem, not this node's.
• Support expectations. The README is explicit: LLM-assisted development, possible overfitting to test cases, "not recommended for use in production" without your own review, and no planned updates. The pack has essentially zero community footprint on Reddit, so nobody has already hit your edge case for you.