Commit Graph

311 Commits

Author SHA1 Message Date
dae43b5487 Camera tracking: multiply all camera matrices by inverted first reconstructed camera matrix
This makes blender camera:
- Be located on exactly the same position at first frame after applying
  Camera Solver constraint
- Be looking in exactly the same direction it used to look before
  applying Camera Solver constraint

Before this patch in most of cases camera used to change direction
after applying solved data on it which can be confusing in some cases.

Currently solved files wouldn't be broken, but after solve scene should
be re-oriented. Not big deal because re-solving isn't so safe for scene
orientation anyway.
2011-11-18 14:42:18 +00:00
3d724d8df5 Camera tracking: made some options more easy to understand
- Changed some names so now people who aren't really familiar with
  motion tracking can understand what they exactly means
- Also cleaned up and rephraded some descriptions
- Changed behavior of operator which creates empty for 2d tracks:
  now it operates on all selected tracks rather than active track only
- Added checkbox to enable/disable rotation stabilization
2011-11-15 12:20:58 +00:00
9e6860d864 fix [#29242] menus have no keyboard shortcuts 2011-11-14 14:42:47 +00:00
0f82384fd0 Camera tracking: code cleanup 2011-11-14 06:41:32 +00:00
6fbc4186fd Assorted camera tracker improvements
- Add support for refining the camera's intrinsic parameters
  during a solve. Currently, refining supports only the following
  combinations of intrinsic parameters:

    f
    f, cx, cy
    f, cx, cy, k1, k2
    f, k1
    f, k1, k2

  This is not the same as autocalibration, since the user must
  still make a reasonable initial guess about the focal length and
  other parameters, whereas true autocalibration would eliminate
  the need for the user specify intrinsic parameters at all.

  However, the solver works well with only rough guesses for the
  focal length, so perhaps full autocalibation is not that
  important.

  Adding support for the last two combinations, (f, k1) and (f,
  k1, k2) required changes to the library libmv depends on for
  bundle adjustment, SSBA. These changes should get ported
  upstream not just to libmv but to SSBA as well.

- Improved the region of convergence for bundle adjustment by
  increasing the number of Levenberg-Marquardt iterations from 50
  to 500. This way, the solver is able to crawl out of the bad
  local minima it gets stuck in when changing from, for example,
  bundling k1 and k2 to just k1 and resetting k2 to 0.

- Add several new region tracker implementations. A region tracker
  is a libmv concept, which refers to tracking a template image
  pattern through frames. The impact to end users is that tracking
  should "just work better". I am reserving a more detailed
  writeup, and maybe a paper, for later.

- Other libmv tweaks, such as detecting that a tracker is headed
  outside of the image bounds.

This includes several changes made directly to the libmv extern
code rather expecting to get those changes through normal libmv
channels, because I, the libmv BDFL, decided it was faster to work
on libmv directly in Blender, then later reverse-port the libmv
changes from Blender back into libmv trunk. The interesting part
is that I added a full Levenberg-Marquardt loop to the region
tracking code, which should lead to a more stable solutions. I
also added a hacky implementation of "Efficient Second-Order
Minimization" for tracking, which works nicely. A more detailed
quantitative evaluation will follow.

Original patch by Keir, cleaned a bit by myself.
2011-11-14 06:41:23 +00:00
3689830484 Camera solving: fixed incorrect warnings about failure of solving some frames
Error was caused y not very accurate calculating which frames should be solved.
2011-11-13 17:16:04 +00:00
094c9799f9 quiet -Wdouble-promotion warnings 2011-11-11 12:00:08 +00:00
127f9e9b8f quiet warning 2011-11-08 18:23:23 +00:00
62988d6311 Attempt to fix #29200: Camera Tracking Solver
It was an mistake in join tracks operator which lead to reading unitialized memory.
2011-11-08 14:03:16 +00:00
9ced8a23fe quiet warnings when building without libmv 2011-11-07 16:26:23 +00:00
27d42c63d9 Camera tracking integration
===========================

Commiting camera tracking integration gsoc project into trunk.

This commit includes:

- Bundled version of libmv library (with some changes against official repo,
  re-sync with libmv repo a bit later)
- New datatype ID called MovieClip which is optimized to work with movie
  clips (both of movie files and image sequences) and doing camera/motion
  tracking operations.
- New editor called Clip Editor which is currently used for motion/tracking
  stuff only, but which can be easily extended to work with masks too.

  This editor supports:
  * Loading movie files/image sequences
  * Build proxies with different size for loaded movie clip, also supports
    building undistorted proxies to increase speed of playback in
    undistorted mode.
  * Manual lens distortion mode calibration using grid and grease pencil
  * Supervised 2D tracking using two different algorithms KLT and SAD.
  * Basic algorithm for feature detection
  * Camera motion solving. scene orientation

- New constraints to "link" scene objects with solved motions from clip:

  * Follow Track (make object follow 2D motion of track with given name
    or parent object to reconstructed 3D position of track)
  * Camera Solver to make camera moving in the same way as reconstructed camera

This commit NOT includes changes from tomato branch:

- New nodes (they'll be commited as separated patch)
- Automatic image offset guessing for image input node and image editor
  (need to do more tests and gather more feedback)
- Code cleanup in libmv-capi. It's not so critical cleanup, just increasing
  readability and understanadability of code. Better to make this chaneg when
  Keir will finish his current patch.

More details about this project can be found on this page:
    http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2011

Further development of small features would be done in trunk, bigger/experimental
features would first be implemented in tomato branch.
2011-11-07 12:55:18 +00:00