nareshmlx/opencv-pr huggingface dataset:
**File:** modules/photo/test/test_inpaint.cpp
**Change Type:** modified
**Context:** PR #25402: Handle top and left border masked pixels correctly in inpaint method

**Code Changes:**
```diff
@@ -157,4 +157,30 @@ TEST(Photo_InpaintBorders, regression)
     ASSERT_TRUE(countNonZero(diff) == 0);
 }
 
+typedef testing::TestWithParam<tuple<perf::MatType>> Photo_InpaintSmallBorders;
+
+TEST_P(Photo_InpaintSmallBorders, regression)
+{
+    int type = get<0>(GetParam());
+    Mat img(5, 5, type, Scalar::all(128));
```

Review comment:
You can reduce code duplication with parameterized test, e.g.: ``` typedef testing::TestWithParam<int> Photo_InpaintSmallBorders; TEST(Photo_InpaintSmallBorders, regression) { int channels = get<0>(GetParam()); Mat img(5, 5, CV_MAKETYPE(CV_8U, channels), Scalar::all(128)); ... } INSTANTIATE_TEST_CASE_P(/*nothing*/, Photo_InpaintSmallBorders, Values(1, 3)); ``` Or even simpler: push matrix type as a parameter, but not only amount of channels.
**File:** modules/photo/test/test_inpaint.cpp
**Change Type:** modified
**Context:** PR #25402: Handle top and left border masked pixels correctly in inpaint method

**Code Changes:**
```diff
@@ -157,4 +157,30 @@ TEST(Photo_InpaintBorders, regression)
     ASSERT_TRUE(countNonZero(diff) == 0);
 }
 
+typedef testing::TestWithParam<tuple<perf::MatType>> Photo_InpaintSmallBorders;
+
+TEST_P(Photo_InpaintSmallBorders, regression)
+{
+    int type = get<0>(GetParam());
+    Mat img(5, 5, type, Scalar::all(128));
```

Review comment:
Okay, I updated the code.
**File:** samples/cpp/geometry.cpp
**Change Type:** added
**Context:** PR #25304: geometry cpp sample combining other shape detection samples

**Code Changes:**
```diff
@@ -0,0 +1,268 @@
+/*******************************************************************************
+ *
+ * This program demonstrates various shape fitting techniques using OpenCV.
+ * It reads an image, applies binary thresholding, and then detects contours.
+ *
+ * For each contour, it fits and draws several geometric shapes including
+ * convex hulls, minimum enclosing circles, rectangles, triangles, and ellipses
+ * using different fitting methods:
+ *  1: OpenCV's original method fitEllipse which implements Fitzgibbon 1995 method.
```

Review comment:
Range check is needed.
**File:** samples/cpp/geometry.cpp
**Change Type:** added
**Context:** PR #25304: geometry cpp sample combining other shape detection samples

**Code Changes:**
```diff
@@ -0,0 +1,268 @@
+/*******************************************************************************
+ *
+ * This program demonstrates various shape fitting techniques using OpenCV.
+ * It reads an image, applies binary thresholding, and then detects contours.
+ *
+ * For each contour, it fits and draws several geometric shapes including
+ * convex hulls, minimum enclosing circles, rectangles, triangles, and ellipses
+ * using different fitting methods:
+ *  1: OpenCV's original method fitEllipse which implements Fitzgibbon 1995 method.
```

Review comment:
I propose to introduce named constants.
**File:** samples/cpp/geometry.cpp
**Change Type:** added
**Context:** PR #25304: geometry cpp sample combining other shape detection samples

**Code Changes:**
```diff
@@ -0,0 +1,268 @@
+/*******************************************************************************
+ *
+ * This program demonstrates various shape fitting techniques using OpenCV.
+ * It reads an image, applies binary thresholding, and then detects contours.
+ *
+ * For each contour, it fits and draws several geometric shapes including
+ * convex hulls, minimum enclosing circles, rectangles, triangles, and ellipses
+ * using different fitting methods:
+ *  1: OpenCV's original method fitEllipse which implements Fitzgibbon 1995 method.
```

Review comment:
I propose to pass the value as function parameter in `drawFittedEllipses` and `drawShapes`
**File:** samples/cpp/geometry.cpp
**Change Type:** added
**Context:** PR #25304: geometry cpp sample combining other shape detection samples

**Code Changes:**
```diff
@@ -0,0 +1,268 @@
+/*******************************************************************************
+ *
+ * This program demonstrates various shape fitting techniques using OpenCV.
+ * It reads an image, applies binary thresholding, and then detects contours.
+ *
+ * For each contour, it fits and draws several geometric shapes including
+ * convex hulls, minimum enclosing circles, rectangles, triangles, and ellipses
+ * using different fitting methods:
+ *  1: OpenCV's original method fitEllipse which implements Fitzgibbon 1995 method.
```

Review comment:
I propose to format command line parameters like in https://github.com/opencv/opencv/blob/b0d905864d6af8fef33ab30e102aa3cfcb329fe0/samples/cpp/aruco_dict_utils.cpp#L255
**File:** samples/cpp/geometry.cpp
**Change Type:** added
**Context:** PR #25304: geometry cpp sample combining other shape detection samples

**Code Changes:**
```diff
@@ -0,0 +1,268 @@
+/*******************************************************************************
+ *
+ * This program demonstrates various shape fitting techniques using OpenCV.
+ * It reads an image, applies binary thresholding, and then detects contours.
+ *
+ * For each contour, it fits and draws several geometric shapes including
+ * convex hulls, minimum enclosing circles, rectangles, triangles, and ellipses
+ * using different fitting methods:
+ *  1: OpenCV's original method fitEllipse which implements Fitzgibbon 1995 method.
```

Review comment:
Looks like `polylines` can be used.
**File:** samples/cpp/geometry.cpp
**Change Type:** added
**Context:** PR #25304: geometry cpp sample combining other shape detection samples

**Code Changes:**
```diff
@@ -0,0 +1,268 @@
+/*******************************************************************************
+ *
+ * This program demonstrates various shape fitting techniques using OpenCV.
+ * It reads an image, applies binary thresholding, and then detects contours.
+ *
+ * For each contour, it fits and draws several geometric shapes including
+ * convex hulls, minimum enclosing circles, rectangles, triangles, and ellipses
+ * using different fitting methods:
+ *  1: OpenCV's original method fitEllipse which implements Fitzgibbon 1995 method.
```

Review comment:
Done by using userData struct
**File:** modules/3d/src/pointcloud/load_point_cloud.cpp
**Change Type:** modified
**Context:** PR #25382: Fix mesh loading for texture coordinates and face indices

**Code Changes:**
```diff
@@ -140,7 +140,7 @@ void loadMesh(const String &filename, OutputArray vertices, OutputArrayOfArrays
     std::vector<std::vector<int32_t>> vec_indices;
 
     std::vector<Point3f> vec_texCoords;
-    int nTexCoords;
+    int nTexCoords = 0;
 
     decoder->readData(vec_vertices, vec_normals, vec_rgb, vec_texCoords, nTexCoords, vec_indices, 0);
 
@@ -210,32 +210,30 @@ void loadMesh(const String &filename, OutputArray vertices, OutputArrayOfArrays
```

Review comment:
Looks like mixChannels is enough instead of all the changes: https://docs.opencv.org/4.x/d2/de8/group__core__array.html#ga83b61f9875e6618ee08487b21ec71ab1. As better alternative I propose to use OutputArray/cv::Mat in readData and handle it on data creation.
**File:** doc/tutorials/objdetect/aruco_faq/aruco_faq.markdown
**Change Type:** added
**Context:** PR #25422: (5.x) Merge 4.x - OpenCV Contrib: https://github.com/opencv/opencv_contrib/pull/3721 OpenCV Extra: None #25107 from catree:fix_mistake_repr...
**Review Line:** 4

**Code Changes:**
```diff
@@ -0,0 +1,191 @@
+Aruco module FAQ {#tutorial_aruco_faq}
+================
+
+@prev_tutorial{tutorial_aruco_calibration}
+@next_tutorial{tutorial_barcode_detect_and_decode}
+
+This is a compilation of questions that can be useful for those that want to use the aruco module.
+
+- I only want to label some objects, what should I use?
```

Review comment:
`prev` goes first
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25422: (5.x) Merge 4.x - OpenCV Contrib: https://github.com/opencv/opencv_contrib/pull/3721 OpenCV Extra: None #25107 from catree:fix_mistake_repr...
**Review Line:** 938

**Code Changes:**
```diff
 #endif
 }
 
+#if !defined(__OPENCV_BUILD) && !(defined __STDCPP_FLOAT16_T__) && !(defined __ARM_NEON)
 typedef hfloat float16_t;
+#endif
 
 class bfloat
 {
```

Review comment:
This should be dropped in 5.x. That's to say no float16_t in 5.x even for external user.
**File:** 3rdparty/libjpeg-turbo/CMakeLists.txt
**Change Type:** modified
**Context:** PR #25388: Fixed jpeg-turbo diagnostics and build options in default configuration.
**Review Line:** 60

**Code Changes:**
```diff
 endif()
 
-OCV_OPTION(ENABLE_LIBJPEG_TURBO_SIMD "Include SIMD extensions for libjpeg-turbo, if available for this platform" (NOT CV_DISABLE_OPTIMIZATION)
-  VISIBLE_IF BUILD_JPEG)
+OCV_OPTION(ENABLE_LIBJPEG_TURBO_SIMD "Include SIMD extensions for libjpeg-turbo, if available for this platform" (NOT CV_DISABLE_OPTIMIZATION))
 option(WITH_ARITH_ENC "Include arithmetic encoding support when emulating the libjpeg v6b API/ABI" TRUE)
 option(WITH_ARITH_DEC "Include arithmetic decoding support when emulating the libjpeg v6b API/ABI" TRUE)
 set(WITH_SIMD 1)
```

Review comment:
Maybe we should add `BUILD_JPEG_TURBO` variable instead and check it here? Currently logic is not very obvious, i.e. in order to disable own JPEG library users must provide `BUILD_JPEG=OFF` **and** `BUILD_JPEG_TURBO_DISABLE=ON`.
**File:** modules/imgproc/src/hal_replacement.hpp
**Change Type:** modified
**Context:** PR #25343: HAL interface for bilaterialFilter
**Review Line:** 781

**Code Changes:**
```diff
+   @param d Diameter of each pixel neighborhood that is used during filtering. If it is non-positive, it is computed from sigmaSpace
+   @param sigma_color Filter sigma in the color space
+   @param sigma_space Filter sigma in the coordinate space. When d>0, it specifies the neighborhood size regardless of sigmaSpace. Otherwise, d is proportional to sigmaSpace
+   @param border_type border mode used to extrapolate pixels outside of the image
+*/
+inline int hal_ni_bilateralFilter(const uchar* src_data, size_t src_step, uchar* dst_data, size_t dst_step,
+                                  int width, int height, int depth, int cn, int d, double sigma_color, double sigma_space, int border_type)
+{ return CV_HAL_ERROR_NOT_IMPLEMENTED; }
+
+//! @cond IGNORED
+#define cv_hal_bilateralFilter hal_ni_bilateralFilter
```

Review comment:
the API is a bit confusing; semantically, it should take pointers of any type (U8 and F32 at least, maybe F16/BF16 in the future), but it uses `uchar*`. Suggest to use `void*`.
**File:** modules/imgproc/src/hal_replacement.hpp
**Change Type:** modified
**Context:** PR #25343: HAL interface for bilaterialFilter
**Review Line:** 781

**Code Changes:**
```diff
+   @param d Diameter of each pixel neighborhood that is used during filtering. If it is non-positive, it is computed from sigmaSpace
+   @param sigma_color Filter sigma in the color space
+   @param sigma_space Filter sigma in the coordinate space. When d>0, it specifies the neighborhood size regardless of sigmaSpace. Otherwise, d is proportional to sigmaSpace
+   @param border_type border mode used to extrapolate pixels outside of the image
+*/
+inline int hal_ni_bilateralFilter(const uchar* src_data, size_t src_step, uchar* dst_data, size_t dst_step,
+                                  int width, int height, int depth, int cn, int d, double sigma_color, double sigma_space, int border_type)
+{ return CV_HAL_ERROR_NOT_IMPLEMENTED; }
+
+//! @cond IGNORED
+#define cv_hal_bilateralFilter hal_ni_bilateralFilter
```

Review comment:
I reviewed existing HAL interfaces and it's done in the same way everywhere. Examples: hal_ni_integral, hal_ni_resize. I added information about supported types to description.
**File:** modules/core/test/test_io.cpp
**Change Type:** modified
**Context:** PR #25351: core: persistence: output reals as human-friendly expression.
**Review Line:** 1973

**Code Changes:**
```diff
+}
+
+TEST_P(Core_InputOutput_regression_25073, my_float16)
+{
+    cv::String res = "";
+    cv::float16_t my_float16(0.5);
+
+    FileStorage fs( GetParam(), cv::FileStorage::WRITE | cv::FileStorage::MEMORY);
+    EXPECT_NO_THROW( fs << "my_float16" << my_float16 );
+    EXPECT_NO_THROW( fs << "my_int" << 5 );
+    EXPECT_NO_THROW( res = fs.releaseAndGetString() );
```

Review comment:
We should not use `cv::float16_t` internally in OpenCV. See https://github.com/opencv/opencv/pull/25387
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -900,7 +900,9 @@ inline hfloat hfloatFromBits(ushort w) {
 #endif
 }
 
+#if !defined(__OPENCV_BUILD) && !(defined __STDCPP_FLOAT16_T__) && !(defined __ARM_NEON)
 typedef hfloat float16_t;
+#endif
 
 }
 #endif
```

Review comment:
you can add c++ version check with `__cplusplus` macro. See https://stackoverflow.com/questions/2324658/how-to-determine-the-version-of-the-c-standard-used-by-the-compiler
**File:** modules/dnn/src/layers/cpu_kernels/conv_block.simd.hpp
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -494,10 +494,9 @@ void convBlockMR1_F32(int np, const float * a, const float * b, float *c, const
 void convBlock_F16(int np, const char * _a, const char * _b, char * _c, int ldc, bool init_c, int width,
                     const int convMR_fp16, const int convNR_fp16)
 {
-    typedef __fp16 float16_t;
-    const float16_t* a = (const float16_t*)_a;
-    const float16_t* b = (const float16_t*)_b;
-    float16_t* c = (float16_t*)_c;
+    const __fp16* a = (const __fp16*)_a;
+    const __fp16* b = (const __fp16*)_b;
```

Review comment:
Why do we still need this `float16_t`?
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -900,7 +900,9 @@ inline hfloat hfloatFromBits(ushort w) {
 #endif
 }
 
+#if !defined(__OPENCV_BUILD) && !(defined __STDCPP_FLOAT16_T__) && !(defined __ARM_NEON)
 typedef hfloat float16_t;
+#endif
 
 }
 #endif
```

Review comment:
In original comment there is complete guard condition to avoid using of `float16_t` in OpenCV code. --- > `__cplusplus` That could be added to C too. No need to make conditions near C++.
**File:** modules/dnn/src/layers/cpu_kernels/conv_block.simd.hpp
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -494,10 +494,9 @@ void convBlockMR1_F32(int np, const float * a, const float * b, float *c, const
 void convBlock_F16(int np, const char * _a, const char * _b, char * _c, int ldc, bool init_c, int width,
                     const int convMR_fp16, const int convNR_fp16)
 {
-    typedef __fp16 float16_t;
-    const float16_t* a = (const float16_t*)_a;
-    const float16_t* b = (const float16_t*)_b;
-    float16_t* c = (float16_t*)_c;
+    const __fp16* a = (const __fp16*)_a;
+    const __fp16* b = (const __fp16*)_b;
```

Review comment:
Because `vdupq_n_f16` at line 505 is an macro defined in Clang `arm_neon.h` (details in https://github.com/opencv/opencv/issues/25210#issue-2183606808). In this macro, `float16_t` is used, so this typedef has to be saved to make `vdupq_n_f16` works unless we undo `typedef hfloat float16_t` in this file. Note that `vdupq_n_f16` in GCC `arm_neon.h` is an function.
**File:** modules/dnn/src/layers/cpu_kernels/conv_block.simd.hpp
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -494,10 +494,9 @@ void convBlockMR1_F32(int np, const float * a, const float * b, float *c, const
 void convBlock_F16(int np, const char * _a, const char * _b, char * _c, int ldc, bool init_c, int width,
                     const int convMR_fp16, const int convNR_fp16)
 {
-    typedef __fp16 float16_t;
-    const float16_t* a = (const float16_t*)_a;
-    const float16_t* b = (const float16_t*)_b;
-    float16_t* c = (float16_t*)_c;
+    const __fp16* a = (const __fp16*)_a;
+    const __fp16* b = (const __fp16*)_b;
```

Review comment:
Maksim's solution may also work, which is to drop `typedef hfloat float16_t` for ARM platform: https://github.com/opencv/opencv/issues/25210#issuecomment-1996833371.
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -900,7 +900,9 @@ inline hfloat hfloatFromBits(ushort w) {
 #endif
 }
 
+#if !defined(__OPENCV_BUILD) && !(defined __STDCPP_FLOAT16_T__) && !(defined __ARM_NEON)
 typedef hfloat float16_t;
+#endif
 
 }
 #endif
```

Review comment:
Maksim's solution https://github.com/opencv/opencv/issues/25210#issuecomment-1996833371: ``` #if !(defined __STDCPP_FLOAT16_T__) && !(defined __ARM_NEON) typedef our_pod_fp16_struct float16_t; #endif ``` also looks good. Macro `__STDCPP_FLOAT16_T__` stands for the existing of `std::float16_t` in C++23.
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -900,7 +900,9 @@ inline hfloat hfloatFromBits(ushort w) {
 #endif
 }
 
+#if !defined(__OPENCV_BUILD) && !(defined __STDCPP_FLOAT16_T__) && !(defined __ARM_NEON)
 typedef hfloat float16_t;
+#endif
 
 }
 #endif
```

Review comment:
I still want to see `__OPENCV_BUILD` condition here to avoid usage in OpenCV completely (to avoid mistakes like recent issue).
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -900,7 +900,9 @@ inline hfloat hfloatFromBits(ushort w) {
 #endif
 }
 
+#if !defined(__OPENCV_BUILD) && !(defined __STDCPP_FLOAT16_T__) && !(defined __ARM_NEON)
 typedef hfloat float16_t;
+#endif
 
 }
 #endif
```

Review comment:
> I still want to see `__OPENCV_BUILD` condition here to avoid usage in OpenCV completely (to avoid mistakes like recent issue). Added.
**File:** modules/dnn/src/layers/cpu_kernels/conv_block.simd.hpp
**Change Type:** modified
**Context:** PR #25387: Rename remaining float16_t for future proof

**Code Changes:**
```diff
@@ -494,10 +494,9 @@ void convBlockMR1_F32(int np, const float * a, const float * b, float *c, const
 void convBlock_F16(int np, const char * _a, const char * _b, char * _c, int ldc, bool init_c, int width,
                     const int convMR_fp16, const int convNR_fp16)
 {
-    typedef __fp16 float16_t;
-    const float16_t* a = (const float16_t*)_a;
-    const float16_t* b = (const float16_t*)_b;
-    float16_t* c = (float16_t*)_c;
+    const __fp16* a = (const __fp16*)_a;
+    const __fp16* b = (const __fp16*)_b;
```

Review comment:
They all are dropped now.
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #25241: Added int support to padding layer

**Code Changes:**
```diff
@@ -2407,8 +2407,16 @@ void ONNXImporter::parsePad(LayerParams& layerParams, const opencv_onnx::NodePro
         if (node_proto.input_size() == 3 && !node_proto.input(2).empty())
         {
             Mat value = getBlob(node_proto, 2);
-            float padValue = (depth == CV_8S) ? (float)value.ptr<int8_t>()[0] : value.ptr<float>()[0];
-            layerParams.set("value", padValue);
+            double padValue = 0;
+            switch(value.depth())
+            {
+                case CV_32F: padValue = value.ptr<float>()[0];   break;
```

Review comment:
Not sure that this is correct, because `getBlob(node_proto, 2)` is bias but here is Convolution and `inp_zp` means zero padding (the value after `inp_zp` subtraction). But let's wait for tests (to verify that we cover it)
**File:** modules/dnn/src/layers/padding_layer.cpp
**Change Type:** modified
**Context:** PR #25241: Added int support to padding layer

**Code Changes:**
```diff
@@ -34,7 +34,7 @@ class PaddingLayerImpl CV_FINAL : public PaddingLayer
     PaddingLayerImpl(const LayerParams &params)
     {
         setParamsFrom(params);
-        paddingValue = params.get<float>("value", 0);
+        paddingValue = params.get<double>("value", 0);
         inputDims = params.get<int>("input_dims", -1);
         paddingType = params.get<String>("type", "constant");
 
@@ -70,6 +70,23 @@ class PaddingLayerImpl CV_FINAL : public PaddingLayer
```

Review comment:
Looks weird to me. Now it is a `Mat` either way. Possible to change the behavior of other importers as well?
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #25241: Added int support to padding layer

**Code Changes:**
```diff
@@ -2407,8 +2407,16 @@ void ONNXImporter::parsePad(LayerParams& layerParams, const opencv_onnx::NodePro
         if (node_proto.input_size() == 3 && !node_proto.input(2).empty())
         {
             Mat value = getBlob(node_proto, 2);
-            float padValue = (depth == CV_8S) ? (float)value.ptr<int8_t>()[0] : value.ptr<float>()[0];
-            layerParams.set("value", padValue);
+            double padValue = 0;
+            switch(value.depth())
+            {
+                case CV_32F: padValue = value.ptr<float>()[0];   break;
```

Review comment:
https://github.com/onnx/onnx/blob/main/docs/Operators.md#QLinearConv input of index 2 is the zero point of x (input data).
**File:** modules/dnn/src/layers/padding_layer.cpp
**Change Type:** modified
**Context:** PR #25241: Added int support to padding layer

**Code Changes:**
```diff
@@ -34,7 +34,7 @@ class PaddingLayerImpl CV_FINAL : public PaddingLayer
     PaddingLayerImpl(const LayerParams &params)
     {
         setParamsFrom(params);
-        paddingValue = params.get<float>("value", 0);
+        paddingValue = params.get<double>("value", 0);
         inputDims = params.get<int>("input_dims", -1);
         paddingType = params.get<String>("type", "constant");
 
@@ -70,6 +70,23 @@ class PaddingLayerImpl CV_FINAL : public PaddingLayer
```

Review comment:
tf_lite importer adds some blobs to any layer (probably constant inputs) https://github.com/opencv/opencv/blob/4.x/modules/dnn/src/tflite/tflite_importer.cpp#L293 And there is a test where padding layer already has one blob. So looks like storing padding value in a blob requires some significant changes in the tf_lite parser.
**File:** modules/dnn/src/layers/padding_layer.cpp
**Change Type:** modified
**Context:** PR #25241: Added int support to padding layer

**Code Changes:**
```diff
@@ -34,7 +34,7 @@ class PaddingLayerImpl CV_FINAL : public PaddingLayer
     PaddingLayerImpl(const LayerParams &params)
     {
         setParamsFrom(params);
-        paddingValue = params.get<float>("value", 0);
+        paddingValue = params.get<double>("value", 0);
         inputDims = params.get<int>("input_dims", -1);
         paddingType = params.get<String>("type", "constant");
 
@@ -70,6 +70,23 @@ class PaddingLayerImpl CV_FINAL : public PaddingLayer
```

Review comment:
TFLite padding layer does not set padding values at all: https://github.com/opencv/opencv/blob/52f3f5a3f617e8b1fa708bdfc37a6bc58a13ebb7/modules/dnn/src/tflite/tflite_importer.cpp#L479
**File:** modules/dnn/src/cuda4dnn/primitives/padding.hpp
**Change Type:** modified
**Context:** PR #25241: Added int support to padding layer

**Code Changes:**
```diff
@@ -34,7 +34,7 @@ namespace cv { namespace dnn { namespace cuda4dnn {
         using wrapper_type = GetCUDABackendWrapperType<T>;
 
         /* `ranges` is indexed by axis and contains the range in the output where the input is copied to */
-        PaddingOp(csl::Stream stream_, PaddingType type_, T value_, std::vector<cv::Range> ranges)
+        PaddingOp(csl::Stream stream_, PaddingType type_, T value_, const std::vector<cv::Range>& ranges)
             : stream(std::move(stream_)),  type{ type_ }, value{ value_ }, dstRanges(std::move(ranges))
         {
         }
```

Review comment:
`const std::vector<cv::Range>&`