Extending decomposeHomographyMat

asked 2016-08-02 05:23:41 -0600

Vaesper gravatar image

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?

edit retag flag offensive close merge delete

Comments

1

would this be like some kind of "filter" for the returned solution sets ?

imho, there's 2 args for making it a seperate function: 1. abi compatibility 2. less confusing

you got this on github somewhere, ?

berak gravatar imageberak ( 2016-08-02 06:33:26 -0600 )edit
1

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).

Vaesper gravatar imageVaesper ( 2016-08-02 06:52:18 -0600 )edit

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).

Vaesper gravatar imageVaesper ( 2016-08-02 06:54:19 -0600 )edit
  1. hehe, note, it's aBi (binary compatibility). there's a pass in the automated buildbots, that will check for it, and it's usually quite pesky about it..

  2. yes, true. just my first thought on it. let's wait, what others say.

  3. at least, you already made an account. that's a start ;) also take a look at https://github.com/opencv/opencv/wiki...

berak gravatar imageberak ( 2016-08-02 06:59:33 -0600 )edit
  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.

Vaesper gravatar imageVaesper ( 2016-08-02 07:10:30 -0600 )edit