Boost logo

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

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

> 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

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


       ...ich hab' noch einen Koffer in Berlin...

Boost list run by Boost-Gil-Owners