Yamyam: 1版をインポートしました

2018-06-28T20:57:17Z

1版をインポートしました

wiki>Sftrabbit: /* Multiview Reconstruction Internals Design */

2013-09-22T21:14:20Z

‎Multiview Reconstruction Internals Design

新規ページ

=Multiview Reconstruction Internals Design=

'''The following describes my original plans for the multicamera reconstruction. For a current description, see the [[../Technical_Overview|'''technical overview''']].'''

==C API==

Currently, the libmv C API exposes reconstruction through the <code>libmv_solve</code> function. It takes a set of tracks, camera intrinsics options, reconstruction options, and a callback for progress updates. Depending on the <code>libmv_reconstructionOptions::motion_flag</code> flags, it forwards these arguments to either <code>libmv_solveReconstruction</code> or <code>libmv_solveModal</code>. It returns a <code>libmv_Reconstruction</code> which contains the reconstructed cameras and tracking points.

I've considered two options for adding multiview reconstruction to the API:

# Expose a <code>libmv_solveMultiview</code> function in addition to <code>libmv_solve</code>.
# Have <code>libmv_solve</code> determine whether an internal <code>libmv_solveMultiview</code> should be called based on the arguments passed.

I have chosen option 2, because it '''simplifies the interface and treats single view and multiview reconstruction uniformly''' (at least as far as the blenkern is concerned). The given <code>Tracks</code> arguments can store <code>Markers</code> associated with particular views, and <code>libmv_Solve</code> determine whether to perform multiview reconstruction based on the number of views associated with the given tracks. This means that <code>libmv_Solve</code> will call one of the following functions:

* <code>libmv_solveReconstruction</code>
* <code>libmv_solveModal</code>
* <code>libmv_solveMultiview</code>

'''Perhaps it is worth combining these functions in some way''', as they all perform many steps in common. It's also worth thinking about what will happen when we have modal multiview reconstruction. In fact, for multiple views, only a subset of cameras may have fixed positions. This suggests that it might be possible to have a single <code>libmv_solve</code> function that:

# Treats single view and multiview reconstruction uniformly.
# Takes motion constraints associated with each view.

==Tracks==

To store tracks across multiple views, the <code>Tracks</code> class needs to be modified. Currently, <code>Tracks</code> just stores a <code>vector<Marker></code>. The <code>Marker</code>s themselves keep track of which track and image (frame of video) they belong to. For example, all of the markers for a single track will have the <code>track</code> value but different <code>image</code> values.

For multiview reconstruction, the obvious solution is to give <code>Marker</code>s a <code>view</code> member, which associates them with a particular view. That is, all <code>Marker</code>s with the same <code>view</code> value correspond to markers on the images from a single camera. So the <code>Marker</code> struct will simply be:

<source lang="cpp">
struct Marker {
int view;
int image;
int track;
double x, y;
};
</source>

Then the member functions of <code>Tracks</code> need to be updated to allow insertion and extraction of <code>Marker</code>s in different views. For example, <code>Tracks::MarkersInView</code> will return all of the markers corresponding to a particular view. Attempting to insert or extract <code>Marker</code>s giving only image and track values will assume a value of 0 for the view. This means that <code>Tracks</code> can continue to be used in a single view situation.

==Solving==

Coming soon...

==Reconstruction result==

Coming soon...

← 古い版	2018年6月28日 (木) 20:57時点における版
(相違点なし)

利用者:Sftrabbit/GSoC 2013/Documentation/Multiview Reconstruction Internals Design - 版の履歴

Yamyam: 1版 をインポートしました

wiki>Sftrabbit: /* Multiview Reconstruction Internals Design */

Yamyam: 1版をインポートしました