nareshmlx/opencv-pr huggingface dataset:
**File:** modules/objdetect/src/aruco/aruco_detector.cpp
**Change Type:** modified
**Context:** PR #26934: Extend ArUcoDetector to run multiple dictionaries in an efficient manner.

**Code Changes:**
```diff
@@ -10,6 +10,7 @@
 #include "apriltag/apriltag_quad_thresh.hpp"
 #include "aruco_utils.hpp"
 #include <cmath>
+#include <map>
 
 namespace cv {
 namespace aruco {
@@ -640,9 +641,14 @@ static inline void findCornerInPyrImage(const float scale_init, const int closes
     }
```

Review comment:
If I understand correctly, this function filters candidates using marker size as a hint to estimate distances or something. Could dictionaries with different marker sizes affect detections of each other?
**File:** modules/objdetect/src/aruco/aruco_detector.cpp
**Change Type:** modified
**Context:** PR #26934: Extend ArUcoDetector to run multiple dictionaries in an efficient manner.

**Code Changes:**
```diff
@@ -10,6 +10,7 @@
 #include "apriltag/apriltag_quad_thresh.hpp"
 #include "aruco_utils.hpp"
 #include <cmath>
+#include <map>
 
 namespace cv {
 namespace aruco {
@@ -640,9 +641,14 @@ static inline void findCornerInPyrImage(const float scale_init, const int closes
     }
```

Review comment:
Can dictionary have marker size other than 4, 5, 6, 7? I don't see any checks in `Dictionary` constructor or other places. If it can, then we have possible out-of-bounds access.
**File:** modules/objdetect/src/aruco/aruco_detector.cpp
**Change Type:** modified
**Context:** PR #26934: Extend ArUcoDetector to run multiple dictionaries in an efficient manner.
**Review Line:** 785

**Code Changes:**
```diff
+                if (_dictIndices.needed()) {
+                    dictIndices.insert(dictIndices.end(), currentCandidates.size(), dictIndex);
+                }
+
+                /// STEP 3: Corner refinement :: use corner subpix
+                if (detectorParams.cornerRefinementMethod == (int)CORNER_REFINE_SUBPIX) {
+                    performCornerSubpixRefinement(grey, grey_pyramid, closest_pyr_image_idx, currentCandidates, currentDictionary);
+                }
+                candidates.insert(candidates.end(), currentCandidates.begin(), currentCandidates.end());
+                dictIndex++;
+            }
```

Review comment:
Is it possible to extract this large block to separate function to reduce code duplication?
**File:** modules/objdetect/src/aruco/aruco_detector.cpp
**Change Type:** modified
**Context:** PR #26934: Extend ArUcoDetector to run multiple dictionaries in an efficient manner.

**Code Changes:**
```diff
@@ -10,6 +10,7 @@
 #include "apriltag/apriltag_quad_thresh.hpp"
 #include "aruco_utils.hpp"
 #include <cmath>
+#include <map>
 
 namespace cv {
 namespace aruco {
@@ -640,9 +641,14 @@ static inline void findCornerInPyrImage(const float scale_init, const int closes
     }
```

Review comment:
Yeah, I was thinking about the predefined dictionaries only, but custom dictionaries could potentially break this. I made it more flexible that now any size of marker is supported.
**File:** modules/objdetect/src/aruco/aruco_detector.cpp
**Change Type:** modified
**Context:** PR #26934: Extend ArUcoDetector to run multiple dictionaries in an efficient manner.

**Code Changes:**
```diff
@@ -10,6 +10,7 @@
 #include "apriltag/apriltag_quad_thresh.hpp"
 #include "aruco_utils.hpp"
 #include <cmath>
+#include <map>
 
 namespace cv {
 namespace aruco {
@@ -640,9 +641,14 @@ static inline void findCornerInPyrImage(const float scale_init, const int closes
     }
```

Review comment:
That was also my worry and when reading into the code of the function it may affect candidates in some corner cases. This is why I'm making copies of the vectors before filtering, so the order of identifying with multiple dictionaries doesn't matter. The copies are an overhead though that I'd like to avoid.
**File:** modules/objdetect/include/opencv2/objdetect/aruco_detector.hpp
**Change Type:** modified
**Context:** PR #26934: Extend ArUcoDetector to run multiple dictionaries in an efficient manner.
**Review Line:** 365

**Code Changes:**
```diff
+     * @param rejectedImgPoints contains the imgPoints of those squares whose inner code has not a
+     * correct codification. Useful for debugging purposes.
+     * @param dictIndices vector of dictionary indices for each detected marker. Use getDictionaries() to get the
+     * list of corresponding dictionaries.
+     *
+     * Performs marker detection in the input image. Only markers included in the specific dictionaries
+     * are searched. For each detected marker, it returns the 2D position of its corner in the image
+     * and its corresponding identifier.
+     * Note that this function does not perform pose estimation.
+     * @note The function does not correct lens distortion or takes it into account. It's recommended to undistort
+     * input image with corresponding camera model, if camera parameters are known
```

Review comment:
Good idea. Added a test that shows off how you can detect three markers for 2 similar dictionaries.
**File:** modules/objdetect/src/aruco/aruco_detector.cpp
**Change Type:** modified
**Context:** PR #26934: Extend ArUcoDetector to run multiple dictionaries in an efficient manner.

**Code Changes:**
```diff
@@ -10,6 +10,7 @@
 #include "apriltag/apriltag_quad_thresh.hpp"
 #include "aruco_utils.hpp"
 #include <cmath>
+#include <map>
 
 namespace cv {
 namespace aruco {
@@ -640,9 +641,14 @@ static inline void findCornerInPyrImage(const float scale_init, const int closes
     }
```

Review comment:
made it a map now as marker size needs to map to candidate tree. I made this connection now more deliberately and direct so I also don't need to calculate indices for other containers which may cause bounds issues as you correctly pointed out.
**File:** modules/imgproc/test/test_thresh.cpp
**Change Type:** modified
**Context:** PR #26842: added optional mask to cv::threshold

**Code Changes:**
```diff
@@ -520,6 +520,98 @@ TEST(Imgproc_Threshold, threshold_dryrun)
     }
 }
 
+typedef tuple < bool, int, int, int, int > Imgproc_Threshold_Masked_Params_t;
+
+typedef testing::TestWithParam< Imgproc_Threshold_Masked_Params_t > Imgproc_Threshold_Masked_Fixed;
+
+TEST_P(Imgproc_Threshold_Masked_Fixed, threshold_mask_fixed)
+{
```

Review comment:
I propose to use parameterized google test here. It generates all "loops" by itself and print options combination in case of failure
**File:** modules/imgproc/test/test_thresh.cpp
**Change Type:** modified
**Context:** PR #26842: added optional mask to cv::threshold

**Code Changes:**
```diff
@@ -520,6 +520,98 @@ TEST(Imgproc_Threshold, threshold_dryrun)
     }
 }
 
+typedef tuple < bool, int, int, int, int > Imgproc_Threshold_Masked_Params_t;
+
+typedef testing::TestWithParam< Imgproc_Threshold_Masked_Params_t > Imgproc_Threshold_Masked_Fixed;
+
+TEST_P(Imgproc_Threshold_Masked_Fixed, threshold_mask_fixed)
+{
```

Review comment:
If-else branches use different pattern and a bit different logic. I propose to split them on 2 test cases with different names. It also allows to get rid of complex logic with `isValidConfig` flag.
**File:** modules/imgproc/src/opencl/threshold_mask.cl
**Change Type:** added
**Context:** PR #26842: added optional mask to cv::threshold

**Code Changes:**
```diff
@@ -0,0 +1,60 @@
+// This file is part of OpenCV project.
+// 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.
+// @Authors
+//    Zhang Ying, zhangying913@gmail.com
+//    Pierre Chatelier, pierre@chachatelier.fr
+
+#ifdef DOUBLE_SUPPORT
+#ifdef cl_amd_fp64
```

Review comment:
I propose to use modern copyright header and mention the original OpenCL code author too.
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/magnitude.hpp
**Change Type:** added
**Context:** PR #27002: [HAL RVV] impl magnitude | add perf test

**Code Changes:**
```diff
@@ -0,0 +1,42 @@
+// This file is part of OpenCV project.
+// 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.
+
+// Copyright (C) 2025, Institute of Software, Chinese Academy of Sciences.
+
+#ifndef OPENCV_HAL_RVV_MAGNITUDE_HPP_INCLUDED
+#define OPENCV_HAL_RVV_MAGNITUDE_HPP_INCLUDED
+
```

Review comment:
I guess you can try the same as in https://github.com/opencv/opencv/pull/27015.
**File:** modules/core/src/mathfuncs_core.simd.hpp
**Change Type:** modified
**Context:** PR #27010: [HAL RVV] impl exp and log | add log perf test

**Code Changes:**
```diff
@@ -771,7 +771,7 @@ void log32f( const float *_x, float *y, int n )
     int i = 0;
     const int* x = (const int*)_x;
 
-#if CV_SIMD
+#if (CV_SIMD || CV_SIMD_SCALABLE)
     const int VECSZ = VTraits<v_float32>::vlanes();
     const v_float32 vln2 = vx_setall_f32((float)ln_2);
     const v_float32 v1 = vx_setall_f32(1.f);
@@ -846,7 +846,7 @@ void log64f( const double *x, double *y, int n )
```

Review comment:
It should be `CV_SIMD_SCALABLE_64F`. Double may be not supported by the platform.
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/exp.hpp
**Change Type:** added
**Context:** PR #27010: [HAL RVV] impl exp and log | add log perf test
**Review Line:** 1

**Code Changes:**
```diff
@@ -0,0 +1,202 @@
+// This file is part of OpenCV project.
+// 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.
+#pragma once
+
+#include <riscv_vector.h>
```

Review comment:
Basic math function like exp and log may be used in other HAL implementation as well. Consider to put them in `common.hpp` or `common_utils.hpp` when we have such files.
**File:** modules/core/test/test_arithm.cpp
**Change Type:** modified
**Context:** PR #27010: [HAL RVV] impl exp and log | add log perf test
**Review Line:** 1102

**Code Changes:**
```diff
@@ -1099,7 +1099,7 @@ struct ExpOp : public BaseElemWiseOp
     }
     void getValueRange(int depth, double& minval, double& maxval)
     {
-        maxval = depth == CV_32F ? 50 : 100;
+        maxval = depth == CV_32F ? 80 : 700;
         minval = -maxval;
     }
     void op(const vector<Mat>& src, Mat& dst, const Mat&)
```

Review comment:
Why changing the value here?
**File:** modules/core/test/test_arithm.cpp
**Change Type:** modified
**Context:** PR #27010: [HAL RVV] impl exp and log | add log perf test
**Review Line:** 1102

**Code Changes:**
```diff
@@ -1099,7 +1099,7 @@ struct ExpOp : public BaseElemWiseOp
     }
     void getValueRange(int depth, double& minval, double& maxval)
     {
-        maxval = depth == CV_32F ? 50 : 100;
+        maxval = depth == CV_32F ? 80 : 700;
         minval = -maxval;
     }
     void op(const vector<Mat>& src, Mat& dst, const Mat&)
```

Review comment:
> And I found a logical error in my implementation of `exp`, which caused the CI to fail. This error only occurs when the input is large enough, and that's why it passes all tests related to `exp` in the core module (Core_HAL/mathfuncs._:Core_Exp/ElemWiseTest_). This is discussed above. And the new value is approaching the limit of float/double.
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/exp.hpp
**Change Type:** added
**Context:** PR #27010: [HAL RVV] impl exp and log | add log perf test
**Review Line:** 1

**Code Changes:**
```diff
@@ -0,0 +1,202 @@
+// This file is part of OpenCV project.
+// 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.
+#pragma once
+
+#include <riscv_vector.h>
```

Review comment:
Same discussion [here](https://github.com/opencv/opencv/pull/27000#discussion_r1986729939)
**File:** doc/tutorials/imgproc/table_of_content_imgproc.markdown
**Change Type:** modified
**Context:** PR #26441: Update tutorials

**Code Changes:**
```diff
@@ -1,8 +1,15 @@
 Image Processing (imgproc module) {#tutorial_table_of_content_imgproc}
 =================================
 
-Basic
------
+@tableofcontents
+
+The imgproc module in OpenCV is a collection of per-pixel image operations (color conversions, filters) drawing (contours, objects, text), and
+geometry transformations (warping, resize) useful for computer vision.
```

Review comment:
The imgproc module in OpenCV is a collection of per-pixel image operations (color conversions, filters) drawing (contours, objects, text), and geometry transformations (warping, resize) useful for computer vision. Here's an overview of the content in the imgproc module, categorized for easier navigation.
**File:** modules/core/perf/perf_lut.cpp
**Change Type:** modified
**Context:** PR #26941: Impl hal_rvv LUT | Add more LUT test

**Code Changes:**
```diff
@@ -24,4 +24,23 @@ PERF_TEST_P( SizePrm, LUT,
     SANITY_CHECK(dst, 0.1);
 }
 
+PERF_TEST_P( SizePrm, LUT_multi,
+             testing::Values(szQVGA, szVGA, sz1080p)
+           )
+{
+    Size sz = GetParam();
+
```

Review comment:
My thoughts on dropping this test: 1. This patch does not bring speedup in case of multiple channels lut. 2. It does not check sanity. 3. You have added a regression test to test the accuracy of multi-channel lut.
**File:** cmake/OpenCVDetectCUDA.cmake
**Change Type:** modified
**Context:** PR #27112: cuda: Force C++17 Standard for CUDA targets when CUDA Toolkit >=12.8

**Code Changes:**
```diff
@@ -151,12 +151,14 @@ macro(ocv_cuda_compile VAR)
   ocv_check_windows_crt_linkage()
   ocv_nvcc_flags()
 
-  if(UNIX OR APPLE)
-    if(NOT " ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} ${CMAKE_CXX_FLAGS_DEBUG} ${CUDA_NVCC_FLAGS}" MATCHES "-std=")
+  if(NOT " ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} ${CMAKE_CXX_FLAGS_DEBUG} ${CUDA_NVCC_FLAGS}" MATCHES "-std=")
+    if(UNIX OR APPLE)
       if(CUDA_VERSION VERSION_LESS "11.0")
         list(APPEND CUDA_NVCC_FLAGS "--std=c++11")
```

Review comment:
Why `--std=c++11` and `--std=c++14` are set for UNIX or APPLE, but -`-std=c++17` - for all platforms. Most probably it's a mistake.
**File:** cmake/OpenCVDetectCUDA.cmake
**Change Type:** modified
**Context:** PR #27112: cuda: Force C++17 Standard for CUDA targets when CUDA Toolkit >=12.8

**Code Changes:**
```diff
@@ -151,12 +151,14 @@ macro(ocv_cuda_compile VAR)
   ocv_check_windows_crt_linkage()
   ocv_nvcc_flags()
 
-  if(UNIX OR APPLE)
-    if(NOT " ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} ${CMAKE_CXX_FLAGS_DEBUG} ${CUDA_NVCC_FLAGS}" MATCHES "-std=")
+  if(NOT " ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} ${CMAKE_CXX_FLAGS_DEBUG} ${CUDA_NVCC_FLAGS}" MATCHES "-std=")
+    if(UNIX OR APPLE)
       if(CUDA_VERSION VERSION_LESS "11.0")
         list(APPEND CUDA_NVCC_FLAGS "--std=c++11")
```

Review comment:
Please presume the empty line.
**File:** cmake/OpenCVDetectCUDA.cmake
**Change Type:** modified
**Context:** PR #27112: cuda: Force C++17 Standard for CUDA targets when CUDA Toolkit >=12.8

**Code Changes:**
```diff
@@ -151,12 +151,14 @@ macro(ocv_cuda_compile VAR)
   ocv_check_windows_crt_linkage()
   ocv_nvcc_flags()
 
-  if(UNIX OR APPLE)
-    if(NOT " ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} ${CMAKE_CXX_FLAGS_DEBUG} ${CUDA_NVCC_FLAGS}" MATCHES "-std=")
+  if(NOT " ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} ${CMAKE_CXX_FLAGS_DEBUG} ${CUDA_NVCC_FLAGS}" MATCHES "-std=")
+    if(UNIX OR APPLE)
       if(CUDA_VERSION VERSION_LESS "11.0")
         list(APPEND CUDA_NVCC_FLAGS "--std=c++11")
```

Review comment:
Perhaps Windows requires other flags (of there is similar problem - need Windows configuration to check that first). BTW, We use `CMAKE_CXX_STANDARD` variable for general C++ code: https://github.com/opencv/opencv/blob/4.11.0/cmake/OpenCVDetectCXXCompiler.cmake#L211 May be we should have proper `try_compile()` check for nvcc? Perhaps `CMAKE_CXX_STANDARD` should be tuned (or checked/[forced](https://github.com/opencv/opencv/blob/4.11.0/cmake/OpenCVFindProtobuf.cmake#L83-L85)) instead of manual flags
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/sqrt.hpp
**Change Type:** added
**Context:** PR #27015: [HAL RVV] impl sqrt and invSqrt

**Code Changes:**
```diff
@@ -0,0 +1,122 @@
+// This file is part of OpenCV project.
+// 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.
+#ifndef OPENCV_HAL_RVV_SQRT_HPP_INCLUDED
+#define OPENCV_HAL_RVV_SQRT_HPP_INCLUDED
+
+#include <riscv_vector.h>
+#include <cmath>
+#include "hal_rvv_1p0/types.hpp"
```

Review comment:
nit: Use something like below https://github.com/opencv/opencv/blob/12d182bf9e2fa518aafad75dd5b77835c75674b4/3rdparty/hal_rvv/hal_rvv_1p0/merge.hpp#L4-L5
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/sqrt.hpp
**Change Type:** added
**Context:** PR #27015: [HAL RVV] impl sqrt and invSqrt
**Review Line:** 49

**Code Changes:**
```diff
+        t = __riscv_vfmul(t, x2, vl);
+        t = __riscv_vfrsub(t, 1.5, vl);
+        y = __riscv_vfmul(t, y, vl);
+    }
+    // just to prevent the compiler from calculating mask before the invSqrt, which will run out
+    // of registers and cause memory access.
+    asm volatile("" ::: "memory");
+    auto mask = __riscv_vmfne(x, 0.0, vl);
+    mask = __riscv_vmfne_mu(mask, mask, x, INFINITY, vl);
+    return __riscv_vfmul_mu(mask, x, x, y, vl);
+}
```

Review comment:
How does this happen?
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/sqrt.hpp
**Change Type:** added
**Context:** PR #27015: [HAL RVV] impl sqrt and invSqrt

**Code Changes:**
```diff
@@ -0,0 +1,122 @@
+// This file is part of OpenCV project.
+// 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.
+#ifndef OPENCV_HAL_RVV_SQRT_HPP_INCLUDED
+#define OPENCV_HAL_RVV_SQRT_HPP_INCLUDED
+
+#include <riscv_vector.h>
+#include <cmath>
+#include "hal_rvv_1p0/types.hpp"
```

Review comment:
Considering that RISC-V is relatively new, it's unlikely any compiler that doesn't support `#pragma once`. So I think using `#pragma once` should be acceptable.
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/sqrt.hpp
**Change Type:** added
**Context:** PR #27015: [HAL RVV] impl sqrt and invSqrt

**Code Changes:**
```diff
@@ -0,0 +1,122 @@
+// This file is part of OpenCV project.
+// 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.
+#ifndef OPENCV_HAL_RVV_SQRT_HPP_INCLUDED
+#define OPENCV_HAL_RVV_SQRT_HPP_INCLUDED
+
+#include <riscv_vector.h>
+#include <cmath>
+#include "hal_rvv_1p0/types.hpp"
```

Review comment:
Just follow the convention to avoid confusion.
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/sqrt.hpp
**Change Type:** added
**Context:** PR #27015: [HAL RVV] impl sqrt and invSqrt
**Review Line:** 49

**Code Changes:**
```diff
+        t = __riscv_vfmul(t, x2, vl);
+        t = __riscv_vfrsub(t, 1.5, vl);
+        y = __riscv_vfmul(t, y, vl);
+    }
+    // just to prevent the compiler from calculating mask before the invSqrt, which will run out
+    // of registers and cause memory access.
+    asm volatile("" ::: "memory");
+    auto mask = __riscv_vmfne(x, 0.0, vl);
+    mask = __riscv_vmfne_mu(mask, mask, x, INFINITY, vl);
+    return __riscv_vfmul_mu(mask, x, x, y, vl);
+}
```

Review comment:
In the `for` loop (calculating `invSqrt`), at most four variables, `x`, `x2`, `y`, `t`, need to be stored simultaneously, so it occupies at least 4 LMUL registers. However, after exiting the `for` loop, only `x` and `y` need to be retained. Therefore, when using mask registers, the number of registers used should not exceed the previous 4 LMUL. However, without a memory barrier, both GCC and Clang from the `riscv-collab/riscv-gnu-toolchain` release `Nightly: December 16, 2024` tend to do the mask calculation first, causing the `for` loop to require 4 LMUL registers plus one additional mask register at the same time.
**File:** modules/core/src/persistence_base64_encoding.cpp
**Change Type:** modified
**Context:** PR #26937: Support bool type for FileStorage Base64

**Code Changes:**
```diff
@@ -202,6 +202,7 @@ int base64::icvCalcStructSize(const char *dt, int initial_size) {
         switch ( *type )
         {
             case 'u': { elem_max_size = std::max( elem_max_size, sizeof(uchar ) ); break; }
+            case 'b': { elem_max_size = std::max( elem_max_size, sizeof(uchar ) ); break; }
             case 'c': { elem_max_size = std::max( elem_max_size, sizeof(schar ) ); break; }
             case 'w': { elem_max_size = std::max( elem_max_size, sizeof(ushort) ); break; }
             case 's': { elem_max_size = std::max( elem_max_size, sizeof(short ) ); break; }
@@ -333,6 +334,10 @@ size_t base64::RawDataToBinaryConvertor::make_to_binary_funcs(const std::string
                     size = sizeof(uchar);
```

Review comment:
sizeof(bool) may be different on different platforms. `to_binary()` converts it to uchar.
**File:** modules/core/src/persistence_base64_encoding.cpp
**Change Type:** modified
**Context:** PR #26937: Support bool type for FileStorage Base64

**Code Changes:**
```diff
@@ -202,6 +202,7 @@ int base64::icvCalcStructSize(const char *dt, int initial_size) {
         switch ( *type )
         {
             case 'u': { elem_max_size = std::max( elem_max_size, sizeof(uchar ) ); break; }
+            case 'b': { elem_max_size = std::max( elem_max_size, sizeof(uchar ) ); break; }
             case 'c': { elem_max_size = std::max( elem_max_size, sizeof(schar ) ); break; }
             case 'w': { elem_max_size = std::max( elem_max_size, sizeof(ushort) ); break; }
             case 's': { elem_max_size = std::max( elem_max_size, sizeof(short ) ); break; }
@@ -333,6 +334,10 @@ size_t base64::RawDataToBinaryConvertor::make_to_binary_funcs(const std::string
                     size = sizeof(uchar);
```

Review comment:
sizeof(bool) may be different on different platforms. to_binary() converts it to uchar.
**File:** modules/core/src/hal_replacement.hpp
**Change Type:** modified
**Context:** PR #26865: Add RISC-V HAL implementation for cv::dft and cv::dct

**Code Changes:**
```diff
@@ -756,10 +756,28 @@ inline int hal_ni_dft1D(cvhalDFT *context, const uchar *src, uchar *dst) { retur
  */
 inline int hal_ni_dftFree1D(cvhalDFT *context) { return CV_HAL_ERROR_NOT_IMPLEMENTED; }
 
+/**
+@param src source data
+@param dst destination data
+@param depth depth of source
+@param nf OcvDftOptions data
+@param factors OcvDftOptions data
```

Review comment:
Why do you need Ocv suffix here and on the caller side? It breaks existing code style.
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/dxt.hpp
**Change Type:** added
**Context:** PR #26865: Add RISC-V HAL implementation for cv::dft and cv::dct

**Code Changes:**
```diff
@@ -0,0 +1,569 @@
+// This file is part of OpenCV project.
+// 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.
+#ifndef OPENCV_HAL_RVV_DXT_HPP_INCLUDED
+#define OPENCV_HAL_RVV_DXT_HPP_INCLUDED
+
+#include <riscv_vector.h>
+
+namespace cv { namespace cv_hal_rvv { namespace dxt {
```

Review comment:
Could you add reference to paper or other implementation details.
**File:** 3rdparty/hal_rvv/hal_rvv_1p0/dxt.hpp
**Change Type:** added
**Context:** PR #26865: Add RISC-V HAL implementation for cv::dft and cv::dct

**Code Changes:**
```diff
@@ -0,0 +1,569 @@
+// This file is part of OpenCV project.
+// 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.
+#ifndef OPENCV_HAL_RVV_DXT_HPP_INCLUDED
+#define OPENCV_HAL_RVV_DXT_HPP_INCLUDED
+
+#include <riscv_vector.h>
+
+namespace cv { namespace cv_hal_rvv { namespace dxt {
```

Review comment:
It was copied from core/src/dxt.cpp, I have added some comments on it.