I get a segmentation fault almost every time I use the SIFT method, thus I use SURF instead. I understand your remarks are valid for SURF as well. Thanks
On Tue, Sep 1, 2015 at 10:09 AM, Julien Michel <[email protected]> wrote: > Hi again, > > Well, you really need to dig into sift/surf methods to answer properly > (see [1] for instance). > > To make it short : > - The standard sift matching using the ratios will try to match all the > keypoints and is more general, as sift matching is invariant to rotation, > scaling ... You could match two images with totally different orientations, > it will still work. The filtering by precision is a posteriori step based > on the knowledge of the transform we usually have in remote sensing. > - The signature has little to do with the radiometry (it is composed of > several histograms of gradient orientation). > > Regards, > > Julien > > [1] https://en.wikipedia.org/wiki/Scale-invariant_feature_transform > > Le 01/09/2015 09:37, Agustin Lobo a écrit : > > Thanks for the explanation. This kind of background is essential to > understand the methods and thus use them right. > Just to fully clarify, for a given keypoint in image1, is the ratio of > "the distance to the closest to the distance to the second closest" computed > to all keypoints of image 2 or just to those within a radius equal to > precision only? If the ratio is computed to all keypoints of image 2 we > could often have > points with similar radiometry, thus would get a high ratio and > erroneously discard a correct matching. While the probability of having a > non-homologous point with similar radiometry within the radius of precision > would be low and thus the erroneous rejection would be rare. > > Also, why is "the signature is a 128 dimension vector" ? Are you using a > window instead of the actual pixel of the keypoint? > > Agus > > > On Mon, Aug 31, 2015 at 3:12 PM, Julien Michel <[email protected]> > wrote: > >> Le 31/08/2015 14:29, Agustin Lobo a écrit : >> >> Actually, I do not quite understand: >> Is mfilter stating whether homologous points are filtered according to >> the value >> of "precision"? >> >> yes >> >> What do you mean by " padded according to the user defined *precision*.? >> >> >> I mean that in geobins mode, we consider square tiles in reference image >> and predict the location of the same tile on the secondary image. We take a >> slightly larger region on the secondary image, to account for sensor model >> precision (given by parameter "precision"). The idea is the following : the >> naive matching cost is O(n1xn2), where n1 and n2 are the number of >> keypoints found in each image. Therefore if you try to match large images, >> it will take forever ... But if you divide your reference image in bins, >> and predict roughly where the bin is in the second image, you only match a >> few point at a time, and therefore gain speed (and robustness, since it >> will constrain the range within which false matches occur). >> >> No padding is done in full mode (obviously), which is the one you use. >> >> What is threshold? Is it a radiometric distance or an spatial distance? >> >> >> Threshold is used during matching. Each keypoint has a signature, and the >> matching algorithm works as follows : >> - Euclidean distance is computed between the signatures of each keypoint >> of the reference image and each keypoint of the secondary image (hence the >> O(n1xn2) cost). >> - A naive matching approach would consider that the correct match has the >> minimum distance >> - However, this does not allow to discard matches (each point will have a >> match). But we know that some points should not have matches (because they >> were not detected in both images). We therefore need a way to discard them. >> - We could filter them by considering that the distance should be minimum >> AND bellow a given threshold. However, the signature is a 128 dimension >> vector, and setting such a threshold is not easy, >> - A much more robust way of finding matches is by thresholding the ratio >> from the distance to the closest to the distance to the second closest. In >> fact, the more this ratio is close to 1 the more the match is ambiguous >> (because there exist a second point in about the same distance). The >> thresold parameter is exactly this : the thresold above with the match will >> be discarded by the matching algortihm. >> >> Let me explain. 0.6 is a fair default value and used in many papers / >> implementaiton. By setting threshold to 10, you discard the filter on >> distance ratio (remember the max is 1). Therefore, you have one match for >> each of the detected point in image 1. >> >> You therefore end up with a lot of false matches, and this is where >> mfilter comes : since you are using this option, all matches that are more >> that "precision" away of the the homologous point predicted by sensor >> modelling get discarded (therefore, you discard 11469 points). >> >> To cut it short : with threshold = 0.6, you have a few homologous points, >> but none of them get discarded by the posteriori filtering, probably >> because they are good. >> With threshold = 10, you have a lot of homologous points, but most of >> them get discareded by the a posteriori filter. >> >> >> I have tested and by increasing threshold I get more homologous points >> but also more of them get discarded (all other parameters equal): >> >> $ otbcli_HomologousPointsExtraction -in1 IMG_0062.tif -band1 2 -in2 >> IMG_0062.tif -band2 1 -mode full -precision 50 -mfilter 1 -algorithm surf >> -out IMG_0062homSURF2.txt -threshold 0.6 >> >> 2015 Aug 31 13:58:34 : Application.logger (INFO) Elevation management: >> setting default height above ellipsoid to 0 meters >> 2015 Aug 31 13:58:34 : Application.logger (INFO) Doing update >> 2015 Aug 31 13:58:40 : Application.logger (INFO) Found 15650 surf >> points in image 1. >> 2015 Aug 31 13:58:47 : Application.logger (INFO) Found 15722 surf >> points in image 2. >> 2015 Aug 31 13:59:14 : Application.logger (INFO) Found 740 homologous >> points. >> 2015 Aug 31 13:59:14 : Application.logger (INFO) 0 points discarded >> >> $ otbcli_HomologousPointsExtraction -in1 IMG_0062.tif -band1 2 -in2 >> IMG_0062.tif -band2 1 -mode full -precision 50 -mfilter 1 -algorithm surf >> -out IMG_0062homSURF2.txt -threshold 10 >> >> 2015 Aug 31 13:59:26 : Application.logger (INFO) Elevation management: >> setting default height above ellipsoid to 0 meters >> 2015 Aug 31 13:59:26 : Application.logger (INFO) Doing update >> 2015 Aug 31 13:59:32 : Application.logger (INFO) Found 15650 surf >> points in image 1. >> 2015 Aug 31 13:59:38 : Application.logger (INFO) Found 15722 surf >> points in image 2. >> 2015 Aug 31 14:00:07 : Application.logger (INFO) Found 15650 >> homologous points. >> 2015 Aug 31 14:00:08 : Application.logger (INFO) 11469 points discarded >> >> Thanks! >> Agus >> >> >> On Wed, Jun 10, 2015 at 2:52 PM, Julien Michel <[email protected]> >> wrote: >> >>> Hi Agus, >>> >>> The readthedoc documentation export is experimental (Rashad did this a >>> while ago), and surely has some unsolved issues for now. If you refer to >>> the official documentation here : >>> >>> >>> https://www.orfeo-toolbox.org/CookBook/CookBooksu103.html#x136-6690005.6.7 >>> >>> You will see that the table is right. For instance : >>> >>> precision >>> Float >>> >>> Estimated precision of the colocalisation function (in pixels). >>> >>> mfilter >>> Boolean >>> >>> Filter points according to geographical or sensor based colocalisation >>> >>> Regarding the precision parameter documentation, it is used at several >>> steps of the algorithm, as described in the Detailed Description of the >>> application : >>> >>> "In this mode, the corresponding spatial bin in the second image is >>> estimated using geographical transform or sensor modelling, and is padded >>> according to the user defined *precision*." >>> >>> "Last, in both modes the application can filter matches whose >>> colocalisation in first image exceed this *precision*." >>> >>> But we can update the documentation of the parameter if you think this >>> is not clear enough. >>> >>> Regards, >>> >>> Julien >>> >>> >>> Le 10/06/2015 10:00, Agustin Lobo a écrit : >>> >>> Doc on Homologous Point >>> Extractionhttp://otbcb.readthedocs.org/en/latest/Applications/app_HomologousPointsExtraction.html >>> >>> is incomplete. >>> For example, the only information provided on argument mfilter >>> is that it is a Boolean. No definition, no default value, no example. >>> >>> Instead, the command line help page is more informative: >>> "-mfilter <boolean> Filter points according to >>> geographical or sensor based colocalisation (optional, off by >>> default)" >>> >>> although it is not clear if the user has to write "on" or "1" to turn >>> it on. And it is not clear either what kind of filter (mean filter?) >>> and which radius >>> >>> Regarding "precision", there is also no definition in the table (the >>> information on >>> Parameter Type is just repeated) but it is later defined as in the >>> command line help page: >>> >>> "Estimated precision of the colocalisation function (in pixels). >>> Estimated precision of the colocalisation function in pixels." >>> >>> I do not say this definition is wrong, but it is no appropriate. The >>> definition must >>> state the role of the argument in the process. In this case, I >>> understand that the >>> algorithm searches, for a given point image in1 band1, an homologous point >>> on >>> image in2 band2 within a radius equal to the value of precision in pixels. >>> Correct? >>> >>> Also, what happens if the user sets precision to i.e. 10 and mfilter is off? >>> >>> Thanks >>> >>> Agus >>> >>> >>> >>> >>> -- >>> Julien MICHEL >>> CNES - DCT/SI/AP - BPI 1219 >>> 18, avenue Edouard Belin >>> 31401 Toulouse Cedex 09 - France >>> Tel: +33 561 282 894 - Fax: +33 561 283 109 >>> >>> -- >>> -- >>> Check the OTB FAQ at >>> http://www.orfeo-toolbox.org/FAQ.html >>> >>> You received this message because you are subscribed to the Google >>> Groups "otb-users" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/otb-users?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "otb-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Julien MICHEL >> CNES - DCT/SI/AP - BPI 1219 >> 18, avenue Edouard Belin >> 31401 Toulouse Cedex 09 - France >> Tel: +33 561 282 894 - Fax: +33 561 283 109 >> >> -- >> -- >> Check the OTB FAQ at >> http://www.orfeo-toolbox.org/FAQ.html >> >> You received this message because you are subscribed to the Google >> Groups "otb-users" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/otb-users?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "otb-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > Check the OTB FAQ at > http://www.orfeo-toolbox.org/FAQ.html > > You received this message because you are subscribed to the Google > Groups "otb-users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/otb-users?hl=en > --- > You received this message because you are subscribed to the Google Groups > "otb-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > > -- > Julien MICHEL > CNES - DCT/SI/AP - BPI 1219 > 18, avenue Edouard Belin > 31401 Toulouse Cedex 09 - France > Tel: +33 561 282 894 - Fax: +33 561 283 109 > > -- > -- > Check the OTB FAQ at > http://www.orfeo-toolbox.org/FAQ.html > > You received this message because you are subscribed to the Google > Groups "otb-users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/otb-users?hl=en > --- > You received this message because you are subscribed to the Google Groups > "otb-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- Check the OTB FAQ at http://www.orfeo-toolbox.org/FAQ.html You received this message because you are subscribed to the Google Groups "otb-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/otb-users?hl=en --- You received this message because you are subscribed to the Google Groups "otb-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
