There is no check for size/dims match. For example, ROI will have the same data ptr:

Mat m (10, 10, CV_8U);
Mat roi = m.rowRange(0, 2);
m.convertTo(roi, CV_8S);

I had through !dst.getMat().isSubmatrix() to determine this case.

What about the following case? .data matched but not the shapes.

Mat m (10, 10, CV_8U);
Mat m2(5, 10, CV_8U, m.ptr<uint8_t>());
m.convertTo(m2, CV_8S);

Firstly, if roi is a submatrix, the refcount will add 1.
if (this->data == dst.getMat().data && this->elemSize() == CV_ELEM_SIZE(dtype) && refcount == 2)
This condition can recognize the first case.
Mat m (10, 10, CV_8U); Mat roi = m.rowRange(0, 2); m.convertTo(roi, CV_8S);

BUt, I have come up with a new question. Like,

Mat m (10, 10, CV_8U); Mat m2(10, 10, CV_8U, m.ptr<uint8_t>()); m.convertTo(m2, CV_8S);

In this case, the member 'u' is NULL. By checking whether 'u' is null, we can solve this problem.

Mat m (10, 10, CV_8U); Mat m2(10, 10, CV_8U, m.ptr<uint8_t>()); m.convertTo(m, CV_8S);

And, in this case, the original data of 'm' will be released, and 'm2' may encounter unpredictable errors. I believe such risky behavior should be noted by OpenCV users.

Add a check for resulting values:

EXPECT_EQ(0, countNonZero(A != cv::Scalar(1, 2, 3)));

I had add a function to replace countNonZero, because countNonZero only support cn == 1.

it's quite bad idea to do it at such a high-level with such unsafe low-level details: 1) refcount==2, 2) 3 calls to getMat(), which can be rather expensive. 3) dst.assign() call, which is not that safe.

@vpisarev
I have added a reinterpretType API to reinterpret the data type of Mat. However, it seems that these checks are unavoidable. Instead, I have changed it to refcount == 1 and reduced the number of dst.getMat calls.

it's safer to use m.flags = (m.flags & ~CV_MAT_TYPE_MASK) | type; here.

@vpisarev I had done

don't silently assume that obj is Mat*. Do
return getMat().reinterpretType(mtype); instead

@vpisarev I had done

can we skip Type suffix in the name? (Mat reinterpret(int type) const;?)

@vpisarev I had done

this is wrong. When 8u is converted to 8s, for example, 255 should map to 127. In the case of opposite conversion (8s to 8u) all negative numbers should be converted to 0's. You also don't check noScale flag. I suggest to just retain reinterpret() and don't try to patch convertTo(). If reinterpret() works for you, just make the proper test that demonstrates the use of reinterpret().

@vpisarev The function aims to reuse memory while performing data type conversion within the conversion function. such as BinaryFunc func = noScale ? getConvertFunc(sdepth, ddepth) : getConvertScaleFunc(sdepth, ddepth);

However, I believe your suggestion is correct: if memory reuse is needed, it's more reasonable to first call the reinterpret function. This is a more correct approach compared to modifying the convertTo function.

@vpisarev My understanding and use of OpenCV, as well as my coding skills, indeed have some shortcomings. I am very grateful for your guidance, which has been very beneficial to me.

Why do we need CV_MAT_TYPE operation?

I want to retrieve the actual type of the cv::Mat to prevent users from passing incorrect parameters, and then perform an assertion check.

Need to start with "bad param" test then.
Silent ignoring of invalid input doesn't look good.

I had added assert checks CV_Assert(CV_ELEM_SIZE(this->type()) == CV_ELEM_SIZE(type));

Surely, I will add test cases, and should I create a new PR to update this issue?

It is still not clear why do we need type = CV_MAT_TYPE(type) operation:

• it is useless for valid MatType (works as no-op).
• it silently ignores invalid out-of-range input converting/truncating it to some value (which user may not expect).

My initial thought was that types with the same element size could perform a reinterpret operation, and for any other type, an assert operation would be executed. Your point seems to be:

When newtype < this->type, a reinterpret operation (truncate) can also be performed.
When newtype > this->type, a new mat (convert) should be created.

The CV_MAT_TYPE operation is indeed redundant, as these operations are actually the responsibility of the convertTo function. CV_MAT_TYPE is indeed unnecessary.