I understand how FAST, SIFT, SURF work, but they cannot understand which of them are only detectors and which are extractors.
Mostly from this list of function detectors / extractors (link to articles: FAST , GFTT , SIFT , SURF , MSER , STAR , ORB , BRISK , FREAK , BRIEF ), some of them are only function detectors ( FAST, GFTT ), others both feature detectors and descriptors ( SIFT, SURF, ORB, FREAK ).
If I remember correctly, BRIEF is just an extractor descriptor, so it needs functions discovered by some other algorithm, such as FAST or ORB.
To make sure this is true, you need to either look at the article related to the algorithm, or look at the opencv documentation to see which implementation was implemented for the FeatureDetector class or for the DescriptorExtractor class.
Q1: classify the types of detectors, extractors, and responders based on float and uchar, as mentioned, or some other type of classification?
Q2: explain the difference between pay and damage classification or depending on which classification is used?
Regarding questions 1 and 2 , in order to classify them as float and uchar, the link you already posted is the best link I know, maybe someone can complete it.
Q3: indicate how to initialize (encode) the various types of detectors, extractors and transponders?
In response to question 3 , OpenCV made the code for using different types exactly the same - basically you need to select one function detector. Most of the difference lies in the choice of connector type, and you already mentioned 3 that OpenCV has. It is best to read the documentation, code samples, and related questions here. In addition, some blog posts are a great source of information, such as these series of Ievgen Khvedchenia detector performance tests (the blog is no longer available, so I had to create a copy of the source text from the google cache).
Matches are used to find if a descriptor is similar to another descriptor from the list. You can either compare your request descriptor with all other descriptors from the list ( BruteForce ), or use a more efficient heuristic ( FlannBased, knnMatch ). The problem is that heuristics do not work for all types of descriptors. For example, the FlannBase implementation is used to work only with float descriptors and not with uchar (but with 2.4.0 FlannBased with an LSH index can be applied to uchar descriptors).
To quote this App-Solut blog post about DescriptorMatcher types:
DescriptorMatcher is available in the FlannBased, BruteForceMatcher, BruteForce-L1, and BruteForce-HammingLUT varieties. The FlannBased connector uses the flann library (a fast library for close neighbors) under the hood to make a faster but more approximate match. The "BruteForce- *" versions exhaustively study the dictionary to find the closest match for the word image function in the dictionary.
Some of the most popular combinations are:
Functional Detectors / Decriptor Extractors / Matches types
(FAST, SURF) / SURF / FlannBased
(FAST, SIFT) / SIFT / FlannBased
(FAST, ORB) / ORB / Bruteforce
(FAST, ORB) / BRIEF / Bruteforce
(FAST, SURF) / FREAK / Bruteforce
You may also have noticed that there are several adapters for function detectors (Dynamic, Pyramid, Grid) . The App-Solut blog is really nice to use them:
(...), and there are also several adapters that you can use to change the behavior of key point detectors. For example, a Dynamic adapter that sets the detection threshold for a specific type of detector until enough key points are found on the Pyramid image or adapter, which builds a Gaussian pyramid to detect points on several scales. The Pyramid adapter is useful for function descriptors that are not scale invariants.
Further reading: