Independent and future-proof: decoupling of hardware and software through image abstraction Martin Kersting, Technical Director, Authorized Executive STEMMER IMAGING STEMMER IMAGING Technology Forum 2015, Unterschleißheim
THE CHALLENGE WHY USE ABSTRACTION THROUGH SOFTWARE INTERFACES? Hardware components usually not available indefinitely Different camera/acquisition technologies easily manageable through abstraction layer Targeting different processors and operating systems becomes easier Abstraction provides the flexibility to easily adapt even to changing application requirements
THE CHALLENGE WHAT ABOUT STANDARDS LIKE GIGE-VISION AND USB3-VISION Both are low-level standards defining mostly the transport protocol The GenICam standard on top gives access to the properties of the camera (XML file) and the transport interface of the data (Transport Layer) Every GenICam Transport Layer has two ends, the Consumer end and the Producer end The producer comes from a hard- or a software manufacture and may support only a limited range of devices
SOFTWARE INTERFACES SOFTWARE INTERFACES Well-defined and documented contracts that can be implemented by an arbitrary number of software components Contracts are immutable Such components can easily be individually tested against their contracts Consumers of these components need no knowledge about the contract s implementation but may rely on the behavior defined by the contract (black-box character) Availability of specific interfaces can be queried at runtime Ideally usable across different compilers and programming languages Components that implement the same contract become interchangeable on the code level as well as on the binary level
SOFTWARE INTERFACES SOFTWARE INTERFACES Software interfaces are a great basis for implementing a hardware abstraction layer Immutable contracts guarantee backward compatibility New functionality and technology trends can be wrapped in new interfaces Switching to different hardware boils down to swapping out one interface implementation for another one simply be loading a different driver
THE COMPONENT OBJECT MODEL COM THE COMPONENT OBJECT MODEL Introduced by Microsoft in 1992 An instance of an interface implementation is referenced through a pointer to an array of pointers to the methods of the interface (vtable-interface) The implementation can be identified and instantiated at runtime through a globally unique identified (GUID) Accessible via all the relevant development environments on the Windows platform But: Inherently bound to and therefore only available under Windows
PSEUDO COM THE COMMON VISION BLOX FLAVOR OF COM Introduced with Common Vision Concept in 1996 Conceptually derived from COM with minor differences Lightweight design without requirement for a component registry, therefore easily transferable to different operating systems and processors Strict adherence to design rules (e.g. no interface change since 1996) Binary backward compatibility over the whole product lifetime Yet always up-to-date with newly introduced interface abstractions for new features
ACCESSING ACQUISITION HARDWARE THE HARDWARE ABSTRACTION LAYER OF CVB Grabbing images IGrabber IPingPong IGrab2 ILineScan Accessing the hardware IDeviceControl INodeMapHandle INodeMapHandle2 INotify IPropertyChange IRegPort Trigger and I/O ISoftwareTrigger ITrigger IBasicDigIO Device selection IBoardSelect IBoardSelect2 ICameraSelect ICameraSelect2
HARDWARE INTERFACES Imaging Application Proprietary Algorithms CVB Tools Manto Minos Display OCX Display DLL Image OCX Image DLL Grabber OCX Driver DLL IImageVPA ITrigger IGrab2 IDeviceControl IBoardSelect ICameraSelect... CVB Image Object XXX.vin YYY.vin X64CL.vin X64AN.vin CVAVT1394.vin GenICam.vin GenICam.vin AVI.dll Hardware abstraction through the DDK Grabber Grabber IEEE1394 DCAM USB3-Vision GigE-Vision Video files Image files... Image Source: Hardware Image Source: File system
ACQUISITION INTERFACES CVB SUPPORTS FOUR APPROACHES TO IMAGE ACQUISITION Modeled into four different interfaces: IGrabber Single buffer frame grabber or camera Repeated snaps will update the buffer content IPingPong Two buffers filled in ping-pong mode Process one buffer while acquiring into the other buffer IGrab2 Fills a ring buffer of fixed length Process one buffer while acquiring into the other buffers IRingBuffer Allows changing the number of buffers IGrab2 can use dynamically Provides full control over the buffer lock mode
IGRABBER INTERFACE APP VIN Camera Snap() Ret Snap() Snap() method waits until an image has been acquired The availability of only one image buffer may lead to frame drops (not intended for high throughput)
IPINGPONG INTERFACE APP VIN Camera StartPingPong() Ret StartPingPong() WaitPingPong() Ret WaitPingPong() StartPingPong() Ret StartPingPong() UpdatePingPong() Ret UpdatePingPong() WaitPingPong() Ret WaitPingPong() StartPingPong() Ret StartPingPong() UpdatePingPong() Ret UpdatePingPong() Image acquisition and processing alternating between two buffers No frame loss as long as processing keeps up with camera frame rate
IGRAB2 INTERFACE I APP VIN Camera G2Grab() G2Wait() Ret G2Wait() G2Grab() starts continuous acquisition into a ringbuffer The frame transfer will increase the acquisition index and lock the acuired buffer G2Wait() blocks until an image has been acquired and increase the processing index
IGRAB2 INTERFACE II APP VIN Camera G2Wait Ret G2Wait The frame transfer will increase the acquisition index and lock the acquired buffer G2Wait() will unlock the previous processing buffer and increase the processing index
IGRAB2 INTERFACE III APP VIN Camera G2Grab G2Wait TIMEOUT G2Wait() generally waits until an image has been acquired but not indefinitely
IGRAB2 INTERFACE IV APP VIN Camera G2Grab Images that have been acquired will lock their ringbuffer slot
IGRAB2 INTERFACE V APP VIN Camera G2Wait G2Wait G2Wait() will unlock the previous image at the processing index and switch to the next image within the ringbuffer, making the buffer available for a new image
IGRAB2 WAIT MODES ADVANCED WAIT MODES Advanced wait modes fine-tune the behavior of G2Wait() (selectable in configuration file) ; waiting mode for grab2 ; 0 wait for new image ; 1 wait for next image after last delivered one ; 2 return last acquired image WaitNextFrame = 1
IGRAB2 WAIT MODE = 1 (DEFAULT) APP VIN Camera G2Wait The next image in acquisition order will be used
IGRAB2 WAIT MODE = 2 APP VIN Camera G2Wait The last image in acquisition order will be used any older pending images will be discarded
IGRAB2 WAIT MODE = 0 APP VIN Camera G2Wait The driver will wait until the next image has been acquired, all pending images will be discarded
IRINGBUFFER DYNAMICALLY CHANGE THE NUMBER OF BUFFERS AVAILABLE TO IGRAB2 Limited by the available contiguous host memory ~1GByte under 32 bit Windows 70GByte successfully tested under 64 bit Windows Supports manual and automatic Lock modes Allows for a simple implementation of high speed recording systems
STILL GOT QUESTIONS? Join our LinkedIn group EUROPEAN VISION TECHNOLOGY FORUM and continue discussing with our experts.
THANK YOU FOR YOUR ATTENTION! STEMMER IMAGING GmbH Gutenbergstr. 9-13 82178 Puchheim Germany Phone: +49 89 80902-0 Fax: +49 89 80902-116 info@stemmer-imaging.de www.stemmer-imaging.com Your contact: Martin Kersting