nareshmlx/opencv-pr huggingface dataset:
**File:** modules/imgproc/src/clahe.cpp
**Change Type:** modified
**Context:** PR #3033: CPU (non-OpenCL) CLAHE Support for CV_16UC1 Images - The CPU implementation (non-OpenCL) implementation algorithm now supports image types o...

**Code Changes:**
```diff
@@ -126,10 +126,11 @@ namespace clahe
 
 namespace
 {
+    template <class T, int histSize, int shift>
     class CLAHE_CalcLut_Body : public cv::ParallelLoopBody
     {
     public:
-        CLAHE_CalcLut_Body(const cv::Mat& src, cv::Mat& lut, cv::Size tileSize, int tilesX, int clipLimit, float lutScale) :
+        CLAHE_CalcLut_Body(const cv::Mat& src, const cv::Mat& lut, const cv::Size& tileSize, const int& tilesX, const int& clipLimit, const float& lutScale) :
```

Review comment:
use lut_.step/sizeof(T)
**File:** modules/imgproc/src/clahe.cpp
**Change Type:** modified
**Context:** PR #3033: CPU (non-OpenCL) CLAHE Support for CV_16UC1 Images - The CPU implementation (non-OpenCL) implementation algorithm now supports image types o...

**Code Changes:**
```diff
@@ -126,10 +126,11 @@ namespace clahe
 
 namespace
 {
+    template <class T, int histSize, int shift>
     class CLAHE_CalcLut_Body : public cv::ParallelLoopBody
     {
     public:
-        CLAHE_CalcLut_Body(const cv::Mat& src, cv::Mat& lut, cv::Size tileSize, int tilesX, int clipLimit, float lutScale) :
+        CLAHE_CalcLut_Body(const cv::Mat& src, const cv::Mat& lut, const cv::Size& tileSize, const int& tilesX, const int& clipLimit, const float& lutScale) :
```

Review comment:
Using cv::makePtr throws an error for me. I think its because makePtr expects the constructor arguments to be consts. Thoughts?
**File:** modules/imgproc/src/clahe.cpp
**Change Type:** modified
**Context:** PR #3033: CPU (non-OpenCL) CLAHE Support for CV_16UC1 Images - The CPU implementation (non-OpenCL) implementation algorithm now supports image types o...

**Code Changes:**
```diff
@@ -126,10 +126,11 @@ namespace clahe
 
 namespace
 {
+    template <class T, int histSize, int shift>
     class CLAHE_CalcLut_Body : public cv::ParallelLoopBody
     {
     public:
-        CLAHE_CalcLut_Body(const cv::Mat& src, cv::Mat& lut, cv::Size tileSize, int tilesX, int clipLimit, float lutScale) :
+        CLAHE_CalcLut_Body(const cv::Mat& src, const cv::Mat& lut, const cv::Size& tileSize, const int& tilesX, const int& clipLimit, const float& lutScale) :
```

Review comment:
yes, this is a bit weird. Change "Mat&" parameters in loop body constructors to "const Mat&" and it compiles. BTW, I also found another problem. If you use 4096 bins, the shift needs to be set to 4, not 6
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #2827: add NEON realization for StereoBM(findCorrespondence, prefilterXSobel)
**Review Line:** 618

**Code Changes:**
```diff
     const uchar* lptr0 = left.data + lofs;
@@ -560,12 +615,29 @@ findStereoCorrespondenceBM( const Mat& left, const Mat& right,
         for( y = -dy0; y < height + dy1; y++, hsad += ndisp, cbuf += ndisp, lptr += sstep, rptr += sstep )
         {
             int lval = lptr[0];
+        #if CV_NEON
+            int16x8_t lv = vdupq_n_s16 ((int16_t)lval);
+
+            for( d = 0; d < ndisp; d += 8 )
+            {
+                int16x8_t rv = vreinterpretq_s16_u16 (vmovl_u8 (vld1_u8 (rptr + d)));
```

Review comment:
looks like here and in several other places you do not handle the case when ndisp is not divisible by 8. The common idiom is to use <pre> int loop_counter = 0; #if &lt;USE_SIMD&gt; // unrolled part of the loop for( /* initialization section is omitted */ ; loop_counter &lt;= max_value - unroll_factor; loop_counter += unroll_factor ) { /* vectorized SIMD code */ } #endif // note that we use endif, without else for( /* initialization section is also omitted */ ; loop_counter &lt; max_value; loop_counter++ ) { /* scalar C code */ } </pre>
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #2827: add NEON realization for StereoBM(findCorrespondence, prefilterXSobel)
**Review Line:** 618

**Code Changes:**
```diff
     const uchar* lptr0 = left.data + lofs;
@@ -560,12 +615,29 @@ findStereoCorrespondenceBM( const Mat& left, const Mat& right,
         for( y = -dy0; y < height + dy1; y++, hsad += ndisp, cbuf += ndisp, lptr += sstep, rptr += sstep )
         {
             int lval = lptr[0];
+        #if CV_NEON
+            int16x8_t lv = vdupq_n_s16 ((int16_t)lval);
+
+            for( d = 0; d < ndisp; d += 8 )
+            {
+                int16x8_t rv = vreinterpretq_s16_u16 (vmovl_u8 (vld1_u8 (rptr + d)));
```

Review comment:
Yes, I agree with you. I wanted to write code which would look like the code written with SSE-instructions, where this case isn't handled. I can add the case where ndisp not divisible by 8
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #2827: add NEON realization for StereoBM(findCorrespondence, prefilterXSobel)
**Review Line:** 618

**Code Changes:**
```diff
     const uchar* lptr0 = left.data + lofs;
@@ -560,12 +615,29 @@ findStereoCorrespondenceBM( const Mat& left, const Mat& right,
         for( y = -dy0; y < height + dy1; y++, hsad += ndisp, cbuf += ndisp, lptr += sstep, rptr += sstep )
         {
             int lval = lptr[0];
+        #if CV_NEON
+            int16x8_t lv = vdupq_n_s16 ((int16_t)lval);
+
+            for( d = 0; d < ndisp; d += 8 )
+            {
+                int16x8_t rv = vreinterpretq_s16_u16 (vmovl_u8 (vld1_u8 (rptr + d)));
```

Review comment:
If it is crucial, I can redo more general.
**File:** modules/calib3d/src/stereobm.cpp
**Change Type:** modified
**Context:** PR #2827: add NEON realization for StereoBM(findCorrespondence, prefilterXSobel)
**Review Line:** 618

**Code Changes:**
```diff
     const uchar* lptr0 = left.data + lofs;
@@ -560,12 +615,29 @@ findStereoCorrespondenceBM( const Mat& left, const Mat& right,
         for( y = -dy0; y < height + dy1; y++, hsad += ndisp, cbuf += ndisp, lptr += sstep, rptr += sstep )
         {
             int lval = lptr[0];
+        #if CV_NEON
+            int16x8_t lv = vdupq_n_s16 ((int16_t)lval);
+
+            for( d = 0; d < ndisp; d += 8 )
+            {
+                int16x8_t rv = vreinterpretq_s16_u16 (vmovl_u8 (vld1_u8 (rptr + d)));
```

Review comment:
you are right, it's not checked in SSE2 version that (ndisp % 8 == 0). This check will be added. Also, please put such CV_Assert in the case of NEON use.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #3038: NEON acceleration of some core/arithm functions - ARM NEON accelerated implementation of cv::addWeighted, cv::inRange and cv::compare functi...

**Code Changes:**
```diff
@@ -2440,6 +2440,34 @@ addWeighted8u( const uchar* src1, size_t step1,
                 _mm_storel_epi64((__m128i*)(dst + x), u);
             }
         }
+#elif CV_NEON
+        float32x4_t g = vdupq_n_f32 (gamma);
+
+        for( ; x <= size.width - 8; x += 8 )
+        {
+            uint8x8_t in1 = vld1_u8(src1+x);
```

Review comment:
this can potentially give wrong results, because alpha_src1[x] + beta_src2[x] + gamma may be negative. it's better to use vcvtq_s32_f32 instead of vcvt_u32_f32 and then use vqmovun_s32 to convert s32 to u16.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #3020: disabled some acceleration to make the core tests pass - 1. disabled OpenCL acceleration for cv::multiply() (CV_32F), cv::divide (CV_32F), c...
**Review Line:** 1494

**Code Changes:**
```diff
@@ -1491,6 +1491,9 @@ static bool ocl_arithm_op(InputArray _src1, InputArray _src2, OutputArray _dst,
     if (!doubleSupport && (depth2 == CV_64F || depth1 == CV_64F))
         return false;
 
+    if( (oclop == OCL_OP_MUL_SCALE || oclop == OCL_OP_DIV_SCALE) && (depth1 >= CV_32F || depth2 >= CV_32F || ddepth >= CV_32F) )
+        return false;
+
     int kercn = haveMask || haveScalar ? cn : ocl::predictOptimalVectorWidth(_src1, _src2, _dst);
     int scalarcn = kercn == 3 ? 4 : kercn, rowsPerWI = d.isIntel() ? 4 : 1;
 
```

Review comment:
I believe the same is for `OCL_OP_RDIV_SCALE` and maybe even for `OCL_OP_RECIP_SCALE`
**File:** modules/core/include/opencv2/core/ocl.hpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 640

**Code Changes:**
```diff
@@ -636,6 +636,9 @@ class CV_EXPORTS Image2D
 
 CV_EXPORTS MatAllocator* getOpenCLAllocator();
 
+CV_EXPORTS_W bool isPerformanceCheckBypassed();
+#define OCL_PERFORMANCE_CHECK(condition) (cv::ocl::isPerformanceCheckBypassed() || (condition))
+
 }}
 
 #endif
```

Review comment:
bad name, too long and inappropriate
**File:** modules/core/include/opencv2/core/ocl.hpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 640

**Code Changes:**
```diff
@@ -636,6 +636,9 @@ class CV_EXPORTS Image2D
 
 CV_EXPORTS MatAllocator* getOpenCLAllocator();
 
+CV_EXPORTS_W bool isPerformanceCheckBypassed();
+#define OCL_PERFORMANCE_CHECK(condition) (cv::ocl::isPerformanceCheckBypassed() || (condition))
+
 }}
 
 #endif
```

Review comment:
and your suggestion is ...
**File:** modules/core/include/opencv2/core/ocl.hpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 640

**Code Changes:**
```diff
@@ -636,6 +636,9 @@ class CV_EXPORTS Image2D
 
 CV_EXPORTS MatAllocator* getOpenCLAllocator();
 
+CV_EXPORTS_W bool isPerformanceCheckBypassed();
+#define OCL_PERFORMANCE_CHECK(condition) (cv::ocl::isPerformanceCheckBypassed() || (condition))
+
 }}
 
 #endif
```

Review comment:
to think more carefully about suitable name
**File:** modules/core/include/opencv2/core/ocl.hpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 640

**Code Changes:**
```diff
@@ -636,6 +636,9 @@ class CV_EXPORTS Image2D
 
 CV_EXPORTS MatAllocator* getOpenCLAllocator();
 
+CV_EXPORTS_W bool isPerformanceCheckBypassed();
+#define OCL_PERFORMANCE_CHECK(condition) (cv::ocl::isPerformanceCheckBypassed() || (condition))
+
 }}
 
 #endif
```

Review comment:
ocl.hpp is sort of public OpenCV header. So the macro should have CV prefix. Internally, in precomp.hpp, you can define OCL_PERFORMANCE_CHECK as synonym for this public macro
**File:** modules/core/src/ocl.cpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 62

**Code Changes:**
```diff
 # endif
 #endif
 
+
+// TODO Move to some common place
+static bool getBoolParameter(const char* name, bool defaultValue)
+{
+    const char* envValue = getenv(name);
+    if (envValue == NULL)
+    {
+        return defaultValue;
```

Review comment:
Practice shows that using text strings as parameters is not very good idea. It's better to have enumeration.
**File:** modules/core/src/ocl.cpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 62

**Code Changes:**
```diff
 # endif
 #endif
 
+
+// TODO Move to some common place
+static bool getBoolParameter(const char* name, bool defaultValue)
+{
+    const char* envValue = getenv(name);
+    if (envValue == NULL)
+    {
+        return defaultValue;
```

Review comment:
Text strings is a natural way to use with environment variables. Can you describe this problem?
**File:** modules/core/include/opencv2/core/ocl.hpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 640

**Code Changes:**
```diff
@@ -636,6 +636,9 @@ class CV_EXPORTS Image2D
 
 CV_EXPORTS MatAllocator* getOpenCLAllocator();
 
+CV_EXPORTS_W bool isPerformanceCheckBypassed();
+#define OCL_PERFORMANCE_CHECK(condition) (cv::ocl::isPerformanceCheckBypassed() || (condition))
+
 }}
 
 #endif
```

Review comment:
Ok. Actually users should not use this macro. It is only for internal functions implementations, so I will try to move it into some internal files like `ocl_defs.hpp` with CV_ prefix
**File:** modules/core/src/ocl.cpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 62

**Code Changes:**
```diff
 # endif
 #endif
 
+
+// TODO Move to some common place
+static bool getBoolParameter(const char* name, bool defaultValue)
+{
+    const char* envValue = getenv(name);
+    if (envValue == NULL)
+    {
+        return defaultValue;
```

Review comment:
Internally, when you call getenv, you can convert enumeration constant to text string. But when you promote this text string to API, you can only catch the bug (a typo) at runtime. By using enumeration constant you get more confidence that you did not misspell the parameter name
**File:** modules/core/src/ocl.cpp
**Change Type:** modified
**Context:** PR #2879: OCL: added runtime flags for debugging - Added environment parameters to control execution of OpenCL code: - `OPENCV_OPENCL_RAISE_ERROR` - c...
**Review Line:** 62

**Code Changes:**
```diff
 # endif
 #endif
 
+
+// TODO Move to some common place
+static bool getBoolParameter(const char* name, bool defaultValue)
+{
+    const char* envValue = getenv(name);
+    if (envValue == NULL)
+    {
+        return defaultValue;
```

Review comment:
It is true if there are many places where this text constant is used. But I see one place only without future extending. Also this problem is successfully resolved by compiler defines (`#define CV_PARAMETER1 "OPENCV_PARAMETER_1"`), without introducing new enumeration types with dynamic set of values.
**File:** modules/core/include/opencv2/core/core.hpp
**Change Type:** modified
**Context:** PR #2970: Function for drawing arrows - Since I am not a python expert, the function is currently only available for c++

**Code Changes:**
```diff
@@ -2590,6 +2590,10 @@ CV_EXPORTS_AS(randShuffle) void randShuffle_(InputOutputArray dst, double iterFa
 CV_EXPORTS_W void line(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
                      int thickness=1, int lineType=8, int shift=0);
 
+//! draws an arrow from pt1 to pt2 in the image
+CV_EXPORTS_W void arrowedLine(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
+                     int thickness=1, int line_type=8, int shift=0, double tipLength=0.1);
+
 //! draws the rectangle outline or a solid rectangle with the opposite corners pt1 and pt2 in the image
 CV_EXPORTS_W void rectangle(CV_IN_OUT Mat& img, Point pt1, Point pt2,
```

Review comment:
the type of `img` should be `InputOutputArray`
**File:** modules/core/include/opencv2/core/core.hpp
**Change Type:** modified
**Context:** PR #2970: Function for drawing arrows - Since I am not a python expert, the function is currently only available for c++

**Code Changes:**
```diff
@@ -2590,6 +2590,10 @@ CV_EXPORTS_AS(randShuffle) void randShuffle_(InputOutputArray dst, double iterFa
 CV_EXPORTS_W void line(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
                      int thickness=1, int lineType=8, int shift=0);
 
+//! draws an arrow from pt1 to pt2 in the image
+CV_EXPORTS_W void arrowedLine(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
+                     int thickness=1, int line_type=8, int shift=0, double tipLength=0.1);
+
 //! draws the rectangle outline or a solid rectangle with the opposite corners pt1 and pt2 in the image
 CV_EXPORTS_W void rectangle(CV_IN_OUT Mat& img, Point pt1, Point pt2,
```

Review comment:
Ok, maybe for 2.4 branch your solution is good, but in master branch we use `InputArray` / `OutputArray` anywhere to ensure the functions to work with both `Mat` and `UMat`.
**File:** modules/core/include/opencv2/core/core.hpp
**Change Type:** modified
**Context:** PR #2970: Function for drawing arrows - Since I am not a python expert, the function is currently only available for c++

**Code Changes:**
```diff
@@ -2590,6 +2590,10 @@ CV_EXPORTS_AS(randShuffle) void randShuffle_(InputOutputArray dst, double iterFa
 CV_EXPORTS_W void line(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
                      int thickness=1, int lineType=8, int shift=0);
 
+//! draws an arrow from pt1 to pt2 in the image
+CV_EXPORTS_W void arrowedLine(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
+                     int thickness=1, int line_type=8, int shift=0, double tipLength=0.1);
+
 //! draws the rectangle outline or a solid rectangle with the opposite corners pt1 and pt2 in the image
 CV_EXPORTS_W void rectangle(CV_IN_OUT Mat& img, Point pt1, Point pt2,
```

Review comment:
Ok. Should I leave the code as it is, add the missing "CV_IN_OUT" or switch to the new InputOutputArray?
**File:** modules/core/include/opencv2/core/core.hpp
**Change Type:** modified
**Context:** PR #2970: Function for drawing arrows - Since I am not a python expert, the function is currently only available for c++

**Code Changes:**
```diff
@@ -2590,6 +2590,10 @@ CV_EXPORTS_AS(randShuffle) void randShuffle_(InputOutputArray dst, double iterFa
 CV_EXPORTS_W void line(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
                      int thickness=1, int lineType=8, int shift=0);
 
+//! draws an arrow from pt1 to pt2 in the image
+CV_EXPORTS_W void arrowedLine(CV_IN_OUT Mat& img, Point pt1, Point pt2, const Scalar& color,
+                     int thickness=1, int line_type=8, int shift=0, double tipLength=0.1);
+
 //! draws the rectangle outline or a solid rectangle with the opposite corners pt1 and pt2 in the image
 CV_EXPORTS_W void rectangle(CV_IN_OUT Mat& img, Point pt1, Point pt2,
```

Review comment:
I think you should make prototype of the function according to 2.4 style, i.e. `CV_IN_OUT Mat& img` and if this patch has been accepted, you make another PR for master with `InputOutputArray`
**File:** modules/core/src/drawing.cpp
**Change Type:** modified
**Context:** PR #2970: Function for drawing arrows - Since I am not a python expert, the function is currently only available for c++

**Code Changes:**
```diff
@@ -1580,6 +1580,25 @@ void line( Mat& img, Point pt1, Point pt2, const Scalar& color,
     ThickLine( img, pt1, pt2, buf, thickness, line_type, 3, shift );
 }
 
+void arrowedLine(Mat& img, Point pt1, Point pt2, const Scalar& color,
+           int thickness, int line_type, int shift, double tipLength)
+{
+    const double tipSize = norm(pt1-pt2)*tipLength;// Factor to normalize the size of the tip depending on the length of the arrow
+
+    line(img, pt1, pt2, color, thickness, line_type, shift);
```

Review comment:
please, use cvRound(x) instead of (int)(x), since this will give you more accurate results. The comment relates to this line and few places below
**File:** modules/imgproc/src/templmatch.cpp
**Change Type:** modified
**Context:** PR #3013: OCL: matchTemplate - **Description:** - used `float` instead of `int` for `CV_8U` in sumTemplate - new block size for `dft` - added `dft` fo...

**Code Changes:**
```diff
@@ -79,7 +79,7 @@ static bool extractFirstChannel_32F(InputArray _image, OutputArray _result, int
 static bool sumTemplate(InputArray _src, UMat & result)
 {
     int type = _src.type(), depth = CV_MAT_DEPTH(type), cn = CV_MAT_CN(type);
-    int wdepth = std::max(CV_32S, depth), wtype = CV_MAKE_TYPE(wdepth, cn);
+    int wdepth = CV_32F, wtype = CV_MAKE_TYPE(wdepth, cn);
     size_t wgs = ocl::Device::getDefault().maxWorkGroupSize();
 
     int wgs2_aligned = 1;
@@ -89,10 +89,10 @@ static bool sumTemplate(InputArray _src, UMat & result)
```

Review comment:
Can we use `std::min` for consistency?
**File:** modules/imgproc/src/templmatch.cpp
**Change Type:** modified
**Context:** PR #3013: OCL: matchTemplate - **Description:** - used `float` instead of `int` for `CV_8U` in sumTemplate - new block size for `dft` - added `dft` fo...
**Review Line:** 82

**Code Changes:**
```diff
@@ -79,7 +79,7 @@ static bool extractFirstChannel_32F(InputArray _image, OutputArray _result, int
 static bool sumTemplate(InputArray _src, UMat & result)
 {
     int type = _src.type(), depth = CV_MAT_DEPTH(type), cn = CV_MAT_CN(type);
-    int wdepth = std::max(CV_32S, depth), wtype = CV_MAKE_TYPE(wdepth, cn);
+    int wdepth = CV_32F, wtype = CV_MAKE_TYPE(wdepth, cn);
     size_t wgs = ocl::Device::getDefault().maxWorkGroupSize();
 
     int wgs2_aligned = 1;
@@ -89,10 +89,10 @@ static bool sumTemplate(InputArray _src, UMat & result)
 
```

Review comment:
are you sure that `CV_32F` should be used for `CV_64F` too?
**File:** modules/imgproc/src/templmatch.cpp
**Change Type:** modified
**Context:** PR #3013: OCL: matchTemplate - **Description:** - used `float` instead of `int` for `CV_8U` in sumTemplate - new block size for `dft` - added `dft` fo...
**Review Line:** 82

**Code Changes:**
```diff
@@ -79,7 +79,7 @@ static bool extractFirstChannel_32F(InputArray _image, OutputArray _result, int
 static bool sumTemplate(InputArray _src, UMat & result)
 {
     int type = _src.type(), depth = CV_MAT_DEPTH(type), cn = CV_MAT_CN(type);
-    int wdepth = std::max(CV_32S, depth), wtype = CV_MAKE_TYPE(wdepth, cn);
+    int wdepth = CV_32F, wtype = CV_MAKE_TYPE(wdepth, cn);
     size_t wgs = ocl::Device::getDefault().maxWorkGroupSize();
 
     int wgs2_aligned = 1;
@@ -89,10 +89,10 @@ static bool sumTemplate(InputArray _src, UMat & result)
 
```

Review comment:
No, but this function is used only for `CV_8U` and `CV_32F`
**File:** modules/python/common.cmake
**Change Type:** added
**Context:** PR #3047: Build both Python 2 and Python 3 bindings - This replaces #2912 and potentially #3040 by @vpisarev. I have once again updated my branch with...
**Review Line:** 19

**Code Changes:**
```diff
+
+# module blacklist
+ocv_list_filterout(candidate_deps "^opencv_cud(a|ev)")
+ocv_list_filterout(candidate_deps "^opencv_adas$")
+ocv_list_filterout(candidate_deps "^opencv_matlab$")
+ocv_list_filterout(candidate_deps "^opencv_tracking$")
+
+
+ocv_add_module(${MODULE_NAME} BINDINGS OPTIONAL ${candidate_deps})
+
+ocv_module_include_directories(
```

Review comment:
while you are here, please, also add opencv_matlab into the list of ignored modules.
**File:** modules/python/common.cmake
**Change Type:** added
**Context:** PR #3047: Build both Python 2 and Python 3 bindings - This replaces #2912 and potentially #3040 by @vpisarev. I have once again updated my branch with...

**Code Changes:**
```diff
@@ -0,0 +1,139 @@
+# This file is included from a subdirectory
+set(PYTHON_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../")
+
+set(candidate_deps "")
+foreach(mp ${OPENCV_MODULES_PATH} ${OPENCV_EXTRA_MODULES_PATH})
+    file(GLOB names "${mp}/*")
+    foreach(m IN LISTS names)
+        if(IS_DIRECTORY ${m})
+            get_filename_component(m ${m} NAME)
```

Review comment:
the suggestion is to put cv2.so into the root directory and python3 module into the python3 subdirectory; this will make our python tests pass