C++ Camera Grabber

The C++ Camera Grabber camserver can grab image data from multiple camera sources and process the datata in real time. Typical processors (here called Extractor) are to store the data as a file or to render some part of the image data as preview and send it to some GUI program.

The program takes no direct input but can be controlled via Remote Object Call over some network socket. It is stopped by pressing Ctrl+C once. Pressing it a second time will kill the program immediately.

As the program is heavily threaded, the direct program flow is not immediately visible from the source code. Here, you will find an overview graphic about the communication, which is maybe more insightful. The graphic shows only threads for one camera. In reality mutliple cameras can be connected and will start multiple threads (ImaqGrabber + CamManager).

Threads inside the camserver process are shown in rectangular shape, while external (possibly connected via network) processes are shown in oval shape. All communication over solid arrows happens via ZeroMQ, while dashed arrows can contain ZeroMQ communication but not exclusively. ZeroMQ communication inside the camserver process is done via 'inproc://' sockets. This is especially important for the data stream, as this ensures, that the data is never actually copied inside the process. The exceptions are obviously:

Camera-Memory -> System-Memory
System-Memory -> Harddisk

The downside of not copying the data is, that a slow preview Extractor could potentially hold references to many old data frames and thereby crash the ImaqGrabber because it does not find any free preallocated space. This currently does not seem to be a real issue (never happens in practice) and could also be worked around by stopping all preview threads while capturing important images or increasing the preallocated image space.

A single ImaqGrabber can have multiple Extractor instances connected at the same time, so you can e.g. have a FileStorageExtractor which dumps all received image data into a file (after closing the file, it will be accompanied by an additional header file, containing metadata), and mutliple ZmqPubExtractor (maybe one for the 200th and one for the 300th wavelength) to send some preview data to the GUI.

The GUI can start and stop Extractor instances at any time by sending appropriate commands though the RocBroker to the right CamManager.

The current purpose of the InfoServer is to provide a bindable endpoint of the previewProxy, so that the GUI needs to know only how to connect to the RocBroker.