nareshmlx/opencv-pr huggingface dataset:
**File:** modules/imgproc/perf/opencl/perf_imgwarp.cpp
**Change Type:** modified
**Context:** PR #25984: imgproc: add optimized warpAffine kernels for 8U/16U/32F + C1/C3/C4 inputs
**Review Line:** 78

**Code Changes:**
```diff
     const int type = get<1>(params), interpolation = get<2>(params);
-    const double eps = CV_MAT_DEPTH(type) <= CV_32S ? 1 : interpolation == INTER_CUBIC ? 2e-3 : 1e-4;
+
+    // BUG: OpenCL and CPU version diverges a bit
+    // Ticket: https://github.com/opencv/opencv/issues/26235
+    const double eps = CV_MAT_DEPTH(type) <= CV_32S ? 2 : interpolation == INTER_CUBIC ? 2e-3 : 3e-2;
 
     checkDeviceMaxMemoryAllocSize(srcSize, type);
 
```

Review comment:
Looks like the change does not make sense as soon as you introduced `AlgorithmHint`. I reverted the change and no not see regressions with Intel OpenCL (iGPU) and NVIDIA GF 1080.
**File:** modules/imgproc/test/ocl/test_warp.cpp
**Change Type:** modified
**Context:** PR #25984: imgproc: add optimized warpAffine kernels for 8U/16U/32F + C1/C3/C4 inputs
**Review Line:** 175

**Code Changes:**
```diff
@@ -172,7 +172,7 @@ OCL_TEST_P(WarpAffine, Mat)
 {
     for (int j = 0; j < test_loop_times; j++)
     {
-        double eps = depth < CV_32F ? 0.04 : 0.06;
+        double eps = depth < CV_32F ? ( depth < CV_16U ? 0.09 : 0.04 ) : 0.06;
         random_roi();
 
         Mat M = getRotationMatrix2D(Point2f(src_roi.cols / 2.0f, src_roi.rows / 2.0f),
@@ -189,7 +189,7 @@ OCL_TEST_P(WarpAffine, inplace_25853) // when src and dst are the same variable,
 {
```

Review comment:
I propose to convert it to conditions with explicit types. We have fp16, int64, bool that comes after fp64. Also it's hard to understand the condition.
**File:** modules/imgproc/test/ocl/test_warp.cpp
**Change Type:** modified
**Context:** PR #25984: imgproc: add optimized warpAffine kernels for 8U/16U/32F + C1/C3/C4 inputs
**Review Line:** 192

**Code Changes:**
```diff
@@ -189,7 +189,7 @@ OCL_TEST_P(WarpAffine, inplace_25853) // when src and dst are the same variable,
 {
     for (int j = 0; j < test_loop_times; j++)
     {
-        double eps = depth < CV_32F ? 0.04 : 0.06;
+        double eps = depth < CV_32F ? ( depth < CV_16U ? 0.09 : 0.04 ) : 0.06;
         random_roi();
 
         Mat M = getRotationMatrix2D(Point2f(src_roi.cols / 2.0f, src_roi.rows / 2.0f),
```

Review comment:
The same proposal here.
**File:** modules/imgproc/test/test_imgwarp_strict.cpp
**Change Type:** modified
**Context:** PR #25984: imgproc: add optimized warpAffine kernels for 8U/16U/32F + C1/C3/C4 inputs

**Code Changes:**
```diff
@@ -150,7 +150,7 @@ void CV_ImageWarpBaseTest::generate_test_data()
     while (depth == CV_8S || depth == CV_32S)
         depth = rng.uniform(0, CV_64F);
 
-    int cn = rng.uniform(1, 4);
+    int cn = rng.uniform(1, 5);
 
     src.create(ssize, CV_MAKE_TYPE(depth, cn));
 
@@ -1045,6 +1045,13 @@ class CV_WarpAffine_Test :
```

Review comment:
The change is not relevant after AlgorithmHint introduction. It passes without the change on Intel at least.
**File:** modules/imgproc/test/test_imgwarp_strict.cpp
**Change Type:** modified
**Context:** PR #25984: imgproc: add optimized warpAffine kernels for 8U/16U/32F + C1/C3/C4 inputs
**Review Line:** 153

**Code Changes:**
```diff
@@ -150,7 +150,7 @@ void CV_ImageWarpBaseTest::generate_test_data()
     while (depth == CV_8S || depth == CV_32S)
         depth = rng.uniform(0, CV_64F);
 
-    int cn = rng.uniform(1, 4);
+    int cn = rng.uniform(1, 5);
 
     src.create(ssize, CV_MAKE_TYPE(depth, cn));
 
@@ -1045,6 +1045,13 @@ class CV_WarpAffine_Test :
     Mat M;
```

Review comment:
The change triggers massve OpenCL code compilation errors for the new case. Some check should be added on OpenCL side. See attached log. [Uploading test.log…]()
**File:** modules/imgproc/test/test_imgwarp_strict.cpp
**Change Type:** modified
**Context:** PR #25984: imgproc: add optimized warpAffine kernels for 8U/16U/32F + C1/C3/C4 inputs
**Review Line:** 153

**Code Changes:**
```diff
@@ -150,7 +150,7 @@ void CV_ImageWarpBaseTest::generate_test_data()
     while (depth == CV_8S || depth == CV_32S)
         depth = rng.uniform(0, CV_64F);
 
-    int cn = rng.uniform(1, 4);
+    int cn = rng.uniform(1, 5);
 
     src.create(ssize, CV_MAKE_TYPE(depth, cn));
 
@@ -1045,6 +1045,13 @@ class CV_WarpAffine_Test :
     Mat M;
```

Review comment:
I added check to OpenCL code.
**File:** modules/imgproc/test/test_drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries

**Code Changes:**
```diff
@@ -680,6 +680,75 @@ TEST(Drawing, fillpoly_circle)
     EXPECT_LT(diff_fp3, 1.);
 }
 
+TEST(Drawing, fillpoly_contours)
+{
+    const int imgSize = 50;
+    const int type = CV_8UC1;
+    const int shift = 0;
+    const Scalar cl = Scalar::all(255);
```

Review comment:
Why is this test disabled?
**File:** modules/imgproc/test/test_drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries

**Code Changes:**
```diff
@@ -680,6 +680,75 @@ TEST(Drawing, fillpoly_circle)
     EXPECT_LT(diff_fp3, 1.);
 }
 
+TEST(Drawing, fillpoly_contours)
+{
+    const int imgSize = 50;
+    const int type = CV_8UC1;
+    const int shift = 0;
+    const Scalar cl = Scalar::all(255);
```

Review comment:
It takes a lot of time compared to the other tests. The last time I added such a heavy test I was advised to not run it by default, see https://github.com/opencv/opencv/pull/23076#discussion_r1060193514
**File:** modules/imgproc/test/test_drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries

**Code Changes:**
```diff
@@ -680,6 +680,75 @@ TEST(Drawing, fillpoly_circle)
     EXPECT_LT(diff_fp3, 1.);
 }
 
+TEST(Drawing, fillpoly_contours)
+{
+    const int imgSize = 50;
+    const int type = CV_8UC1;
+    const int shift = 0;
+    const Scalar cl = Scalar::all(255);
```

Review comment:
Instead of two comparison we can make one simpler check: ```.cpp im1 = 0; img2 = 0; cv::fillPoly(img1, ...); cv::polylines(img2, ...); // same color EXPECT_MAT_N_DIFF(img1, img2, 0); ```
**File:** modules/imgproc/test/test_drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries

**Code Changes:**
```diff
@@ -680,6 +680,75 @@ TEST(Drawing, fillpoly_circle)
     EXPECT_LT(diff_fp3, 1.);
 }
 
+TEST(Drawing, fillpoly_contours)
+{
+    const int imgSize = 50;
+    const int type = CV_8UC1;
+    const int shift = 0;
+    const Scalar cl = Scalar::all(255);
```

Review comment:
I suggest reducing this test by: 1. use only corners and the middle as the first point: ```.cpp for (int x1 = 0; x1 < imgSize; x1 += imgSize / 2) // imgSize = 49 for (int y1 = 0; y1 < imgSize; y1 += imgSize / 2) ``` 2. Draw on two separate images and compare them afterwards (see my other comment) I've prepared an example: https://github.com/opencv/opencv/commit/1b1277b787438b3827208b7323652a892e486072 Does it cover all the required cases, what do you think?
**File:** modules/imgproc/test/test_drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries

**Code Changes:**
```diff
@@ -680,6 +680,75 @@ TEST(Drawing, fillpoly_circle)
     EXPECT_LT(diff_fp3, 1.);
 }
 
+TEST(Drawing, fillpoly_contours)
+{
+    const int imgSize = 50;
+    const int type = CV_8UC1;
+    const int shift = 0;
+    const Scalar cl = Scalar::all(255);
```

Review comment:
Make one `vector<vector<Point>>` with all required data and pass it directly to the function: ```.cpp std::vector<std::vector<cv::Point>> polygonPoints {{ {x1, y1}, {x2, y2} }}; ```
**File:** modules/imgproc/test/test_drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries

**Code Changes:**
```diff
@@ -680,6 +680,75 @@ TEST(Drawing, fillpoly_circle)
     EXPECT_LT(diff_fp3, 1.);
 }
 
+TEST(Drawing, fillpoly_contours)
+{
+    const int imgSize = 50;
+    const int type = CV_8UC1;
+    const int shift = 0;
+    const Scalar cl = Scalar::all(255);
```

Review comment:
What about other line types? `LINE_AA`? Will it work the same as before?
**File:** modules/imgproc/src/drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries
**Review Line:** 1302

**Code Changes:**
```diff
                 if (t0.y != t1.y)
                 {
                     pt0c.y = t0.y; pt1c.y = t1.y;
-                    pt0c.x = (int64)(t0.x) << XY_SHIFT;
-                    pt1c.x = (int64)(t1.x) << XY_SHIFT;
                 }
             }
-            else
-            {
-                pt0c.x += XY_ONE >> 1;
-                pt1c.x += XY_ONE >> 1;
```

Review comment:
Does any test check clipping scenario? Non-zero shift?
**File:** modules/imgproc/src/drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries
**Review Line:** 1302

**Code Changes:**
```diff
                 if (t0.y != t1.y)
                 {
                     pt0c.y = t0.y; pt1c.y = t1.y;
-                    pt0c.x = (int64)(t0.x) << XY_SHIFT;
-                    pt1c.x = (int64)(t1.x) << XY_SHIFT;
                 }
             }
-            else
-            {
-                pt0c.x += XY_ONE >> 1;
-                pt1c.x += XY_ONE >> 1;
```

Review comment:
I did not add tests for all scenarios since `fillPoly` and `polylines` handle incoming points slightly different and also have differences in drawing the contours for certain parameters. To make the contours match in all scenarios probably both functions would need further adjustments. This PR should fix the matching contours for `line_type < LINE_AA` and zero shift since it used to match before the changes of #23076
**File:** modules/imgproc/test/test_drawing.cpp
**Change Type:** modified
**Context:** PR #26187: Fix fillPoly drawing over boundaries

**Code Changes:**
```diff
@@ -680,6 +680,75 @@ TEST(Drawing, fillpoly_circle)
     EXPECT_LT(diff_fp3, 1.);
 }
 
+TEST(Drawing, fillpoly_contours)
+{
+    const int imgSize = 50;
+    const int type = CV_8UC1;
+    const int shift = 0;
+    const Scalar cl = Scalar::all(255);
```

Review comment:
`LINE_AA` is not affected by the changes of this PR so it works the same, but it does not pass the test due to the reasons mentioned in the other comment. `LINE_4` passes this test with any shift. `LINE_8` passes this test only with a zero shift. It fails for non-zero shifts, most likely because the methods to draw the contour in `fillPoly` and `polylines` differ for `LINE_8` with non-zero shifts.
**File:** modules/core/include/opencv2/core/hal/intrin_math.hpp
**Change Type:** modified
**Context:** PR #25892: Add support for v_sin and v_cos (Sine and Cosine)
**Review Line:** 410

**Code Changes:**
```diff
 }
 //! @}
 
+//! @name Sine and Cosine
+//! @{
+template<typename _TpVec16F, typename _TpVec16S>
+inline void v_sincos_default_16f(const _TpVec16F &x, _TpVec16F &ysin, _TpVec16F &ycos) {
+    const _TpVec16F v_cephes_FOPI = v_setall_<_TpVec16F>(hfloat(1.27323954473516f)); // 4 / M_PI
+    const _TpVec16F v_minus_DP1 = v_setall_<_TpVec16F>(hfloat(-0.78515625f));
+    const _TpVec16F v_minus_DP2 = v_setall_<_TpVec16F>(hfloat(-2.4187564849853515625E-4f));
+    const _TpVec16F v_minus_DP3 = v_setall_<_TpVec16F>(hfloat(-3.77489497744594108E-8f));
```

Review comment:
It'll be great to add reference to the algorithm source/description and m.b. how the coefficients are generated.
**File:** modules/core/include/opencv2/core/hal/intrin_math.hpp
**Change Type:** modified
**Context:** PR #25892: Add support for v_sin and v_cos (Sine and Cosine)
**Review Line:** 410

**Code Changes:**
```diff
 }
 //! @}
 
+//! @name Sine and Cosine
+//! @{
+template<typename _TpVec16F, typename _TpVec16S>
+inline void v_sincos_default_16f(const _TpVec16F &x, _TpVec16F &ysin, _TpVec16F &ycos) {
+    const _TpVec16F v_cephes_FOPI = v_setall_<_TpVec16F>(hfloat(1.27323954473516f)); // 4 / M_PI
+    const _TpVec16F v_minus_DP1 = v_setall_<_TpVec16F>(hfloat(-0.78515625f));
+    const _TpVec16F v_minus_DP2 = v_setall_<_TpVec16F>(hfloat(-2.4187564849853515625E-4f));
+    const _TpVec16F v_minus_DP3 = v_setall_<_TpVec16F>(hfloat(-3.77489497744594108E-8f));
```

Review comment:
I can't find the original algorithm, the approximate implementations are the same and they refer to (it's already existed in the `intrin_math.hpp` ``` /* Universal Intrinsics implementation of sin, cos, exp and log Inspired by Intel Approximate Math library, and based on the corresponding algorithms of the cephes math library */ /* Copyright (C) 2010,2011 RJVB - extensions */ /* Copyright (C) 2011 Julien Pommier ``` The explanation is my own interpretation. The basic idea involves leveraging periodicity and trigonometric identities to scale the input, followed by the use of a Taylor series for calculation. The coefficients are nearly identical to those in the Taylor series, with some adjustments.
**File:** modules/core/test/ocl/test_arithm.cpp
**Change Type:** modified
**Context:** PR #26256: extended Norm tests to prove that cv::norm() already supports all the…
**Review Line:** 2041

**Code Changes:**
```diff
@@ -2038,7 +2038,7 @@ OCL_INSTANTIATE_TEST_CASE_P(Arithm, Magnitude, Combine(::testing::Values(CV_32F,
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, Flip, Combine(OCL_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, MinMaxIdx, Combine(OCL_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, MinMaxIdx_Mask, Combine(OCL_ALL_DEPTHS, ::testing::Values(Channels(1)), Bool()));
-OCL_INSTANTIATE_TEST_CASE_P(Arithm, Norm, Combine(OCL_ALL_DEPTHS_16F, OCL_ALL_CHANNELS, Bool()));
+OCL_INSTANTIATE_TEST_CASE_P(Arithm, Norm, Combine(OCL_ABSOLUTELY_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, Sqrt, Combine(::testing::Values(CV_32F, CV_64F), OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, Normalize, Combine(OCL_ALL_DEPTHS, Values(Channels(1)), Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, InRange, Combine(OCL_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool(), Bool()));
```

Review comment:
`OCL_ABSOLUTELY_ALL_DEPTHS` => `OCL_ALL_NUMERICAL_DEPTHS`, because bool is not there.
**File:** modules/core/test/ocl/test_arithm.cpp
**Change Type:** modified
**Context:** PR #26256: extended Norm tests to prove that cv::norm() already supports all the…
**Review Line:** 2041

**Code Changes:**
```diff
@@ -2038,7 +2038,7 @@ OCL_INSTANTIATE_TEST_CASE_P(Arithm, Magnitude, Combine(::testing::Values(CV_32F,
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, Flip, Combine(OCL_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, MinMaxIdx, Combine(OCL_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, MinMaxIdx_Mask, Combine(OCL_ALL_DEPTHS, ::testing::Values(Channels(1)), Bool()));
-OCL_INSTANTIATE_TEST_CASE_P(Arithm, Norm, Combine(OCL_ALL_DEPTHS_16F, OCL_ALL_CHANNELS, Bool()));
+OCL_INSTANTIATE_TEST_CASE_P(Arithm, Norm, Combine(OCL_ABSOLUTELY_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, Sqrt, Combine(::testing::Values(CV_32F, CV_64F), OCL_ALL_CHANNELS, Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, Normalize, Combine(OCL_ALL_DEPTHS, Values(Channels(1)), Bool()));
 OCL_INSTANTIATE_TEST_CASE_P(Arithm, InRange, Combine(OCL_ALL_DEPTHS, OCL_ALL_CHANNELS, Bool(), Bool()));
```

Review comment:
added norm for Bool too
**File:** modules/core/include/opencv2/core/hal/intrin_cpp.hpp
**Change Type:** modified
**Context:** PR #25891: Resolve Compilation Error for v_func Function in SIMD Emulator

**Code Changes:**
```diff
@@ -263,7 +263,7 @@ Most of these operations return only one value.
 
 ### Other math
 
-- Some frequent operations: @ref v_sqrt, @ref v_invsqrt, @ref v_magnitude, @ref v_sqr_magnitude, @ref v_exp,
+- Some frequent operations: @ref v_sqrt, @ref v_invsqrt, @ref v_magnitude, @ref v_sqr_magnitude, @ref v_exp, @ref v_log,
                             @ref v_erf
 - Absolute values: @ref v_abs, @ref v_absdiff, @ref v_absdiffs
 
@@ -2801,7 +2801,8 @@ inline void v_transpose4x4( v_reg<_Tp, n>& a0, const v_reg<_Tp, n>& a1,
```

Review comment:
It is expected that tests like `hal_intrin*CPP_EMULATOR` call the code from `intrin_cpp.hpp`. But they don't. To debug modify `intrin_cpp.hpp`: ```.diff #define OPENCV_HAL_IMPL_MATH_FUNC(func, cfunc, _Tp2) \ template<typename _Tp, int n> inline v_reg<_Tp2, n> func(const v_reg<_Tp, n>& a) \ { \ + printf(#func " is called\n"); \ v_reg<_Tp2, n> c; \ for( int i = 0; i < n; i++ ) \ c.s[i] = cfunc(a.s[i]); \ ``` Run tests: `./bin/opencv_test_core --gtest_filter=*intrin*EMULATOR*` ``` [ RUN ] hal_intrin128.float32x4_CPP_EMULATOR SIMD128: void opencv_test::hal::intrin128::opt_EMULATOR_CPP::test_hal_intrin_float32() v_abs is called v_sqrt is called v_abs is called <<<<<<< missing v_exp call through generic C++ exp() >>>>>>>>> v_abs is called v_abs is called v_abs is called ... ``` (both build configurations: with/without -DOPENCV_EXTRA_FLAGS="-DCV_FORCE_SIMD128_CPP=1") --- BTW, without this PR the correct version is called (in "default" build): ``` [ RUN ] hal_intrin128.float32x4_CPP_EMULATOR SIMD128: void opencv_test::hal::intrin128::opt_EMULATOR_CPP::test_hal_intrin_float32() v_abs is called v_sqrt is called v_abs is called v_exp is called v_exp is called v_exp is called v_exp is called v_exp is called ... v_log is called ... ```
**File:** modules/core/include/opencv2/core/hal/intrin_math.hpp
**Change Type:** modified
**Context:** PR #25891: Resolve Compilation Error for v_func Function in SIMD Emulator

**Code Changes:**
```diff
@@ -2,10 +2,6 @@
 // It is subject to the license terms in the LICENSE file found in the top-level directory
 // of this distribution and at http://opencv.org/license.html
 
-// This header is not standalone. Don't include directly, use "intrin.hpp" instead.
-#ifdef OPENCV_HAL_INTRIN_HPP  // defined in intrin.hpp
-
-namespace CV__SIMD_NAMESPACE {
 
 /* Universal Intrinsics implementation of sin, cos, exp and log
```

Review comment:
I propose to use templates here. v_int##TpSuffix and v_float##TpSuffix will be template arguments.
**File:** modules/core/include/opencv2/core/hal/intrin_math.hpp
**Change Type:** modified
**Context:** PR #25891: Resolve Compilation Error for v_func Function in SIMD Emulator

**Code Changes:**
```diff
@@ -2,10 +2,6 @@
 // It is subject to the license terms in the LICENSE file found in the top-level directory
 // of this distribution and at http://opencv.org/license.html
 
-// This header is not standalone. Don't include directly, use "intrin.hpp" instead.
-#ifdef OPENCV_HAL_INTRIN_HPP  // defined in intrin.hpp
-
-namespace CV__SIMD_NAMESPACE {
 
 /* Universal Intrinsics implementation of sin, cos, exp and log
```

Review comment:
OK, but it will introduce many parameters and may use the macro to maintain the code.
**File:** modules/core/include/opencv2/core/hal/intrin_math.hpp
**Change Type:** modified
**Context:** PR #25891: Resolve Compilation Error for v_func Function in SIMD Emulator

**Code Changes:**
```diff
@@ -2,10 +2,6 @@
 // It is subject to the license terms in the LICENSE file found in the top-level directory
 // of this distribution and at http://opencv.org/license.html
 
-// This header is not standalone. Don't include directly, use "intrin.hpp" instead.
-#ifdef OPENCV_HAL_INTRIN_HPP  // defined in intrin.hpp
-
-namespace CV__SIMD_NAMESPACE {
 
 /* Universal Intrinsics implementation of sin, cos, exp and log
```

Review comment:
Wouldn't wide intrinsics like `vx_setall_f32` work here? Or maybe we can introduce traits type (or extend existing ones) which would map `_setall_` to corresponding types.
**File:** modules/core/include/opencv2/core/hal/intrin_lasx.hpp
**Change Type:** modified
**Context:** PR #25891: Resolve Compilation Error for v_func Function in SIMD Emulator
**Review Line:** 563

**Code Changes:**
```diff
     inline _Tpvec v256_setall_##suffix(_Tp v)                                     \
     { return _Tpvec(__lasx_xvreplgr2vr_##ssuffix((ctype_s)v)); }                  \
+    template <> inline _Tpvec v_setzero_()                                        \
+    { return v256_setzero_##suffix(); }                                           \
+    template <> inline _Tpvec v_setall_(_Tp v)                                    \
+    { return v256_setall_##suffix(v); }                                           \
     OPENCV_HAL_IMPL_LASX_CAST(_Tpvec, v_uint8x32,  suffix, OPENCV_HAL_NOP)        \
     OPENCV_HAL_IMPL_LASX_CAST(_Tpvec, v_int8x32,   suffix, OPENCV_HAL_NOP)        \
     OPENCV_HAL_IMPL_LASX_CAST(_Tpvec, v_uint16x16, suffix, OPENCV_HAL_NOP)        \
@@ -588,7 +592,11 @@ inline __m256d _lasx_256_castsi256_pd(const __m256i &v)
     inline _Tpvec v256_setzero_##suffix()                                 \
```

Review comment:
if you copy-paste code 3+ times, when we have anti-pattern and design should be changed.
**File:** modules/core/include/opencv2/core/hal/intrin_avx.hpp
**Change Type:** modified
**Context:** PR #25891: Resolve Compilation Error for v_func Function in SIMD Emulator

**Code Changes:**
```diff
@@ -447,6 +447,10 @@ OPENCV_HAL_IMPL_AVX_LOADSTORE_FLT(v_float64x4, double, pd, __m128d)
     { return _Tpvec(_mm256_setzero_si256()); }                                   \
     inline _Tpvec v256_setall_##suffix(_Tp v)                                    \
     { return _Tpvec(_mm256_set1_##ssuffix((ctype_s)v)); }                        \
+    template <> inline _Tpvec v_setzero_()                                       \
+    { return v256_setzero_##suffix(); }                                          \
+    template <> inline _Tpvec v_setall_(_Tp v)                                   \
+    { return v256_setall_##suffix(v); }                                          \
     OPENCV_HAL_IMPL_AVX_CAST(_Tpvec, v_uint8x32,  suffix, OPENCV_HAL_NOP)        \
     OPENCV_HAL_IMPL_AVX_CAST(_Tpvec, v_int8x32,   suffix, OPENCV_HAL_NOP)        \
```

Review comment:
> `_Tpvec /*unused*/` Template should be used instead. Static code analyzers dislike passing of uninitialized vars.
**File:** modules/core/include/opencv2/core/hal/intrin_avx.hpp
**Change Type:** modified
**Context:** PR #25891: Resolve Compilation Error for v_func Function in SIMD Emulator
**Review Line:** 451

**Code Changes:**
```diff
@@ -447,6 +447,10 @@ OPENCV_HAL_IMPL_AVX_LOADSTORE_FLT(v_float64x4, double, pd, __m128d)
     { return _Tpvec(_mm256_setzero_si256()); }                                   \
     inline _Tpvec v256_setall_##suffix(_Tp v)                                    \
     { return _Tpvec(_mm256_set1_##ssuffix((ctype_s)v)); }                        \
+    template <> inline _Tpvec v_setzero_()                                       \
+    { return v256_setzero_##suffix(); }                                          \
+    template <> inline _Tpvec v_setall_(_Tp v)                                   \
+    { return v256_setall_##suffix(v); }                                          \
     OPENCV_HAL_IMPL_AVX_CAST(_Tpvec, v_uint8x32,  suffix, OPENCV_HAL_NOP)        \
     OPENCV_HAL_IMPL_AVX_CAST(_Tpvec, v_int8x32,   suffix, OPENCV_HAL_NOP)        \
     OPENCV_HAL_IMPL_AVX_CAST(_Tpvec, v_uint16x16, suffix, OPENCV_HAL_NOP)        \
```

Review comment:
Mess of v256_ / v_ (which is used for 128-bit)