nareshmlx/opencv-pr huggingface dataset:
**File:** modules/core/src/system.cpp
**Change Type:** modified
**Context:** PR #17922: Build riscv with c++ intrinsics
**Review Line:** 603

**Code Changes:**
```diff
@@ -597,6 +599,10 @@ struct HWFeatures
         have[CV_CPU_VSX3] = (CV_VSX3);
     #endif
 
+    #if defined __riscv && defined __riscv_vector
+        have[CV_CPU_RVV] = true;
+    #endif
+
         bool skip_baseline_check = false;
 #ifndef NO_GETENV
         if (getenv("OPENCV_SKIP_CPU_BASELINE_CHECK"))
```

Review comment:
RISC-V vector extension spec have not mentioned about runtime check up to now. I will try to ask them about it.
**File:** platforms/linux/riscv64-clang.toolchain.cmake
**Change Type:** added
**Context:** PR #17922: Build riscv with c++ intrinsics

**Code Changes:**
```diff
@@ -0,0 +1,27 @@
+set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_PROCESSOR riscv64)
+
+set(RISCV_CLANG_BUILD_ROOT /opt/rvv-llvm CACHE PATH "Path to CLANG for RISC-V cross compiler build directory")
+set(RISCV_GCC_INSTALL_ROOT /opt/RISCV CACHE PATH "Path to GCC for RISC-V cross compiler installation directory")
+set(CMAKE_SYSROOT ${RISCV_GCC_INSTALL_ROOT}/sysroot CACHE PATH "RISC-V sysroot")
+
+set(CLANG_TARGET_TRIPLE riscv64-unknown-linux-gnu)
+
```

Review comment:
Are these paths hardcoded in the toolchain installation instruction? Usually `/home` directory contains users' home directories, according to these lines your system have two users named `git` and `RISCV`. In some cases software can be installed in `/opt` directory, it is universal location and will not confuse readers.
**File:** modules/core/include/opencv2/core/cv_cpu_dispatch.h
**Change Type:** modified
**Context:** PR #17922: Build riscv with c++ intrinsics

**Code Changes:**
```diff
@@ -168,6 +168,10 @@
 #  include <wasm_simd128.h>
 #endif
 
+#if defined CV_CPU_COMPILE_RVV
+#  define CV_RVV 1
+#endif
+
 #endif // CV_ENABLE_INTRINSICS && !CV_DISABLE_OPTIMIZATION && !__CUDACC__
 
```

Review comment:
Wouldn't it be included in `intrin_rvv.hpp`?
**File:** modules/core/include/opencv2/core/cv_cpu_dispatch.h
**Change Type:** modified
**Context:** PR #17922: Build riscv with c++ intrinsics

**Code Changes:**
```diff
@@ -168,6 +168,10 @@
 #  include <wasm_simd128.h>
 #endif
 
+#if defined CV_CPU_COMPILE_RVV
+#  define CV_RVV 1
+#endif
+
 #endif // CV_ENABLE_INTRINSICS && !CV_DISABLE_OPTIMIZATION && !__CUDACC__
 
```

Review comment:
I think it might need to be included here. All the other implementation of universal intrinsics included their headers here but not in `intrin_XXX.hpp`. I haven't tested to included it in `intrin_rvv.hpp` but I think it should be consistent with other versions, should it? Then I just remove it at present.
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #17922: Build riscv with c++ intrinsics

**Code Changes:**
```diff
@@ -260,6 +260,8 @@ namespace cv {
 #define CV_CPU_VSX              200
 #define CV_CPU_VSX3             201
 
+#define CV_CPU_RVV              210
+
 // CPU features groups
 #define CV_CPU_AVX512_SKX       256
 #define CV_CPU_AVX512_COMMON    257
@@ -312,6 +314,8 @@ enum CpuFeatures {
```

Review comment:
Please use 210 here and below. 256+ is used for "groups".
**File:** modules/gapi/test/common/gapi_video_tests_common.hpp
**Change Type:** modified
**Context:** PR #17896: GAPI: KW fix - video_tests

**Code Changes:**
```diff
@@ -43,7 +43,7 @@ inline void initTrackingPointsArray(std::vector<cv::Point2f>& points, int width,
 
     points.clear();
     GAPI_Assert((nPointsX >= 0) && (nPointsY) >= 0);
-    points.reserve(static_cast<size_t>(nPointsX * nPointsY));
+    points.reserve(nPointsX * nPointsY);
 
     for (int x = stepX / 2; x < width; x += stepX)
     {
@@ -80,9 +80,7 @@ struct OptFlowLKTestOutput
```

Review comment:
lets just drop the cast completely. I believe it will make the tool happy. As here https://github.com/opencv/opencv/blob/master/modules/gapi/test/internal/gapi_int_island_tests.cpp#L72 it works OK.
**File:** modules/dnn/src/dnn.cpp
**Change Type:** modified
**Context:** PR #17788: cuda4dnn: catch common build mistakes early and better diagnostics
**Review Line:** 2367

**Code Changes:**
```diff
+            context.cublas_handle = cuda4dnn::csl::cublas::Handle(context.stream);
+            context.cudnn_handle = cuda4dnn::csl::cudnn::Handle(context.stream);
+
+            auto d2h_stream = cuda4dnn::csl::Stream(true); // stream for background D2H data transfers
+            cudaInfo = std::unique_ptr<CudaInfo_t>(new CudaInfo_t(std::move(context), std::move(d2h_stream)));
+            cuda4dnn::checkVersions();
+        }
+
+        cudaInfo->workspace = cuda4dnn::csl::Workspace(); // release workspace memory if any
+
+        for (auto& layer : layers)
```

Review comment:
Massive facepalm. This is a very embarrassing mistake. If a version mismatch occurs, exceptions will be thrown even before it reaches this line. This makes this version check mechanism completely useless. It's not a bug that breaks things. It just makes this version check useless.
**File:** modules/dnn/src/dnn.cpp
**Change Type:** modified
**Context:** PR #17788: cuda4dnn: catch common build mistakes early and better diagnostics
**Review Line:** 2367

**Code Changes:**
```diff
+            context.cublas_handle = cuda4dnn::csl::cublas::Handle(context.stream);
+            context.cudnn_handle = cuda4dnn::csl::cudnn::Handle(context.stream);
+
+            auto d2h_stream = cuda4dnn::csl::Stream(true); // stream for background D2H data transfers
+            cudaInfo = std::unique_ptr<CudaInfo_t>(new CudaInfo_t(std::move(context), std::move(d2h_stream)));
+            cuda4dnn::checkVersions();
+        }
+
+        cudaInfo->workspace = cuda4dnn::csl::Workspace(); // release workspace memory if any
+
+        for (auto& layer : layers)
```

Review comment:
Could you move the check to proper place with another PR then?
**File:** modules/dnn/src/dnn.cpp
**Change Type:** modified
**Context:** PR #17788: cuda4dnn: catch common build mistakes early and better diagnostics
**Review Line:** 2367

**Code Changes:**
```diff
+            context.cublas_handle = cuda4dnn::csl::cublas::Handle(context.stream);
+            context.cudnn_handle = cuda4dnn::csl::cudnn::Handle(context.stream);
+
+            auto d2h_stream = cuda4dnn::csl::Stream(true); // stream for background D2H data transfers
+            cudaInfo = std::unique_ptr<CudaInfo_t>(new CudaInfo_t(std::move(context), std::move(d2h_stream)));
+            cuda4dnn::checkVersions();
+        }
+
+        cudaInfo->workspace = cuda4dnn::csl::Workspace(); // release workspace memory if any
+
+        for (auto& layer : layers)
```

Review comment:
Yes, I am planning to do that. This time I am trying to test by making lots of containers with broken builds. So this will take some time.
**File:** cmake/OpenCVFindIPPIW.cmake
**Change Type:** modified
**Context:** PR #16769: Do not copy standalone IPP libraries to install for static builds

**Code Changes:**
```diff
@@ -108,12 +108,13 @@ macro(ippiw_setup PATH BUILD)
           message(STATUS "found Intel IPP Integration Wrappers binaries: ${IW_VERSION_MAJOR}.${IW_VERSION_MINOR}.${IW_VERSION_UPDATE}")
           message(STATUS "at: ${IPP_IW_PATH}")
 
-          add_library(ippiw STATIC IMPORTED)
-          set_target_properties(ippiw PROPERTIES
+          add_library(ipp_iw STATIC IMPORTED)
+          set_target_properties(ipp_iw PROPERTIES
             IMPORTED_LINK_INTERFACE_LIBRARIES ""
             IMPORTED_LOCATION "${FILE}"
```

Review comment:
All dependencies must be CMake targets. Absolute paths are not allowed anymore.
**File:** cmake/OpenCVFindIPPIW.cmake
**Change Type:** modified
**Context:** PR #16769: Do not copy standalone IPP libraries to install for static builds
**Review Line:** 116

**Code Changes:**
```diff
+          set_target_properties(ipp_iw PROPERTIES
             IMPORTED_LINK_INTERFACE_LIBRARIES ""
             IMPORTED_LOCATION "${FILE}"
           )
-          if (NOT BUILD_SHARED_LIBS)
+
+          if (NOT BUILD_SHARED_LIBS AND ";${OPENCV_INSTALL_EXTERNAL_DEPENDENCIES};" MATCHES ";ipp;")
             # CMake doesn't support "install(TARGETS ${name} ...)" command with imported targets
             install(FILES "${FILE}"
                     DESTINATION ${OPENCV_3P_LIB_INSTALL_PATH} COMPONENT dev)
@@ -122,7 +123,7 @@ macro(ippiw_setup PATH BUILD)
```

Review comment:
Instead of complete dropping this code, please add `OPENCV_INSTALL_EXTERNAL_DEPENDENCIES` option: For example as list, including "all" (`ipp` in this case) - for better configuration. See [here](https://github.com/opencv/opencv/commit/7465125f67fa8c535477193e0730867a7a88136a#diff-a8bb897ccface5bd5e7eff5548b73f77).
**File:** modules/imgproc/test/test_convhull.cpp
**Change Type:** modified
**Context:** PR #16594: fixed the ordering of contour convex hull points - Fixes issue #14521. Partially fixes the issue #4539. 1. if possible, the convex hull ind...

**Code Changes:**
```diff
@@ -2154,5 +2154,157 @@ TEST(Imgproc_FitLine, regression_4903)
     EXPECT_GE(fabs(lineParam[1]), fabs(lineParam[0]) * 4) << lineParam;
 }
 
+#if 0
+#define DRAW(x) x
+#else
+#define DRAW(x)
+#endif
+
```

Review comment:
Why do we not test input "as is"? Why do we need these hacks with preparation of input before calling of testing functions? Why is original input considered as invalid and it requires such processing? Suggested input comes from somewhere and should be processed in its original form - instead of drawing, dilating and finding contours.
**File:** modules/imgproc/test/test_convhull.cpp
**Change Type:** modified
**Context:** PR #16594: fixed the ordering of contour convex hull points - Fixes issue #14521. Partially fixes the issue #4539. 1. if possible, the convex hull ind...

**Code Changes:**
```diff
@@ -2154,5 +2154,157 @@ TEST(Imgproc_FitLine, regression_4903)
     EXPECT_GE(fabs(lineParam[1]), fabs(lineParam[0]) * 4) << lineParam;
 }
 
+#if 0
+#define DRAW(x) x
+#else
+#define DRAW(x)
+#endif
+
```

Review comment:
ok, I added the code to test the original contour
**File:** modules/imgproc/src/convhull.cpp
**Change Type:** modified
**Context:** PR #16594: fixed the ordering of contour convex hull points - Fixes issue #14521. Partially fixes the issue #4539. 1. if possible, the convex hull ind...
**Review Line:** 359

**Code Changes:**
```diff
         Point pt0 = ptr[hcurr], pt1 = ptr[hnext];
+        if( increasing_idx < 0 )
+            increasing_idx = !(hcurr < hnext);
+        else if( increasing_idx != (hcurr < hnext))
+        {
+            CV_Error(Error::StsBadArg,
+            "The convex hull indices are not monotonous, which can be in the case when the input contour contains self-intersections");
+        }
+
         double dx0 = pt1.x - pt0.x;
         double dy0 = pt1.y - pt0.y;
```

Review comment:
This change sometimes breaks the ERFilter. https://github.com/opencv/opencv_contrib/blob/master/modules/text/src/erfilter.cpp#L2837
**File:** modules/imgproc/src/convhull.cpp
**Change Type:** modified
**Context:** PR #16594: fixed the ordering of contour convex hull points - Fixes issue #14521. Partially fixes the issue #4539. 1. if possible, the convex hull ind...
**Review Line:** 359

**Code Changes:**
```diff
         Point pt0 = ptr[hcurr], pt1 = ptr[hnext];
+        if( increasing_idx < 0 )
+            increasing_idx = !(hcurr < hnext);
+        else if( increasing_idx != (hcurr < hnext))
+        {
+            CV_Error(Error::StsBadArg,
+            "The convex hull indices are not monotonous, which can be in the case when the input contour contains self-intersections");
+        }
+
         double dx0 = pt1.x - pt0.x;
         double dy0 = pt1.y - pt0.y;
```

Review comment:
Please provide complete minimal reproducer and fill an issue in opencv_contrib.
**File:** modules/imgproc/src/shapedescr.cpp
**Change Type:** modified
**Context:** PR #17417: improved fitEllipse and fitEllipseDirect accuracy in singular cases

**Code Changes:**
```diff
@@ -337,8 +337,15 @@ double cv::contourArea( InputArray _contour, bool oriented )
     return a00;
 }
 
+namespace cv
+{
 
-cv::RotatedRect cv::fitEllipse( InputArray _points )
+static inline Point2f getOfs(int i, float eps)
+{
```

Review comment:
static analysis tools require variables initialization
**File:** modules/imgproc/src/shapedescr.cpp
**Change Type:** modified
**Context:** PR #17417: improved fitEllipse and fitEllipseDirect accuracy in singular cases

**Code Changes:**
```diff
@@ -337,8 +337,15 @@ double cv::contourArea( InputArray _contour, bool oriented )
     return a00;
 }
 
+namespace cv
+{
 
-cv::RotatedRect cv::fitEllipse( InputArray _points )
+static inline Point2f getOfs(int i, float eps)
+{
```

Review comment:
overriding content of input array is not a good idea.
**File:** modules/imgproc/src/shapedescr.cpp
**Change Type:** modified
**Context:** PR #17417: improved fitEllipse and fitEllipseDirect accuracy in singular cases
**Review Line:** 741

**Code Changes:**
```diff
-    M(1,2) = -DM(1,2) - (DM(1,3)*TM(0,2) + DM(1,4)*TM(1,2) + DM(1,5)*TM(2,2))/Ts;
-    M(2,0) = (DM(0,0) + (DM(0,3)*TM(0,0) + DM(0,4)*TM(1,0) + DM(0,5)*TM(2,0))/Ts)/2.;
-    M(2,1) = (DM(0,1) + (DM(0,3)*TM(0,1) + DM(0,4)*TM(1,1) + DM(0,5)*TM(2,1))/Ts)/2.;
-    M(2,2) = (DM(0,2) + (DM(0,3)*TM(0,2) + DM(0,4)*TM(1,2) + DM(0,5)*TM(2,2))/Ts)/2.;
+    // first, try the original pointset.
+    // if it's singular, try to shift the points a bit
+    int iter = 0;
+    for( iter = 0; iter < 2; iter++ ) {
+        for( i = 0; i < n; i++ )
+        {
+            Point2f p = is_float ? ptsf[i] : Point2f((float)ptsi[i].x, (float)ptsi[i].y);
```

Review comment:
There is still no guarantee that this method always provides correct results. What is about some regular normalization process for input data?
**File:** modules/imgproc/src/shapedescr.cpp
**Change Type:** modified
**Context:** PR #17417: improved fitEllipse and fitEllipseDirect accuracy in singular cases

**Code Changes:**
```diff
@@ -337,8 +337,15 @@ double cv::contourArea( InputArray _contour, bool oriented )
     return a00;
 }
 
+namespace cv
+{
 
-cv::RotatedRect cv::fitEllipse( InputArray _points )
+static inline Point2f getOfs(int i, float eps)
+{
```

Review comment:
actually, it's the copy of input data that was modified. I made it a bit more clear
**File:** modules/imgproc/src/shapedescr.cpp
**Change Type:** modified
**Context:** PR #17417: improved fitEllipse and fitEllipseDirect accuracy in singular cases
**Review Line:** 741

**Code Changes:**
```diff
-    M(1,2) = -DM(1,2) - (DM(1,3)*TM(0,2) + DM(1,4)*TM(1,2) + DM(1,5)*TM(2,2))/Ts;
-    M(2,0) = (DM(0,0) + (DM(0,3)*TM(0,0) + DM(0,4)*TM(1,0) + DM(0,5)*TM(2,0))/Ts)/2.;
-    M(2,1) = (DM(0,1) + (DM(0,3)*TM(0,1) + DM(0,4)*TM(1,1) + DM(0,5)*TM(2,1))/Ts)/2.;
-    M(2,2) = (DM(0,2) + (DM(0,3)*TM(0,2) + DM(0,4)*TM(1,2) + DM(0,5)*TM(2,2))/Ts)/2.;
+    // first, try the original pointset.
+    // if it's singular, try to shift the points a bit
+    int iter = 0;
+    for( iter = 0; iter < 2; iter++ ) {
+        for( i = 0; i < n; i++ )
+        {
+            Point2f p = is_float ? ptsf[i] : Point2f((float)ptsi[i].x, (float)ptsi[i].y);
```

Review comment:
indeed, there is no absolute guarantee. However, such situations appear then we have point singularity, i.e. many points lie on the same line, as in issue 10270. No data normalization can help here. But if we shift points semi-randomly just a tiny bit, the configuration will not be a singular anymore. Also, please note that initially we try original points and we check determinant with 1e-10. It's really, really small number. That is, in 99.99999...% of cases the original points will be used. by the way, I improved normalization of the input data. In cv::fitEllipse(NoDirect)() there is already quite complex data normalization procedure. And in each of fitEllipse, fitEllipseAMS and fitEllipseDirect there was already data centering, i.e. subtraction of the mass center. I added extra normalization to convert too small or too big ellipses to medium ones, with the final re-scaling (see the scale parameter). Indeed, it helped to narrow down the value range of computed minors/determinants in fitEllipseAMS and fitEllipseDirect, i.e. instead of 1e30 etc. we now have 1e8 or something like that. fitEllipse(NonDirect)() was less affected, because it already uses multiple SVD's to address the value range problem (but it's much slower).
**File:** cmake/OpenCVDetectCUDA.cmake
**Change Type:** modified
**Context:** PR #17526: respect CUDA_HOST_COMPILER when detecting CUDA arch - ``` force_builders=Custom buildworker:Custom=linux-4 build_image:Custom=ubuntu-cuda:1...
**Review Line:** 90

**Code Changes:**
```diff
-  SET(DETECT_ARCHS_COMMAND "${CUDA_NVCC_EXECUTABLE}" ${CUDA_NVCC_FLAGS} "${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu" "--run")
-  if(WIN32 AND CMAKE_LINKER) #Workaround for VS cl.exe not being in the env. path
-    get_filename_component(host_compiler_bindir ${CMAKE_LINKER} DIRECTORY)
-    SET(DETECT_ARCHS_COMMAND ${DETECT_ARCHS_COMMAND} "-ccbin" "${host_compiler_bindir}")
+  if(CUDA_HOST_COMPILER)
+    LIST(APPEND CUDA_NVCC_FLAGS -ccbin ${CUDA_HOST_COMPILER})
+  else()
+    if(WIN32 AND CMAKE_LINKER) #Workaround for VS cl.exe not being in the env. path
+      get_filename_component(host_compiler_bindir ${CMAKE_LINKER} DIRECTORY)
+      LIST(APPEND CUDA_NVCC_FLAGS -ccbin ${host_compiler_bindir})
+    endif()
```

Review comment:
`CUDA_HOST_COMPILER` is path to executable, but not directory as it's done in else branch.
**File:** cmake/OpenCVDetectCUDA.cmake
**Change Type:** modified
**Context:** PR #17526: respect CUDA_HOST_COMPILER when detecting CUDA arch - ``` force_builders=Custom buildworker:Custom=linux-4 build_image:Custom=ubuntu-cuda:1...
**Review Line:** 90

**Code Changes:**
```diff
-  SET(DETECT_ARCHS_COMMAND "${CUDA_NVCC_EXECUTABLE}" ${CUDA_NVCC_FLAGS} "${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu" "--run")
-  if(WIN32 AND CMAKE_LINKER) #Workaround for VS cl.exe not being in the env. path
-    get_filename_component(host_compiler_bindir ${CMAKE_LINKER} DIRECTORY)
-    SET(DETECT_ARCHS_COMMAND ${DETECT_ARCHS_COMMAND} "-ccbin" "${host_compiler_bindir}")
+  if(CUDA_HOST_COMPILER)
+    LIST(APPEND CUDA_NVCC_FLAGS -ccbin ${CUDA_HOST_COMPILER})
+  else()
+    if(WIN32 AND CMAKE_LINKER) #Workaround for VS cl.exe not being in the env. path
+      get_filename_component(host_compiler_bindir ${CMAKE_LINKER} DIRECTORY)
+      LIST(APPEND CUDA_NVCC_FLAGS -ccbin ${host_compiler_bindir})
+    endif()
```

Review comment:
> `CUDA_HOST_COMPILER` is path to executable, but not directory as it's done in else branch. 4.2.1.11. --compiler-bindir directory (-ccbin) Specify the directory in which the compiler executable resides. **The host compiler executable name can be also specified to ensure that the correct host compiler is selected**. In addition, driver prefix options (--input-drive-prefix, --dependency-drive-prefix, or --drive-prefix) may need to be specified, if nvcc is executed in a Cygwin shell or a MinGW shell on Windows.
**File:** modules/imgproc/src/hough.cpp
**Change Type:** modified
**Context:** PR #16561: improved version of HoughCircles (HOUGH_GRADIENT_ALT method)

**Code Changes:**
```diff
@@ -1005,6 +1005,7 @@ void HoughLinesPointSet( InputArray _point, OutputArray _lines, int lines_max, i
 
 struct EstimatedCircle
 {
+    EstimatedCircle() { accum = 0; }
     EstimatedCircle(Vec3f _c, int _accum) :
         c(_c), accum(_accum) {}
     Vec3f c;
@@ -1710,6 +1711,530 @@ static void HoughCirclesGradient(InputArray _image, OutputArray _circles,
     }
```

Review comment:
reuse existed popcnt implementations.
**File:** modules/imgproc/src/hough.cpp
**Change Type:** modified
**Context:** PR #16561: improved version of HoughCircles (HOUGH_GRADIENT_ALT method)

**Code Changes:**
```diff
@@ -1005,6 +1005,7 @@ void HoughLinesPointSet( InputArray _point, OutputArray _lines, int lines_max, i
 
 struct EstimatedCircle
 {
+    EstimatedCircle() { accum = 0; }
     EstimatedCircle(Vec3f _c, int _accum) :
         c(_c), accum(_accum) {}
     Vec3f c;
@@ -1710,6 +1711,530 @@ static void HoughCirclesGradient(InputArray _image, OutputArray _circles,
     }
```

Review comment:
Avoid merging of if's conditions and if's body. Let make code coverage reports more useful.
**File:** modules/imgproc/src/hough.cpp
**Change Type:** modified
**Context:** PR #16561: improved version of HoughCircles (HOUGH_GRADIENT_ALT method)
**Review Line:** 1780

**Code Changes:**
```diff
+    dp = std::max(dp, 1.);
+
+    Mat Dx, Dy, edges;
+    Scharr(img, Dx, CV_16S, 1, 0);
+    Scharr(img, Dy, CV_16S, 0, 1);
+    Canny(Dx, Dy, edges, cannyThreshold/2, cannyThreshold, true);
+    Mat mask(img.rows + 2, img.cols + 2, CV_8U, Scalar::all(0));
+    double idp = 1./dp;
+    int minR = cvFloor(minRadius*idp);
+    int maxR = cvCeil(maxRadius*idp);
+    int acols = cvRound(img.cols*idp);
```

Review comment:
I believe such pre-processing should be optional.
**File:** modules/imgproc/src/hough.cpp
**Change Type:** modified
**Context:** PR #16561: improved version of HoughCircles (HOUGH_GRADIENT_ALT method)
**Review Line:** 1815

**Code Changes:**
```diff
+
+    for( int y = 0; y < edges.rows; y++ )
+    {
+        for( int x = 0; x < edges.cols; x++ )
+        {
+            if(!edgeData[y*estep + x] || mdata[y*mstep + x])
+                continue;
+
+            mdata[y*mstep + x] = (uchar)1;
+            stack.push_back(Point(x, y));
+            bool backtrace_mode = false;
```

Review comment:
Avoid manual address arithmetic. There is still efficient `.at(y, x)` method for release builds and there are extra checks in debug builds.
**File:** modules/imgproc/src/hough.cpp
**Change Type:** modified
**Context:** PR #16561: improved version of HoughCircles (HOUGH_GRADIENT_ALT method)
**Review Line:** 1804

**Code Changes:**
```diff
+    int mstep = (int)mask.step1();
+
+    circles.clear();
+    std::vector<Vec4f> nz;
+
+    std::vector<Point> stack;
+    const int n33[][2] = {{-1, -1}, {-1, 0}, {-1, 1}, {0, 1}, {1, 1}, {1, 0}, {1, -1}, {0, -1}};
+
+    for( int x = 0; x < mask.cols; x++ ) mdata[x] = mdata[(mask.rows-1)*mstep + x] = (uchar)1;
+    for( int y = 0; y < mask.rows; y++ ) mdata[y*mstep] = mdata[y*mstep + mask.cols-1] = (uchar)1;
+    mdata += mstep + 1;
```

Review comment:
There is [`std::stack`](https://en.cppreference.com/w/cpp/container/stack) for that.
**File:** modules/imgproc/src/hough.cpp
**Change Type:** modified
**Context:** PR #16561: improved version of HoughCircles (HOUGH_GRADIENT_ALT method)

**Code Changes:**
```diff
@@ -1005,6 +1005,7 @@ void HoughLinesPointSet( InputArray _point, OutputArray _lines, int lines_max, i
 
 struct EstimatedCircle
 {
+    EstimatedCircle() { accum = 0; }
     EstimatedCircle(Vec3f _c, int _accum) :
         c(_c), accum(_accum) {}
     Vec3f c;
@@ -1710,6 +1711,530 @@ static void HoughCirclesGradient(InputArray _image, OutputArray _circles,
     }
```

Review comment:
What is 1024 magic number? Consider declaring this constant separately with descriptive name. Same notes are about `64`, `7`, `3` below.
**File:** modules/imgproc/src/hough.cpp
**Change Type:** modified
**Context:** PR #16561: improved version of HoughCircles (HOUGH_GRADIENT_ALT method)

**Code Changes:**
```diff
@@ -1005,6 +1005,7 @@ void HoughLinesPointSet( InputArray _point, OutputArray _lines, int lines_max, i
 
 struct EstimatedCircle
 {
+    EstimatedCircle() { accum = 0; }
     EstimatedCircle(Vec3f _c, int _accum) :
         c(_c), accum(_accum) {}
     Vec3f c;
@@ -1710,6 +1711,530 @@ static void HoughCirclesGradient(InputArray _image, OutputArray _circles,
     }
```

Review comment:
Don't add line break before `while` in `do while` statements.