| Age | Commit message (Collapse) | Author |
|---|
|
|
|
called a lot, only defined for gcc at the moment.
also some cmake formatting edits.
|
|
Also updated generation scripts and templates
|
|
|
|
Keir's comment:
Add support for detecting tracking failure in the ESM tracker component of
libmv. Since both KLT and Hybrid rely on ESM underneath, KLT and Hybrid now
have a minimum correlation setting to match. With this fix, track failures
should get detected quicker, with the issue that sometimes the tracker will
give up too easily. That is fixable by reducing the required correlation (in
the track properties).
Command used for merge: svn merge -r 42396:42397 -r 42399:42400 ^/branches/soc-2011-tomato
|
|
|
|
|
|
|
|
define __MSVCRT_VERSION__ to 0x0700 (microsoft runtime msvcr70.dll) so _aligned_malloc is defined.
|
|
Comment from Keir's commit:
Add a new hybrid region tracker for motion tracking to libmv, and
add it as an option (under "Hybrid") in the tracking settings. The
region tracker is a combination of brute force tracking for coarse
alignment, then refinement with the ESM/KLT algorithm already in
libmv that gives excellent subpixel precision (typically 1/50'th
of a pixel)
This also adds a new "brute force" region tracker which does a
brute force search through every pixel position in the destination
for the pattern in the first frame. It leverages SSE if available,
similar to the SAD tracker, to do this quickly. Currently it does
some unnecessary conversions to/from floating point that will get
fixed later.
The hybrid tracker glues the two trackers (brute & ESM) together
to get an overall better tracker. The algorithm is simple:
1. Track from frame 1 to frame 2 with the brute force tracker.
This tries every possible pixel position for the pattern from
frame 1 in frame 2. The position with the smallest
sum-of-absolute-differences is chosen. By definition, this
position is only accurate up to 1 pixel or so.
2. Using the result from 1, initialize a track with ESM. This does
a least-squares fit with subpixel precision.
3. If the ESM shift was more than 2 pixels, report failure.
4. If the ESM track shifted less than 2 pixels, then the track is
good and we're done. The rationale here is that if the
refinement stage shifts more than 1 pixel, then the brute force
result likely found some random position that's not a good fit.
svn command used: svn merge -r 42375:42376 -r 42377:42379 ^/branches/soc-2011-tomato
|
|
|
|
It was error in CMakeLists.txt caused by automatic bundling script which
expanded variables instead of substituting them as-is.
Fixed both of bundling script and CMakeLists.txt
|
|
present in release builds, happens due to name clashes between tracker functions. static-fied them so the linker stops complaining.
|
|
(rectangle patterns are getting enlarged to square like it's happening for KLT)
|
|
In some cases solving can take a while (especially when refining is used)
and keeping interface locked is a bit annoying. Now camera solver is moved
to job system and interface isn't locking.
Reporting progress isn't really accurate, but trying to make it more linear
can lead to spending more effort on it than having benefit. Also, changing
status in the information line helps to understand that blender isn't hang
up and solving is till working nicely.
Main changes in code:
- libmv_solveReconstruction now accepts additional parameters:
* progress_update_callback - a function which is getting called
from solver algorithm to report progress back to Blender.
* callback_customdata - a user-defined context which is passing
to progress_update_callback so progress can be updated in needed
blender-side data structures.
This parameters are optional.
- Added structure MovieTrackingStats which is placed in MovieTracking
structure. It's supposed to be used for displaying information about
different operations (currently it's only camera solver, but can be
easily used for something else in the future) in clip editor.
This statistics structure is getting allocated for time operator is
working and not saving into .blend file.
- Clip Editor now displays statistics stored in MovieTrackingStats structure
like it's done for rendering.
|
|
Send object which implements ProgressUpdateCallback to complete reconstruction
function rather than sending C-like procedure variable and context.
|
|
|
|
|
|
|
|
|
|
Reporting progress isn't really accurate, but trying to make it more linear
can lead to spending more effort on it than having benefit. Also, changing
status in the information line helps to understand that blender isn't hang
up and solving is till working nicely.
Main changes in code:
- libmv_solveReconstruction now accepts additional parameters:
* progress_update_callback - a function which is getting called
from solver algorithm to report progress back to Blender.
* callback_customdata - a user-defined context which is passing
to progress_update_callback so progress can be updated in needed
blender-side data structures.
This parameters are optional.
- Added structure MovieTrackingStats which is placed in MovieTracking
structure. It's supposed to be used for displaying information about
different operations (currently it's only camera solver, but can be
easily used for something else in the future) in clip editor.
This statistics structure is getting allocated for time operator is
working and not saving into .blend file.
- Clip Editor now displays statistics stored in MovieTrackingStats structure
like it's done for rendering.
|
|
|
|
- Fixed incorrect memory access on distoritons more than 128 pixels
- Do not use UNDO operators flags for delete proxy operator (files can't be restored form disk),
and also do not use UNDO for set as background operator (background images are storing in
3d viewport which isn't getting re-loaded on undo which can lead to incorrect users count
of movie clip user).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
- Replace set of booleans with menu, so now you'll simply be unable to choose
unsupported refine combination
- Some internal code cleanup and minor refactor
|
|
- 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.
|
|
remove unneeded collection length function.
|
|
Tested with official MinGW and SCons, not sure how ti check it when using CMake.
|
|
===========================
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.
|
|
|
|
- Remove the overly-conservative use of libmv's re-track tracker. The re-track
tracker would take a normal tracker such as TRKLT or KLT or pyramid KLT, and
track from frame 1 to 2, then back from the position found in 2 back to 1.
Then, when the reverse-track doesn't match the original track with high
precision, the track is considered "failed". This is a good approach for
fully automatic reconstruction, but is too conservative for supervised
tracking.
The retrack-tracker will return when fully automatic tracking is added.
- Always solve for (dx, dy) in the TRKLT loop even if the linear system is
ill-conditioned. The client (Blender in this case) can still use the solved
position, even though it is less reliable.
- Expose the pyramid level setting to the tracking UI when in KLT tracking
mode. While it was tempting to hide this detail from the user, in reality it
does more harm than good, since the way tracking fails depends on the pyramid
level. For now, exposing the pyramid details is a good compromise.
- Move the settings for the tracking algorithm, including search window,
tracking algorithm, pyramid levels, etc, into the track object instead of a
global movie clip object.
|
|
==========================
Fix for SAD tracking sliding marker.
|
|
===========================
DeBalie commit (main changes only):
- Code cleanup
- Selectable tracking graph curves and curve knots
- Graph curve and curve knots can be deleted now
- Fixed wrong write when linking libraries
(error is caused by hardcoded cound of linkable ID blocks)
- Fixed for KLT tracker when using keyframe adjustment
|
|
|
|
- Upgrade Eigen2 library to Eigen3
- Upgrade colamd library and placed in extern/ so other libraries from extern/ can use it
NOTE: With previous version of Eigen (3.0.1) it was necessary to define
EIGEN_DONT_ALIGN_STATICALLY macro to make it compilable on windows 32bit.
After latest upgrade it seems to be unnecessary (at least when was testing libmv),
so i removed that defines which can reduce speed and lead to other problems.
|
|
===========================
Remove $Id$
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
===========================
Initial implementation of graph view for movie tracking data.
Used the same UI-side approach as preview region for sequencer:
create region for graph-related information inside clip editor.
It's easier and nicer than trying to hack graph editor which is
currently designed to work with AnimData only. Trying to make it
more abstract to deal with any kind of data doesn't seem be real
benefit for now.
Currently supported displaying per-frame average error and
selected tracks' movement speed (pixels per frame).
Additional changes:
- Collect per-frame average error after solving.
- Split space clip drawing code into different files.
- Added per-frame average solving error.
|
|
===========================
Some improvements for feature detectors:
- Sort features by score when filtering features by
distance using FAST library.
- Added option to place markers only in areas outlined
by grease pencil.
|
|
===========================
Added option to choose which method to use for feature detector: FAST or Moravec
Moravec was supposed to be more "stable", but it collected worse feedback.
before returning back to FAST detector added option to easier toggle between
different detector to compare it's result and find out if we can leave only FAST.
|
|
===========================
Support for (un)distortion of images with overscan. Needed for
easier keeping this up-to-date until proper overscan support is
implemented in renderer. Not exposed into UI yet at all.
|
|
===========================
Fixed threading issues used to happen when compositor tree
and rendering happened in the same time. Problem was caused
by cached camera intrinsics stored in MovieTracking structure
and access to which wasn't thread-safe.
Now each movie distoriton mode stores it's own camera intrinsics
in it's storage which makes compositor (un)distoriton be totally
thread-safe and this also makes compositor tree faster when
(un)distortion happens on images with different resolution.
|
