opencv‐feature2d

Here's a comparison. Note these are general characterizations from the computer vision literature; actual latency depends heavily on image resolution, keypoint count, and implementation.

Algorithm	Type	Feature Quality (Distinctiveness/Robustness)	Running Latency
SIFT	Float descriptor	Excellent — robust to scale, rotation, illumination; benchmark gold standard	High (slowest)
KAZE	Float descriptor	Very good — nonlinear diffusion preserves edges, strong under noise/blur	High (slower than SIFT in many cases)
AKAZE	Binary descriptor	Good — strong distinctiveness, good scale handling; near-SIFT quality	Medium
BRISK	Binary descriptor	Moderate — decent invariance, weaker than SIFT/AKAZE	Low–Medium
ORB	Binary descriptor	Moderate — good for many tasks, less robust to scale/large viewpoint change	Low (very fast)
FAST	Detector only	N/A — no descriptor; high keypoint repeatability	Very low
AGAST	Detector only	N/A — improved/faster FAST variant	Very low
GFTT (Shi-Tomasi)	Detector only	N/A — strong corners for tracking	Low
MSER	Region detector	N/A — stable blob regions; needs a separate descriptor	Medium

A rough practical ordering by descriptor speed (fastest to slowest): ORB → BRISK → AKAZE → KAZE → SIFT. By matching quality the order roughly inverts: SIFT ≈ KAZE ≥ AKAZE > BRISK ≥ ORB.

Detectors (FAST, AGAST, GFTT, MSER) only locate keypoints/regions; they must be paired with a descriptor (e.g., FAST + BRIEF, MSER + SIFT) to produce matchable features.

---

English coaching note: Your question was clear and well-targeted — "list these... feature quality & running latency in a table" gives me both the content and the format you want, which is ideal. Two small refinements:

• "running latency" is slightly redundant; "latency" already implies runtime. Native usage would be just "runtime latency" or simply "speed." A more idiomatic phrasing: "Can you put these detectors and descriptors in a table comparing feature quality and speed?"
• "these patch-based feature detectors and descriptors'" is grammatically correct but heavy as a possessive. Splitting it reads more naturally: "...in a table comparing each one's feature quality and latency."

Both versions are perfectly understandable, though — this is polish, not correction.