GenICam™ GenDC Format

Since version 2.50 Impact Acquire supports the GenICam™ GenDC format developed by the GenICam working group. This format was triggered by the need to allow various vendors to transfer specific payload without the need to standardize a new payload format all the time. By using this format devices have an interoperable way to transfer e.g. 3D data which typically consists of several independent parts of data belonging together. So the main idea was to be able to report a single block of memory to the user that contains all this information and to have an interface that can access each part of this block of memory. A typical example where the GenDC format could be used is with a 3D camera or a dual head stereo camera where either multiple images that logically belong together (left sensor and right sensor or 3D image and confidence mask). But there are other use cases as well like e.g. when a device supports a hardware JPEG encoder an application might want to access both the raw data and the compressed data for different purposes like perform image processing on the raw data while streaming the compressed data via the network.

The API for accessing GenDC or multi-part data belonging to a mvIMPACT::acquire::Request object basically consists of 2 functions:

• mvIMPACT::acquire::Request::getBufferPartCount()
• mvIMPACT::acquire::Request::getBufferPart()

properties residing in a separate list BufferParts within each request.

When mvIMPACT::acquire::ptGenDC data is reported by the mvIMPACT::acquire::Request::payloadType property and the mvIMPACT::acquire::SystemSettings::genDCParserEnable property is set to mvIMPACT::acquire::bTrue (the default) all the properties residing in the Image list of a request are don't care thus have the cfInvisible flag set. If normal (thus non-multi-part or GenDC) data is reported or mvIMPACT::acquire::SystemSettings::genDCParserEnable is switched off all properties residing in the BufferParts list of a request are don't care thus have the cfInvisible flag set. For GenDC data then mvIMPACT::acquire::Request::imageData points to the start of the container descriptor. Details on how to parse a GenICam™ GenDC descriptor can be found in the GenDC specification

The memory layout of a GenDC buffer can roughly be described like this:

One way of dealing with GenDC data in Impact Acquire could be implemented like this:

// ... more code
FunctionInterface& fi( getFunctionInterfaceFromSomewhere() );
int requestNr = fi.imageRequestWaitFor( timeout_ms );
pRequest = fi.isRequestNrValid( requestNr ) ? fi.getRequest( requestNr ) : 0;
if( pRequest )
{
  if( pRequest->isOK() )
  {
    const unsigned int bufferPartCount = pRequest->getBufferPartCount();
    if( bufferPartCount > 0 )
    {
      // data has been delivered in GenDC or multi-part format. Features like 'pRequest->imageWidth' are "don't care"
      for( unsigned int i = 0; i < bufferPartCount; i++ )
      {
        BufferPart& part( pRequest->getBufferPart( i ) );
        cout << "Part " << i << " carries data type " << part.dataType.readS() << ", " << part.dataSize.read()
             << " bytes starting at " << part.address.read() << endl;
      }
    }
    else
    {
      // access feature the standard way. This buffer does not carry GenDC or multi-part information
      cout << "Data has been captured: "
           << pRequest->imageOffsetX.read() << "x" << pRequest->imageOffsetY.read()
           << "@"
           << pRequest->imageWidth.read() << "x" << pRequest->imageHeight.read()
           << "(" << pRequest->imagePixelFormat.readS() << ")" << endl;
    }
    // chunk data evaluation would start here as it works exactly the same way no matter in which
    // format the data is delivered!
// ... even more code

Note

Some more specific sample code about the handling of GenDC/Multi-part data can be found within the handleAdvancedPayloadType() function within the exampleHelper.h file. This file is part of the example applications of a typical Impact Acquire installation. Some sample applications will illustrate the handling of GenDC/Multipart buffers.

See also

• ContinuousCapture.cpp
• SingleCapture.cpp
• GenICamInterfaceLayout.cpp

In case the unprocessed GenDC container shall be received something like this could be implemented:

// ... more code
SystemSettings ss( getDevicePointerFromSomewhere() );
ss.genDCParserEnable.write( bFalse );
// ... more code
FunctionInterface& fi( getFunctionInterfaceFromSomewhere() );
int requestNr = fi.imageRequestWaitFor( timeout_ms );
pRequest = fi.isRequestNrValid( requestNr ) ? fi.getRequest( requestNr ) : 0;
if( pRequest )
{
  if( pRequest->isOK() )
  {
    if( pRequest->payloadType.read() == ptGenDC )
    {
      // This buffer does carry a GenDC container
      cout << "A GenDC Container has been captured! Start parsing it at "
           << pRequest->imageData.read() << ", but don't read beyond "
           << reinterpret_cast<char*>( pRequest->imageData.read() ) + pRequest->imageSize.read() << "!" << endl;
    }
    else
    {
        // In case GenDC and nothing else was expected raise the alarm
    }
// ... even more code

Limitations

For mvIMPACT::acquire::ptGenDC payload currently the same limitations as described here will apply: Limitations