nareshmlx/opencv-pr huggingface dataset:
**File:** cmake/OpenCVDownload.cmake
**Change Type:** added
**Context:** PR #8421: Modified cmake file download process - Coupled with opencv/opencv_contrib#1073 and opencv/opencv_extra#327 ### This pullrequest changes Upda...

**Code Changes:**
```diff
@@ -0,0 +1,133 @@
+#
+#  Download and optionally unpack a file
+#
+#  ocv_download(FILENAME p HASH h URL u1 [u2 ...] DESTINATION_DIR d [STATUS s] [UNPACK] [RELATIVE])
+#    FILENAME - filename
+#    HASH - MD5 hash
+#    URL - full download url (first nonempty value will be chosen)
+#    DESTINATION_DIR - file will be copied to this directory
+#    STATUS - passed variable will be updated in parent scope,
```

Review comment:
We need to support environment variables to specify external download directory - It is preferable way for buildbot
**File:** cmake/OpenCVDownload.cmake
**Change Type:** added
**Context:** PR #8421: Modified cmake file download process - Coupled with opencv/opencv_contrib#1073 and opencv/opencv_extra#327 ### This pullrequest changes Upda...

**Code Changes:**
```diff
@@ -0,0 +1,133 @@
+#
+#  Download and optionally unpack a file
+#
+#  ocv_download(FILENAME p HASH h URL u1 [u2 ...] DESTINATION_DIR d [STATUS s] [UNPACK] [RELATIVE])
+#    FILENAME - filename
+#    HASH - MD5 hash
+#    URL - full download url (first nonempty value will be chosen)
+#    DESTINATION_DIR - file will be copied to this directory
+#    STATUS - passed variable will be updated in parent scope,
```

Review comment:
The log file is supposed to be used in external scripts, so it should contain all download commands only once.
**File:** cmake/OpenCVDownload.cmake
**Change Type:** added
**Context:** PR #8421: Modified cmake file download process - Coupled with opencv/opencv_contrib#1073 and opencv/opencv_extra#327 ### This pullrequest changes Upda...

**Code Changes:**
```diff
@@ -0,0 +1,133 @@
+#
+#  Download and optionally unpack a file
+#
+#  ocv_download(FILENAME p HASH h URL u1 [u2 ...] DESTINATION_DIR d [STATUS s] [UNPACK] [RELATIVE])
+#    FILENAME - filename
+#    HASH - MD5 hash
+#    URL - full download url (first nonempty value will be chosen)
+#    DESTINATION_DIR - file will be copied to this directory
+#    STATUS - passed variable will be updated in parent scope,
```

Review comment:
Do you mean "remove RELATIVE_URL flag and always append DL_FILENAME to DL_URL"? In some cases an URL can have different format, for example on the SourceForge we have `https://sourceforge.net/projects/<project>/files/<path>/<name>/download` It is also useful if we want to rename file during download. We could make the opposite mode the default and eliminate this flag, but than the most of `ocv_download` calls will look more complicated, because of appending FILENAME to URL.
**File:** cmake/OpenCVDownload.cmake
**Change Type:** added
**Context:** PR #8421: Modified cmake file download process - Coupled with opencv/opencv_contrib#1073 and opencv/opencv_extra#327 ### This pullrequest changes Upda...

**Code Changes:**
```diff
@@ -0,0 +1,133 @@
+#
+#  Download and optionally unpack a file
+#
+#  ocv_download(FILENAME p HASH h URL u1 [u2 ...] DESTINATION_DIR d [STATUS s] [UNPACK] [RELATIVE])
+#    FILENAME - filename
+#    HASH - MD5 hash
+#    URL - full download url (first nonempty value will be chosen)
+#    DESTINATION_DIR - file will be copied to this directory
+#    STATUS - passed variable will be updated in parent scope,
```

Review comment:
I agree. What about single `Download: ${DL_URL}`? Or `Download: ${DL_FILENAME}`?
**File:** .gitignore
**Change Type:** modified
**Context:** PR #8421: Modified cmake file download process - Coupled with opencv/opencv_contrib#1073 and opencv/opencv_extra#327 ### This pullrequest changes Upda...
**Review Line:** 6

**Code Changes:**
```diff
@@ -3,6 +3,7 @@
 *.user
 *~
 .*.swp
+.cache
 .DS_Store
 .sw[a-z]
 Thumbs.db
```

Review comment:
Sure, I will make PR for 2.4.
**File:** cmake/OpenCVDownload.cmake
**Change Type:** added
**Context:** PR #8421: Modified cmake file download process - Coupled with opencv/opencv_contrib#1073 and opencv/opencv_extra#327 ### This pullrequest changes Upda...
**Review Line:** 65

**Code Changes:**
```diff
+
+  # Copy mode: check if copy destination exists and is correct
+  if(NOT DL_UNPACK)
+    set(COPY_DESTINATION "${DL_DESTINATION_DIR}/${DL_FILENAME}")
+    if(EXISTS "${COPY_DESTINATION}")
+      file(MD5 "${COPY_DESTINATION}" target_md5)
+      if(target_md5 STREQUAL DL_HASH)
+        return()
+      endif()
+    endif()
+  endif()
```

Review comment:
This check is for _"copy single file"_ mode only, so unpacks are not affected. And most of such files will be copied to the source folder (descriptors in xfeatures2d). I think it is better to leave it as is because it is more simple, less error prone and doesn't affect performance too much.
**File:** cmake/OpenCVDownload.cmake
**Change Type:** added
**Context:** PR #8421: Modified cmake file download process - Coupled with opencv/opencv_contrib#1073 and opencv/opencv_extra#327 ### This pullrequest changes Upda...

**Code Changes:**
```diff
@@ -0,0 +1,133 @@
+#
+#  Download and optionally unpack a file
+#
+#  ocv_download(FILENAME p HASH h URL u1 [u2 ...] DESTINATION_DIR d [STATUS s] [UNPACK] [RELATIVE])
+#    FILENAME - filename
+#    HASH - MD5 hash
+#    URL - full download url (first nonempty value will be chosen)
+#    DESTINATION_DIR - file will be copied to this directory
+#    STATUS - passed variable will be updated in parent scope,
```

Review comment:
In this case we don't want to depend on cmake behavior - sometimes we throw fatal error, sometimes a warning. Restoring this part will also result in double MD5 check.
**File:** modules/cudaarithm/src/cuda/absdiff_scalar.cu
**Change Type:** modified
**Context:** PR #8314: fix #8309 : make cuda::absdiff support multi-channel scalars - resolves #8309 I took the subScalar.cu code and changed the inner operation

**Code Changes:**
```diff
@@ -56,14 +56,14 @@ void absDiffScalar(const GpuMat& src, cv::Scalar val, bool, GpuMat& dst, const G
 
 namespace
 {
-    template <typename T, typename S> struct AbsDiffScalarOp : unary_function<T, T>
+    template <typename SrcType, typename ScalarType, typename DstType> struct AbsDiffScalarOp : unary_function<SrcType, DstType>
     {
-        S val;
+        ScalarType val;
 
```

Review comment:
`T` is not "src" type only. There is "dst" type too. So "T" naming seems valid. `S` is probably "work type" here ("WT").
**File:** modules/cudaarithm/src/cuda/absdiff_scalar.cu
**Change Type:** modified
**Context:** PR #8314: fix #8309 : make cuda::absdiff support multi-channel scalars - resolves #8309 I took the subScalar.cu code and changed the inner operation
**Review Line:** 81

**Code Changes:**
```diff
@@ -78,33 +78,57 @@ namespace
     };
 
     template <typename SrcType, typename ScalarDepth>
-    void absDiffScalarImpl(const GpuMat& src, double value, GpuMat& dst, Stream& stream)
+    void absDiffScalarImpl(const GpuMat& src, cv::Scalar value, GpuMat& dst, Stream& stream)
     {
-        AbsDiffScalarOp<SrcType, ScalarDepth> op;
-        op.val = static_cast<ScalarDepth>(value);
+        typedef typename MakeVec<ScalarDepth, VecTraits<SrcType>::cn>::type ScalarType;
+
```

Review comment:
Does `cv::Scalar value` => `const cv::Scalar& value` work? What is about "double value[4]"?
**File:** modules/cudaarithm/src/cuda/absdiff_scalar.cu
**Change Type:** modified
**Context:** PR #8314: fix #8309 : make cuda::absdiff support multi-channel scalars - resolves #8309 I took the subScalar.cu code and changed the inner operation

**Code Changes:**
```diff
@@ -56,14 +56,14 @@ void absDiffScalar(const GpuMat& src, cv::Scalar val, bool, GpuMat& dst, const G
 
 namespace
 {
-    template <typename T, typename S> struct AbsDiffScalarOp : unary_function<T, T>
+    template <typename SrcType, typename ScalarType, typename DstType> struct AbsDiffScalarOp : unary_function<SrcType, DstType>
     {
-        S val;
+        ScalarType val;
 
```

Review comment:
Why do we need to force "double" instead of "float" for all types? This change will reduce performance. Or this may [not work](https://github.com/opencv/opencv/blob/3.2.0/modules/cudaarithm/src/element_operations.cpp#L146-L147) at all.
**File:** modules/cudaarithm/src/cuda/absdiff_scalar.cu
**Change Type:** modified
**Context:** PR #8314: fix #8309 : make cuda::absdiff support multi-channel scalars - resolves #8309 I took the subScalar.cu code and changed the inner operation

**Code Changes:**
```diff
@@ -56,14 +56,14 @@ void absDiffScalar(const GpuMat& src, cv::Scalar val, bool, GpuMat& dst, const G
 
 namespace
 {
-    template <typename T, typename S> struct AbsDiffScalarOp : unary_function<T, T>
+    template <typename SrcType, typename ScalarType, typename DstType> struct AbsDiffScalarOp : unary_function<SrcType, DstType>
     {
-        S val;
+        ScalarType val;
 
```

Review comment:
I have integrated corrections matching your remarks. About testing, I do not know (yet) how to integrate that properly in opencv tests. For now, I use a local external program that runs : `int depths[] = {CV_8U, CV_8S, CV_16U, CV_16S, CV_32S, CV_32F, CV_64F}; int channels[] = {1, 3, 4}; if (isGpuEnabled) for(int i = 0 ; i<sizeof(depths)/sizeof(int) ; ++i) { for(int j = 0 ; j<sizeof(channels)/sizeof(int) ; ++j) { int type = CV_MAKETYPE(depths[i], channels[j]); try{ cv::cuda::GpuMat gpuMat1(cv::Size(512, 512), type); cv::cuda::GpuMat gpuMat2(cv::Size(512, 512), type); cv::Mat mat1; cv::Mat mat2; gpuMat1.setTo(cv::Scalar(64, 128, 192, 256)); gpuMat2.setTo(cv::Scalar(64, 128, 192, 256)); cv::cuda::subtract(gpuMat1, cv::Scalar(64, -64, 32, -1024), gpuMat1); cv::cuda::abs(gpuMat1, gpuMat1); gpuMat1.download(mat1); cv::cuda::absdiff(gpuMat2, cv::Scalar(64, -64, 32, -1024), gpuMat2); gpuMat2.download(mat2); cv::Mat diff = (mat1 != mat2); std::vector<cv::Mat> channels(diff.channels()); cv::split(diff, channels); size_t countNonZero = 0; for(std::vector<cv::Mat>::const_iterator it = channels.begin() ; it != channels.end() ; ++it) countNonZero += cv::countNonZero(*it); if (!countNonZero) printf("equality for type %d\n", type); else printf("NOT equality for type %d\n", type); } catch(std::exception& e){ printf("type %d, exception <%s>\n", type, e.what()); } } }`
**File:** modules/cudaarithm/src/cuda/absdiff_scalar.cu
**Change Type:** modified
**Context:** PR #8314: fix #8309 : make cuda::absdiff support multi-channel scalars - resolves #8309 I took the subScalar.cu code and changed the inner operation

**Code Changes:**
```diff
@@ -56,14 +56,14 @@ void absDiffScalar(const GpuMat& src, cv::Scalar val, bool, GpuMat& dst, const G
 
 namespace
 {
-    template <typename T, typename S> struct AbsDiffScalarOp : unary_function<T, T>
+    template <typename SrcType, typename ScalarType, typename DstType> struct AbsDiffScalarOp : unary_function<SrcType, DstType>
     {
-        S val;
+        ScalarType val;
 
```

Review comment:
do we really need that many generated overloads? double and int are quite rarely used types for images
**File:** modules/cudaarithm/src/cuda/absdiff_scalar.cu
**Change Type:** modified
**Context:** PR #8314: fix #8309 : make cuda::absdiff support multi-channel scalars - resolves #8309 I took the subScalar.cu code and changed the inner operation

**Code Changes:**
```diff
@@ -56,14 +56,14 @@ void absDiffScalar(const GpuMat& src, cv::Scalar val, bool, GpuMat& dst, const G
 
 namespace
 {
-    template <typename T, typename S> struct AbsDiffScalarOp : unary_function<T, T>
+    template <typename SrcType, typename ScalarType, typename DstType> struct AbsDiffScalarOp : unary_function<SrcType, DstType>
     {
-        S val;
+        ScalarType val;
 
```

Review comment:
I agree, using double will likely degrade performance significantly
**File:** modules/cudaarithm/src/cuda/absdiff_scalar.cu
**Change Type:** modified
**Context:** PR #8314: fix #8309 : make cuda::absdiff support multi-channel scalars - resolves #8309 I took the subScalar.cu code and changed the inner operation

**Code Changes:**
```diff
@@ -56,14 +56,14 @@ void absDiffScalar(const GpuMat& src, cv::Scalar val, bool, GpuMat& dst, const G
 
 namespace
 {
-    template <typename T, typename S> struct AbsDiffScalarOp : unary_function<T, T>
+    template <typename SrcType, typename ScalarType, typename DstType> struct AbsDiffScalarOp : unary_function<SrcType, DstType>
     {
-        S val;
+        ScalarType val;
 
```

Review comment:
I did not sync my previous modifications, ok to use float instead of double
**File:** modules/core/include/opencv2/core/openvx/ovx_defs.hpp
**Change Type:** modified
**Context:** PR #8455: OpenVX HAL calls disabled for images less than certain threshold - ### This pullrequest changes Disable calls to OpenVX for small image proc...
**Review Line:** 28

**Code Changes:**
```diff
@@ -24,6 +24,8 @@ namespace cv{
 namespace ovx{
 // Get common thread local OpenVX context
 CV_EXPORTS_W ivx::Context& getOpenVXContext();
+
+template <int kernel_id> inline bool skipSmallImages(int w, int h)     { return w*h < 3840 * 2160; }
 }}
 
 #define CV_OVX_RUN(condition, func, ...)          \
```

Review comment:
I think, this implementation-dependent checks must not be put to a header file; please, move them to .cpp's.
**File:** modules/core/include/opencv2/core/openvx/ovx_defs.hpp
**Change Type:** modified
**Context:** PR #8455: OpenVX HAL calls disabled for images less than certain threshold - ### This pullrequest changes Disable calls to OpenVX for small image proc...

**Code Changes:**
```diff
@@ -24,6 +24,8 @@ namespace cv{
 namespace ovx{
 // Get common thread local OpenVX context
 CV_EXPORTS_W ivx::Context& getOpenVXContext();
+
+template <int kernel_id> inline bool skipSmallImages(int w, int h)     { return w*h < 3840 * 2160; }
 }}
 
 #define CV_OVX_RUN(condition, func, ...)          \
```

Review comment:
I do not quite understand why the corresponding functions cannot be moved to the respective .cpp files?
**File:** modules/core/include/opencv2/core/openvx/ovx_defs.hpp
**Change Type:** modified
**Context:** PR #8455: OpenVX HAL calls disabled for images less than certain threshold - ### This pullrequest changes Disable calls to OpenVX for small image proc...

**Code Changes:**
```diff
@@ -24,6 +24,8 @@ namespace cv{
 namespace ovx{
 // Get common thread local OpenVX context
 CV_EXPORTS_W ivx::Context& getOpenVXContext();
+
+template <int kernel_id> inline bool skipSmallImages(int w, int h)     { return w*h < 3840 * 2160; }
 }}
 
 #define CV_OVX_RUN(condition, func, ...)          \
```

Review comment:
It relates to the particular implementation, right? So, these conditions will likely evolve to something like: <pre> #if INTEL_OPENVX return w*h < constant_A; #elif AMD_OPENVX return w*h < constant_B; #else ... #endif </pre> such code should not pollute header files, it must be put to .cpp
**File:** modules/core/include/opencv2/core/openvx/ovx_defs.hpp
**Change Type:** modified
**Context:** PR #8455: OpenVX HAL calls disabled for images less than certain threshold - ### This pullrequest changes Disable calls to OpenVX for small image proc...

**Code Changes:**
```diff
@@ -24,6 +24,8 @@ namespace cv{
 namespace ovx{
 // Get common thread local OpenVX context
 CV_EXPORTS_W ivx::Context& getOpenVXContext();
+
+template <int kernel_id> inline bool skipSmallImages(int w, int h)     { return w*h < 3840 * 2160; }
 }}
 
 #define CV_OVX_RUN(condition, func, ...)          \
```

Review comment:
I've moved specializations to respective .cpp files
**File:** modules/core/include/opencv2/core/base.hpp
**Change Type:** modified
**Context:** PR #8359: Add more information to the error code.

**Code Changes:**
```diff
@@ -73,30 +73,30 @@ enum Code {
     StsNoMem=                   -4,  //!< insufficient memory
     StsBadArg=                  -5,  //!< function arg/param is bad
     StsBadFunc=                 -6,  //!< unsupported function
-    StsNoConv=                  -7,  //!< iter. didn't converge
+    StsNoConv=                  -7,  //!< iteration didn't converge
     StsAutoTrace=               -8,  //!< tracing
     HeaderIsNull=               -9,  //!< image header is NULL
     BadImageSize=              -10,  //!< image size is invalid
     BadOffset=                 -11,  //!< offset is invalid
```

Review comment:
Probably it is "not wrong", neither "invalid" or "bad" - current value is usually "not supported"/"unsupported" by current implementation.
**File:** modules/core/include/opencv2/core/base.hpp
**Change Type:** modified
**Context:** PR #8359: Add more information to the error code.

**Code Changes:**
```diff
@@ -73,30 +73,30 @@ enum Code {
     StsNoMem=                   -4,  //!< insufficient memory
     StsBadArg=                  -5,  //!< function arg/param is bad
     StsBadFunc=                 -6,  //!< unsupported function
-    StsNoConv=                  -7,  //!< iter. didn't converge
+    StsNoConv=                  -7,  //!< iteration didn't converge
     StsAutoTrace=               -8,  //!< tracing
     HeaderIsNull=               -9,  //!< image header is NULL
     BadImageSize=              -10,  //!< image size is invalid
     BadOffset=                 -11,  //!< offset is invalid
```

Review comment:
I copied the information from https://github.com/opencv/opencv/blob/master/modules/core/src/system.cpp#L764 In this case, does the function `cvErrorStr` also need to be updated, returning "supported/unsupported" ?
**File:** modules/imgproc/test/test_color.cpp
**Change Type:** modified
**Context:** PR #8697: imgproc: fix BGRA2BGRA conversion

**Code Changes:**
```diff
@@ -2190,3 +2190,28 @@ TEST(ImgProc_Bayer2RGBA, accuracy)
         }
     }
 }
+
+TEST(ImgProc_BGR2RGBA, regression_8696)
+{
+    Mat src(Size(80, 10), CV_8UC4);
+    src.setTo(Scalar(255, 0, 200, 100));
+
```

Review comment:
1. Please use issue number in regression test: `regression_8696` 2. It is better to use bigger size to enable checks for vectorized code too: `Size(80,10)`
**File:** modules/core/include/opencv2/core/mat.inl.hpp
**Change Type:** modified
**Context:** PR #8432: fix issue 8411.
**Review Line:** 90

**Code Changes:**
```diff
 _InputArray::_InputArray(const std::vector<std::vector<_Tp> >& vec)
 { init(FIXED_TYPE + STD_VECTOR_VECTOR + DataType<_Tp>::type + ACCESS_READ, &vec); }
 
+inline
+_InputArray::_InputArray(const std::vector<std::vector<bool> >&)
+{ CV_Error(Error::StsUnsupportedFormat, "std::vector<std::vector<bool> > is not supported!\n"); }
+
 template<typename _Tp> inline
 _InputArray::_InputArray(const std::vector<Mat_<_Tp> >& vec)
 { init(FIXED_TYPE + STD_VECTOR_MAT + DataType<_Tp>::type + ACCESS_READ, &vec); }
@@ -157,6 +161,10 @@ template<typename _Tp> inline
```

Review comment:
[CV_StaticAssert](https://github.com/opencv/opencv/blob/3.2.0/modules/core/include/opencv2/core/matx.hpp#L503) would be better here because it is not a "runtime" problem.
**File:** modules/imgproc/src/imgwarp.cpp
**Change Type:** modified
**Context:** PR #8391: Optimize WarpAffine(linear) using AVX2 - Pretty straight forward. I just replaced the SSE instructions with the AVX2 instructions. I added t...

**Code Changes:**
```diff
@@ -5523,6 +5523,9 @@ class WarpAffineInvoker :
         const int AB_BITS = MAX(10, (int)INTER_BITS);
         const int AB_SCALE = 1 << AB_BITS;
         int round_delta = interpolation == INTER_NEAREST ? AB_SCALE/2 : AB_SCALE/INTER_TAB_SIZE/2, x, y, x1, y1;
+    #if CV_AVX2
+        bool useAVX2 = checkHardwareSupport(CV_CPU_AVX2);
+    #endif
     #if CV_SSE2
         bool useSSE2 = checkHardwareSupport(CV_CPU_SSE2);
     #endif
```

Review comment:
Probably we should not drop SSE2 optimization if we want to add AVX2 optimization. Also we should use vzeroupper if we [mix AVX/SSE](http://stackoverflow.com/questions/41303780/why-is-this-sse-code-6-times-slower-without-vzeroupper-on-skylake) instructions. ```.diff } + _mm256_zeroupper(); } -#elif CV_SSE2 +#endif +#if CV_SSE2 ```
**File:** modules/video/test/ocl/test_optflowpyrlk.cpp
**Change Type:** modified
**Context:** PR #8609: Fix pyrlk.cl's wrong output of calcOpticalFlowPyrLK function's output vect… - resolves #8608 I set the max error of the output err between c...

**Code Changes:**
```diff
@@ -77,6 +77,7 @@ OCL_TEST_P(PyrLKOpticalFlow, Mat)
 {
     static const int npoints = 1000;
     static const float eps = 0.03f;
+    static const float erreps = 0.1f;
 
     cv::Mat frame0 = readImage("optflow/RubberWhale1.png", cv::IMREAD_GRAYSCALE);
     ASSERT_FALSE(frame0.empty());
@@ -104,6 +105,8 @@ OCL_TEST_P(PyrLKOpticalFlow, Mat)
     ASSERT_EQ(cpuStatusCPU.size(), status.size());
```

Review comment:
This test is intended to test optical flow implementation (any "optimized" version with passed parameters). So this `winSize` limitation looks illogical here. Especially, these `winSize` values are not covered by test parameters [below](https://github.com/opencv/opencv/pull/8609/files#diff-12bd0224b222e84bc79818257f400787R149) BTW, Please ignore "OCL_" prefix here - it is for legacy reasons here (to compare with OpenCV 2.4 tests). It doesn't force OpenCL code.
**File:** modules/video/test/ocl/test_optflowpyrlk.cpp
**Change Type:** modified
**Context:** PR #8609: Fix pyrlk.cl's wrong output of calcOpticalFlowPyrLK function's output vect… - resolves #8608 I set the max error of the output err between c...

**Code Changes:**
```diff
@@ -77,6 +77,7 @@ OCL_TEST_P(PyrLKOpticalFlow, Mat)
 {
     static const int npoints = 1000;
     static const float eps = 0.03f;
+    static const float erreps = 0.1f;
 
     cv::Mat frame0 = readImage("optflow/RubberWhale1.png", cv::IMREAD_GRAYSCALE);
     ASSERT_FALSE(frame0.empty());
@@ -104,6 +105,8 @@ OCL_TEST_P(PyrLKOpticalFlow, Mat)
     ASSERT_EQ(cpuStatusCPU.size(), status.size());
```

Review comment:
Hi alalek, I totally get your point. This test not only works for OpenCL, but also works for the CUDA and any other optimized version code. Therefore, this modification may badly influence the relevant code using this test. In modules/video/src/opencl/pyrlk.cl file, however, the kernel can only support the winSize within `16*16` to `24*24`, although its input accepts the winSize outside this range. In this kernel, the input winSize bigger than `24*24` will be referred as `24*24`, the input winSize smaller than 16*16 will be referred as `16*16`. In the test case 2 and 3, with winSize `25*25`, although the kernel can output the correct result of nextPts, the output of err is wrong even with the patch I pulled. This is the reason why I modify this test adding the winSize limitation in it. So, are there any ways to resolve this problem? How about that I add a new test specifically for OpenCL optical flow? Or would you mind that give me any other ideas? Best,