Inconsistent naming of features

[sarlinpe]

Thanks for the extensive codebase and the nice config/batching system. I have a few questions & remarks:

1) The documentation does not say that keypoint and descriptor names should be lowercase, and the feature importer does not enforce this.

2) It would be nice to have a script that converts the training sequences into the validation format, so that a larger validation set can be used (the current one is small).

3) Why do you force the model estimator to be the 8-point algorithm when custom matches are provided? This forces the users to write custom code to run the robust estimators on the test matches. It also introduces a discrepancy between validation and test - an estimator might perform a geometric refinement, which the current setup does not allow.

4) What is the relocalization task?

[ducha-aiki]

Thanks for the extensive codebase and the nice config/batching system. I have a few questions & remarks:

The documentation does not say that keypoint and descriptor names should be lowercase, and the feature importer does not enforce this.

Thank you for catching that. Could you please do PR with the fix into the docs?

It would be nice to have a script that converts the training sequences into the validation format, so that a larger validation set can be used (the current one is small).

We are planning to just release training set in a val format in ~1-2 weeks.

Why do you force the model estimator to be the 8-point algorithm when custom matches are >provided? This forces the users to write custom code to run the robust estimators on the test >matches.

Well, we treat custom matcher as robust estimator - and - your own superglue confirmed that 8pt (DLT) is better than RANSAC in such cases. DEGENSAC is open-sourced (https://github.com/ducha-aiki/pyransac) and I see no problems of merging it into the custom matcher.

It also introduces a discrepancy between validation and test - an estimator might perform a > > > geometric refinement, which the current setup does not allow.

Why? You are free to do geometric refiniment

What is the relocalization task?

So far it is non-existent ;)

[sarlinpe]

Thank you for catching that. Could you please do PR with the fix into the docs?

Sure, will do so shortly.

We are planning to just release training set in a val format in ~1-2 weeks.

Great!

Well, we treat custom matcher as robust estimator - and - your own superglue confirmed that 8pt (DLT) is better than RANSAC in such cases. DEGENSAC is open-sourced (https://github.com/ducha-aiki/pyransac) and I see no problems of merging it into the custom matcher.

Whether 8-pt or *SAC is better does not matter here: my point is that it would be nicer & easier to export geometrically-verified matches for the test images from the run.py script.

Why? You are free to do geometric refiniment

No, since the essential matrix is always estimated from the 8-pt algorithm for custom matches, and the keypoint location are shared for all pairs. It would be nice to allow participants to submit fundamental matrices or even poses, so they are free to use their own model estimators.

[ducha-aiki]

We are planning to allow pose submission, but it is not ready yet.

[sarlinpe]

Fixed by #11