Difference between Cvb.SharedImg and Cvb.Image.IMG

I try to clear things up a bit - that is actually why we introduced the new OOP CVB interfaces:

  • CVB.Net for .Net languages
  • CVB++ for C++
  • CVBpy for Python

These are wrappers around our C api (using the C api). You are currently using a direct translation of the C api for .Net. The new .Net wrappers are written like the wrappers I wrote in the earlier post, but using their own types. The goal for these is that the data and operations you need are attached to the objects you expect to hold them (like having an Unlock() method on the RingBufferImage). The link to Getting Started with CVB.Net gives an introduction. It should make your life working with CVB much easier. Switching to it depends heavily on how much CVB code you have written so far.

The Timestamps

Why do we have three ways to read-out a timestamp?

  1. IRingBuffer.RBGetRingBufferInfo:
    To get the timestamp of a specific ring buffer image.
  2. IGrab2.G2GetGrabStatus:
    To get the timestamp of the latest awaited image (via IGrab2.G2Wait). It is shorthand for
    int bufferIndex;
    int res = Driver.IRingBuffer.RBBufferSeq(m_DriverImage, 0, out bufferIndex);
    double timestamp;
    res = Driver.IRingBuffer.RBGetRingBufferInfo(m_DriverImage, bufferIndex, Driver.IRingBuffer.TRingbufferInfoCMD.RINGBUFFER_INFO_TIMESTAMP, out timestamp);
    
  3. IDeviceControl:
    This just gives you the full resolution of the timestamp delivered by the transport technology. A double normally suffices, but in GEV/U3V timestamps are integers with the unit ticks (the tick-frequency can normally be queried via the GenApi).

As I said the driver image (m_DriverImage) is special: it represents the driver, all its controlling interfaces (like IRingBuffer, IImageVPA, IDeviceControl, …). IImageVPA is the interface you use for image data access (width, height, data type, pixels, …). The m_DriverImage always points to the image you synced last via G2Wait. As seen above and in the wrapper I wrote you can query the actual ring buffer image index that has been filled via

int bufferIndex;
int res = Driver.IRingBuffer.RBBufferSeq(m_DriverImage, 0, out bufferIndex);

The query via IDeviceControl and G2GetGrabStatus always accesses the latest awaited image (G2Wait). Thus the timestamp returned by these two ways will change the next time G2Wait returns successfully.

The IRingBuffer timestamp query will return the timestamp of the image at the given buffer index – not the latest awaited one. This value will only change if this specific buffer is overwritten by the acquisition engine.

If you query the timestamp of the ring buffer image of the index returned by RBBufferSeq right after the G2Wait call, the values will be the same for all three methods. They will differ, though, after you called G2Wait again: the buffer index for the newly awaited image will have changed (a new call to RBBufferSeq will give you a new index).