Blender Git Loki

Code cleanup: keyframe selection explicitly single-camera

The current keyframe selection algorithm only looks at frames from camera 0 to find two frames with high variance. It's definitely worth looking at algorithms for keyframe selection from multiple cameras - different cameras are likely to have high variance.

Code cleanup: use const references for input parameters

Code cleanup: modal solver explicitly single-camera

Non-functional change to the modal solver to explicitly document it as being a single-camera algorithm, working with only camera 0.

Improved naming of cameras/views

The recent change that distinguished "multicamera reconstruction" from "multiview reconstruction" led to some confusing naming. A EuclideanReconstruction would store EuclideanCameras, which are the position and orientation of a physical camera for a specific image. That is, a EuclideanCamera is a camera at an instance, rather than representing the physical camera itself. This meant that EuclideanCameras had associated cameras, which is clearly confusing. This commit attempts to unify the terminology:

- View - a specific instance of a camera at some orientation and point in space (giving an image of the scene)
- Multiview reconstruction - reconstruction of a scene from multiple views
- Camera - a physical video camera
- Multicamera reconstruction - a form of multiview reconstruction, where the views are associated with some number of video cameras

To this end, EuclideanCamera and ProjectiveCamera have been renamed to EuclideanView and ProjectiveView, as they represent a camera at a specific instance.

Some functions continue to have variables named "camera" where "view" would be more appropriate.

Modify constraints user interface and usability

I have recently been preparing focal length constraints for committing to trunk but unfortunately missed BCon2, so it'll have to wait until next time. In the meantime, this commit brings the changes that were made according to code reviews and user feedback into my branch. The interface changes include:

- Constraint value inputs are now in a column.
- User interface button names have been simplified.
- The focal length camera property is not forced to fit inside the focal length constraint range. Instead, the focal length is clamped to the range when solving.
- When the constraint is not enabled, the min and max values will adjust to match the focal length camera property. This gives the user an anchor to help understand the meaning of the values.

Merging from trunk r59849 into soc-2013-motion_track

Merging from trunk r59488 into soc-2013-motion_track

Fix compilation with WITH_LIBMV=OFF

Once again, I forgot to update libmv-capi_stub.cc to match the header.

Fix ignored constraint flag

Incorrect flags were being checked for whether a focal lenght constraint should be applied, causing it to always be applied whenever the focal length was chosen for refinement.

Fix invalid returned camera intrinsics

libmv provides a way to get the camera intrinsics from a reconstruction, which may be different to the intrinsics passed to the solver if refinement has taken place. My multicamera changes introduced a bug caused by a pointer cast between incompatible types causing the returned intrinsics to have screwed up values. This patch fixes that cast.

More framework for multicamera reconstruction

All algorithms have been adjusted to take into account multiple cameras and their intrinsics except for the bundle adjustment. This means it will give an incorrect result for multicamera reconstruction at the moment, but single camera reconstruction still functions normally.

Use multicamera intrinsics to calculate reprojection error

The reprojection error calculation would only take a single CameraIntrinsics and would apply it to all markers. Adjust it to take a vector of CameraIntrinsics and apply the intrinsics corresponding to the marker's associated camera.

Add correct handling of multicamera intrinsics

One argument to libmv_solve is an array of camera intrinsics options. The code now converts all elements of the array to internal CameraIntrinsics, instead of just the first. The output struct, libmv_Reconstruction, now contains a vector of output camera intrinsics (each element corresponding to a different camera).

Change from multiview to multicamera terminology

All 3D reconstruction is multiview reconstruction. A better, unambigious term for reconstructing multiple cameras is multicamera reconstruction, so change all references to "views" to "cameras".

Unfortunately, this introduces some confusion in simple_pipeline/reconstruction.h, but I'm currently discussing this with Keir.

Rename CameraForViewImage to CameraForImage

It is uncommon to refer to an image without a particular view, so shorten the function name for simplicity. If a function is needed that references all views at once, suffixing with AllViews will do.

Modify Tracks to multiview only

The Tracks class stores Markers that correspond to tracks across different views and images. There's no need to have an interface for both singleview and multiview reconstruction, so remove the single view interface. For now, all algorithms assume view 0, but should instead be passed the view that they should work on.

Merging from trunk r58769 into soc-2013-motion_track

Mostly to have the cleaned up libmv C API from r58765.

Modify libmv output types to store multiview reconstructions

The libmv_solve function returns a libmv_Reconstruction which contains a EuclideanReconstruction. This class and its brother, ProjectiveReconstruction, store the results of a reconstruction. To make way for multiview reconstruction, modify these classes to store reconstructed camera poses associated with particular views.

All libmv algorithms have been adjusted to meet the new API, temporarily assuming view 0 everywhere until they have also been multiviewified.

Fix alignment indentation

Although file is tab indented, split lines should be aligned with spaces.

Refactor bundle refinement in libmv C API

Instead of having libmv_solveRefineIntrinsics, which creates bundle options from reconstruction options and passes them to the libmv bundle adjuster, have a simpler function that just creates and returns the options. This brings all of the solving logic into libmv_solve.