Ask Your Question

Vaesper's profile - activity

2016-08-10 05:58:03 -0600 received badge  Enthusiast
2016-08-02 07:10:30 -0600 commented question Extending decomposeHomographyMat
  1. Ah, was not familiar with that term. Confusingly enough, the page you linked is titled "API compatibility report".

  2. Indeed, that's why I'm asking :)

  3. Will do, thanks.

2016-08-02 06:54:19 -0600 commented question Extending decomposeHomographyMat

To respond to your arguments:

  1. Wouldn't it be the "same difference" for API compatibility if we only added 2 optional arguments? As in, no old code would break because the additional parameters are not mandatory to give, and it acts the same if they are not given?

  2. Something could be said for that. Semantically it might make more sense to split out this logic, though on the other hand I believe the initial solution set is already filtered in the current implementation of decomposeHomographyMat from an initial 8 or 16 solutions (I forget which).

Also, I don't have it on github (yet).

2016-08-02 06:52:18 -0600 commented question Extending decomposeHomographyMat

Basically, yes. The idea is that the (up to) 4 solutions from decomposeHomographyMat are actually 2 distinct solutions and their "opposites". The invalid "opposites" can be filtered out if we have access to the "point correspondences" (slightly misleading term as there isn't strictly a need to know which point in one set corresponds to which point in the other or for them to correspond at all, but that's how it will be in 99% of use cases).

2016-08-02 06:25:41 -0600 received badge  Student (source)
2016-08-02 06:03:54 -0600 asked a question Extending decomposeHomographyMat

The documentation of decomposeHomographyMat proposes a method to invalidate some of the output if additional information is present in the system (needs point sets representing the observed plane in both "before" and "after" images - see the paper linked in the documentation for more details). I have implemented this and it occurred to me that it seems like a piece of functionality that should be present in OpenCV itself.

The way I see it, it could either be a standalone function, or decomposeHomographyMat could be extended (without backwards incompatibility) by adding the point sets as optional extra parameters with empty default values. Perhaps even both (although I can't think of any scenario in which you'd want to use the standalone function call and would not want to use the "integrated" one).

Aside from all that, I'm relatively new to OpenCV so am not entirely sure of all the intricacies of the design philosophies ie. how to integrate this functionality into the framework. What does the OpenCV community think?