C++11 features in cv::Mat

[Paul92]

I noticed that there is a proposal for working on bringing C++11 features into opencv, namely OE-4, with a discussion in #11023.

I would be willing to lend a hand in this, although I am not sure about the current progress. However, I would have some suggestions regarding the issues I have encountered in my work regarding cv::Mat:

• Iterators. I find it common to have to process all the pixels in a matrix, and C++11 provides nicer features than a plain old double for loop, such range for. Also, compatibility with standard algorithms would be also nice to process the pixels in the matrix (e.g. std::transform).

• A way to create a matrix from a const pointer. I know this might be a bit tricky to tackle (or I am not aware of an easy way), but as a end user is a very frustrating limitation.

• A stronger type system. My feeling while working with cv::Mat and even cv::Mat_ is that the type system is not as capable as it could be, and this prevents some optimizations and compile time checks. It is to discuss how much of this is possible without affecting too much the current library while still having a similar support. I know there is cv::Mat_, and my experience with it is a bit limited, but one limitation I hit is the lack of a cv::convert that can handle any types. I would suggest a version that takes a function used to perform the conversion of each pixel.

More on this could be discussed if there is any interest. I am also open to any suggestions you might have in this direction.

---

I know these are some very crude ideas. Please let me know if there is any interest in pursuing them, I would be happy to provide a more detailed proposal for discussion and PRs.

As a note, I am not thinking about anything that would break backwards compatibility.

[alalek]

Iterators
standard algorithms

OpenCV should stay an efficient library.

There is "forEach" approach for per-pixel processing with builtin parallel processing or direct paralle_for_() with lambda.

Please clarify that did you mean here.
Why this doesn't work for you? Is there a problem with strong type check?

Keep in mind there is no "read-only" cv::Mat.

Did you measure efficiency of proposed suggestions?
cv::Mat::convertTo()? cv::Mat::convertFp16()?

[Paul92]

Thank you for your reply.

I agree that the first point I raised is a non-problem since there is that functionality already. I am still getting used to OpenCV and its idiomatic ways of doing things.

For the second point, your example works fine. I just find it unsafe that there is no read-only cv::Mat. I was also thinking about some more compile-time support, such as a version of mat with size as templated argument. This would help with performing some checks at compile time, when the size is available (e.g. functions that must take two matrices of the same size). I am not sure, however, how common is to have the size known at compile time to make it worth.

I know the provided conversions are fast, but they do not work with matrices of user defined types (i.e. cv::Mat). I agree that there is the debate whether this should be supported at all.