nareshmlx/opencv-pr huggingface dataset:
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
> May I also change this way the SSE2 optimizations? Sure, by all means (just please test that you didn't break them :wink:). FWIW, I think you can change those operators to static functions, which should remove the need to create dummy `Op8` objects.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
There's no need for this operator. Just leave it out and let it bomb at compile time.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
You haven't factored out all duplication yet. All that distinguishes these bodies is the function name; you can move `{ return` and `(a); }` into the macro.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
I need to make a habit of scrolling further down before commenting. Yeah, VAbsDiff is slightly different. You could still factor out the braces and `return`, though.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Well, all of this seems workable, but I have to say I had something slightly different in mind. Basically, like this: ``` template <> struct VLoadStore128<ushort> { typedef uint16x8_t reg_type; static reg_type load(const ushort * p) { ... } static store(ushort * p, reg_type value) { ... } }; ``` Then you could do stuff like: ``` template<> struct VAdd<ushort> { static VLoadStore<ushort>::reg_type do(VLoadStore<ushort>::reg_type a, VLoadStore<ushort>::reg_type b) { ... } }; ``` (all generatable with a macro, of course) What you gain is that you reduce the number of macro arguments to 4 for each load/store pair (you currently have 10) and 3 for every arithmetic operation (you have 4). You also get the `VLoadStore<T>::reg_type` metafunction, which you might need elsewhere. I can accept this as it is, since it can always be refactored later, but consider my approach.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Isn't this a one-argument operation?
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Ah, but you have changed the order of operations, which I'm pretty sure was deliberate. ~~You have also removed the second loop, which was probably deliberate as well.~~
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
These declarations are getting increasingly awkward. You should probably switch to static methods.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
This `if` here should probably stay as it is.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Huh. Does this actually work?
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Shouldn't this be `FUNCTOR_2arg`? I'm not sure, but are these the same as in the NEON branch? If so, make them common.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
VNot was considered a binary operator from the start, this is why I kept it as such.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Right, never mind then.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Looking good, but I don't think you need the 3rd parameter - you can use `VLoadStore128<template_arg>::reg_type` instead.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
This isn't a very descriptive name. :smiley: How about `FUNCTOR_LOADSTORE_TYPESAFE`? Or perhaps make this one just `FUNCTOR_LOADSTORE` and the previous one `FUNCTOR_LOADSTORE_CAST`. Addendum: you don't really need the second macro, since the first one will work for both. But if you want that extra bit of type safety, sure, go ahead.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Unfortunately, this causes warnings like these: http://build.opencv.org/builders/precommit_ubuntu/builds/5262/steps/compile/logs/stdio You'll have to create a variant of `FUNCTOR_CLOSURE_2arg` where the second argument to `operator()` isn't named.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
This cast looks like it should be to `const reg_type *`.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
The same comment about not needing the 3rd argument applies here, I believe.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Here it would be more awkward, as instead of a single VLoadStore class I have three instead of only one (the regular one, the 64-bit one and the memory-aligned one) but none of them works for all data types.
**File:** modules/core/src/arithm.cpp
**Change Type:** modified
**Context:** PR #1292: Add optional NEON intrinsics to core/src/arithm.cpp - I wrote some vector-processing code using NEON compiler intrinsics, and in the future ...

**Code Changes:**
```diff
@@ -54,21 +54,23 @@ namespace cv
 
 struct NOP {};
 
-#if CV_SSE2
+#if CV_SSE2 || CV_NEON
 
 #define FUNCTOR_TEMPLATE(name)          \
     template<typename T> struct name {}
 
```

Review comment:
Well, `VLoadStore128` is only missing a `double` version, right? Just add it, and then you can use it everywhere.
**File:** cmake/OpenCVCompilerOptions.cmake
**Change Type:** modified
**Context:** PR #2836: Changes to support Intel AVX/AVX2 in cvResize(). - This patch - adds code path for Intel AVX2 detection, and - utilizes Intel AVX/AVX2 intri...

**Code Changes:**
```diff
@@ -140,7 +140,11 @@ if(CMAKE_COMPILER_IS_GNUCXX)
   # SSE3 and further should be disabled under MingW because it generates compiler errors
   if(NOT MINGW)
     if(ENABLE_AVX)
-      add_extra_compiler_option(-mavx)
+      ocv_check_flag_support(CXX "-mavx" _varname)
+    endif()
+
+    if(ENABLE_AVX2)
+      ocv_check_flag_support(CXX "-mavx2" _varname)
```

Review comment:
hm, according to this: http://www.virtualdub.org/blog/pivot/entry.php?id=347, if I put /arch:AVX or /arch:AVX2, the code will likely crash on CPUs without AVX/AVX2 support. I see that this is not you who introduced the problem, we also have the same problem with SSE 4.x. But since OpenCV checks in runtime whether architecture supports SSE4.x/AVX/AVX2, can we somehow enable your fast branches of resize (and maybe other functions) and at the same time keep the backward compatibility with older CPUs?
**File:** cmake/OpenCVCompilerOptions.cmake
**Change Type:** modified
**Context:** PR #2836: Changes to support Intel AVX/AVX2 in cvResize(). - This patch - adds code path for Intel AVX2 detection, and - utilizes Intel AVX/AVX2 intri...

**Code Changes:**
```diff
@@ -140,7 +140,11 @@ if(CMAKE_COMPILER_IS_GNUCXX)
   # SSE3 and further should be disabled under MingW because it generates compiler errors
   if(NOT MINGW)
     if(ENABLE_AVX)
-      add_extra_compiler_option(-mavx)
+      ocv_check_flag_support(CXX "-mavx" _varname)
+    endif()
+
+    if(ENABLE_AVX2)
+      ocv_check_flag_support(CXX "-mavx2" _varname)
```

Review comment:
That is correct. /arch:AVX and /arch:AVX2 allow the compiler to use extended instructions in generated code, even when the intrinsics aren't used. -mavx and -mavx2 on GCC have the same effect, as well. Easiest solution would be to consolidate AVX/AVX2 functions in separate files, and specify /arch:AVX\* or -mavx\* only when compiling those files. Should I refactor the code and submit a new pull request?
**File:** cmake/OpenCVCompilerOptions.cmake
**Change Type:** modified
**Context:** PR #2836: Changes to support Intel AVX/AVX2 in cvResize(). - This patch - adds code path for Intel AVX2 detection, and - utilizes Intel AVX/AVX2 intri...

**Code Changes:**
```diff
@@ -140,7 +140,11 @@ if(CMAKE_COMPILER_IS_GNUCXX)
   # SSE3 and further should be disabled under MingW because it generates compiler errors
   if(NOT MINGW)
     if(ENABLE_AVX)
-      add_extra_compiler_option(-mavx)
+      ocv_check_flag_support(CXX "-mavx" _varname)
+    endif()
+
+    if(ENABLE_AVX2)
+      ocv_check_flag_support(CXX "-mavx2" _varname)
```

Review comment:
question - can the AVX code be built without specifying /arch:AVX or /arch:AVX2? If yes, then we should build the files without those flags.
**File:** cmake/OpenCVCompilerOptions.cmake
**Change Type:** modified
**Context:** PR #2836: Changes to support Intel AVX/AVX2 in cvResize(). - This patch - adds code path for Intel AVX2 detection, and - utilizes Intel AVX/AVX2 intri...

**Code Changes:**
```diff
@@ -140,7 +140,11 @@ if(CMAKE_COMPILER_IS_GNUCXX)
   # SSE3 and further should be disabled under MingW because it generates compiler errors
   if(NOT MINGW)
     if(ENABLE_AVX)
-      add_extra_compiler_option(-mavx)
+      ocv_check_flag_support(CXX "-mavx" _varname)
+    endif()
+
+    if(ENABLE_AVX2)
+      ocv_check_flag_support(CXX "-mavx2" _varname)
```

Review comment:
OK. I've finished refactoring. Just to double check; should I submit a new pull request?
**File:** cmake/templates/OpenCVConfig.cmake.in
**Change Type:** modified
**Context:** PR #2714: Fix non-Android cross compilation with OpenCVConfig.cmake - Right now in some cases setup og OpenCV_ANDROID_NATIVE_API_LEVEL leads to invali...

**Code Changes:**
```diff
@@ -60,7 +60,11 @@ set(OpenCV_USE_CUFFT    @HAVE_CUFFT@)
 set(OpenCV_USE_NVCUVID  @HAVE_NVCUVID@)
 
 # Android API level from which OpenCV has been compiled is remembered
-set(OpenCV_ANDROID_NATIVE_API_LEVEL @OpenCV_ANDROID_NATIVE_API_LEVEL_CONFIGCMAKE@)
+if(ANDROID)
+  set(OpenCV_ANDROID_NATIVE_API_LEVEL @OpenCV_ANDROID_NATIVE_API_LEVEL_CONFIGCMAKE@)
+else
+  set(OpenCV_ANDROID_NATIVE_API_LEVEL 0)
+endif()
```

Review comment:
I have a feeling people might rely on `OpenCV_ANDROID_NATIVE_API_LEVEL` to always be defined. I suggest an `else` branch setting it to zero. Also, no spaces after command names, please.
**File:** modules/core/src/dxt.cpp
**Change Type:** modified
**Context:** PR #2930: Fixed dst size in cv::dft - In case 1d real to complex transformation, result size is (width/2+1, height/2+1) - half of full complex output ...

**Code Changes:**
```diff
@@ -1496,6 +1496,7 @@ void cv::dft( InputArray _src0, OutputArray _dst, int flags, int nonzero_rows )
     int elem_size = (int)src.elemSize1(), complex_elem_size = elem_size*2;
     int factors[34];
     bool inplace_transform = false;
+    bool is1d = (flags & DFT_ROWS) != 0 || src.rows == 1;
 #ifdef USE_IPP_DFT
     AutoBuffer<uchar> ippbuf;
     int ipp_norm_flag = !(flags & DFT_SCALE) ? 8 : inv ? 2 : 1;
@@ -1504,7 +1505,10 @@ void cv::dft( InputArray _src0, OutputArray _dst, int flags, int nonzero_rows )
     CV_Assert( type == CV_32FC1 || type == CV_32FC2 || type == CV_64FC1 || type == CV_64FC2 );
```

Review comment:
what's wrong with `src.cols` & `src.rows`?
**File:** modules/imgproc/src/pyramids.cpp
**Change Type:** modified
**Context:** PR #2766: Disabling BORDER_CONSTANT for pyramid functions - Added assert to check for borderType is not BORDER_CONSTANT for pyrDown and borderType is ...
**Review Line:** 438

**Code Changes:**
```diff
     _dst.create( dsz, src.type() );
@@ -433,6 +435,8 @@ void cv::pyrDown( InputArray _src, OutputArray _dst, const Size& _dsz, int borde
 
 void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderType )
 {
+    CV_Assert(borderType == BORDER_DEFAULT);
+
     Mat src = _src.getMat();
     Size dsz = _dsz == Size() ? Size(src.cols*2, src.rows*2) : _dsz;
     _dst.create( dsz, src.type() );
@@ -463,6 +467,8 @@ void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderT
```

Review comment:
why is this check? do we support a single border mode?
**File:** modules/imgproc/src/pyramids.cpp
**Change Type:** modified
**Context:** PR #2766: Disabling BORDER_CONSTANT for pyramid functions - Added assert to check for borderType is not BORDER_CONSTANT for pyrDown and borderType is ...
**Review Line:** 438

**Code Changes:**
```diff
     _dst.create( dsz, src.type() );
@@ -433,6 +435,8 @@ void cv::pyrDown( InputArray _src, OutputArray _dst, const Size& _dsz, int borde
 
 void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderType )
 {
+    CV_Assert(borderType == BORDER_DEFAULT);
+
     Mat src = _src.getMat();
     Size dsz = _dsz == Size() ? Size(src.cols*2, src.rows*2) : _dsz;
     _dst.create( dsz, src.type() );
@@ -463,6 +467,8 @@ void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderT
```

Review comment:
Yes, pyrUp supports only `BORDER_DEFAULT`. I have updated description and documantation.
**File:** modules/imgproc/src/pyramids.cpp
**Change Type:** modified
**Context:** PR #2766: Disabling BORDER_CONSTANT for pyramid functions - Added assert to check for borderType is not BORDER_CONSTANT for pyrDown and borderType is ...
**Review Line:** 438

**Code Changes:**
```diff
     _dst.create( dsz, src.type() );
@@ -433,6 +435,8 @@ void cv::pyrDown( InputArray _src, OutputArray _dst, const Size& _dsz, int borde
 
 void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderType )
 {
+    CV_Assert(borderType == BORDER_DEFAULT);
+
     Mat src = _src.getMat();
     Size dsz = _dsz == Size() ? Size(src.cols*2, src.rows*2) : _dsz;
     _dst.create( dsz, src.type() );
@@ -463,6 +467,8 @@ void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderT
```

Review comment:
should we explicitly replace BORDER_DEFAULT in the assert with BORDER_REFLECT_101? because if we sometimes change the BORDER_DEFAULT, the assert will not longer be true
**File:** modules/imgproc/src/pyramids.cpp
**Change Type:** modified
**Context:** PR #2766: Disabling BORDER_CONSTANT for pyramid functions - Added assert to check for borderType is not BORDER_CONSTANT for pyrDown and borderType is ...
**Review Line:** 438

**Code Changes:**
```diff
     _dst.create( dsz, src.type() );
@@ -433,6 +435,8 @@ void cv::pyrDown( InputArray _src, OutputArray _dst, const Size& _dsz, int borde
 
 void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderType )
 {
+    CV_Assert(borderType == BORDER_DEFAULT);
+
     Mat src = _src.getMat();
     Size dsz = _dsz == Size() ? Size(src.cols*2, src.rows*2) : _dsz;
     _dst.create( dsz, src.type() );
@@ -463,6 +467,8 @@ void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderT
```

Review comment:
Yes. Fixed.
**File:** modules/imgproc/src/pyramids.cpp
**Change Type:** modified
**Context:** PR #2766: Disabling BORDER_CONSTANT for pyramid functions - Added assert to check for borderType is not BORDER_CONSTANT for pyrDown and borderType is ...
**Review Line:** 438

**Code Changes:**
```diff
     _dst.create( dsz, src.type() );
@@ -433,6 +435,8 @@ void cv::pyrDown( InputArray _src, OutputArray _dst, const Size& _dsz, int borde
 
 void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderType )
 {
+    CV_Assert(borderType == BORDER_DEFAULT);
+
     Mat src = _src.getMat();
     Size dsz = _dsz == Size() ? Size(src.cols*2, src.rows*2) : _dsz;
     _dst.create( dsz, src.type() );
@@ -463,6 +467,8 @@ void cv::pyrUp( InputArray _src, OutputArray _dst, const Size& _dsz, int borderT
```

Review comment:
In this case we need to change default parameter of function to `BORDER_REFLECT_101` too. We can change it without breaking compatibility (or other issues)?
**File:** modules/core/doc/drawing_functions.rst
**Change Type:** modified
**Context:** PR #2979: Function for drawing arrows - Porting the [PR 2970](https://github.com/Itseez/opencv/pull/2970) to the new InputOutputArray type

**Code Changes:**
```diff
@@ -361,6 +361,37 @@ The function ``line`` draws the line segment between ``pt1`` and ``pt2`` points
 Antialiased lines are drawn using Gaussian filtering.
 
 
+arrowedLine
+----------------
+Draws a arrow segment pointing from the first point to the second one.
+
+.. ocv:function:: void arrowedLine(InputOutputArray img, Point pt1, Point pt2, const Scalar& color,          int thickness=1, int lineType=8, int shift=0, double tipLength=0.1)
+
```

Review comment:
`Mat&` -> `InputOutputArray`
**File:** modules/core/include/opencv2/core/mat.hpp
**Change Type:** modified
**Context:** PR #2565: TAPI: stitching - Replacement for #2472. check_regression=OCL_stitch_:OCL_Warp_:OCL_Remap_ test_modules=core,features2d,stitching build_exam...
**Review Line:** 223

**Code Changes:**
```diff
     virtual void release() const;
     virtual void clear() const;
     virtual void setTo(const _InputArray& value, const _InputArray & mask = _InputArray()) const;
+
+    void assign(const UMat& u) const;
+    void assign(const Mat& m) const;
 };
 
 
```

Review comment:
should be `void assign(Inputarray m) const;`