-
…available frames from them
-
* upstream/master: (108 commits) Add vbb annotations to seq files Add all the bbs in a single Template Remove "bad idea," fix appending empty bbs more robust search for openbr Use our fork of cvmatio for a better install and move non-find logic to top CMakeLists install cvmatio libs (well, only for mac...) Add vbbGallery (if cvmatio is being used) Add cvmatio library as optional 3rd party lib Heatmap improvements Ignore the Caltech annotations Add SeqReader to Stream to process Caltech Pedestrian seq files Add Caltech Pedestrians dataset to downloadDatasets.sh Bug fix with linspace linspace bug fix Linspace helper function Better cropping for eyes strip subdirectory from OPENBR_DIR to ensure it points to the root dir fixed #107 fixed set-but-unused warning reintroduced useGui flag so it can be overridden ... Conflicts: README.md openbr/gui/utility.cpp openbr/plugins/stream.cpp
-
In stream, only release the calling thread after the last thread has exited the last stage. This should prevent any issues related to the calling thread being released, then deleting or otherwise damaging the stream while anything is still active.
-
If we are doing nonsense like composing algorithms in memory, checking for a NULL parent is not a viable way to detect when smartCopy has returned a loose transform. This is because root transforms created through algorithmCore or whatever also have NULL parents, but actually they will be deleted via QSharedPointers, so adding them to a parent chain is dangerous, and they can show up as child transforms if we say attach them as children of a stream or distribute transform as part of a parallelization scheme. So, instead we add an output parameter to smartCopy indicating if the returned pointer is a newly allocated transform, that is not already set up to be deleted.
-
By default, when Transform::fromAlgorithm is used, attach a stream transform as the root of whatever transform is created (can be disabled with a flag). Actually implement stream project(template), give a warning if only returning one of N templates.
-
Move progress counter after gallery output, this should hopefully give slightly more accurate initial ETAs. When doing the finalize step in stream projectUpdate, don't push empty sets through the rest of the transforms (this reduces spurious calls to project, making progress counter work slightly better).
-
Merge Datasource/DataSourceManager, leaving DataSource as the primary interface for opening a template list. Introduce an alternate hieararchy for things that are done to individual templates. Rename FirstStage->ReadStage. Drop LastStage as a unique class, it can be represented as a single threaded stage with a transform that just collects the templates it receives. Introduce a separate class contaiing the stream mode enum. This avoids a lot of circular dependencies, giving us a more sane file layout.
-
When setting up the stream in enroll, use the Stream interface's staging logic on the input algorithm. Making this happen is slightly complex when we don't particularly have header files, but on the plus side algorithms incorporating something like Show (e.g. ShowFaceDetection) will not be used as a single threaded stage in the process.
-
Allows users to directly specify how stream handles input data (i.e. reads from a video source, or just distributes the templates)
-
Since copies are only actually made in calls to distribute, we don't need to be initialized to set up the TimeInvariantWrapperTransform, and can do it in the constructor. This means subclasses don't need to explicitly call TimeVaryingTransform::init, although it depends quite strongly on Resource having a particular behavior.
-
Add a TimeInvariantWrapperTransform member of TimeVaryingTransform, and use that in TimeVaryingTransform::project for thread safety. This is the strategy previously used in Distribute, but putting the alias on TimeVaryingTransform gives us more safety if Distribute is not in fact the top level transform. Note: copies are only made off of calls to project, so having the alias on every TimeVaryingTransform is not too wasteful.
-
This needs to be a little more complicated. Retain the project pattern done by Streams during partial projects by using a timeVarying transform to collect the output template sets (grouped as they are at the end of the partial stream).
-
This should be correct, but is fairly inefficient. Further work could be done if anyone is actually interested in using it.
-
Now, Stream takes a single transform argument. The old interface remains, renamed to DirectStream. If that transform is a pipe, Stream will split its child transforms appropriately, and set up a DirectStream. Adjacent non-timeVarying transforms are grouped in pipes, time varying transforms all get separate stages. The default behavior isn't necessarily ideal if e.g. a lot of light time varying stages are present, in that case its possible the additional synchronization costs will outweight gains from paraellelism (due to having more separate single thread stages). In these cases DirectStream may be preferable, however current algorithms seem largely unaffected.