• Josh Klontz authored
     
    Browse File »
  • Josh Klontz authored
     
    Browse File »
  • Charles Otto authored
     
    Browse File »
  • Josh Klontz authored
     
    Browse File »
  • Charles Otto authored
     
    Browse File »
  • Charles Otto authored
     
    Browse File »
  • Charles Otto authored
     
    Browse File »
  • 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.
    Charles Otto authored
     
    Browse File »
  • 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.
    Charles Otto authored
     
    Browse File »