Exposing CV_MAKETYPE(depth, cn) and CV_8UC(n), CV_8SC(n) etc. to python binding

Hello! As of 4.7.0, C++ macros CV_MAKETYPE(depth, cn) and CV_8UC(n), CV_8SC(n) etc., aren’t exposed in opencv-python. Having them as functions in cv2 could make code dealing with arbitrary channel numbers more readable, for instance, the mat_type = line here:

import cv2
import cupy as cp

def cv_cuda_gpumat_from_cp_array(arr: cp.ndarray) -> cv2.cuda.GpuMat:
    assert len(arr.shape) in (2, 3), "CuPy array must have 2 or 3 dimensions to be a valid GpuMat"
    type_map = {
        cp.dtype('uint8'): cv2.CV_8U,
        cp.dtype('int8'): cv2.CV_8S,
        cp.dtype('uint16'): cv2.CV_16U,
        cp.dtype('int16'): cv2.CV_16S,
        cp.dtype('int32'): cv2.CV_32S,
        cp.dtype('float32'): cv2.CV_32F,
        cp.dtype('float64'): cv2.CV_64F
    depth = type_map.get(arr.dtype)
    assert depth is not None, "Unsupported CuPy array dtype"
    channels = 1 if len(arr.shape) == 2 else arr.shape[2]
    # equivalent to unexposed opencv C++ macro CV_MAKETYPE(depth,channels):
    # (depth&7) + ((channels - 1) << 3)
    mat_type = depth + ((channels - 1) << 3)
    mat = cv2.cuda.createGpuMatFromCudaMemory(arr.__cuda_array_interface__['shape'][1::-1],
    return mat

would look much better as:

mat_type = cv2.CV_MAKETYPE(depth,channels)

Does it sound reasonable to have those macros exposed? What would it take to do this?

you propose it as an issue on the github (check for existence before creating!). that’s the place for others, also the Intel devs behind OpenCV, to give their opinions.

then you can look into building this. or look into it first. either way.

eh, I could imagine use cases… but since the general Python interface uses numpy arrays, which have a shape and dtype, there’s no “channels + dtype” compound type, and no real need to deal with those types generically.

1 Like

Thank you for your quick reply and opinion! Will start with an issue then :slightly_smiling_face: