What was the project decision to combine IplImage and cv :: Mat?

In OpenCV 2.0, they switched from separate image classes and matrices to a unified class called cv::Mat. What was the design decision there? For me, who work with both images and matrices on a daily basis, these are very different objects that simply have commonality: they are accessed in a grid. However, what makes a matrix a matrix in my mind, you can do y = A*xwhere A is m by n, x is n by 1, and y is m by 1. This makes little sense when A is an image, why would you like to do this operation.

The merging of classes was also accompanied by an unpleasant side effect requiring templates and odd types of matrices (for example, CV_32FC3for a 3-channel matrix / floating point image). Since I know that the guys working on OpenCV are not crazy, what design decision forced them to combine image and matrix classes? Was it code reuse? Was it somehow effective?

+3
source share
1 answer

The main drawback is that you cannot overload '*' to do plurality, but I don't think you should overload '*' for anything more complex than the built-in types.

What is a convolutional core - an image or a matrix?

You only need to learn all the functions of the / ctor handler once - instead of two sets of them

+3
source

All Articles