nareshmlx/opencv-pr huggingface dataset:
**File:** samples/cpp/videocapture_obsensor.cpp
**Change Type:** added
**Context:** PR #22196: videoio: add support for obsensor (Orbbec RGB-D Camera )

**Code Changes:**
```diff
@@ -0,0 +1,74 @@
+#include <opencv2/videoio.hpp>
+#include <opencv2/highgui.hpp>
+#include <opencv2/imgproc.hpp>
+#include <iostream>
+
+using namespace cv;
+int main()
+{
+    VideoCapture obsensorCapture(0, CAP_OBSENSOR);
```

Review comment:
we don't need 3 spaces in the middle of code.
**File:** modules/videoio/include/opencv2/videoio.hpp
**Change Type:** modified
**Context:** PR #22196: videoio: add support for obsensor (Orbbec RGB-D Camera )
**Review Line:** 664

**Code Changes:**
```diff
+    @{
+*/
+//! OBSENSOR data given from image generator
+enum VideoCaptureOBSensorDataType{ 
+    CAP_OBSENSOR_DEPTH_MAP = 0, //!< Depth values in mm (CV_16UC1)
+    CAP_OBSENSOR_BGR_IMAGE = 1, //!< Data given from BGR stream generator
+    CAP_OBSENSOR_IR_IMAGE = 2   //!< Data given from IR stream generator(CV_16UC1)
+};
+
+//! OBSENSOR stream generator
+enum VideoCaptureOBSensorGenerators{ 
```

Review comment:
According to the existing code, both OpenNI and Intel Realsense use depth as the default stream。For RGB-D cameras, depth as the default stream is more in line with user needs as they may only need the depth data stream.
**File:** modules/videoio/include/opencv2/videoio.hpp
**Change Type:** modified
**Context:** PR #22196: videoio: add support for obsensor (Orbbec RGB-D Camera )
**Review Line:** 664

**Code Changes:**
```diff
+    @{
+*/
+//! OBSENSOR data given from image generator
+enum VideoCaptureOBSensorDataType{ 
+    CAP_OBSENSOR_DEPTH_MAP = 0, //!< Depth values in mm (CV_16UC1)
+    CAP_OBSENSOR_BGR_IMAGE = 1, //!< Data given from BGR stream generator
+    CAP_OBSENSOR_IR_IMAGE = 2   //!< Data given from IR stream generator(CV_16UC1)
+};
+
+//! OBSENSOR stream generator
+enum VideoCaptureOBSensorGenerators{ 
```

Review comment:
Problem is that this support is enabled by default (for many build configurations). Existed user code may not expect non 8UC3 data and crash (16SC1/16UC1 or 32FC1 are used for depth). Exception is preferable (and reliable for this case) than silent replacing of 8UC3 result. If we go in this way, then we must update many sample code / documentation snippets / etc. But this would not resolve problem with existed users code. BTW, another approach may go through another API, like `VideoDepthCapture`. Including OpenNI/Realsense "buggy" cases.
**File:** modules/videoio/src/cap_v4l.cpp
**Change Type:** modified
**Context:** PR #22236: V4L2: Add multi-planar capture support

**Code Changes:**
```diff
@@ -286,6 +286,12 @@ typedef uint32_t __u32;
 #define MAX_V4L_BUFFERS 10
 #define DEFAULT_V4L_BUFFERS 4
 
+// types of memory in 'special' buffer
+enum {
+    MEMORY_ORIG = 0, // Image data in original format.
+    MEMORY_RGB  = 1, // Image data converted to RGB format.
+};
+
```

Review comment:
It’s my fault. I used the latest for the base, so there are a lot of diffs... Check only the changes in cap_v4l.cpp.
**File:** modules/videoio/src/cap_v4l.cpp
**Change Type:** modified
**Context:** PR #22236: V4L2: Add multi-planar capture support

**Code Changes:**
```diff
@@ -286,6 +286,12 @@ typedef uint32_t __u32;
 #define MAX_V4L_BUFFERS 10
 #define DEFAULT_V4L_BUFFERS 4
 
+// types of memory in 'special' buffer
+enum {
+    MEMORY_ORIG = 0, // Image data in original format.
+    MEMORY_RGB  = 1, // Image data converted to RGB format.
+};
+
```

Review comment:
`cv::Size` stores width and height as int. Both conditions are always true.
**File:** modules/videoio/src/cap_v4l.cpp
**Change Type:** modified
**Context:** PR #22236: V4L2: Add multi-planar capture support

**Code Changes:**
```diff
@@ -286,6 +286,12 @@ typedef uint32_t __u32;
 #define MAX_V4L_BUFFERS 10
 #define DEFAULT_V4L_BUFFERS 4
 
+// types of memory in 'special' buffer
+enum {
+    MEMORY_ORIG = 0, // Image data in original format.
+    MEMORY_RGB  = 1, // Image data converted to RGB format.
+};
+
```

Review comment:
Need a comment, why `buffers[MAX_V4L_BUFFERS].memories[1].start` is used.
**File:** modules/videoio/src/cap_v4l.cpp
**Change Type:** modified
**Context:** PR #22236: V4L2: Add multi-planar capture support

**Code Changes:**
```diff
@@ -286,6 +286,12 @@ typedef uint32_t __u32;
 #define MAX_V4L_BUFFERS 10
 #define DEFAULT_V4L_BUFFERS 4
 
+// types of memory in 'special' buffer
+enum {
+    MEMORY_ORIG = 0, // Image data in original format.
+    MEMORY_RGB  = 1, // Image data converted to RGB format.
+};
+
```

Review comment:
That's right. I modified it to do the same checks as the original code.
**File:** modules/videoio/src/cap_v4l.cpp
**Change Type:** modified
**Context:** PR #22236: V4L2: Add multi-planar capture support

**Code Changes:**
```diff
@@ -286,6 +286,12 @@ typedef uint32_t __u32;
 #define MAX_V4L_BUFFERS 10
 #define DEFAULT_V4L_BUFFERS 4
 
+// types of memory in 'special' buffer
+enum {
+    MEMORY_ORIG = 0, // Image data in original format.
+    MEMORY_RGB  = 1, // Image data converted to RGB format.
+};
+
```

Review comment:
There is no need to initialize planes for single-planar. It has been deleted.
**File:** modules/videoio/src/cap_v4l.cpp
**Change Type:** modified
**Context:** PR #22236: V4L2: Add multi-planar capture support

**Code Changes:**
```diff
@@ -286,6 +286,12 @@ typedef uint32_t __u32;
 #define MAX_V4L_BUFFERS 10
 #define DEFAULT_V4L_BUFFERS 4
 
+// types of memory in 'special' buffer
+enum {
+    MEMORY_ORIG = 0, // Image data in original format.
+    MEMORY_RGB  = 1, // Image data converted to RGB format.
+};
+
```

Review comment:
Certainly magic number is not good. I added a comment and named it with an enum.
**File:** modules/imgproc/test/test_houghlines.cpp
**Change Type:** modified
**Context:** PR #22164: Fix angle discretization in Hough transforms

**Code Changes:**
```diff
@@ -329,6 +329,17 @@ TEST(HoughLinesPointSet, regression_21029)
     EXPECT_TRUE(lines.empty());
 }
 
+TEST(HoughLines, regression_21983)
+{
+    Mat img(200, 200, CV_8UC1, Scalar(0));
+    line(img, Point(0, 100), Point(100, 100), Scalar(255));
+    std::vector<Vec2f> lines;
+    HoughLines(img, lines, 1, CV_PI/180, 90, 0, 0, 0.001, 1.58);
```

Review comment:
I propose to add line parameters check. `lines.empty()` is very weak check.
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22311: DNN: add another two Mish activation to onnx_graph_simplifier
**Review Line:** 561

**Code Changes:**
```diff
+        int addVal = addNodeToMatch("");
+        int add = addNodeToMatch("Add", exp, addVal);
+        addNodeToMatch("Log", add);
+        setFusedNode("Softplus", input);
+    }
+};
+
 class MulCastSubgraph : public Subgraph
 {
 public:
@@ -734,6 +763,8 @@ void simplifySubgraphs(opencv_onnx::GraphProto& net)
```

Review comment:
We have two very similar `SoftplusSubgrap` because `Softplus` contains an `Add` which has two inputs (one is variable and one is `Constant` 1). Since the order of these two inputs is random, we use two `SoftplusSubgraph` to handle this. Is there a better solution?
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22311: DNN: add another two Mish activation to onnx_graph_simplifier
**Review Line:** 561

**Code Changes:**
```diff
+        int addVal = addNodeToMatch("");
+        int add = addNodeToMatch("Add", exp, addVal);
+        addNodeToMatch("Log", add);
+        setFusedNode("Softplus", input);
+    }
+};
+
 class MulCastSubgraph : public Subgraph
 {
 public:
@@ -734,6 +763,8 @@ void simplifySubgraphs(opencv_onnx::GraphProto& net)
```

Review comment:
I think that simplifier should just match different nodes. You can make a small onnx model of both cases, remove the second class and test if it's working(by setting the break point inside Softplus's forward for example).
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22311: DNN: add another two Mish activation to onnx_graph_simplifier
**Review Line:** 561

**Code Changes:**
```diff
+        int addVal = addNodeToMatch("");
+        int add = addNodeToMatch("Add", exp, addVal);
+        addNodeToMatch("Log", add);
+        setFusedNode("Softplus", input);
+    }
+};
+
 class MulCastSubgraph : public Subgraph
 {
 public:
@@ -734,6 +763,8 @@ void simplifySubgraphs(opencv_onnx::GraphProto& net)
```

Review comment:
Hm, actually it makes sense - the operation is not required to be commutative. You could use CRTP to statically parametrise the order, but I don't think the complexity is worth it in this case. The second solution is to add logic of reordering into subgraph matching, but it'll take a while. I think this works for now.
**File:** modules/objdetect/misc/python/test/test_qrcode_detect.py
**Change Type:** modified
**Context:** PR #22358: QRcode, change INTER_LINEAR to INTER_LINEAR_EXACT
**Review Line:** 51

**Code Changes:**
```diff
+        self.assertTrue("TWO STEPS FORWARD" in decoded_data)
+        self.assertTrue("EXTRA" in decoded_data)
+        self.assertTrue("SKIP" in decoded_data)
+        self.assertTrue("STEP FORWARD" in decoded_data)
+        self.assertTrue("STEP BACK" in decoded_data)
+        self.assertTrue("QUESTION" in decoded_data)
         self.assertEqual(points.shape, (6, 4, 2))
```

Review comment:
Why? The change looks very suspicious.
**File:** modules/objdetect/misc/python/test/test_qrcode_detect.py
**Change Type:** modified
**Context:** PR #22358: QRcode, change INTER_LINEAR to INTER_LINEAR_EXACT
**Review Line:** 51

**Code Changes:**
```diff
+        self.assertTrue("TWO STEPS FORWARD" in decoded_data)
+        self.assertTrue("EXTRA" in decoded_data)
+        self.assertTrue("SKIP" in decoded_data)
+        self.assertTrue("STEP FORWARD" in decoded_data)
+        self.assertTrue("STEP BACK" in decoded_data)
+        self.assertTrue("QUESTION" in decoded_data)
         self.assertEqual(points.shape, (6, 4, 2))
```

Review comment:
this code to avoids the problem of the order of the found qr codes
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
If the end user decides to import two networks, it'll see only one warning. I think it's okay to spam this on every converted tensor during import.
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
BTW, OpenCV has `CV_LOG_ONCE_WARNING` macro.
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
> raw_data() We have several reports about alignment issues from ARM platforms. E.g. here: #20725 Mat of CV_16F expects 2 bytes alignment.
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
Then it should be one line per model import imo.
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
Can this problem be fixed in another pull request? We need this feature for GSoC projects.
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
https://stackoverflow.com/questions/16548059/how-to-trap-unaligned-memory-access
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
IIRC, we have this check in CMake scripts. Can we use a precomp macro here?
**File:** modules/dnn/test/test_onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -2098,6 +2098,11 @@ TEST_P(Test_ONNX_nets, MobileNet_v2)
     testONNXModels("mobilenetv2", pb, default_l1, default_lInf, true);
 }
 
+TEST_P(Test_ONNX_nets, MobileNet_v2_FP16)
+{
+    testONNXModels("mobilenetv2_fp16", npy, default_l1, default_lInf, true);
+}
+
 TEST_P(Test_ONNX_nets, LResNet100E_IR)
```

Review comment:
unnecessary commit
**File:** modules/dnn/test/test_onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -2098,6 +2098,11 @@ TEST_P(Test_ONNX_nets, MobileNet_v2)
     testONNXModels("mobilenetv2", pb, default_l1, default_lInf, true);
 }
 
+TEST_P(Test_ONNX_nets, MobileNet_v2_FP16)
+{
+    testONNXModels("mobilenetv2_fp16", npy, default_l1, default_lInf, true);
+}
+
 TEST_P(Test_ONNX_nets, LResNet100E_IR)
```

Review comment:
Put this in the PR in opencv_extra?
**File:** modules/dnn/test/test_onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -2098,6 +2098,11 @@ TEST_P(Test_ONNX_nets, MobileNet_v2)
     testONNXModels("mobilenetv2", pb, default_l1, default_lInf, true);
 }
 
+TEST_P(Test_ONNX_nets, MobileNet_v2_FP16)
+{
+    testONNXModels("mobilenetv2_fp16", npy, default_l1, default_lInf, true);
+}
+
 TEST_P(Test_ONNX_nets, LResNet100E_IR)
```

Review comment:
Thx! Fixed, wrong commit.
**File:** modules/dnn/src/onnx/onnx_graph_simplifier.cpp
**Change Type:** modified
**Context:** PR #22337: DNN: load fp16 ONNX model as fp32

**Code Changes:**
```diff
@@ -767,11 +767,67 @@ Mat getMatFromTensor(const opencv_onnx::TensorProto& tensor_proto)
             Mat(sizes, CV_32FC1, val).copyTo(blob);
         }
     }
+    else if (datatype == opencv_onnx::TensorProto_DataType_FLOAT16)
+    {
+        // FIXME, for now, we only load FP16 Tensor as FP32 Mat, full support for FP16 is required in the future.
+        CV_LOG_ONCE_WARNING(NULL, "DNN: load FP16 model as FP32 model, and it takes twice the FP16 RAM requirement.");
+
+        // ONNX saves float 16 data in two format: int32 and raw_data.
```

Review comment:
Please reuse `WORDS_BIGENDIAN` macro (from cvconfig.h)
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
This code wants to get the depth of the current layer based on the node's input. Do we have a better way to get `depth` directly from the layer?
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
Per spec, zeropoint should be of the same shape as scale, which can be either 0-d(per Tensor) or 1-d(per axis), but we don't support the latter: `CV_CheckEQ(scale.total(), 1, "")` should suffice.
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
These are optional, so should be handled just like `bias` below.
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
These are scalars per spec already, but I think we should add this assertion everywhere
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
assertion missing: scalars
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
Welp, layers have constrains on types in the spec, but we don't have the information in the graph which types this layer supports.
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
So, you look for any real input layer and check if we created internal layer `*Int8`? I mean, someone could rename the layer or add a new one that doesn't follow that convention. Maybe we're better off with `layerParams.set("depth", CV_8S)` in each layer, or we could create a set of all integer layers. I think this should be discussed further with the rest of the team.
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
I'm not sure relying on internal names is a good idea. Let's discuss this on Friday, maybe someone will come up with a better solution.
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
So if we insert unsupported at the moment layer(Gather, for example) after integer node, it will set the depth to CV_8S and corrupt the memory at runtime? (reading int8 as float in this case).
**File:** modules/dnn/src/onnx/onnx_importer.cpp
**Change Type:** modified
**Context:** PR #22531: Parsing quantized nodes does not rely on names

**Code Changes:**
```diff
@@ -52,6 +52,13 @@ extern bool DNN_DIAGNOSTICS_RUN;
 
 class ONNXLayerHandler;
 
+template <typename T>
+static T getScaleFromMat(Mat m)
+{
+    CV_Assert(m.total() == 1);
+    return m.at<T>(0);
+}
```

Review comment:
What if we have a set of ONNX layers instead? e.g. in this set we would put `QuantizeLinear`, `DequantizeLinear`, `QLinearConv`, `Transpose`, `Reshape`, `MaxPool`, etc. And check that if we have integer inputs, current layer should be in this set, otherwise we throw an error, what do you think?