OpenCV convertMaps_1

convertMaps_1 is the second numbered overload of cv2.convertMaps, and yes, it's identical to convertMaps_0. OpenCV's type definitions list this function once for MatLike arrays and once for UMat, the pack auto-generates a node for each, and since both feed the same NPARRAY socket you get two nodes that do exactly the same thing. If you're here for the how-to, read convertMaps_0; this page is the "you probably landed on the wrong twin" signpost.

For the record, the shared behavior: map1, map2 (NPARRAY), dstmap1type (INT), nninterpolation (BOOLEAN) in, and two NPARRAY outputs (nparray_0, nparray_1). It converts remapping coordinate maps between representations - the common case being two separate single-channel float32 maps (dstmap1type = 5) merged into the single two-channel float32 map (dstmap1type = 13) that remap_0 wants. The optional dstmap1/dstmap2 inputs are OpenCV out-parameters; leave them empty and let the node allocate.

This is genuinely niche plumbing - you'd only touch it inside a distortion/warping pipeline, not a normal generation workflow. If you don't know why you'd need a remapping map, you almost certainly don't need this node.

Install and the standard caveats

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

Or ComfyUI Manager → search opencv-comfyui, then restart. No models to download.

The pack rules that apply: these nodes eat numpy NPARRAYs, not Comfy IMAGE tensors, so route through Image2Nparray (batch size 1 only) on the way in and Nparrays2Image on the way out. And remember the maps themselves are coordinate arrays, not viewable pictures - trying to display them produces the familiar 'NoneType' object has no attribute 'shape' complaint.

Bottom line: between convertMaps_0 and convertMaps_1, there is no bottom-line difference. The _1 suffix is an artifact of auto-generation from overloaded type signatures, not a feature. Pick either, keep the same inputs, get the same two output maps.