mirror of
https://github.com/zebrajr/opencv.git
synced 2025-12-06 12:19:50 +01:00
bdab54f79e
Use MatShape instead of MatSize inside cv::Mat/cv::UMat #27757 **Merge together with https://github.com/opencv/opencv_contrib/pull/3996** --- This PR continues cv::Mat/cv::UMat refactoring. See #26056, where `MatShape` was introduced. Now it's put inside cv::Mat/cv::UMat instead of a weird `MatSize`. MatSize is now an alias for MatShape: **before:** ``` struct MatShape { ... }; struct MatSize { ... }; struct Mat { ... int dims; int rows; int cols; ... MatShape shape() const { ... /* constructs MatShape out of MatSize and returns it; layout is always 'unknown', because we don't store it */ } MatSize size; // size is not valid without the parent cv::Mat, // because size.p may point to Mat::rows or to Mat::cols, // depending on the dimensionality, and dims() returns Mat::dims. MatStep step; // may allocate memory, depending on the dimensionality. ... }; ``` **after:** ``` struct MatShape { ... }; typedef MatShape MatSize; // they are now synonyms struct Mat { ... int dims; int rows; int cols; ... MatShape shape() const { return size; } // just return the embedded shape (including the proper layout information) MatSize size; // size is self-contained data structure that can be used without the parent cv::Mat. // size.dims is now a copy of dims; size.p[*] contains copies of Mat::rows and Mat::cols when dims <= 2. MatStep step; // does not allocate extra memory buffers. ... }; ``` There are several reasons to do that: 1. the main reason is to be able to store data layout (MatShape::layout) inside each cv::Mat/cv::UMat. This is necessary for the proper shape inference in DNN module. In particular, it's necessary for the next step of DNN inference optimization where we introduce block-layout-optimized convolution and other operations. Later on, we can use layout information to support non-interleaved images (e.g. RRR...GGG...BBB...) or even batches of such images in core/imgproc modules. 2. the other reason is to represent 3D/4D/5D etc. tensors as cv::Mat/cv::UMat instances more conveniently, without extra dynamic memory allocation. Before this patch we allocated some memory buffers dynamically to store shape & steps for more than 2D arrays. Now the whole cv::Mat/cv::UMat header can be stored completely on stack/in a container. Creating another copy of Mat/UMat header is now done more efficiently. 3. the third reason is to introduce the new coding pattern: `dst.create(src.size, <dst_type>);`. The pattern is suitable for most of element-wise (including cloning) and filtering operations. This pattern does not only look crisp and self-documenting, it will also automatically copy shape (including layout) from the source tensor into the destination matrix/tensor. 4. in the future we might add `colorspace` member to MatShape that will allow to distinguish RGB from BGR or NV12. `dst.create(src.size, <dst_type>);` will then copy the colorspace information as well. ### Pull Request Readiness Checklist See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request - [x] I agree to contribute to the project under Apache 2 License. - [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV - [x] The PR is proposed to the proper branch - [x] There is a reference to the original bug report and related work - [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable Patch to opencv_extra has the same branch name. - [x] The feature is well documented and sample code can be built with the project CMake |
||
|---|---|---|
| .. | ||
| include/opencv2 | ||
| misc | ||
| src | ||
| CMakeLists.txt | ||