|
<< Click to Display Table of Contents >> Navigation: Migration Guide for the Acquisition Stacks > Purpose of the 3rd Generation Stack |
With Common Vision Blox 13.3 new image and data acquisition interfaces have been introduced in 2020. After the original IGrab and IPingPong interface from 1997 and the IGrab2 interface from 2003 this is now the 3rd generation software interface for data acquisition in Common Vision Blox. Unlike its predecessors, the 3rd generation interface now also support acquisition of multiple streams from one device, acquisition of structured data streams that contain multiple logical parts (enabling the acquisition of 3D point clouds directly from devices that support this) and acquisition into user-specified destination buffers.
The sole precondition for using the 3rd generation acquisition stack is to work with a so-called GenTL (generic transport layer). If you have already been using GigE Vision or USB3 Vision devices you have already relied - unwittingly - on the services of the underlying GenTLs that were installed with Common Vision Blox. These days, many more devices (like e. g. frame grabbers) support this software standard and can be used with all the features of the 3rd generation acquisition stack. Whether your device is among them can be checked using the GenICam Browser: If you have Common Vision Blox and the software package provided by your hardware manufacturer installed, simply open the GenICam Browser, which will search and display all accessible transport layers on your computer.
The 2nd generation acquisition stack (based on the IGrab2 interface) allows the acquisition of streams that provide regular image buffers (with the possible option to make use of chunk data) one after the other. The buffers handed back to the caller are always allocated and owned by the driver. There is no possibility to open multiple streams or structured buffers consisting of more than one image buffer or even buffers containing different data. The use of a caller-allocated buffer is not possible with the 2nd generation stack.
To summarize, the 2nd generation stack's functionality:
•Acquisition from devices with only one stream
•Acquisition from devices with a stream containing only image data as one part
•Acquisition into buffers, which are allocated and owned by the driver
The GenICam standard has over time been extended to support more possibilities than implemented in the 2nd generation acquisition stack in order to keep up with evolving requirements of camera users and camera vendors. Recently introduced features are:
•Acquisition from devices that provide more than just one data stream
•Acquisition from devices that provide a structured buffer with multiple distinct parts (subsequently called "composites")
•Acquisition from devices that do not send a “traditional” image buffer but data like 3D point clouds or HSI cubes
•Acquisition into buffers that have been allocated by the caller (as opposed to buffers that have been allocated by the driver itself)
To accommodate these new use cases, the acquisition engine of CVB has been modified. Where before the distinction between device and image was not immediately visible on the C-API level and only modeled into the object oriented wrappers, the new acquisition stack introduces the the following set of entities in the CVB hardware abstraction layer already in the C-API:
Device
•The Device acts as the representative of the camera/sensor in the CVB driver stack.
•On a device, one or several streams can be accessed that facilitate the data transfer from the remote device.
Stream
•A stream provides a time series of the objects that its owning device can provide. When accessing a stream provided by a device, the developer has to be aware of the device capabilities and specify whether the stream delivers images, point clouds or composites. These three cases are further explained in Stream Types.
•Each stream owns a flow set pool which defines a list of buffers into which the data coming from the stream will be acquired. A flow set pool can be provided by the caller or allocated by the driver.
•For each device and each stream, an acquisition engine can be instantiated that controls the acquisition, specifically the passing of the received buffers to the caller.
Depending on the hardware used for streaming, the caller can choose between three different stream options that return the corresponding object type during acquisition:
Image Stream
This stream type matches the vast majority of applications, where a standard camera is used for acquiring mono or color images. The objects acquired can be interpreted as traditional image buffers (i. e. in terms of width, height, color format). When using Image Streams to acquire from devices that supply multi part images, the stream will just provide the first image encountered in the returned composite.
Point Cloud Stream
As the name implies, this stream type delivers the data received from a 3D acquisition device. This stream type allows an indexed access to the different parts of the point cloud data (typically coordinates in x, y and z; potentially also additional data like confidence, color, or normal vectors).
Composite Stream
If none of the above stream types properly matches what the device provides, this generic stream type offers a dynamic payload interpretation based on the other interpretable object types. For example, this object type can combine buffers holding an image with buffers holding a point clouds at the cost of increased complexity when accessing the structured data.
The newly introduced cancellation tokens give the possibility to stop wait calls rather than stopping the entire acquisition. This makes sense because restarting the whole acquisition takes significantly longer than reinitiating a wait for the next data.
A typical use for this would be a scenario where an external stop signal is received by the application. The fastest way to stop the acquisition and restart it once the (externally defined) conditions are right would be to abort the wait function with a cancellation token. The wait call will then return with the wait status "abort".