Update matcher args, opensfm url, and ccd_defs_check

[dakotabenjamin]

• Pull opensfm source from a commit for persistent download link
• Add pythonized ccd_defs_check and update pre-commit hook
• Update args help text
• add --matcher-neighbors and --matcher-distance args
• update opensfm.py to incorporate above changes

[edgarriba]

have you tested that?

[edgarriba]

while writing this I'm thinking that we should provide some testing scripts I order to safely merge new PR.

cc @smathermather

[smathermather]

Agreed @edgarriba. Now the question is how. One of the annoying things about SfM is non-deterministic output. I would say, testing scripts needs to go on the timeline, but we shouldn't halt pull requests until we have a testing framework / testing server in place.

[dakotabenjamin]

Well at least we could test to see if it runs, and for many aspects there are markers indicating successful code. For example, asserting that the prematching step actually reduces to the correct number of photos.

[smathermather]

So, I suppose we should list out what are the testable things, and what things require (at this stage) a more personal touch.

Automated / sem-automated checks:

• ensure prematching works
• check process run time
• maybe some PCL based distance calculations to determine when there are significant changes to the point cloud output
• difference measures for raster output
• ...

[dakotabenjamin]

I'll work on tests for this, keeping in mind the need for an overall testing structure. In my mind, some of the tests for the control of the toolchain will be asserting that correctly formatted outputs are saved to disk. Then with the custom modules, it would make more sense to run tests in C++ for them. Do you have any idea how we should structure the tests to increase efficiency while still being able to isolate code later in the toolchain?

[dakotabenjamin]

I have to admit, I'm a bit of a noob when it comes to testing large projects. I've got the psuedocode for what I think I want to do for this test, but I'm not sure how to implement:

import nose
from opendm import config

def setUp(self):
    # Run ODM completely with no extra parameters

def tearDown(Self):
    # Delete the test folder

class TestODM:
    def setup_test(self):
        # rerun opensfm with parameters

    def test_prematching_config(self):
        # assert that relevant run args are what they say they are

    def test_opensfm_config_file(self):
        # assert that the args in the opensfm config file match those it is set to
        # assert above when matcher_distance > 0
        # check when the arg is out of reasonable bounds

My biggest ignorance comes in the setup methods. How do I access the code to test it during that part? I can't just pass the run.py command.

[edgarriba]

We can just call odm cells and assert some known results. On 26 Jan 2016 17:33, "Dakota Benjamin" notifications@github.com wrote:

I have to admit, I'm a bit of a noob when it comes to testing large projects. I've got the psuedocode for what I think I want to do for this test, but I'm not sure how to implement:

import nose from opendm import config

def setUp(self):

Run ODM completely with no extra parameters

def tearDown(Self):

Delete the test folder

class TestODM: def setup_test(self):

rerun opensfm with parameters

def test_prematching_config(self):
    # assert that relevant run args are what they say they are

def test_opensfm_config_file(self):
    # assert that the args in the opensfm config file match those it is set to
    # assert above when matcher_distance > 0
    # check when the arg is out of reasonable bounds

My biggest ignorance comes in the setup methods. How do I access the code to test it during that part? I can't just pass the run.py command.

— Reply to this email directly or view it on GitHub https://github.com/edgarriba/OpenDroneMap/pull/17#issuecomment-175104089 .