Repository: opencv
Issue: 3D Reconstruction Task: In video processing tasks, the issue of slow detection speed of Aruco under low light, high resolution, and small target detection conditions.
Labels: feature

### Describe the feature and motivation

    In video processing tasks, we encountered a problem where the detection speed of Aruco was very slow under the conditions described in the title. Through testing under different lighting conditions, we found that while the recognition accuracy of Aruco remained high, the detection speed was significantly slowed down. After analyzing the detection principle of Aruco, I concluded that the main factor affecting the speed was the noise caused by low lighting conditions.

    To address this issue, I believe a fast preprocessing function module can be introduced to process the images being detected, improving Aruco's detection speed. This would help meet the real-time requirements of video processing tasks, while also enhancing robustness for tasks under normal lighting conditions.
    
    Through a series of experiments, I have found some solutions to address the performance issues with speed, and I would like to raise this issue to spark discussion within the community, as well as to improve the current methods.
    
    **Solution 1: AI Denoising** Denoising the image can reduce the noise to some extent and thus speed up detection. However, applying an AI denoise model takes 1-2 seconds, which is still unacceptable in real-time video processing tasks.
    
    **Solution 2: YOLO + Aruco** By training YOLO on a large dataset of Aruco markers, we can still achieve fast detection and recognition in low-light environments. However, this method has a high cost: it requires organizing the dataset, training YOLO, and extracting the four corner coordinates of the quadrilateral through detection. It also requires extensive custom modifications to the original Aruco functions to obtain the ordered sequence of corner coordinates. The detection time is around 100ms per frame. Since the implementation cost of the YOLO method is high and the OpenCV community primarily uses traditional image processing methods for Aruco, we are considering alternative solutions, with this one as a backup.
    
    **Solution 3: Video Tracking Points During video capture** I noticed that Aruco markers have a continuous property, meaning that the position of Aruco in the current frame doesn't move significantly in the next frame. First, Aruco markers are small target detections, which means that most of the other areas in the image are irrelevant, often filled with noise. By leveraging this continuity, we can focus detection on certain areas. The green region represents the detected area in the current frame, and the red region extends outward to form a reference for the next frame. Reducing the area can significantly speed up Aruco code detection. We need to save the positions of different Aruco markers in the previous frame and then define a small region for detection in the next frame, of course with appropriate boundary conditions.
    
    **Solution 4: Canny edge detection algorithm combined with a dilation kernel** Solution 4 is based on improvements made to Solution 3. We found that both solutions focus on detecting areas of interest in the image and discarding most of the irrelevant regions to speed up Aruco detection. However, Solution 3 is relatively complex, involving read/write operations for some Aruco points. Additionally, video processing tasks often require multi-threading, and frames in the sequence might not be processed in the same thread. This requires further modifications to the thread handling code, giving rise to Solution 4.
    
    We found that Aruco markers in images have clear boundary conditions. Based on this, we can use the Canny edge detection algorithm combined with a dilation kernel to expand the area of interest. However, it is important to note that this method works best in simple backgrounds; if the environment is too complex, the results may not be as good as those achieved with a YOLO-trained model. This is a key point I hope to discuss, as this acceleration method works well only in scenarios with less complex backgrounds. It meets the needs of my current project, but I invite the community to discuss and improve upon this approach.

### Additional context


![图片1](https://github.com/user-attachments/assets/4290e1d4-44fd-42af-8185-fe2dddb93acc)
![图片2](https://github.com/user-attachments/assets/593f22b1-ebff-4d2e-bbd6-5ebb18141f95)

![2](https://github.com/user-attachments/assets/f19a5ef2-de95-4460-b2e6-36e28b4ed081)
![edge_guided_smoothing_no_salt_pepper](https://github.com/user-attachments/assets/68571434-1f66-4722-a227-426b8d7c2b12)