nareshmlx/opencv-pr huggingface dataset:
**File:** modules/core/include/opencv2/core/cuda.hpp
**Change Type:** modified
**Context:** PR #6991: cudev: add feature to convert FP32(float) from/to FP16(half) on GPU - ### This pullrequest changes - GPU version of #6830, #6447 - add featu...
**Review Line:** 858

**Code Changes:**
```diff
@@ -855,6 +855,8 @@ class CV_EXPORTS DeviceInfo
 CV_EXPORTS void printCudaDeviceInfo(int device);
 CV_EXPORTS void printShortCudaDeviceInfo(int device);
 
+CV_EXPORTS void convertFp16Cuda(InputArray _src, OutputArray _dst, Stream& stream = Stream::Null());
+
 //! @} cudacore_init
 
 }} // namespace cv { namespace cuda {
```

Review comment:
I think `Cuda` prefix is redundant, since the function is already in `cuda::` namespace.
**File:** modules/core/src/stat.cpp
**Change Type:** modified
**Context:** PR #7010: improve SumSqr_SIMD<uchar, int, int>() - I remove wasted '_mm_mullo_epi16() and _mm_mulhi_epi16()' instruction. I remove wasted '_mm_unpackl...

**Code Changes:**
```diff
@@ -757,38 +757,36 @@ struct SumSqr_SIMD<uchar, int, int>
 
         int x = 0;
         __m128i v_zero = _mm_setzero_si128(), v_sum = v_zero, v_sqsum = v_zero;
+        const int len_16 = len & ~15;
 
-        for ( ; x <= len - 16; x += 16)
+        for ( ; x <= len_16 - 16; )
         {
-            __m128i v_src = _mm_loadu_si128((const __m128i *)(src0 + x));
```

Review comment:
this construction implies that len is 32-bit integer; I would use more safe `len & ~15`
**File:** modules/core/src/stat.cpp
**Change Type:** modified
**Context:** PR #7010: improve SumSqr_SIMD<uchar, int, int>() - I remove wasted '_mm_mullo_epi16() and _mm_mulhi_epi16()' instruction. I remove wasted '_mm_unpackl...
**Review Line:** 782

**Code Changes:**
```diff
+            v_sum = _mm_add_epi32(v_sum, _mm_unpacklo_epi16(v_sum_tmp, v_zero));
+            v_sum = _mm_add_epi32(v_sum, _mm_unpackhi_epi16(v_sum_tmp, v_zero));
         }
 
         for ( ; x <= len - 8; x += 8)
         {
             __m128i v_src = _mm_unpacklo_epi8(_mm_loadl_epi64((__m128i const *)(src0 + x)), v_zero);
+            __m128i v_half_0 = _mm_unpackhi_epi64(v_src, v_src);
+            __m128i v_sum_tmp = _mm_add_epi16(v_src, v_half_0);
+            __m128i v_half_1 = _mm_unpacklo_epi16(v_src, v_half_0);
 
```

Review comment:
it's safer to retain "for" rather than "if". That makes the code more universal if you change the unroll factor of the previous loop
**File:** modules/videoio/src/cap_ios_video_camera.mm
**Change Type:** modified
**Context:** PR #7029: Fix crash on double-stop of CvVideoCamera - ### Fix a crash when [CvVideoCamera stop] is called twice Currently calling `[CvVideoCamear stop...
**Review Line:** 125

**Code Changes:**
```diff
 
@@ -118,6 +122,10 @@ - (void)start;
 
 - (void)stop;
 {
+    if (self.running == NO) {
+        return;
+    }
+
     [super stop];
 
```

Review comment:
Looks like self.running could became equal to NO if one calls to [CvVideoCamera pause]. So in such case proper resource deallocation would be skipped.
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #6959: Better stereo bm - 'resolves' 6898 I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S. I chang...

**Code Changes:**
```diff
@@ -317,7 +317,8 @@ prefilterXSobel( const Mat& src, Mat& dst, int ftzero )
 }
 
 
-static const int DISPARITY_SHIFT = 4;
+static const int DISPARITY_SHIFT_16S = 4;
+static const int DISPARITY_SHIFT_32S = 8;
 
 #if CV_SSE2
 static void findStereoCorrespondenceBM_SSE2( const Mat& left, const Mat& right,
```

Review comment:
Please use 4 "spaces" instead of tabs.
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #6959: Better stereo bm - 'resolves' 6898 I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S. I chang...

**Code Changes:**
```diff
@@ -317,7 +317,8 @@ prefilterXSobel( const Mat& src, Mat& dst, int ftzero )
 }
 
 
-static const int DISPARITY_SHIFT = 4;
+static const int DISPARITY_SHIFT_16S = 4;
+static const int DISPARITY_SHIFT_32S = 8;
 
 #if CV_SSE2
 static void findStereoCorrespondenceBM_SSE2( const Mat& left, const Mat& right,
```

Review comment:
it's always a bad idea to use non-constant global variable; it makes the code thread-unsafe
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #6959: Better stereo bm - 'resolves' 6898 I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S. I chang...
**Review Line:** 865

**Code Changes:**
```diff
+findStereoCorrespondenceBM( const Mat& left, const Mat& right,
+                            Mat& disp, Mat& cost, const StereoBMParams& state,
+                            uchar* buf, int _dy0, int _dy1 )
+{
+    if(disp.type() == CV_16S)
+        findStereoCorrespondenceBM_<short>(left, right, disp, cost, state,
+                                           buf, _dy0, _dy1, DISPARITY_SHIFT_16S );
+     else
+        findStereoCorrespondenceBM_<int>(left, right, disp, cost, state,
+                                         buf, _dy0, _dy1, DISPARITY_SHIFT_32S );
+}
```

Review comment:
I'd rather make DISPARITY_SHIFT an argument of the template function
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #6959: Better stereo bm - 'resolves' 6898 I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S. I chang...

**Code Changes:**
```diff
@@ -317,7 +317,8 @@ prefilterXSobel( const Mat& src, Mat& dst, int ftzero )
 }
 
 
-static const int DISPARITY_SHIFT = 4;
+static const int DISPARITY_SHIFT_16S = 4;
+static const int DISPARITY_SHIFT_32S = 8;
 
 #if CV_SSE2
 static void findStereoCorrespondenceBM_SSE2( const Mat& left, const Mat& right,
```

Review comment:
currently, the function supports CV_16S and CV_32F datatypes for the disparity; It looks like you are using CV_32S here instead of CV_32F. It will likely break things.
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #6959: Better stereo bm - 'resolves' 6898 I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S. I chang...
**Review Line:** 865

**Code Changes:**
```diff
+findStereoCorrespondenceBM( const Mat& left, const Mat& right,
+                            Mat& disp, Mat& cost, const StereoBMParams& state,
+                            uchar* buf, int _dy0, int _dy1 )
+{
+    if(disp.type() == CV_16S)
+        findStereoCorrespondenceBM_<short>(left, right, disp, cost, state,
+                                           buf, _dy0, _dy1, DISPARITY_SHIFT_16S );
+     else
+        findStereoCorrespondenceBM_<int>(left, right, disp, cost, state,
+                                         buf, _dy0, _dy1, DISPARITY_SHIFT_32S );
+}
```

Review comment:
Sure, much better. I didn't think about this. I will do the change and commit/push again.
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #6959: Better stereo bm - 'resolves' 6898 I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S. I chang...

**Code Changes:**
```diff
@@ -317,7 +317,8 @@ prefilterXSobel( const Mat& src, Mat& dst, int ftzero )
 }
 
 
-static const int DISPARITY_SHIFT = 4;
+static const int DISPARITY_SHIFT_16S = 4;
+static const int DISPARITY_SHIFT_32S = 8;
 
 #if CV_SSE2
 static void findStereoCorrespondenceBM_SSE2( const Mat& left, const Mat& right,
```

Review comment:
I am using CV_32S only to store the previous CV_16S variable with all the bits the algorithm outputs, then I convert it to float as previously done with CV_16S. I believe this behavior was there to save computing time when using float is expensive. So I decided to preserve that. But maybe I am wrong. I will give a better look.
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #6959: Better stereo bm - 'resolves' 6898 I have seen that you can input a Mat_<float> on StereoBM, but the value seems the same as CV_16S. I chang...

**Code Changes:**
```diff
@@ -317,7 +317,8 @@ prefilterXSobel( const Mat& src, Mat& dst, int ftzero )
 }
 
 
-static const int DISPARITY_SHIFT = 4;
+static const int DISPARITY_SHIFT_16S = 4;
+static const int DISPARITY_SHIFT_32S = 8;
 
 #if CV_SSE2
 static void findStereoCorrespondenceBM_SSE2( const Mat& left, const Mat& right,
```

Review comment:
To me, the change looks legit. I still don't think the it brings a lot of value (since you can increase the precision after the function returns), but I kind of can see the reasoning. The things that are missing: - Other implementations (SSE and OCL) should be modified accordingly - Documentation that the fixed-point format in case of 32S or 32F depth is Q23.8 (instead of Q11.4)
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
Why change [direct initialization](http://en.cppreference.com/w/cpp/language/direct_initialization) to [copy initialization](http://en.cppreference.com/w/cpp/language/copy_initialization)?
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
You can do this in a const-correct manner like so: ``` int const maxWindowHeight = parser.get<int>("maxWindowHeight") > 0 ? parse.get<int>("maxWindowHeight") : -1; ``` This way you get `maxWindowHeight` to be const.
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
I think it's worth to make this const too. ``` bool const resize_bool = maxWindowHeight > 0) && (current_image.rows > maxWindowHeight); ``` Then you can change the conditional below in line 298 that calls `resize()` to just poll this bool.
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
Basically because I think it is more clear that way, but for efficiency reasons I could indeed change it back! Also was due to exploring a possible bug in another thread that we tried to solve it by doing this copy initialization but it turned out to be a different issue.
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
Changed that. What is the reason for maxWindowHeight to be const? Shouldn't all the parameters retrieved by parser be const then?
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
In the case of `std::string` it doesn't make a difference. But that's not true for the general case. In the general case, the two initializations can call different functions. One may compile, while the other not. Or worse yet, it may compile, and differ in (runtime) behaviour. That's why I asked. Not because I thought in this particular case it makes a difference either way, but to see we're aware of this.. For example, ``` struct foo; struct bar { bar(int); explicit bar(double); explicit bar(foo); }; // ... { bar b0(42); // bar(int) bar b1 = 42; // bar(int) foo f; bar b2(f); // bar(foo) // bar b3 = f; // compile error: bar(foo) is explicit bar b4(42.0); // bar(double) bar b5 = 42.0; // bar(int) ``` The last line, with `b5`, might surprise some. So might the line with `b3`, although at least the compiler would catch that one..
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
I was just looking around, and commented when I saw this. Then I looked around some more, and realized there are quite a lot of places in OpenCV that don't mind const-correctness.. I think there's value in being const. suppose you're hunting some bug down. - If you see an initialization done right, you see and know it's initialized properly, and you know it will never change, then you intuitively conclude it will forever remain right. There's value in this confidence, in this peace of mind. - But if you see something initialized right, and you know it _might_ change down the line, then you're still on your guard. You keep reading, looking for the place it changes. And that might not be obvious--for example, some obscure function taking by reference and messing with it, or an assignment from a function that you don't yet know has a bug. const just means one less moving part. it's just easier to work with..
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
Okay true, but that is the case if you use a struct with different types. As far as i know this is not the case here right?
**File:** apps/annotation/opencv_annotation.cpp
**Change Type:** modified
**Context:** PR #7020: allow for screen size related resizing - ### This pullrequest changes Adds the possibility to resize your input images to a maximum size tha...

**Code Changes:**
```diff
@@ -229,6 +229,8 @@ int main( int argc, const char** argv )
         "{ help h usage ? |      | show this message }"
         "{ images i       |      | (required) path to image folder [example - /data/testimages/] }"
         "{ annotations a  |      | (required) path to annotations txt file [example - /data/annotations.txt] }"
+        "{ maxWindowHeight m  |  -1   | (optional) images larger in height than this value will be scaled down }"
+        "{ resizeFactor r  |  2  | (optional) factor for scaling down [default = half the size] }"
     );
     // Read in the input arguments
     if (parser.has("help")){
@@ -244,6 +246,9 @@ int main( int argc, const char** argv )
```

Review comment:
Agreed, seems reasonable!
**File:** modules/imgproc/src/thresh.cpp
**Change Type:** modified
**Context:** PR #6970: improve thresh_8u() - It is related to #6799 Modification: Lazy construction for variable i, j, j_scalar, and tab. Change increment for vari...

**Code Changes:**
```diff
@@ -49,8 +49,6 @@ namespace cv
 static void
 thresh_8u( const Mat& _src, Mat& _dst, uchar thresh, uchar maxval, int type )
 {
-    int i, j, j_scalar = 0;
-    uchar tab[256];
     Size roi = _src.size();
     roi.width *= _src.channels();
     size_t src_step = _src.step;
@@ -125,59 +123,22 @@ thresh_8u( const Mat& _src, Mat& _dst, uchar thresh, uchar maxval, int type )
```

Review comment:
is there a reason to rename j to j_scalar? such a rename does not seem absolutely necessary and it creates really a lot of noise in the patch; could you please re-do your patch without this change?
**File:** modules/imgproc/src/featureselect.cpp
**Change Type:** modified
**Context:** PR #6989: Make goodFeaturesToTrack() return deterministic results - Fixes Issue 6988. When using OCL, the results of goodFeaturesToTrack() vary slight...
**Review Line:** 58

**Code Changes:**
```diff
         public std::binary_function<const float *, const float *, bool>
 {
     bool operator () (const float * a, const float * b) const
-    { return *a > *b; }
+    // Ensure a fully deterministic result of the sort
+    { return (*a > *b) ? true : (*a < *b) ? false : (a > b); }
 };
 
 #ifdef HAVE_OPENCL
@@ -66,7 +67,8 @@ struct Corner
     short x;
```

Review comment:
I thin the addresses `a` and `b` still depend on the execution order.
**File:** modules/imgproc/src/featureselect.cpp
**Change Type:** modified
**Context:** PR #6989: Make goodFeaturesToTrack() return deterministic results - Fixes Issue 6988. When using OCL, the results of goodFeaturesToTrack() vary slight...
**Review Line:** 58

**Code Changes:**
```diff
         public std::binary_function<const float *, const float *, bool>
 {
     bool operator () (const float * a, const float * b) const
-    { return *a > *b; }
+    // Ensure a fully deterministic result of the sort
+    { return (*a > *b) ? true : (*a < *b) ? false : (a > b); }
 };
 
 #ifdef HAVE_OPENCL
@@ -66,7 +67,8 @@ struct Corner
     short x;
```

Review comment:
The addresses 'a' and 'b' are always of pixels within the same Mat, so their ordering is deterministic. If you look at the rest of the GFFT code you will see that it uses the pixel addresses as a shorthand rather than explicitly storing the x,y coords (the way that the OCL version below does).
**File:** modules/core/test/test_io.cpp
**Change Type:** modified
**Context:** PR #6963: Added test to prove that issue #5029 is invalid - resolves #5029 ### This pullrequest changes Added test to write and read `Vec2i` to / from...
**Review Line:** 763

**Code Changes:**
```diff
+        cv::FileStorage fs(file_name, cv::FileStorage::READ);
+        fs["prms0"]["vec0"] >> ovec;
+        fs.release();
+    }
+
+    EXPECT_EQ(vec(0), ovec(0));
+    EXPECT_EQ(vec(1), ovec(1));
+
+    remove(file_name.c_str());
+}
```

Review comment:
the file should probably be removed in the end, or else it should be a temporary file, or else you can use memory-based file storage.
**File:** modules/core/test/test_io.cpp
**Change Type:** modified
**Context:** PR #6963: Added test to prove that issue #5029 is invalid - resolves #5029 ### This pullrequest changes Added test to write and read `Vec2i` to / from...
**Review Line:** 763

**Code Changes:**
```diff
+        cv::FileStorage fs(file_name, cv::FileStorage::READ);
+        fs["prms0"]["vec0"] >> ovec;
+        fs.release();
+    }
+
+    EXPECT_EQ(vec(0), ovec(0));
+    EXPECT_EQ(vec(1), ovec(1));
+
+    remove(file_name.c_str());
+}
```

Review comment:
added file removal.