Blender Git Statistics -> Developers -> Ichthyostega
Hermann Voßeler (Ichthyostega)
Total Commits : 6
Master Commits : 6
Branch Commits : 0
First Commit : August 16, 2016
Latest Commit : August 23, 2016
Commits by Month
Date | Number of Commits | |
---|---|---|
August, 2016 | 6 |
Favourite Files
Filename | Total Edits |
---|---|
tracking_stabilize.c | 4 |
rna_tracking.c | 3 |
versioning_270.c | 3 |
tracking.c | 2 |
space_clip.py | 2 |
COM_MovieClipNode.cpp | 1 |
tracking_ops.c | 1 |
COM_MovieClipAttributeOperation.cpp | 1 |
BKE_tracking.h | 1 |
readfile.c | 1 |
File Changes
Action | Total | Per Commit |
---|---|---|
Modified | 26 | 4.3 |
Code Changes
Action | Total | Per Commit |
---|---|---|
Lines Added | 275 | 55.0 |
Lines Removed | 118 | 23.6 |
Latest commits
August 23, 2016, 09:53 (GMT) |
Fix inconsistency: expected scale not be subject to scale influence We should treat all three "target" ("expected") parameters in a similar way: The "influence" control should only work on the measurement part of stabilisation, i.e. it should only control the automatic part of stabilisation, while the target parameters are deliberately set by the user and thus should even be in effect when the automatic stabilsation is turned down. It used to be so for location and rotation, but for the scale part, I re-used the existing code for autoscale, which also had the scale influence work on the autoscale factor. This was sensible in the old version, since scale_influence was the only way to control the result. But now, the user has always total control trough the "target_*" parameters and thus we should prefer to treat all similar. |
August 23, 2016, 09:53 (GMT) |
2D stabilization: flip orientation of the scale parameter values > 1 will zoom in and values < 1 zoom out Rationale: the changed orientation is more natural from a user POV and doing it this way is also more consistent with the calculation of the other target_* parameters. Compatibility: This will break *.blend files saved with the previous version of this patch from the last days (test period). It will *not* break any old/migrated files: Previously, the DNA field "scale" was only used to cache autoscale. Only with the Stabilisator rework, "scale" becomes a first class persistent DNA field. There is migration code to init this field to 1.0 |
August 23, 2016, 09:53 (GMT) |
2D stabilization: change presentation of target_scale in UI Alongside with this change, we fix disabling of Autoscale, because this feature works even when rotation/scale is disabled. |
August 23, 2016, 09:53 (GMT) |
2D stabilization: by default init anchor_frame to frame 1 It is common in blender to use 1-based counting for frame sequences (while 0-based is allowed). Thus initializing to use frame 1 as reference for stabilization is likely to produce smooth start values in most cases |
August 23, 2016, 09:53 (GMT) |
Change Request: use weight centre of location tracks as pivot Previously, this extension used the translation compensated image centre as reference point for rotation measurement and compensation. During user tests, it turned out that this setup tends to give poor results with very simple track configurations. This can be improved by useiing the weighted average of the location tracks for each frame as pivot point. But there is a technical problem: the existing public API functions do not allow to pass the pivot point for each frame alongside with the stabilisation data. Thus this change implements a trick to package a compensation shift into the translation offset, so the rotation can be performed around a fixed point (center of frame). The compensation shift will then shift the image as if it had been rotated around the desired pivot point. |
August 16, 2016, 11:30 (GMT) |
Rework 2D stabilizator See this page for motivation and description of concepts: https://github.com/Ichthyostega/blender/wiki See this video for UI explanation and demonstration of usage http://vimeo.com/blenderHack/stabilizerdemo This proposal attempts to improve usability of Blender's image stabilization feature for real-world footage esp. with moving and panning camera. It builds upon the feature tracking to get a measurement of 2D image movement. - Use a weighted average of movement contributions (instead of a median). - Allow for rotation compensation and zoom (image scale) compensation. - Allow to pick a different set of tracks for translation and for rotation/zoom. - Treat translation / rotation / zoom contributions systematically in a similar way. - Improve handling of partial tracking data with gaps and varying start / end points. - Have a user definable anchor frame and interpolate / extrapolate data to avoid jumping back to "neutral" position when no tracking data is available. - Support for travelling and panning shots by including an //intended// position/rotation/zoom ("target position"). The idea is for these parameters to be //animated// by the user, in order to supply an smooth, intended camera movement. This way, we can keep the image content roughly in frame even when moving completely away from the initial view. A known shortcoming is that the pivot point for rotation compensation is set to the translation compensated image center. This can produce spurious rotation on travelling shots, which needs to be compensated manually (by animating the target rotation parameter). There are several possible ways to address that problem, yet all of them are considered beyond the scope of this improvement proposal for now. Own modifications: - Restrict line length, it's really handy for split-view editing - In motion tracking we prefer fully human-readable comments, meaning we don't use doxygen with it's weird markup and comments are supposed to start with capital and end with a full stop, - Add explicit comparison of pointer to NULL. Reviewers: sergey Subscribers: kusi, kdawg, forest-house, mardy, Samoth, plasmasolutions, willolis, sebastian_k, hype, enetheru, sunboy, jta, leon_cheung Maniphest Tasks: T49036 Differential Revision: https://developer.blender.org/D583 |
MiikaHweb - Blender Git Statistics v1.06