There are stability issues with siftfast (our 3rd party sift implementation) but when it works, it is smoking fast ... Surf are essentially like sift, except that the descriptors is slightly shorter. Matching procedure is the same.

Le 01/09/2015 13:55, Agustin Lobo a écrit :
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] <mailto:[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] <mailto:[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] <mailto:[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 Extraction
            
http://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]
            <mailto:[email protected]>
            To unsubscribe from this group, send email to
            [email protected]
            <mailto:otb-users%[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]
            <mailto:[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] <mailto:[email protected]>
        To unsubscribe from this group, send email to
        [email protected]
        <mailto:otb-users%[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]
        <mailto:[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]
    <mailto:[email protected]>
    To unsubscribe from this group, send email to
    [email protected]
    <mailto:[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]
    <mailto:[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]
    <mailto:[email protected]>
    To unsubscribe from this group, send email to
    [email protected]
    <mailto:otb-users%[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]
    <mailto:[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] <mailto:[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.

Reply via email to