english Sivu saatavilla vain englanninkielisenä.

Blender Git Statistics -> Developers -> keir

Keir Mierle (keir)

Total Commits : 44
Master Commits : 41
Branch Commits : 3
First Commit : October 30, 2011
Latest Commit : October 30, 2014

Commits by Month

DateNumber of Commits
October, 20141
September, 20141
August, 20140
July, 20140
June, 20140
May, 20141
April, 20140
March, 20140
February, 20140
January, 20140
December, 20130
November, 20130
October, 20132
September, 20130
August, 20131
July, 20130
June, 20130
May, 20130
April, 20130
March, 20130
February, 20131
January, 20130
December, 20120
November, 20120
October, 20120
September, 20125
August, 20120
July, 20120
June, 20125
May, 201213
April, 20120
March, 20120
February, 20120
January, 20120
December, 201112
November, 20111
October, 20111

Commit Distribution

PathNumber of Commits
master41
depsgraph_refactor1
soc-2011-tomato1
libmv_prediction1

Favourite Files

FilenameTotal Edits
track_region.cc18
tracking.c14
track_region.h12
space_clip.py9
libmv-capi.cpp9
DNA_tracking_types.h9
libmv-capi.h8
rna_tracking.c7
esm_region_tracker.cc6
CMakeLists.txt5

File Changes

ActionTotalPer Commit
Added451.0
Modified1623.7

Code Changes

ActionTotalPer Commit
Lines Added3 62890.7
Lines Removed1 44936.2

Latest commits Feed

Revision b15a056 by Keir Mierle / Sergey Sharybin (master)
October 30, 2014, 18:03 (GMT)
Libmv: Initial commit of unfinished AutoTrack API

This starts the creating the new AutoTrack API. The new API will
make it possible for libmv to do full autotracking, including
predictive tracking and also support multiple motion models (3D
planes etc).

The first goal (not in this patch) is to convert Blender to use
the new API without adding any new functionality.

This API currently contanins:

- Frame accessor to access frames which are stored in Blender side.
- New Tracks implementation
- New Reconstruction implementation

Currently this API only tested on doing the same frame-to-frame
tracking as the old API allowed to do. But it also supports now
predictive tracking which is based on the Kalman filter.
Revision 9b927ef by Keir Mierle / Sergey Sharybin (libmv_prediction)
September 26, 2014, 18:51 (GMT)
Initial commit of unfinished AutoTrack API

This starts the creating the new AutoTrack API. The new API will
make it possible for libmv to do full autotracking, including
predictive tracking and also support multiple motion models (3D
planes etc).

The first goal (not in this patch) is to convert Blender to use
the new API without adding any new functionality.

This API currently contanins:

- Frame accessor to access frames which are stored in Blender side.
- New Tracks implementation
- New Reconstruction implementation

Currently this API only tested on doing the same frame-to-frame
tracking as the old API allowed to do. But it also supports now
predictive tracking which is based on the Kalman filter.
Revision e13fa94 by Keir Mierle (depsgraph_refactor)
May 20, 2014, 16:25 (GMT)
Removed the IDKey for building relations, due to ambiguity and failing to add
relations.

To add a relations between operations we need to address a specific component or
operation directly.
Revision 427844c by Keir Mierle (master)
October 29, 2013, 01:06 (GMT)
Eagerly attempt to refine a track before doing a brute search

Before the refinement phase of tracking, a brute force SAD search
is run across the search area. This works well but is slow;
especially if the guess for the track's location is accurate.

This patch runs a refinement phase before running a brute force
search, hoping that the guessed position (in x2, y2) is close to
the best answer. If it is, then no brute search is done. If it is
not, then a normal brute force search followed by refinement is
done.

In some cases this may produce worse tracks than before; the
regressions will need investigation. The predictive motion model
(to be implemented) will reduce the probability of that happening.

Revision d10abe6 by Keir Mierle (master)
October 28, 2013, 18:34 (GMT)
Fix bug where libmv tracking incorrectly succeeds on failure

Before this patch, if Ceres returned USER_SUCCESS indicating that
Ceres was only changing the tracked quad slightly between
iterations (indicating convergence), no final correlation check
was done. This leads to incorrectly returning that the tracking
was successful, when it actually failed.

Revision e021860 by Keir Mierle (soc-2011-tomato)
August 2, 2013, 07:59 (GMT)
Add Procrustes PNP ("PPnP") resection algorithm to libmv

This adds a new Euclidean resection method, used to create the
initial reconstruction in the motion tracker, to libmv. The method
is based on the Procrustes PNP algorithm (aka "PPnP"). Currently
the algorithm is not connected with the motion tracker, but it
will be eventually since it supports initialization.

Having an initial guess when doing resection is important for
ambiguous cases where potentially the user could offer extra
guidance to the solver, in the form of "this point is in front of
that point".
Revision 2833994 by Keir Mierle (master)
February 25, 2013, 20:00 (GMT)
Switch motion tracker bundle adjustment to Ceres.

Patch originally written by me, then finished by Sergey. Big
thanks to Sergey for troopering through and fixing the many issues
with my original (not compilable) patch.

The Ceres implementation uses 2 parameter blocks for each camera
(1 for rotation and 1 for translation), 1 parameter block for
common intrinsics (focal length etc) and 1 parameter block for
each track (e.g. bundle or 3D point).

We turn on some fancy optimizer options to get better performance,
in particular:

options.preconditioner_type = ceres::SCHUR_JACOBI;
options.linear_solver_type = ceres::ITERATIVE_SCHUR;
options.use_inner_iterations = true;
options.use_nonmonotonic_steps = true;
options.max_num_iterations = 100;

Special thanks to Sameer Agarwal of Ceres fame for splitting out
the SCHUR_JACOBI preconditioner so that it didn't depend on
CHOLMOD. Previously we could not use that preconditioner in
Blender because CHOLMOD is too large of a dependency for Blender.

BundleIntrinsicsLogMessage:
- Moved bunch of if(foo) LG << "bar" into this function, to make
EuclideanBundleCommonIntrinsics a little bit easier to follow.

EuclideanBundle:
- Fix RMSE logging.

Revision e38c1a5 by Keir Mierle (master)
September 20, 2012, 18:55 (GMT)
Make Euclidean resection "always" succeed.

The Euclidean resection code had a magical constant, 1e-3, used to
compare the results of solving an equation. This failure detection
was well-intended, trying to prevent poor solutions from getting
made without notifying the caller. Unfortunately in practice, this
threshold is too conservative. Furthermore, it is not clear the
threshold should exist at all; the purpose of the Euclidean
resection is to come up with the best solution it can; other
methods (e.g. reprojection error) should be used to compare
whether the method succeeded.

This commit changes the Euclidean EPnP code to always succeed,
causing the previous fallback to projective resection to never
run. In most cases, this will result in better reconstructions.

This should, in most cases, fix the dreaded "flipping" problem.
Revision 5e43392 by Keir Mierle (master)
September 20, 2012, 02:27 (GMT)
Fix variable naming in the planar tracker.
Revision 0af0da9 by Keir Mierle (master)
September 20, 2012, 02:10 (GMT)
Add smarter tolerance checking in the planar tracker.

The planar tracker uses Ceres for the refinement stage. During
refinement, Ceres iteratively updates the parameters with the
latest best guess. If the change in the parameters falls below a
threshold, Ceres will abort successfully ("converged").

For the case of pure translation tracking, the parameters are
exactly the two pixel shifts (dx, dy), and measuring the change in
these parameters gives a meaningful termination criterion.
However, for all the other parameterizations like affine, where
the parameterization involves affine parameters that have no
physical interpretation, Ceres is left with no way to terminate
the solver early. With the existing code, often many iterations
are run long after Ceres has found a solution sufficiently
accurate for all tracking needs. No one needs tracking with
a quadrillionth of a pixel accuracy; that time is wasted.

This patch extends the existing iteration callback that is passed
in to Ceres to check if the pattern has fallen out of the search
window, to also check if the optimizer has made a tiny step. In
particular, if the maximum shift of any patch corner between two
successful optimizer steps is less than a threshold (currently
0.005 pixels), the track is declared successful and tracking
is terminated.

This leads to dramatic speed increases in some cases, with little
to no loss in track quality. This is especially apparent when
tracking patches with affine or perspective motion models. For
example, on some tracking cases I tried, the iterations Ceres took
went from 50 to 3.

MiikaHweb - Blender Git Statistics v1.06
Tehnyt: Miika HämäläinenViimeksi päivitetty: 07.11.2014 14:18MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021