-
Send a deep copy of the current image to the GUI thread, copy must be called explicitly or a shallow copy will be done, and subsequent modifications to the buffer will cause crashes when the GUI thread tries to draw it.
-
Simplify SingleBuffer since controlling the total amount of frames being processed works quite well. Add a double-buffer scheme, which leads to a really marginal performance improvement (but I think it's cool).
-
Rather than putting limits on the number of items in the buffers of individual processing stages of a stream, put a limit on the total number of frames actively being processed by the stream.
-
Add Show2Transform (should replace ShowTransform eventually), which displays input images using QT, rather than going through openCV. Additional modifications to support doing this (since qt is quite particular about how GUI elements are created/modified). Create a QApplication instead of a QCoreApplication (if not building BR_EMBEDDED), restructure br.cpp's main to run its main work in a separate thread while the main thread sits in an event loop.
-
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.