-
Add StreamTransform which represents applying a series of transforms to some sequential input (e.g. a video). Handles reading video frames in and processing them as they become available (rather than loading the entire video into memory before processing it). The basic idea is a pipeline model, every child transform of StreamTransform is run by a separate thread, (as is reading in video frames). A thread waits for a frame as input, when input becomes available performs its operation, and then places the frame on the following stage's input buffer. Single threaded processing is not yet implemented. Moved CompositeTransform to openbr_plugin.h Add ContractTransform -- combines all input templates into a single template Preliminary handling of time varying transforms in DistributeTemplateTransform, the current behavior is not actually correct but will work for the single input case.
-
Handle enrollment of multiple independent templates by creating a single element template list from each input template, then processing these TemplateLists in parallel. This changes the basic operation for processing templates derived from a sinlge image from project(template, template) (a single input/single output function) to project(templateList, templateList), which allows for a transform to output a variable number of templates from a given input (e.g. a detector can output multiple templates, or a filter can remove templates that don't meet some criterion). The basic parallel execution code loop is implemented using DistributeTemplateTransform, instead of through Template::Project(list), and a DistributeTemplateTransform is automatically prepended to input enrollment algorithms. This avoids the problem of having to decide whether or not a split should take place on every call to project(templatelist), and since the distribute transform is just a normal transform, it can be applied more than once in a given algorithm (when this is desirable). Implement ExpandTransform as a basic Transform that take a template list as input, and expands it for its output (in project(templatelist)), due to the restructuring ExpandTransform no longer has to essentially mimic the functionality of PipeTransform to function correctly. This commit breaks binary compatibility (of saved models), so updates to the pre-trained face recognition and gender classification models are included.
-
Make ExpandTransform inherit from PipeTransform, move default implementations of several things to PipeTransform. This is cleaner since only ExpandTransform and PipeTransform actually share code (since they have the same basic execution path). Implement ExpandTransform using a decorator class.
-
Allow inherited properties to be set via a transforms argument list at the command line, but exclude properties of classes that directly inherit from br::Object (this excludes e.g. Transform's properties which should be set during training). Properties are set in the same order that is currently used (the order of their property declarations), but all superclass properties are set before base class properties. Changes to the Transform API: add a set of methods supporting non-const project operations. Since overloading with a non-const version of the same function name won't work, the methods are called projectUpdate, since they perform the expected project operation, but also allow the transform to update its internal state. This can be used to support tracking operations, as well as online learning methods. All current classes can implement projectUpdate by calling their const project method. To handle variable input/output situations (e.g. a tracking function may only wish to emit a single template per unique detected object), a "finalize" method is also added to Transform, to be called to indicate that no further calls to projectUpdate will be made, and allow the transform to emit any final templates This is only relevant for non-const project since a time-invariant transform has no way to manage an internal list of templates it is waiting to emit. Add a "timeVarying" method to Transform, which returns a bool indicate whether or not the transform is time-invariant (only projectUpdate should be called for a time-varying transform). Refactor Transforms that maintain a list of subclasses (pipe transform, expand transform, fork transform, random transform) to inherit from a common subclass (CompositeTransform). Time variance for composite transforms is set based on their child transforms -- a composite transform with any time-varying children is time-varying. Some code consolidation via the shared subclass.
-
PP5 building, bypassing _compare for now added backProject to Context and Transform made pixel happy fixed enroll some final changes to pittpatt added author information
