nareshmlx/opencv-pr huggingface dataset:
**File:** cmake/OpenCVFindLAPACK.cmake
**Change Type:** modified
**Context:** PR #25625: core: deployment compatibility for old mac after Accelerate New LAPACK fix
**Review Line:** 15

**Code Changes:**
```diff
+  set(_apple_device_min_target_os_version "1.0")
+endif()
+
+if(DEFINED _apple_device_min_target_os_version AND
+   ("${CMAKE_OSX_DEPLOYMENT_TARGET}" VERSION_GREATER "${_apple_device_min_target_os_version}" OR
+    "${CMAKE_OSX_DEPLOYMENT_TARGET}" VERSION_EQUAL "${_apple_device_min_target_os_version}"))
+  set(_apple_device_has_required_min_os_version ON)
+else()
+  set(_apple_device_has_required_min_os_version OFF)
+endif()
+
```

Review comment:
[`VERSION_GREATER`](https://cmake.org/cmake/help/latest/command/if.html#version-greater-equal) requires CMake >= 3.7 but OpenCV 4.x has [default minimum requirement of CMake >= 3.5.1](https://github.com/opencv/opencv/blob/79af357cf44214abde34c2f1ac79916849d179ce/cmake/OpenCVMinDepVersions.cmake#L2).
**File:** modules/core/src/minmax.cpp
**Change Type:** modified
**Context:** PR #25679: Fixed offset computation for ND case in MinMaxIdx HAL.
**Review Line:** 1529

**Code Changes:**
```diff
             if (minIdx)
-                ofs2idx(src, minIdx[0], minIdx);
+                ofs2idx(src, minIdx[1], minIdx);
             if (maxIdx)
-                ofs2idx(src, maxIdx[0], maxIdx);
+                ofs2idx(src, maxIdx[1], maxIdx);
             return;
         }
         else if (res != CV_HAL_ERROR_NOT_IMPLEMENTED)
```

Review comment:
`minIdx[1]` and `maxIdx[1]` returned by HAL function should be shifted by 1 It's not described anywhere, let's fix this by #25669
**File:** modules/dnn/src/cuda4dnn/csl/tensor_ops.hpp
**Change Type:** modified
**Context:** PR #25412: Refactor DNN module to build with cudnn 9

**Code Changes:**
```diff
@@ -528,6 +528,46 @@ namespace cv { namespace dnn { namespace cuda4dnn { namespace csl {
         LSTM() = default;
         LSTM(const LSTM&) = delete;
         LSTM(LSTM&&) = default;
+
+#if CUDNN_MAJOR >= 9
+        LSTM(cudnn::Handle handle, const params_type &params)
+            : cudnnHandle(std::move(handle)), seqLength(params.seqLength)
+        {
+            std::vector<int> seqLenArr(params.miniBatch, seqLength);
```

Review comment:
Let's remove std::cout or conver them to CV_LOG_DEBUG.
**File:** modules/dnn/src/cuda4dnn/primitives/recurrent_cells.hpp
**Change Type:** modified
**Context:** PR #25412: Refactor DNN module to build with cudnn 9

**Code Changes:**
```diff
@@ -55,9 +55,6 @@ class LSTMOp final : public CUDABackendNode
 
         c0Tensor = csl::makeTensorHeader<T>(c0);
         csl::copyMatToTensor<T>(c0, c0Tensor, stream);
-
-        csl::WorkspaceBuilder builder;
-        builder.require<T>(lstm.get_workspace_memory_in_bytes());
     }
 
     void forward(const std::vector<cv::Ptr<BackendWrapper>>& inputs,
```

Review comment:
Already done by `builder.require<T>(reserveSpaceSize)`
**File:** modules/dnn/src/cuda4dnn/csl/tensor_ops.hpp
**Change Type:** modified
**Context:** PR #25412: Refactor DNN module to build with cudnn 9

**Code Changes:**
```diff
@@ -528,6 +528,46 @@ namespace cv { namespace dnn { namespace cuda4dnn { namespace csl {
         LSTM() = default;
         LSTM(const LSTM&) = delete;
         LSTM(LSTM&&) = default;
+
+#if CUDNN_MAJOR >= 9
+        LSTM(cudnn::Handle handle, const params_type &params)
+            : cudnnHandle(std::move(handle)), seqLength(params.seqLength)
+        {
+            std::vector<int> seqLenArr(params.miniBatch, seqLength);
```

Review comment:
They can be removed - if I recall correctly I added them for debugging.
**File:** 3rdparty/ndsrvp/src/threshold.cpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,177 @@
+// 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.	
+
+#include "ndsrvp_hal.hpp"
+#include "opencv2/imgproc/hal/interface.h"
+
+namespace cv {
+
```

Review comment:
Stray `#`
**File:** 3rdparty/ndsrvp/include/imgproc.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,71 @@
+// 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_NDSRVP_IMGPROC_HPP
+#define OPENCV_NDSRVP_IMGPROC_HPP
+
+namespace cv {
+
```

Review comment:
`namespace` missing? Function + enum. Maybe it would be better to move all functions to `cv::ndsrvp::` namespace instead of prefixing?
**File:** 3rdparty/ndsrvp/include/imgproc.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,71 @@
+// 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_NDSRVP_IMGPROC_HPP
+#define OPENCV_NDSRVP_IMGPROC_HPP
+
+namespace cv {
+
```

Review comment:
Why is this function here? Can it be removed?
**File:** 3rdparty/ndsrvp/include/core.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,532 @@
+// 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_NDSRVP_CORE_HPP
+#define OPENCV_NDSRVP_CORE_HPP
+
+namespace cv {
+
```

Review comment:
`scalar/vector` might be more conventional than `nonparallel/parallel`.
**File:** 3rdparty/ndsrvp/include/core.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,532 @@
+// 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_NDSRVP_CORE_HPP
+#define OPENCV_NDSRVP_CORE_HPP
+
+namespace cv {
+
```

Review comment:
Wouldn't `__nds__scmple16(b, a)` produce better code? Or it can be left to compiler to optimize?
**File:** 3rdparty/ndsrvp/ndsrvp_hal.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,15 @@
+// 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_NDSRVP_HAL_HPP
+#define OPENCV_NDSRVP_HAL_HPP
+
+#include "opencv2/core/mat.hpp"
+#include <nds_intrinsic.h>
```

Review comment:
Perhaps it would be better to move this include to cpp files in order to limit public HAL interface to `hal/interface.h`. Is it possible?
**File:** 3rdparty/ndsrvp/include/core.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,532 @@
+// 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_NDSRVP_CORE_HPP
+#define OPENCV_NDSRVP_CORE_HPP
+
+namespace cv {
+
```

Review comment:
Please add license header to all source files (https://github.com/opencv/opencv/wiki/Coding_Style_Guide#file-structure). You can also add respective copyrights afterwards.
**File:** 3rdparty/ndsrvp/src/warpPerspective.cpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,159 @@
+// 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.	
+
+#include "ndsrvp_hal.hpp"
+#include "opencv2/core.hpp"
+#include "opencv2/imgproc/hal/interface.h"
+
+namespace cv {
```

Review comment:
Please add single empty line at the end of all files.
**File:** 3rdparty/ndsrvp/include/imgproc.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,71 @@
+// 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_NDSRVP_IMGPROC_HPP
+#define OPENCV_NDSRVP_IMGPROC_HPP
+
+namespace cv {
+
```

Review comment:
I took a closer look here and I think selected approach is not quite in the spirit of the curernt HAL design. We suppose that HAL library would know as little as possible about OpenCV and definitely wouldn't call public OpenCV functions. Looks like warpAffine/warpPerspective are a good place to add a new smaller HAL function which would do the same processing as `opt_SSE4_1::WarpAffineInvoker_Blockline_SSE41`, `opt_AVX2::warpAffineBlockline` and other similar functions, e.g. here: https://github.com/opencv/opencv/blob/78ed6de518b60a2e40c74b86ebd76203998d5b50/modules/imgproc/src/imgwarp.cpp#L2304-L2334
**File:** 3rdparty/ndsrvp/include/imgproc.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,71 @@
+// 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_NDSRVP_IMGPROC_HPP
+#define OPENCV_NDSRVP_IMGPROC_HPP
+
+namespace cv {
+
```

Review comment:
> Looks like warpAffine/warpPerspective are a good place to add a new smaller HAL function which would do the same processing as `opt_SSE4_1::WarpAffineInvoker_Blockline_SSE41`, `opt_AVX2::warpAffineBlockline` and other similar functions, e.g. here: > > https://github.com/opencv/opencv/blob/78ed6de518b60a2e40c74b86ebd76203998d5b50/modules/imgproc/src/imgwarp.cpp#L2304-L2334 I agree. If smaller HAL functions were added, the code could be better modified in the spirit of HAL design.
**File:** 3rdparty/ndsrvp/ndsrvp_hal.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,15 @@
+// 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_NDSRVP_HAL_HPP
+#define OPENCV_NDSRVP_HAL_HPP
+
+#include "opencv2/core/mat.hpp"
+#include <nds_intrinsic.h>
```

Review comment:
This include could be limited to at least `opencv2/core/mat.hpp`.
**File:** 3rdparty/ndsrvp/include/imgproc.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,71 @@
+// 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_NDSRVP_IMGPROC_HPP
+#define OPENCV_NDSRVP_IMGPROC_HPP
+
+namespace cv {
+
```

Review comment:
Maybe the smaller HAL function could be added later in Part 2.
**File:** platforms/linux/riscv64-andes-gcc.toolchain.cmake
**Change Type:** modified
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions
**Review Line:** 14

**Code Changes:**
```diff
 set(CMAKE_C_COMPILER  ${RISCV_GCC_INSTALL_ROOT}/bin/riscv64-linux-gcc)
 set(CMAKE_CXX_COMPILER ${RISCV_GCC_INSTALL_ROOT}/bin/riscv64-linux-g++)
 
+# fix toolchain macro
+
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D__ANDES=1")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__ANDES=1")
+
+# enable rvp
+
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=rv64gc -mext-dsp")
```

Review comment:
It seems that toolchain already defines this macro - do we need it? ``` $ /chains/nds64le-linux-glibc-v5d/bin/riscv64-linux-g++ -dM -E - < /dev/null | grep ANDES #define __ANDES 1 ```
**File:** 3rdparty/ndsrvp/include/core.hpp
**Change Type:** added
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions

**Code Changes:**
```diff
@@ -0,0 +1,532 @@
+// 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_NDSRVP_CORE_HPP
+#define OPENCV_NDSRVP_CORE_HPP
+
+namespace cv {
+
```

Review comment:
Looks like it doesn't work - tests are failing now :slightly_frowning_face: . Commenting cmp functions fixes them.
**File:** platforms/linux/riscv64-andes-gcc.toolchain.cmake
**Change Type:** modified
**Context:** PR #25167: 3rdparty: NDSRVP - A New 3rdparty Library with Optimizations Based on RISC-V P Extension v0.5.2 - Part 1: Basic Functions
**Review Line:** 14

**Code Changes:**
```diff
 set(CMAKE_C_COMPILER  ${RISCV_GCC_INSTALL_ROOT}/bin/riscv64-linux-gcc)
 set(CMAKE_CXX_COMPILER ${RISCV_GCC_INSTALL_ROOT}/bin/riscv64-linux-g++)
 
+# fix toolchain macro
+
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D__ANDES=1")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__ANDES=1")
+
+# enable rvp
+
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=rv64gc -mext-dsp")
```

Review comment:
For versions not greater than gcc 10.3.0, this macro is not defined. Currently the development board for performance tests uses gcc 10.3.0. gcc version 12.2.0 (GCC) ```shell $ ~/opt/andes-backup-530/bin/riscv64-linux-g++ -mext-dsp -dM -E - < /dev/null | grep ANDES #define __ANDES 1 ``` gcc version 10.4.0 (GCC) ```shell $ ~/opt/andes-backup/bin/riscv64-linux-g++ -mext-dsp -dM -E - < /dev/null | grep ANDES #define __ANDES 1 ``` gcc version 10.3.0 (GCC) ```shell $ ~/opt/andes/bin/riscv64-linux-g++ -mext-dsp -dM -E - < /dev/null | grep ANDES ``` gcc version 10.2.1 20200726 (GCC) ```shell $ ~/opt/andes-backup-500/bin/riscv64-linux-g++ -mext-dsp -dM -E - < /dev/null | grep ANDES ```
**File:** modules/core/perf/opencl/perf_arithm.cpp
**Change Type:** modified
**Context:** PR #25633: Tests for cv::rotate() added

**Code Changes:**
```diff
@@ -374,6 +374,36 @@ OCL_PERF_TEST_P(FlipFixture, Flip,
     SANITY_CHECK(dst);
 }
 
+///////////// Rotate ////////////////////////
+
+enum
+{
+    ROTATE_90_CLOCKWISE = 0, ROTATE_180, ROTATE_90_COUNTERCLOCKWISE
+};
```

Review comment:
`cv::rotate`? https://docs.opencv.org/4.x/d2/de8/group__core__array.html#ga4ad01c0978b0ce64baa246811deeac24
**File:** modules/imgproc/include/opencv2/imgproc.hpp
**Change Type:** modified
**Context:** PR #25616: YUV codes for cvtColor: descriptions added

**Code Changes:**
```diff
@@ -641,112 +641,109 @@ enum ColorConversionCodes {
     COLOR_YUV2BGR      = 84,
     COLOR_YUV2RGB      = 85,
 
-    //! YUV 4:2:0 family to RGB
-    COLOR_YUV2RGB_NV12  = 90,
-    COLOR_YUV2BGR_NV12  = 91,
-    COLOR_YUV2RGB_NV21  = 92,
-    COLOR_YUV2BGR_NV21  = 93,
-    COLOR_YUV420sp2RGB  = COLOR_YUV2RGB_NV21,
```

Review comment:
Perhaps it would be better to add this information to the [Color conversions](https://docs.opencv.org/4.x/de/d25/imgproc_color_conversions.html) page and refer them here.
**File:** modules/imgproc/include/opencv2/imgproc.hpp
**Change Type:** modified
**Context:** PR #25616: YUV codes for cvtColor: descriptions added

**Code Changes:**
```diff
@@ -641,112 +641,109 @@ enum ColorConversionCodes {
     COLOR_YUV2BGR      = 84,
     COLOR_YUV2RGB      = 85,
 
-    //! YUV 4:2:0 family to RGB
-    COLOR_YUV2RGB_NV12  = 90,
-    COLOR_YUV2BGR_NV12  = 91,
-    COLOR_YUV2RGB_NV21  = 92,
-    COLOR_YUV2BGR_NV21  = 93,
-    COLOR_YUV420sp2RGB  = COLOR_YUV2RGB_NV21,
```

Review comment:
"Extract Y channel"
**File:** modules/imgproc/include/opencv2/imgproc.hpp
**Change Type:** modified
**Context:** PR #25616: YUV codes for cvtColor: descriptions added
**Review Line:** 723

**Code Changes:**
```diff
+    COLOR_YUV2RGBA_YUNV = COLOR_YUV2RGBA_YUY2, //!< synonym to YUY2
+    COLOR_YUV2BGRA_YUNV = COLOR_YUV2BGRA_YUY2, //!< synonym to YUY2
+
+    COLOR_YUV2GRAY_UYVY = 123, //!< extract Y channel from YUV 4:2:2 image
+    COLOR_YUV2GRAY_YUY2 = 124, //!< extract Y channel from YUV 4:2:2 image
+    //CV_YUV2GRAY_VYUY  = CV_YUV2GRAY_UYVY, //!< synonym to COLOR_YUV2GRAY_UYVY
+    COLOR_YUV2GRAY_Y422 = COLOR_YUV2GRAY_UYVY, //!< synonym to COLOR_YUV2GRAY_UYVY
+    COLOR_YUV2GRAY_UYNV = COLOR_YUV2GRAY_UYVY, //!< synonym to COLOR_YUV2GRAY_UYVY
+    COLOR_YUV2GRAY_YVYU = COLOR_YUV2GRAY_YUY2, //!< synonym to COLOR_YUV2GRAY_YUY2
+    COLOR_YUV2GRAY_YUYV = COLOR_YUV2GRAY_YUY2, //!< synonym to COLOR_YUV2GRAY_YUY2
+    COLOR_YUV2GRAY_YUNV = COLOR_YUV2GRAY_YUY2, //!< synonym to COLOR_YUV2GRAY_YUY2
```

Review comment:
Why is it commented?
**File:** modules/imgproc/include/opencv2/imgproc.hpp
**Change Type:** modified
**Context:** PR #25616: YUV codes for cvtColor: descriptions added
**Review Line:** 723

**Code Changes:**
```diff
+    COLOR_YUV2RGBA_YUNV = COLOR_YUV2RGBA_YUY2, //!< synonym to YUY2
+    COLOR_YUV2BGRA_YUNV = COLOR_YUV2BGRA_YUY2, //!< synonym to YUY2
+
+    COLOR_YUV2GRAY_UYVY = 123, //!< extract Y channel from YUV 4:2:2 image
+    COLOR_YUV2GRAY_YUY2 = 124, //!< extract Y channel from YUV 4:2:2 image
+    //CV_YUV2GRAY_VYUY  = CV_YUV2GRAY_UYVY, //!< synonym to COLOR_YUV2GRAY_UYVY
+    COLOR_YUV2GRAY_Y422 = COLOR_YUV2GRAY_UYVY, //!< synonym to COLOR_YUV2GRAY_UYVY
+    COLOR_YUV2GRAY_UYNV = COLOR_YUV2GRAY_UYVY, //!< synonym to COLOR_YUV2GRAY_UYVY
+    COLOR_YUV2GRAY_YVYU = COLOR_YUV2GRAY_YUY2, //!< synonym to COLOR_YUV2GRAY_YUY2
+    COLOR_YUV2GRAY_YUYV = COLOR_YUV2GRAY_YUY2, //!< synonym to COLOR_YUV2GRAY_YUY2
+    COLOR_YUV2GRAY_YUNV = COLOR_YUV2GRAY_YUY2, //!< synonym to COLOR_YUV2GRAY_YUY2
```

Review comment:
No idea, tracks lead to the original code from 2012. Maybe it didn't work properly then. If we want to enable it back, we need a separate PR.
**File:** modules/calib3d/src/calibration_handeye.cpp
**Change Type:** modified
**Context:** PR #24897: Fix handeye
**Review Line:** 317

**Code Changes:**
```diff
+            //   equation 12, and the remaining 112 all had Pcij or Pgij with norms greater than 1.7. Although errors
+            //   from small rotations were not observed, it is known that these motions are less informative (see
+            //   section II.B.3, and figure 6).
+            double Pgij_norm = cv::norm(Pgij);
+            double Pcij_norm = cv::norm(Pcij);
+            if (Pgij_norm < 0.3 || Pcij_norm < 0.3 || Pgij_norm > 1.7 || Pcij_norm > 1.7) {
+                continue;
+            }
+
+            vec_Hgij.push_back(Hgij);
+            vec_Hcij.push_back(Hcij);
```

Review comment:
You should add the corresponding angle values in rad or deg in comment, since these values come from the quaternion representation I think? --- Maybe also add a `CV_LOG_DEBUG` below to inform the user this data has been skipped?
**File:** modules/calib3d/src/calibration_handeye.cpp
**Change Type:** modified
**Context:** PR #24897: Fix handeye
**Review Line:** 472

**Code Changes:**
```diff
@@ -449,6 +468,9 @@ static void calibrateHandEyeHoraud(const std::vector<Mat>& Hg, const std::vector
             Mat Rcij = Hcij(Rect(0, 0, 3, 3));
 
             Mat qgij = rot2quat(Rgij);
+            if (qgij.at<double>(0, 0) < 0) {
+                qgij *= -1;
+            }
             double r0 = qgij.at<double>(0,0);
             double rx = qgij.at<double>(1,0);
             double ry = qgij.at<double>(2,0);
@@ -461,6 +483,9 @@ static void calibrateHandEyeHoraud(const std::vector<Mat>& Hg, const std::vector
```

Review comment:
Indeed, this can be checked with this online tool: https://www.andre-gaschler.com/rotationconverter/
**File:** modules/calib3d/test/test_calibration_hand_eye.cpp
**Change Type:** modified
**Context:** PR #24897: Fix handeye

**Code Changes:**
```diff
@@ -756,4 +756,110 @@ TEST(Calib3d_CalibrateRobotWorldHandEye, regression)
     }
 }
 
+TEST(Calib3d_CalibrateHandEye, regression_24871)
+{
+    std::vector<Mat> R_target2cam, t_target2cam;
+    std::vector<Mat> R_gripper2base, t_gripper2base;
+    Mat T_true_cam2gripper;
+
```

Review comment:
Could these threshold values be too strict on some exotic architectures, environments?
**File:** modules/calib3d/src/calibration_handeye.cpp
**Change Type:** modified
**Context:** PR #24897: Fix handeye
**Review Line:** 317

**Code Changes:**
```diff
+            //   equation 12, and the remaining 112 all had Pcij or Pgij with norms greater than 1.7. Although errors
+            //   from small rotations were not observed, it is known that these motions are less informative (see
+            //   section II.B.3, and figure 6).
+            double Pgij_norm = cv::norm(Pgij);
+            double Pcij_norm = cv::norm(Pcij);
+            if (Pgij_norm < 0.3 || Pcij_norm < 0.3 || Pgij_norm > 1.7 || Pcij_norm > 1.7) {
+                continue;
+            }
+
+            vec_Hgij.push_back(Hgij);
+            vec_Hcij.push_back(Hcij);
```

Review comment:
Sure, I'll add a comment. I also feel I should explain how I came to these values. The 1.7 value, which translates to rotations of about 120 degrees or greater, was based on calculating equation 12 in the paper with the known ground truth `P'_{cg}`. I ran a test with 25 poses, which gives 300 motions (25*24/2). Equation 12 was satisfied in 188 cases. In the other 112 cases, the norm of the `P_{gij}` or `P_{cij}` was 1.7 or greater. The converse was not always true--in the 188 good cases, there were norms greater than 1.7. The 0.3 value translates to rotations of 17 degrees or less. Honestly, I didn't encounter any problem with these rotations, but I know from the error analysis (and experience) that small rotations are not very informative, so I decided to discard them also. As for the log statement, I'm willing to add it, but I don't think it's necessary. This implementation tries to use all pairs of poses in the calculation, which is actually including redundant information--once you've used the transform from pose 1 to pose 2, and from pose 2 to pose 3, the transform from pose 1 to pose 3 doesn't add any new information. The log message would be pretty noisy (of course, at DEBUG that's probably OK). I do alert the user if the calibration fails because there's not enough useful data.
**File:** modules/calib3d/test/test_calibration_hand_eye.cpp
**Change Type:** modified
**Context:** PR #24897: Fix handeye

**Code Changes:**
```diff
@@ -756,4 +756,110 @@ TEST(Calib3d_CalibrateRobotWorldHandEye, regression)
     }
 }
 
+TEST(Calib3d_CalibrateHandEye, regression_24871)
+{
+    std::vector<Mat> R_target2cam, t_target2cam;
+    std::vector<Mat> R_gripper2base, t_gripper2base;
+    Mat T_true_cam2gripper;
+
```

Review comment:
I don't know, but I can loosen them.