Technical Review: OpenCV for Visual Feature Extraction

OpenCV 5 Visual Features: Technical Review

Review date:June 1, 2026

Scope:OpenCV 5.0.0, the continuing OpenCV 4.x line through 4.14.0, the OpenCV 4-to-5 migration guide, current feature and geometry APIs, and the primary papers behind SIFT, ORB, ALIKED, DISK, and LightGlue.

Executive assessment

The original review begins from the right premise:“visual feature” is not one data type or one algorithm. In OpenCV, the term may refer to a gradient, edge map, corner, blob, keypoint, local descriptor, window descriptor, correspondence, or learned representation. These objects solve different problems and discard different information.

OpenCV is strongest when treated as acomposable visual-measurement toolkitrather than as a single feature extractor. A typical local-feature system contains at least four separate decisions:

1.how the image is prepared;

2.which locations or regions are measured;

3.how local appearance is encoded;

4.how tentative matches are converted into geometrically credible correspondences.

OpenCV 5 makes this breadth more explicit. Version 5.0.0 was released on June 6, 2026. The formerfeatures2dmodule was renamedfeatures, the C++ umbrella header changed to<opencv2/features.hpp>, and the module now includes learned local-feature classes such as ALIKED and DISK alongside classical algorithms such as SIFT, ORB, FAST, GFTT, MSER, and blob detectors. Function and class names are largely unchanged, and Python code usually does not require the same import migration as C++ or Java.[^1][^2]

That common framework should not be mistaken for full interchangeability. FAST and GFTT normally detect locations but do not describe them. SIFT can emit 128-dimensionalCV_32For quantizedCV_8Udescriptors, while ORB emits 32-byte binary descriptors. ALIKED and DISK require external neural-network model files and specific preprocessing assumptions. LightGlue requires keypoint coordinates and image context in addition to descriptors. Every substitution can therefore change descriptor type, dimension, distance function, computational requirements, model provenance, and geometric behavior.[^3][^4][^5][^6]

The final conclusion is more conditional than the original scorecard suggested:

>OpenCV is an exceptionally broad and mature framework for constructing visual-feature pipelines. The scientific validity of a result, however, depends on the complete chain—preprocessing, detector, descriptor, matcher, filter, geometric model, thresholds, acceleration backend, and evaluation data—not merely on the fact that OpenCV was used.

1. What OpenCV means by a feature

A useful review should keep several levels separate.

This hierarchy matters because the wordfeatureis often used as though each level were interchangeable. An edge map is not a SIFT descriptor. A keypoint is not a match. A low descriptor distance is not proof that two pixels arise from the same physical point.

OpenCV’sFeature2Dbase class provides shared operations such asdetect,compute,detectAndCompute,descriptorSize,descriptorType, anddefaultNorm. It is an API contract for a family of algorithms, not a guarantee that every class implements every operation with equivalent semantics.compute, for example, may remove keypoints for which a descriptor cannot be formed, while SIFT may duplicate a keypoint when several dominant orientations are retained.[^3]

A robust application should inspect the actual properties of the selected implementation rather than hard-code assumptions:

size = feature.descriptorSize()

dtype = feature.descriptorType()

norm = feature.defaultNorm()

The same principle applies to learned models: record the model file, checksum, input geometry, DNN backend, and target device.

2. OpenCV 5 and the continuing 4.x line

OpenCV 5.0.0 is a major architectural release, not simply a larger version number. It requires C++17, removes the legacy C API, reorganizes several modules, expands the DNN engine, and makes USAC the default robust-estimation framework in relevant APIs. The feature module was renamed fromfeatures2dtofeaturesbecause its scope now includes feature vectors produced by modern deep networks.[^1][^2]

The migration is language-specific:

// OpenCV 4.x

#include<opencv2/features2d.hpp>

// OpenCV 5.x

#include<opencv2/features.hpp>

The compatibility headerfeatures2d.hppstill includesfeatures.hpp, but new C++ code should use the new header. Python class names such ascv.SIFT_create()andcv.ORB_create()remain familiar.[^2]

OpenCV 4.x also remains active. Version 4.14.0 was released on July 19, 2026, after OpenCV 5.0.0. Its changelog includes feature-related optimizations and fixes, including OpenCL acceleration for BFMatcher cross-check, OpenCL support for AKAZE, and RISC-V RVV optimization for FAST.[^7][^8]These 4.14 changes should not be silently attributed to every OpenCV 5.0 binary. A reproducible benchmark must identify the exact branch, version, build configuration, and optional modules.

A second migration issue concerns object detection. The classical HOG pedestrian detector and Haar cascade infrastructure moved to the contrib-sidexobjdetectmodule in OpenCV 5. This changes package and build requirements; it does not make HOG mathematically obsolete.[^2]

3. Low-level structure: gradients, edges, corners, regions, and lines

Gradients

Gradients remain the foundation of many classical representations. Sobel and Scharr estimate local intensity derivatives. Gradient magnitude and orientation then support edge detection, Harris and Shi–Tomasi corner measures, HOG, SIFT, and many other descriptors.

Gradients remove sensitivity to an additive brightness constant in the idealized relation

\[

I'(x,y)=I(x,y)+c \quad\Rightarrow\quad \nabla I'=\nabla I,

\]

but they are not generally illumination invariant. Contrast changes, clipping, shadows, gamma transforms, blur, demosaicing, denoising, and local lighting changes can all alter the derivative field.

Canny edges

The original review reduced Canny to “gradient, magnitude threshold, non-maximum suppression, connected structure.” The standard algorithm is more specific:

1.suppress noise, commonly with Gaussian smoothing;

2.compute gradient magnitude and direction;

3.apply non-maximum suppression;

4.applytwo-threshold hysteresis, retaining intermediate responses only when connected to strong edges.[^9]

Canny returns an edge map. It does not create a rotation- or scale-normalized local descriptor, and its output is highly dependent on smoothing, aperture, threshold values, and the choice between L1 and L2 gradient magnitude.

Harris, Shi–Tomasi, and FAST

Harris and Shi–Tomasi derive corner strength from the second-moment matrix of local gradients. Shi–Tomasi changes the scoring rule from the Harris determinant-and-trace expression to the minimum eigenvalue, which was proposed for selecting points suitable for tracking.

FAST uses intensity comparisons around a circle and is optimized for rapid corner detection. It normally provides keypoint locations and responses rather than a complete appearance descriptor. Pairing FAST with a descriptor is therefore a separate design choice.

OpenCV keypoints carry more than(x, y): they can include scale/diameter, orientation, detector response, octave, and a class identifier. The meaning and availability of those fields depend on the detector.[^10]

MSER and blob detection

MSER detects regions that remain comparatively stable as an intensity threshold changes. It is useful when region stability, rather than one local derivative maximum, is the desired primitive.

SimpleBlobDetectorapplies a series of thresholds, finds connected components, groups centers across threshold levels, and can filter candidates by color, area, circularity, inertia ratio, and convexity. Its defaults are tuned toward dark circular blobs, so using it for bright, elongated, or irregular structures requires explicit parameter changes.[^11]

Lines and HOG

Hough transforms convert edge evidence into line or circle hypotheses. They are structural estimators rather than keypoint descriptors.

HOG aggregates gradient-orientation histograms over cells and normalizes them over blocks. It is usually a dense window representation rather than a sparse point descriptor. In OpenCV 5, the classicalHOGDescriptorobject-detection path resides in the contrib-sidexobjdetectmodule.[^2]The move reflects product organization and the growth of DNN-based detectors; it is not evidence that HOG is universally inferior on every dataset, processor, or deployment constraint.

4. SIFT: exact OpenCV semantics

SIFT remains a strong classical choice when scale change, rotation, localization, and local distinctiveness matter. Its main stages are:

-Difference-of-Gaussian scale-space extrema;

-subpixel keypoint localization and edge-response rejection;

-dominant orientation assignment;

-local gradient-orientation histograms;

-descriptor normalization and clipping.

The invariances areapproximate robustness properties, not mathematical guarantees. Strong affine viewpoint change, motion blur, repeated texture, weak texture, saturation, severe compression, or a poor scale-space sampling regime can still degrade repeatability and distinctiveness.[^12]

The original review called the SIFT descriptor simply “floating-point.” In current OpenCV 5, SIFT supports bothCV_32FandCV_8Udescriptor output. The default is the familiar floating-point form; the 8-bit form is a quantized representation of the same 128-dimensional SIFT descriptor, not a binary descriptor. Its natural comparison remains L2 distance rather than Hamming distance.[^4]

Important SIFT parameters include:

-maximum retained features;

-octave layers;

-contrast threshold;

-edge threshold;

-initial Gaussian sigma;

-descriptor type;

-precise-upscale option.

OpenCV documents an easily missed detail: the supplied contrast threshold is divided by the number of octave layers when filtering is applied. Reproducing a paper therefore requires the actual constructor arguments, not just the word “SIFT.”[^4]

The historical patent issue should also be stated accurately. The relevant US patent expired in March 2020, and OpenCV 4.4 moved SIFT into the main repository. Current OpenCV 5 exposescv::SIFTin the principal features module.[^13][^14]Older tutorials or contrib pages can still contain historical “non-free” wording, so contemporary API and license information should take precedence.

5. ORB: efficient binary local features

ORB combines an image pyramid, FAST-derived keypoints, Harris or FAST response ranking, intensity-centroid orientation, and rotated BRIEF-style binary tests. Its standard descriptor is 32 bytes, or 256 bits.[^15][^16]

Current defaults include approximately:

-500 retained features;

-pyramid scale factor 1.2;

-eight pyramid levels;

-WTA_K=2;

-Harris response scoring;

-31-pixel edge and patch sizes;

-FAST threshold 20.[^15]

WithWTA_K=2, Hamming distance is the expected matching metric. WhenWTA_Kis 3 or 4, each element encodes a multi-way comparison using two bits, and OpenCV recommendsNORM_HAMMING2.[^15][^17]

ORB’s value is operational: compact descriptors, rapid matching, modest storage, and availability in both CPU and CUDA-specific implementations. It should not be described as uniformly “better for real time” without measuring the complete pipeline. On some systems, image transfer to a GPU, feature count, matcher design, geometric verification, or a learned model’s hardware acceleration may dominate the extractor itself.

Binary compression also has a cost. ORB can be less distinctive than richer descriptors under severe viewpoint or illumination change, repeated texture, blur, and low-detail scenes. Those are empirical tendencies, not universal failure rules.

6. Affine simulation and other classical extensions

OpenCV’sAffineFeaturewraps anotherFeature2Dimplementation and simulates viewpoint tilts and rotations in the style of ASIFT. It can improve robustness to affine viewpoint change, but it does so by running the backend over multiple synthesized views, increasing computation and often producing many duplicate or near-duplicate detections.[^18]

This is a useful example of why the detector name is not enough. “SIFT” and “AffineFeature(SIFT)” can have very different runtime, feature count, spatial distribution, and repeatability.

The larger OpenCV and opencv_contrib ecosystems also include AKAZE, BRISK, KAZE, FREAK, DAISY, BEBLID, and other detector/descriptor combinations. A technical review should avoid implying that SIFT and ORB exhaust OpenCV’s classical feature space.

7. Learned local features in OpenCV 5

OpenCV 5’s learned-feature integration is strategically important, but its maturity and deployment model differ from the classical stack.

ALIKED

OpenCV’s ALIKED class is a CNN-based detector and descriptor extractor. It produces subpixel keypoints and 128-dimensional floating-point descriptors. It expects RGB model input, while the OpenCV wrapper can convert ordinary BGR images internally. Construction requires a path to an external ONNX model.[^5]ALIKED’s published design uses deformable descriptor sampling to improve local geometric representation while keeping extraction relatively lightweight.[^19]

DISK

DISK is also exposed through theFeature2Dinterface. The OpenCV wrapper produces 128-dimensional L2-normalized descriptors through a fully convolutional network and requires an ONNX model path or model buffer. The documented default network input is 1024×1024; overridden dimensions must be positive multiples of 16 because of the network’s downsampling structure.[^6]The original DISK method was trained end-to-end with a policy-gradient objective intended to reward correct matches.[^20]

LightGlue

LightGlue is a learned matcher, not a descriptor-distance replacement that can be attached blindly to any matrix. OpenCV’sLightGlueMatcherconsumes descriptorsandkeypoint coordinates; image dimensions can also be supplied. The context must be set throughsetPairInfo()before matching unless it is obtained automatically from compatible in-process ALIKED objects. The matcher itself is created from an external ONNX model and returns confidence-based pairings.[^21]

The original LightGlue model uses attention and adaptive pruning or early stopping so that easier image pairs can require less computation.[^22]Model variants are trained for particular feature families. Descriptor dimension alone does not establish compatibility.

Practical consequence

The shared OpenCV interface is valuable for orchestration and experimentation, but learned components add provenance requirements absent from a purely handcrafted algorithm:

-model name and exact weights;

-weight hash and license;

-image preprocessing and resize policy;

-DNN backend and target;

-input precision;

-score and keypoint limits;

-matcher variant;

-hardware and runtime versions.

A result labeled only “OpenCV ALIKED” or “OpenCV DISK” is not fully specified.

8. Descriptor matching

Match the metric to the representation

The safest default is to query the feature implementation’sdefaultNorm()rather than infer the metric from a familiar name.

Brute force and approximate search

BFMatchercalculates descriptor distances against the supplied candidate set. It is exact with respect to that set and metric, but its cost grows with the number of query and train descriptors.

FlannBasedMatcherremains available in the OpenCV 5 feature framework. Approximate-nearest-neighbor behavior depends on index type and search parameters. OpenCV 5 also introduces an Annoy-basedANNIndexin its multidimensional-search infrastructure. Approximate search changes the speed–recall tradeoff and must be evaluated as part of the pipeline rather than treated as a transparent implementation detail.[^23]

Cross-check and ratio filtering

Cross-check retains a match when the query’s best candidate is also the candidate’s best query. OpenCV describes it as an alternative consistency filter for one-nearest-neighbor matching.[^17]It is not a substitute for geometry, and it is not automatically compatible with everyk-nearest-neighbour workflow.

The nearest-neighbour ratio compares the best distance with the second-best. It is useful only when two candidates are available, and the threshold is a heuristic whose optimum depends on descriptor type, scene structure, database size, and downstream geometric model. The commonly repeated 0.7 or 0.75 values are starting points, not physical constants.[^12][^17]

Cross-check and ratio filtering answer different questions. Combining them can increase precision but also discard valid asymmetric or repetitive matches. Their interaction should be measured rather than assumed.

Descriptor distance is not correspondence truth

Repeated windows, road markings, leaves, brick patterns, or similar corners can produce excellent descriptor scores at physically incorrect locations. A match should therefore be treated as a hypothesis until it survives an appropriate geometric test.

9. Geometric verification

The geometry must match the scene and the scientific question.

-Homography:suitable for points on one plane, or for images related mainly by pure camera rotation. It is not a general model for arbitrary non-planar scenes with translation and parallax.[^24]

-Fundamental matrix:represents uncalibrated two-view epipolar geometry.

-Essential matrix:represents calibrated two-view geometry and depends on camera intrinsics.

-Affine or similarity transform:useful when the scene or imaging process supports those restricted transformation classes.

-PnP:estimates pose from 3D-to-2D correspondences; it cannot be applied to two arbitrary 2D feature sets without a 3D reference.[^25]

RANSAC and USAC attempt to estimate a model despite outliers. OpenCV’s USAC framework provides multiple sampling, scoring, local-optimization, degeneracy, and error-metric choices. Homography, fundamental-matrix, and essential-matrix estimation do not use the same residual definition.[^26]

Robust estimation does not repair a wrong model. A homography can reject correct points on a non-planar scene or select a misleading dominant plane. A large inlier count can also result from repeated structure, weak thresholds, degeneracy, or a biased spatial distribution.

A sound report should include:

-model type;

-robust estimator and method variant;

-residual definition;

-inlier threshold and units;

-confidence and iteration limits;

-degeneracy checks;

-inlier count and spatial coverage;

-independent downstream error, such as pose or reprojection accuracy.

10. Performance and acceleration

OpenCV’s feature stack benefits from vectorized CPU kernels, threading, OpenCL paths, hardware abstraction layers, and algorithm-specific CUDA modules. The project’s current documentation describes acceleration across SIMD, CUDA, OpenCL, and Vulkan, but coverage is not uniform.[^1]

CUDA feature classes live in the optional contrib-sidecudafeatures2dmodule.cv::cuda::ORBandcv::cuda::FastFeatureDetector, for example, expose GPU-specific and asynchronous APIs; they are separate classes rather than a universal switch that moves everyFeature2Dobject to the GPU.[^27][^28]

A fair acceleration benchmark must include:

-image upload and result download;

-model loading and warm-up;

-pinned or pageable memory;

-asynchronous stream use;

-feature count and image size;

-matching and geometric verification;

-CPU and GPU model;

-build flags and optional libraries;

-cold and steady-state timing.

For small images or isolated pairs, transfer and setup can dominate the GPU kernel. For video streams, batching or persistent device data can make acceleration much more favorable.

Branch-specific optimizations also matter. OpenCV 4.14’s OpenCL BFMatcher and AKAZE changes are evidence of continuing engineering work in the 4.x line, not proof that every OpenCV 5.0 package has identical kernels.[^8]

11. Classical and learned features are complementary

The original review sometimes framed classical and learned methods as successive generations. A better comparison is task-specific.

Classical features offer:

-transparent construction;

-no learned weight file;

-modest deployment requirements;

-stable CPU behavior;

-inspectable parameters;

-strong subpixel and geometric workflows;

-easier controlled ablation.

Learned features can offer:

-greater robustness to appearance and viewpoint changes represented in training;

-task-adapted detection and description;

-higher match recall on difficult benchmarks;

-learned match confidence and contextual reasoning.

Learned methods also add:

-domain-shift risk;

-model-license and provenance requirements;

-backend and precision dependence;

-weight-download and supply-chain concerns;

-larger compute and memory requirements;

-potentially weaker interpretability.

Hybrid systems are often sensible. A learned detector/descriptor can propose correspondences; classical geometry can verify them; camera-calibration tools can convert inliers into physical pose estimates. Conversely, a classical SIFT or ORB pipeline may be the better scientific baseline when interpretability, CPU deployment, deterministic debugging, or limited data are central.

12. Validation, reproducibility, and reporting

Evaluate the complete pipeline

Detector repeatability and descriptor matching are useful intermediate metrics, but the final benchmark should follow the intended application.

For image matching or registration, report:

-keypoint count and spatial distribution;

-repeatability under known transforms;

-matching precision and recall;

-mean matching accuracy;

-inlier count and inlier ratio;

-geometric coverage;

-homography, pose, or reprojection error;

-catastrophic failure rate;

-runtime, memory, and storage.

For retrieval, report recall at K, mean reciprocal rank, failure or rejection behavior, and domain-specific relevance—not only descriptor distance.

For tracking or SLAM, report trajectory or pose error, track length, relocalization, robustness to blur and exposure change, and real-time latency distribution.

The benchmark should vary the transformations that matter: scale, rotation, affine viewpoint, illumination, blur, compression, occlusion, repeated texture, textureless regions, and sensor changes. A descriptor that succeeds on one homography dataset may fail in a low-light endoscope, aerial image, microscope, industrial camera, or mobile-video setting.

Reproducibility checklist

A complete methods record should preserve:

-OpenCV version, Git commit, and build information;

-4.x versus 5.x branch;

-core versus contrib modules;

-language binding and compiler/runtime versions;

-CPU/GPU architecture and enabled backends;

-image decoding, orientation handling, color conversion, resize, crop, blur, normalization, and contrast processing;

-detector name and every constructor parameter;

-descriptor type, dimension, normalization, and model weights;

-keypoint cap and selection rule;

-matcher, norm, approximate-index settings, cross-check, ratio, and score thresholds;

-geometric model, robust estimator, residual threshold, confidence, and iterations;

-random seeds where applicable;

-input hashes and benchmark splits;

-output precision and storage format.

“Classical” should not be used as a synonym for bit-for-bit deterministic across builds. SIMD implementations, OpenCL/CUDA paths, floating-point order, parallelism, version changes, and robust-sampling configuration can alter outputs. OpenCV documents deterministic behavior for its current USAC solvers given the same points, parameters, and state, but changing the state or surrounding pipeline changes the result.[^26]

Licensing

OpenCV 4.5.0 and later, including OpenCV 5, use the Apache License 2.0; OpenCV 4.4.0 and earlier used the three-clause BSD license.[^29]External ONNX weights, datasets, codecs, and optional third-party packages can have separate licenses. OpenCV’s license does not automatically grant rights to every downloaded model or data source used by an application.

Overall conclusion

OpenCV’s feature architecture remains highly relevant because it exposes the decisions that convert pixels into evidence:

pixels

-> derivatives and regions

-> keypoints

-> descriptors

-> tentative matches

-> robust geometry

-> application-level measurement

Each arrow is an information bottleneck and a modeling choice. SIFT prioritizes scale, orientation, and structured local gradients. ORB prioritizes speed, storage, and binary comparison. HOG prioritizes distributions of local edge orientation over exact pixels. MSER prioritizes region stability. ALIKED and DISK allow training data to shape local representation. LightGlue allows context to shape matching.

OpenCV’s value lies in making these components accessible within one mature ecosystem. Its breadth does not remove the need to justify the representation. A technically correct pipeline is not the one with the most advanced descriptor; it is the one whose invariances, matching rule, geometry, resource use, and validation procedure fit the actual imaging problem.

References

[^1]: OpenCV, “OpenCV 5.0 documentation,” current 5.0 overview and module reference: https://docs.opencv.org/5.0/

[^2]: OpenCV, “OpenCV 4 to 5 migration,” current migration guide: https://github.com/opencv/opencv/wiki/OpenCV-4-to-5-migration

[^3]: OpenCV,cv::Feature2DAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1Feature2D.html

[^4]: OpenCV,cv::SIFTAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1SIFT.html

[^5]: OpenCV,cv::ALIKEDAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1ALIKED.html

[^6]: OpenCV,cv::DISKAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1DISK.html

[^7]: OpenCV GitHub releases, OpenCV 5.0.0 and 4.14.0: https://github.com/opencv/opencv/releases

[^8]: OpenCV, “OpenCV Change Logs,” version 4.14.0: https://github.com/opencv/opencv/wiki/OpenCV-Change-Logs#version4140

[^9]: OpenCV, “Canny Edge Detector”: https://docs.opencv.org/5.0/tutorials/imgproc/imgtrans/canny_detector/canny_detector.html

[^10]: OpenCV,cv::KeyPointin “Basic structures”: https://docs.opencv.org/5.0/main_modules/core_basic.html

[^11]: OpenCV,cv::SimpleBlobDetectorAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1SimpleBlobDetector.html

[^12]: D. G. Lowe, “Distinctive Image Features from Scale-Invariant Keypoints,”International Journal of Computer Vision60, 91–110 (2004): https://doi.org/10.1023/B:VISI.0000029664.99615.94

[^13]: OpenCV, “OpenCV 4.4.0,” noting SIFT’s move to the main repository after patent expiration: https://opencv.org/opencv-4-4-0/

[^14]: OpenCV SIFT source notice, patent expiration: https://github.com/opencv/opencv/blob/4.x/modules/features2d/src/sift.dispatch.cpp

[^15]: OpenCV,cv::ORBAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1ORB.html

[^16]: E. Rublee et al., “ORB: An efficient alternative to SIFT or SURF,” ICCV 2011: https://doi.org/10.1109/ICCV.2011.6126544

[^17]: OpenCV, “Feature Matching”: https://docs.opencv.org/5.0/py_tutorials/py_features/py_matcher/py_matcher.html

[^18]: OpenCV,cv::AffineFeatureAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1AffineFeature.html

[^19]: X. Zhao et al., “ALIKED: A Lighter Keypoint and Descriptor Extraction Network via Deformable Transformation”: https://arxiv.org/abs/2304.03608

[^20]: M. J. Tyszkiewicz, P. Fua, and E. Trulls, “DISK: Learning local features with policy gradient”: https://arxiv.org/abs/2006.13566

[^21]: OpenCV,cv::LightGlueMatcherAPI: https://docs.opencv.org/5.0/main_modules/classcv_1_1LightGlueMatcher.html

[^22]: P. Lindenberger, P.-E. Sarlin, and M. Pollefeys, “LightGlue: Local Feature Matching at Light Speed”: https://arxiv.org/abs/2306.13643

[^23]: OpenCV, “Descriptor Matchers”: https://docs.opencv.org/5.0/main_modules/features_match.html

[^24]: OpenCV, “Basic concepts of the homography explained with code”: https://docs.opencv.org/5.0/tutorials/features/homography/homography.html

[^25]: OpenCV, “Real Time pose estimation of a textured object”: https://docs.opencv.org/5.0/tutorials/calib3d/real_time_pose/real_time_pose.html

[^26]: OpenCV, “USAC: Improvement of Random Sample Consensus in OpenCV”: https://docs.opencv.org/5.0/tutorials/calib3d/usac.html

[^27]: OpenCV,cv::cuda::ORBAPI: https://docs.opencv.org/5.0/extra_modules/classcv_1_1cuda_1_1ORB.html

[^28]: OpenCV, CUDA feature-detection and description module: https://docs.opencv.org/5.0/extra_modules/cudafeatures2d.html

[^29]: OpenCV license by version: https://opencv.org/license/