You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: