|
Boost : |
Subject: Re: [GSOC 2019] [Draft] Proposal by Olzhas Zhumabek - Epipolar geometry
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2019-04-03 23:08:48
On 2019-04-03 6:15 p.m., Olzhas Zhumabek wrote:
> From my understanding, the only culprit is the feature detection. The rest
> should be straightforward linear algebra.
>
> For completeness, you should also add some feature detection: To find a
>> fundamental matrix you need to feed in pairs of points. That is, you
>> need to already have obtained those corresponding points (as features)
>> in the original images.
> It seems like SIFT algorithm for feature detection is the way to go. I
> found a page that summarizes the steps of the algorithm:
> https://opencv-python-tutroals.readthedocs.io/en/latest/py_tutorials/py_feature2d/py_sift_intro/py_sift_intro.html
> .
I'm not sure. Without any a-priori knowledge of what the images contain,
I'd expect a conceptual workflow as
* feature (point) detection
* registration (matching features in one image to ones in another)
* reconstruction (mapping 2D features to 3D features)
And in that (very high-level) picture, the different stages are (mostly)
independent of each other.
> The matching part is mostly nearest neighbor search (pick one interest
> point from one image and try to find closest match from interest points of
> other image).
Doesn't this depend a lot on context ? How far are the two cameras apart
? If they are close enough together, one might start the search in image
2 using the positions in image 1 as a starting point. If not, that may
not be a good strategy.
> It doesn't look that fast though. I guess after checking out
> performance of serial version I'll try either parallel CPU or CUDA/SYCL
> version, if performance is completely unreasonable.
Now that is yet a different (mostly orthogonal) area of development:
performance improvements. While it might be interesting to implement a
special-purpose algorithm on special hardware, I think for a (mostly)
generic library such as Boost.GIL it would be best to keep portability
in mind, i.e. to first focus on functionality, then add
hardware-specific optimizations that can be optionally enabled depending
on context. But developing the algorithm itself on special-purpose
hardware (such as GPUs) doesn't seem to fit well into the Boost (and
Boost.GIL) philosophy.
> About motion capture: sounds a bit ambitious, but certainly doable.
You are right, I was getting carried away. :-) And I didn't mean to
suggest this as a topic for a single GSoC project. Only that this would
be a nice demo to keep in mind while working on epipolar geometry
algorithms.
> I guess
> I should start doing that after I got aforementioned algorithms of
> reasonable quality with all of the accompanying documentation and
> tutorials. I'll try to find some simple to use video decoder for this demo
> project at a later time.
>
> I'll have a PDF version of my proposal ready with more rigid wording and
> clear stated goals. Is there anything else I should add into the proposal
> other than plans and link to my solution of coding competency test?
One very important aspect is a (rough) schedule: Try to estimate the
time you think you'd spend on individual milestones. This is not so much
meant to be binding for the project, but it's a very useful device for
you to be realistic, i.e. to think carefully about whether your proposal
is realistic in the given timeframe. (Hint: try to define the proposal
such that you have achievable goals, perhaps with some optional features
you could work on if time permits. And please leave room for testing and
documentation.)
> P.S. I deleted auto generated quote of previous messages and tried to quote
> only relevant part of relevant messages. Is this accepted practice in
> mailing lists?
Definitely, at least here. :-) (As you can see from my own replies, I'm
happily replying "in-line", even removing things I'm not explicitly
replying to. That's not a sign of disrespect, or disagreement, but helps
the discussion to stay focused.
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by Boost-Gil-Owners