The GThread API is available since more than 11 years with GLib, it is now safe
to assume that it is always available.

throw() -> noexcept

Resolve Swift method name conflicts by adding missing namespace

code clean opencv#25931

Align code and remove redundant CMake code

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake

Add tutorial on using Orbbec 3D cameras (UVC) opencv#25907

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake

Fix cmake macro in `riscv64-clang.toolchain.cmake`.

Add a check for src == dst in ocl warpTransform opencv#25898

As mentioned in opencv#25853, when doing WarpAffine with Mat and UMat respectively, if you force the use of the in-place operation (so that src and dst are passed the same variables), Mat produces the correct results, but UMat produces unexpected results.

Obviously in-place operations are not possible with this transformation. When Mat performs the operation, if dst and src are the same variable, the function inherently makes a copy of src without telling the user. 

https://github.com/opencv/opencv/blob/74b50c7af05c91194469a1f059f971dff00ef889/modules/imgproc/src/imgwarp.cpp#L2831-L2834

So I did the same check in UMat, but I'm not sure if it's appropriate, should we just do a copy operation without telling the user (even if the user thinks he's doing an in-place operation), or should we throw an exception to indicate that we shouldn't pass in two same variables here?

The possible reason for this problem is that there is a create function here, so it gives the developer the false impression that this create function has allocated new memory for dst, however it does not.

https://github.com/opencv/opencv/blob/74b50c7af05c91194469a1f059f971dff00ef889/modules/imgproc/src/imgwarp.cpp#L2607-L2609

Because by the time the check is done here, the function has returned back.

https://github.com/opencv/opencv/blob/74b50c7af05c91194469a1f059f971dff00ef889/modules/core/src/umatrix.cpp#L668-L675

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake

Upgrade RISC-V Vector intrinsic and cleanup the obsolete RVV backend. opencv#25883

This patch upgrade RISC-V Vector intrinsic from `v0.10` to `v0.12`/`v1.0`:
- Update cmake check and options;
- Upgrade RVV implement for Universal Intrinsic;
- Upgrade RVV optimized DNN kernel.
- Cleanup the obsolete RVV backend (`intrin_rvv.hpp`) and compatable header file.

With this patch, RVV backend require Clang 17+ or GCC 14+ (which means `__riscv_v_intrinsic >= 12000`, see https://godbolt.org/z/es7ncETE3)

This patch is test with Clang 17.0.6 (require extra `-DWITH_PNG=OFF` due to ICE), Clang 18.1.8 and GCC 14.1.0 on QEMU and k230 (with `--gtest_filter="*hal_*"`).

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [ ] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake

highgui: Make GThread mandatory with GTK

…ivations_with_v_exp

dnn: optimize activations with v_exp opencv#25881

Merge with opencv/opencv_extra#1191.

This PR optimizes the following activations:

- [x] Swish
- [x] Mish
- [x] Elu
- [x] Celu
- [x] Selu
- [x] HardSwish

### Performance (Updated on 2024-07-18)

#### AmLogic A311D2 (ARM Cortex A73 + A53)

```
Geometric mean (ms)

            Name of Test              activations activations.patch activations.patch
                                                                              vs
                                                                         activations
                                                                          (x-factor)
Celu::Layer_Elementwise::OCV/CPU        115.859          27.930              4.15
Elu::Layer_Elementwise::OCV/CPU          27.846          27.003              1.03
Gelu::Layer_Elementwise::OCV/CPU         0.657           0.602               1.09
HardSwish::Layer_Elementwise::OCV/CPU    31.885          6.781               4.70
Mish::Layer_Elementwise::OCV/CPU         35.729          32.089              1.11
Selu::Layer_Elementwise::OCV/CPU         61.955          27.850              2.22
Swish::Layer_Elementwise::OCV/CPU        30.819          26.688              1.15
```

#### Apple M1

```
Geometric mean (ms)

               Name of Test                activations activations.patch activations.patch
                                                                                   vs
                                                                              activations
                                                                               (x-factor)
Celu::Layer_Elementwise::OCV/CPU              16.184          2.118               7.64
Celu::Layer_Elementwise::OCV/CPU_FP16         16.280          2.123               7.67
Elu::Layer_Elementwise::OCV/CPU               9.123           1.878               4.86
Elu::Layer_Elementwise::OCV/CPU_FP16          9.085           1.897               4.79
Gelu::Layer_Elementwise::OCV/CPU              0.089           0.081               1.11
Gelu::Layer_Elementwise::OCV/CPU_FP16         0.086           0.074               1.17
HardSwish::Layer_Elementwise::OCV/CPU         1.560           1.555               1.00
HardSwish::Layer_Elementwise::OCV/CPU_FP16    1.536           1.523               1.01
Mish::Layer_Elementwise::OCV/CPU              6.077           2.476               2.45
Mish::Layer_Elementwise::OCV/CPU_FP16         5.990           2.496               2.40
Selu::Layer_Elementwise::OCV/CPU              11.351          1.976               5.74
Selu::Layer_Elementwise::OCV/CPU_FP16         11.533          1.985               5.81
Swish::Layer_Elementwise::OCV/CPU             4.687           1.890               2.48
Swish::Layer_Elementwise::OCV/CPU_FP16        4.715           1.873               2.52
```

#### Intel i7-12700K

```
Geometric mean (ms)

            Name of Test              activations activations.patch activations.patch
                                                                    vs
                                                               activations
                                                                (x-factor)
Celu::Layer_Elementwise::OCV/CPU        17.106       3.560         4.81
Elu::Layer_Elementwise::OCV/CPU          5.064       3.478         1.46
Gelu::Layer_Elementwise::OCV/CPU         0.036       0.035         1.04
HardSwish::Layer_Elementwise::OCV/CPU    2.914       2.893         1.01
Mish::Layer_Elementwise::OCV/CPU         3.820       3.529         1.08
Selu::Layer_Elementwise::OCV/CPU        10.799       3.593         3.01
Swish::Layer_Elementwise::OCV/CPU        3.651       3.473         1.05
```

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake

…capsulate_ts

videoio: fix cv::VideoWriter with FFmpeg encapsulation timestamps opencv#25874

Fix opencv#25873 by modifying `cv::VideoWriter` to use provided presentation indices (pts).

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake

…architecture search

HAL for dot product added opencv#25936

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake

Report used HAL to test log and xml

This fix is useless in 4.x and fixes harmless overflows in 5.x
This belongs to 4.x as it is closer to the intended meaning.

Properly check markers when none are provided. opencv#25938

CharucoDetectorImpl::detectBoard finds temporary markers when none are provided but those are discarded when
charucoDetectorImpl::checkBoard is called.

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake

…_arch_with_cmp0104

`cuda`: prevent `CMAKE_CUDA_ARCHITECTURES` default from overiding OpenCV architecture search (issue 25920)

Search in two directions when try to add new quad in addOuterQuad opencv#25807

In ChessBoardDetector::addOuterQuad, previous code try to connect new quad with inner quad, if possible, but only search for one direction. I have made  three test images, one is normal(a.jpg), one lossed an outer quad(b.jpg), and then i flipped it vertically(c.jpg). Only last one fails. I fixed it by check two directions and row/col.

Here is the test code and images:
```
Mat img;
vector<Point2f> corners;
auto size = cv::Size(6, 6);
img = imread("D:/tmp/a.jpg", 0);
std::cout<<cv::findChessboardCorners(img, size, corners)<<"\n";
std::cout << corners.size() << "\n";
img = imread("D:/tmp/b.jpg", 0);
std::cout<<cv::findChessboardCorners(img, size, corners)<<"\n";
std::cout << corners.size() << "\n";
img = imread("D:/tmp/c.jpg", 0);
std::cout<<cv::findChessboardCorners(img, size, corners)<<"\n";
std::cout << corners.size() << "\n";
```
![a](https://github.com/opencv/opencv/assets/92856207/0dc7f5bf-7637-4333-9a9f-ec4ede790027)
a
![b](https://github.com/opencv/opencv/assets/92856207/39793485-ca0c-44c0-b44d-a593d36c1888)
b
![c](https://github.com/opencv/opencv/assets/92856207/2e7789c8-cfa5-438c-9530-2862a8a3741f)
c

Avoid future integer overflow in _OutputArray::create

add getFrameCount() member function to BaseImageDecoder