利用者:Sftrabbit/GSoC 2013/Documentation/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.
C API
Currently, the libmv C API exposes reconstruction through the libmv_solve
function. It takes a set of tracks, camera intrinsics options, reconstruction options, and a callback for progress updates. Depending on the libmv_reconstructionOptions::motion_flag
flags, it forwards these arguments to either libmv_solveReconstruction
or libmv_solveModal
. It returns a libmv_Reconstruction
which contains the reconstructed cameras and tracking points.
I've considered two options for adding multiview reconstruction to the API:
- Expose a
libmv_solveMultiview
function in addition tolibmv_solve
. - Have
libmv_solve
determine whether an internallibmv_solveMultiview
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 Tracks
arguments can store Markers
associated with particular views, and libmv_Solve
determine whether to perform multiview reconstruction based on the number of views associated with the given tracks. This means that libmv_Solve
will call one of the following functions:
libmv_solveReconstruction
libmv_solveModal
libmv_solveMultiview
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 libmv_solve
function that:
- Treats single view and multiview reconstruction uniformly.
- Takes motion constraints associated with each view.
Tracks
To store tracks across multiple views, the Tracks
class needs to be modified. Currently, Tracks
just stores a vector<Marker>
. The Marker
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 track
value but different image
values.
For multiview reconstruction, the obvious solution is to give Marker
s a view
member, which associates them with a particular view. That is, all Marker
s with the same view
value correspond to markers on the images from a single camera. So the Marker
struct will simply be:
struct Marker {
int view;
int image;
int track;
double x, y;
};
Then the member functions of Tracks
need to be updated to allow insertion and extraction of Marker
s in different views. For example, Tracks::MarkersInView
will return all of the markers corresponding to a particular view. Attempting to insert or extract Marker
s giving only image and track values will assume a value of 0 for the view. This means that Tracks
can continue to be used in a single view situation.
Solving
Coming soon...
Reconstruction result
Coming soon...