爲什麼opencv FREAK提取器刪除這麼多關鍵點，具體使用ORB檢測器

我正在使用OpenCV 2.4.3 C++接口來查找兩個圖像之間的匹配點。第一次嘗試是使用SURF。唯一的問題是消耗時間，所以我嘗試了新的FREAK提取器。使用SURF進行檢測並使用FREAK進行描述，我意識到FREAK將關鍵點的數量減少到檢測到的幾乎一半，並且所得到的匹配不夠。這就是我爲什麼試圖快速獲得更多關鍵點的原因。結果：爲什麼opencv FREAK提取器刪除這麼多關鍵點，具體使用ORB檢測器

SURF檢測器，SURF提取器，BFMatcher交叉檢查true，RANSAC：70個關鍵點第一個圖像，50個關鍵點第二個圖像，200ms。 250毫秒。爲15ms。爲15ms。
SURF檢測器，提取器FREAK，BFMatcher交叉檢查爲真，RANSAC：39點的關鍵點的第一圖像，關鍵點30第二圖像（FREAK後），200毫秒，50毫秒。，0ms，0ms。結果是很少有很好的配對。
FAST檢測器，提取器FREAK，BFMatcher交叉檢查真，RANSAC：120點的關鍵點，關鍵點90，（69和FREAK後48個關鍵點），10毫秒，450毫秒，15毫秒，10毫秒。

之後，我使用ORBFeatureDetector，它獲得的關鍵點數量與FAST相同，但是在FREAK提取器之後，每個圖像的結果關鍵點爲0。難道我做錯了什麼？ ORB關鍵點與從FAST獲得的關鍵點不同？也許我可以爲此打開另一個問題，但我有最後一個問題。爲了獲得與使用SURF的第一個實驗相同的結果，檢測器/提取器的最佳組合是什麼？但是減少處理時間？因爲當我獲得更多關鍵點時，雖然我使用FREAK，但提取器部件也更耗時。

來源

2013-01-21 min.yong.yoon

我喜歡用BRREF檢測器和FREAK描述符。它工作得很好。 –

FREAK刪除點，如果它不能產生一個描述它，很多時候，這發生在圖像的邊界，如果它掉下來的邊界圖像的它不能產生一個描述符。我在提取之前應用ROI來避免此問題。

我也FREAK使用快速結合，我得到的最好的結果，但我仍然有減少提取時間，這是太高了我的問題。

來源

2013-02-06 12:25:57

但是在某些情況下，關鍵點的數量從800減少到84。邊界不是太多嗎？ –

它取決於與patternScale參數相關的關鍵點大小。但是，這是相當多的。 –

Pfff。 PatternScale。我無法理解這個FREAK描述符，也沒有獲得任何好的結果。謝謝Jav –

FAST只是一個關鍵點檢測器（無描述符）。如果你結合FAST和用於描述（多尺度）BRIEF，你將得到ORB。

來源

2013-01-26 14:52:44 user2011909

也許我沒有解釋清楚。問題在於，在檢測關鍵點之後，我嘗試使用FREAK進行描述，但是此描述符減少了描述之後檢測到的關鍵點的數量。特別是當我使用ORB時，描述後得到的關鍵點爲0.我注意到在FAST和ORB之後調試結果關鍵點的一點是，使用ORB時，每個關鍵點上的響應都是非常小的浮點值。 –

請給我們展示一些代碼片段。對我來說，它完美的作品。 – user2011909

我無法重現我的問題。 –

實際上，您使用了參數cross check = true。這也是你的很多觀點被淘汰的原因。這個參數如果是真的，從計算角度看是昂貴的。它用於避免在匹配過程中不完全匹配的描述符對。

如果有兩組描述符D1和D2，那麼，這個參數只允許對那些在D1-通常匹配> D2和D2-> D1匹配的方向。

那麼，這一切都取決於你的應用程序，也許你並不需要這麼多的匹配精度...

最好的問候。

亞歷

來源

2013-12-02 20:57:59 Alex

我確實需要精確度，這就是我使用交叉檢查的原因。不管怎麼說，還是要謝謝你。 –

從拆除的邊界點

除此之外，作爲Jav_Rock表明，點的巨大（不一致？）下降真的取決於你存儲在關鍵點的尺寸參數。即使將scaleNormalized設置爲false，size-parameter的浮點值接近於零，FREAK也會放棄此keyPoint。（但我似乎無法弄清楚爲什麼，因爲keyPoint的大小參數僅在scaleNormalized爲真時使用：source）

所以一定要將大小參數設置爲大於零的值（如一個），如果你沒有使用scaleNormalization。
並將其作爲單位'像素大小'進行插值（當使用scaleNormalization時）。
Btw。最小關鍵點大小爲7×default。

希望這有助於...

來源

2014-03-24 11:07:38 Michael

爲什麼opencv FREAK提取器刪除這麼多關鍵點，具體使用ORB檢測器

回答

相關問題