Is cv::Mat class flawed by design?

Question

I work a lot with the OpenCV C++ interface and designed a number of classes which use Mat\'s as private resources.

Recently, I got concerned about the Mat class, as

Answer 1

Adding and expanding on Vadim's answer, here are some thoughts on the topic.

I have also used cv::Mat extensively, in many ways, and enjoyed its benefits.

A general truth in programming is that you have to balance different opposing needs of a projects. One of them is performance versus maintainability. And this was resolved once and for all with "Premature optimization is evil.". This approach is great, but many programmers just follow it blindly.

For image processing, performance is of paramount importance. Without it, many projects simply aren't feasible. So it is never premature to optimize when processing images. It is one of those very few fields where milliseconds count, where all you do is measured by both quality and speed. And, it may be hard to digest it if you come from C#, Java, or user interface design, but for this speed improvement, it's worth sacrificing some of the established practices of object oriented design.

If you go through the OpenCV's source code, you will see an incredible emphasis on optimization: SSE-based functions, NEON functions, pointer tricks, all kinds of algorithm curiosities, graphics processor implementations, OpenCL implementations, lookup tables, and many, many others which would be considered overkill, hard-to-mantain, or "premature optimization" in other types of projects.

A small change in your app architecture (like cv::Mat allocation strategy) can make a really huge difference when it comes to performance. Sharing an image on an embedded device, instead of cloning may make the difference between a great gadget and a dead-end proof-of-concept.

So, when Vadim said they do not see an efficient way to implement your suggested changes, he suggested that the performance penalties of those changes would not cover the benefits.

Such a project is harder to write and to maintain, but it is for good. And usually, the difficult part of an imaging project is writing the right algorithm. Encapsulating it is just the 1% work at the end.