cv2.applyColorMap (2/2)

The second cv2.applyColorMap overload takes your palette instead of OpenCV's. You hand it a 256-entry ramp, it maps every grey value through it. That's how you colorize a depth map with your own near-to-far gradient, turn a luminance mask into a heat signature, or build a false-colour transfer curve that matches whatever the rest of your pipeline uses.

It's a niche node, and the niche is real: the moment you're producing visualisations for other people, "jet" and "viridis" stop being acceptable defaults, because everyone else's tooling has its own ramp.

How it works

src is grey (or colour, which OpenCV greys internally with BGR weights); userColor is your lookup table, and OpenCV requires it to be exactly 256 entries of CV_8UC1 or CV_8UC3. Value 0 of the source indexes entry 0, 255 indexes entry 255, and every grey in between picks its corresponding row. There's no interpolation and no normalization - it's a straight table lookup, the same mechanic as cv2_LUT, just expressed as a ramp rather than a per-channel table.

The output is 3-channel BGR and echoes src's format, so an IMAGE link comes back as an IMAGE you can preview.

Inputs and outputs

• src (COMFY_MATCHTYPE_V3) - 8-bit grey or colour.
• userColor (NPARRAY,IMAGE,MASK) - the 256-entry ramp. CV_8UC1 gives you a grey ramp rendered through the palette machinery; CV_8UC3 gives you colour.
• result - the colorized image, echoing src.

Building the ramp

The awkward part is authorship: you need a 256-long array, and ComfyUI's IMAGE type is [B,H,W,C], so a 1×256 or 256×1 image works once bridged to an array.

Three workable routes:

• From an image. Crop or resize any gradient - a sky, a colour wheel, a LUT strip - down to 256×1, then Image → CV Array. This is the most practical one, and it's how people accidentally discover that a photo's colour ramp makes a beautiful colormap.
• From literals. CV Points / CV Constant Like plus the arithmetic wrappers: build three linear ramps (one per channel), stack them with CV Concat Arrays, cast to uint8 with CV Cast Array. More nodes, total control.
• From a plotted ramp. The pack's plotting nodes (CV Chart Series, CV Plot2D) can produce a strip you then bridge back into an array.

Then check it with CV Array Shape before wiring it in - "256" is the number that matters, and "256×3" is not the same as "256×1×3" as far as OpenCV's expectations go.

Install

ComfyUI Manager → comfyui_cv (ComfyUI CV), or:

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

Restart ComfyUI. Python ≥ 3.12, recent V3-API ComfyUI, behaviour pinned against OpenCV 5.0.0.93. The contrib wheel is the declared dependency; a non-contrib opencv-python installed over it silently empties the contrib submodules.

Where people get burned

Not 256 entries. OpenCV will not stretch or sample your ramp. A 255- or 257-row array is an error, not a resize.

Float ramps. Build it as uint8. A float32 array goes through the pack's conversion paths unpredictably enough that you'll spend an evening on it - CV Cast Array to uint8 explicitly.

Assuming normalization. Same trap as the named-palette overload: your data has to actually span 0–255, or you'll only ever touch a slice of your ramp. A depth map spanning 40 values renders as 40 colours regardless of how nice the gradient is.

Expecting a colour source to stay colour. A 3-channel src is greyed first (BGR weights), so your beautiful RGB ramp authoring doesn't change which values get mapped - only what they map to.

Wondering why the named-palette node was easier. It was. Reach for this one when you need a specific ramp, and for cv2_applyColorMap with colormap when viridis will do.