[ros-users] [Discourse.ros.org] [Packaging and Release Management] OpenCV 3.3

Maarten de Vries ros.discourse at gmail.com
Sun Sep 17 21:47:11 UTC 2017



Note that opencv 3.3 added initializer list constructors for `cv::Mat` and `cv::Mat_`. As a result, code using uniform initialization syntax may change meaning:

```
cv::Mat a{2, 2, CV_8UC1};
```

In opencv 3.2 that creates a 2 by 2 matrix with data type 8UC1. In opencv 3.3 it creates a cv::Mat with a single column containing 3 integers.

In the latest release (3.3.0) this even took over from the copy constructor because the `initializer_list` constructor was implemented as an constructor template for all `std::initializer_list<T>` without placing limits on `T`:

```
cv::Mat foo = cv::imread("foo.png");
cv::Mat copy{foo};
```

In opencv 3.2 this invokes the copy constructor. In opencv 3.3.0 this creates a 1x1 matrix containing some strange value. Templates that don't know they're dealing with a `cv::Mat` are especially prone to bugs because of this. A PR has been merged that makes sure the above code invokes the copy constructor again in opencv 3.3 (by restricting the initializer list constructor to arithmetic types), but it's not in a release yet:
https://github.com/opencv/opencv/pull/9507



Personally I made sure that none of our code was accidentally using the `std::initializer_list` constructor by adding a `static_assert(!std::is_same<T, T>::value, "")` inside the constructor in the opencv header and then recompiling all our code. Not pretty, but it works.





---
[Visit Topic](https://discourse.ros.org/t/opencv-3-3/2674/5) or reply to this email to respond.




More information about the ros-users mailing list