opened
UrielSalomon
username_0
<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 
- Operating System / Platform => 
- Compiler => 
-->

- OpenCV => 3.2
- Operating System / Platform => Ubuntu 16.04.10
- Compiler => g++ 5.4.0

##### Detailed description

Rect_<_Tp> operator & (const Rect_<_Tp>& a, const Rect_<_Tp>& b)
returns a wrong result for Rect_<unsigned>, Rect_<unsigned long>.
For example, the intersection of x=0,y=0,w=1,h=1 and 2,2,1,1 should be zero, but I get 1. The intersection variable gets a very large width and height: 4294967295 for both. 

##### Steps to reproduce

	cv::Rect_<unsigned> r1(0,0,1,1);
	cv::Rect_<unsigned> r2(2,2,1,1);
	auto intersection = r1 & r2;
	auto area = intersection.area();
Rect_<Tp> operator & return wrong result
issue
created
csukuangfj
username_1
Underflow for `unsigned`
https://github.com/opencv/opencv/blob/5e31c82b5b71efdd4e9e119e73765d4a2b50457b/modules/core/include/opencv2/core/types.hpp#L1947-L1948

https://github.com/opencv/opencv/blob/5e31c82b5b71efdd4e9e119e73765d4a2b50457b/modules/core/include/opencv2/core/types.hpp#L1951

I think it is a bug.
comment
created
alalek
username_2
Not all template parameters work well (and tested).

Consider using type from [this list](https://github.com/opencv/opencv/blob/3.4.2/modules/core/include/opencv2/core/types.hpp#L453-L456):
```
typedef Rect_<int> Rect2i;
typedef Rect_<float> Rect2f;
typedef Rect_<double> Rect2d;
typedef Rect2i Rect;
```
comment
created
berak
username_3
the `-=` operators suffer from the same problem with unsigned types
comment
created
UrielSalomon
username_0
@username_3 are you suggesting to change these operators? If you are, shouldn't `-=` just stay as it is, and have the users of `-=` worry about underflow? like this:

```
Rect_<unsigned> rect1;
Point_<unsigned> point1;
if (rect1.tl() >= point1) 
{
    rect1 -= point1;
} else
{
//handle this underflow case. maybe set rect.tl() = (0,0);
}
```
comment
created
berak
username_3
@username_0 i'm not suggesting anything right now ;)
comment
created
kinchungwong
username_4
Perhaps the ```Rect<>``` template should be modified to `static_assert` prevent instantiation on unsigned numeric types.

```Rect<>``` doesn't come with integer overflow detection. For typical integer use (less than pow(2,31)), always use ```Rect<int>```. For larger integers, use ```Rect<int64_t>``` (with C++11 compliant `<cstdint>` standard header include).

Might need to check whether ```Rect<int64_t>``` passes all unit tests. If the unit test doesn't run on ```int64_t```, it is time to add them now.
comment
created
UrielSalomon
username_0
@username_3, yeah, I wouldn't implement < or > for Point or Size, since it's not straightforward (is it p1.x < p2.x && p1.y < p2.y? or ||?)

@username_4, why you're not considering the positive case of supporting unsigned types? In my company, we love defining using BoundingBox = cv::Rect_<unsigned>; Since we're dealing with images, we found no reason to allow for negative coordinates.
comment