-
Compare changes
-
For galleries, add a property to Gallery indicating the number of templates that will be read per block (for galleries that do incremental reads--really just galGallery and memGallery). For outputs, add two properties indicating the rows and columns of blocks to use (i.e. support non-square output blocks). For both classes, default these properties to Globals->blockSize
-
Instead of returning references to static memory (which are invalidated by subsequent or concurrent calls to the function), require users to input string buffers to functions that return strings. Affected functions: br_get_filename br_get_metadata_string br_scratch_path br_objects br_most_recent_message In some GUI functions, use C++ functions instead of going through the c api add a c++ method correspondign to br_objects (which returns a stringlist instead of merging the lines) br_read_pipe and br_get_header also use static memory in a similar way, but are not addressed in this commit.
-
This change consolidates the previous 'read' and 'noDuplicates' flags into a single 'append' flag. If append is specified, and an output gallery already exists, and the gallery format supports read/write or has explicit append support, then enrollment will be restricted to those files in the input list not already present in the gallery, and the results will be appended to the existing gallery. append defaults to 'false', which is a deparature from previous behavior. The .gal format has explicit append support, for other cases, if the gallery supports both read and write (less common than you might think), we support append by reading the existing gallery, and writing back out to an overwriting file. It should be possible to add explicit append support to several other gallery types.
-
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.
-
Conflicts: openbr/core/core.cpp
-
Conflicts: openbr/core/core.cpp
-
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.