-
… to keep scale consistent
-
* Store confidence values in the Mat instead of the QMap. * Negative features are resized to the detector window size
-
Currently, no QtWarnings generated on windows, how exciting.
-
Although we do have to use exactly 1 thread for all operations on a given socket (at least on windows...), it doesn't have to be the main thread. Even odds if this will break windows support in some unforseen way.
-
In a shocking turn of events, Qt is annoying, and not particularly consistent across platforms. Lot of not particularly intelligent business with signals to get things to execute on the main thread. I would rather not even use the event driven interfaces to QLocalServer/QLocalSocket but sadly it seems that on windows even if we try and use the blocking calls, we are still required to use using exactly one thread per object. Of course that makes sense since obviously we are writing a simple event-driven GUI application.
-
Add a wrapper transform that runs a child transform in a separate process
-
The primary addition is ProcessWrapperTransform, which takes a transform as a child, and creates a worker process that runs that transform. The main point of this is to handle cases where we interface with non-threadsafe code, and need to isolate transforms in their own processes if we want to use multiple copies of them. Inter-process communication is handled using QLocalServer/QLocalSocket, the actual worker processes are additional instance of br, which does mean this bleeds out to the public API to an unfortunate extent. Initial trvial tests seem promising, but generally we can expect performance to degrade if larger amounts of data are transfered, ideally we should do ProcessWrapper(Open+FeatureExtraction), so the data transfered to the worker is an image name, and the data transfered from the worker is a feature vector.
-
Decouple variantlist
-
Conflicts: openbr/core/qtutils.cpp openbr/plugins/landmarks.cpp
-
This reverts commit 04105a9414fb68a95667812184e89cb937e858d5.
