use standard C++ types in API

[vpisarev]

Describe the feature and motivation

For OpenCV 5, where we have a good chance to repair certain things, even if it slightly breaks API, it would be nice to replace some "home-brewed" names with somewhat more standard:

• uchar => uint8_t
• schar => int8_t
• short => int16_t
• ushort => uint16_t
• unsigned => uint32_t (where it makes sense)
• int64 => int64_t
• uint64 => uint64_t
• cv::String => std::string (some functions may take std::string_view for slightly better efficiency)
• cv::Ptr => std::shared_ptr

'int' is a special story - it's used very often in API and probably we should keep it as-is in API (except when int means int32_t, not just "integer with sufficiently large value range")

the old definitions may be put into a dedicated header that may be included by default in OpenCV 5 and not included by default in OpenCV 6+

Additional context

No response

[asmorkalov]

Several side notes on proposal:

• Java does not support signed types. Signed int should be used as much as possible.
• Need to tune all bindings generators to prevent regressions.

[vpisarev]

In API we mostly use int's, double's and float's. I don't expect many changes in API. But I agree that we need to update bindings generators.

I myself, just like Java creators, don't like unsigned integer types, but we need them for a lot of stuff, especially inside OpenCV code; most notably, uint8_t.

[asmorkalov]

Also I propose to got rid of double and double* as supertype. We have (u)int64 that does not fit into double. Also it break user types in many places.

[vpisarev]

'Also it break user types in many places' - can you please decrypt it?

[asmorkalov]

I mean strong typing and extra code to convert to double and back.

[vpisarev]

ok, then probably those few functions that take/return scalars as scalars, not as Input/OutputArrays, should use the new std::variant<> type.

[asmorkalov]

Need to tune Java, Python, JS, Julia bindings for std::variant then.

[mshabunin]

Wouldn't it also make sense to redesign current Scalar concept to align it with mathematical definition (and NumPy)? Maybe even get rid of this class completely? Then 3-channel images will be represented as 3D Mat (which they technically are) and might make interoperability with NumPy and other libraries easier.

[fengyuentau]

Then 3-channel images will be represented as 3D Mat

Hands up for this feature 🙋

[vpisarev]

@mshabunin, this is interesting proposal, but we need to think about details, like:

1. what the functions like Scalar sum(InputArray arr); will look like
2. what the functions like void circle(InputOutputArray img, Point center, int radius, Scalar color, ...); will look like
3. how to combine it with batch support, a 'must have' feature for 5.0 that is proposed in #25012. That is, what the functions like void GaussianBlur(...), void resize(...) etc. should do when they are given 0D, 1D, 2D, 3D, 4D, 5D, ... arrays on input?

4. what users should do with their manually-written image processing loops that assume multi-channel 2D images, e.g.

   for (int y = 0; y < img.rows; y++)
         for (int x = 0; x < img.cols; x++)
              img.at<Vec3b>(y, x) = Vec3b(y, x, y+x);

[mshabunin]

1. Similarly to NumPy sum should have axis parameter, e.g. sum(InputArray img, OutputArray res, InputArray axis), it can default to H&W axes for 2D-3D arrays for compatibility.
2. Instead of Scalar InputArray should be used to pass color value, its type and dimensions should be checked for compatibility with given image, e.g. it can be Vec3b for 3-channel 8u image.
3. For batch processing we can assume input is 4D array with NHWC layout. 2D suffix can be added to functions which are limited to working with regular images (2D arrays - HW, 3D arrays - HWC, 4D arrays - NHWC).
4. This loop should stay the same assuming that image is a 3D array with HWC layout. at should check for type and dimensions compatibility as it does now.

[zchrissirhcz]

I would like to share that int might be different with int32_t in some compiler, such as with HexagonSDK 5.5.0.1's hexagon-clang compiler, which may cause template function definition and invocation mismatch issue.

https://github.com/quic/toolchain_for_hexagon/issues/26#issuecomment-2049286555