Independent and future-proof: decoupling of hardware and software through image abstraction

Size: px

Start display at page:

Download "Independent and future-proof: decoupling of hardware and software through image abstraction"

Sibyl Whitehead
6 years ago
Views:

1 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

Hardware components usually not available

processors and operating systems becomes

2 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

transport interface of the data (Transport Layer) Every GenICam Transport Layer has two ends, the Consumer end and

3 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

4 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

5 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

6 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

therefore easily transferable to different operating systems and processors Strict adherence to design rules

7 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) Thread safe Lifetime guarantee New functionality introduced by new interfaces

8 ACCESSING ACQUISITION HARDWARE THE HARDWARE ABSTRACTION LAYER OF CVB Grabbing images IGrabber IPingPong IGrab2 ILineScan Accessing the hardware IDeviceControl INodeMapHandle INodeMapHandle2 Trigger and I/O ISoftwareTrigger ITrigger IBasicDigIO Selecting the hardware IBoardSelect IBoardSelect2 ICameraSelect ICameraSelect2 INotify IPropertyChange IRegPort

9 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 OVER TIME CVB IMPLEMENTED 4 ACQUISITION INTERFACES IGrabber Single buffer frame grabber or camera Repeated snaps will fill the buffer IPingPong Two buffers filled in ping-pong

10 ACQUISITION INTERFACES OVER TIME CVB IMPLEMENTED 4 ACQUISITION INTERFACES IGrabber Single buffer frame grabber or camera Repeated snaps will fill the buffer IPingPong Two buffers filled in ping-pong mode Process one buffer while acquiring into the second buffer IGrab2 Fills a ring buffer of a fix length Process one buffer while filling the other buffers IRingBuffer Change the number of buffers IGrab2 can use dynamically

11 IGRABBER INTERFACE APP VIN Camera Snap Ret Snap Snap function waits until an image has been acquired The availability of only one image buffer will likely lead to frame drops

Ret WaitPingPong StartPingPong Ret StartPingPong UpdatePingPong Ret UpdatePingPong Two

12 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 Two buffers are used in ping-pong mode No frame loss as long as processing keeps up with camera frame rate

13 IGRAB2 INTERFACE I APP VIN Camera G2Grab G2Wait Ret G2Wait G2Grab starts acquisition into a ringbuffer The frame transfer will increase the acquisition index and lock the acuired buffer G2Wait waits until an image has been acquired and increase the processing index

14 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

15 IGRAB2 INTERFACE III APP VIN Camera G2Grab G2Wait TIMEOUT G2Wait waits until an image has been acquired, but not forever

16 IGRAB2 INTERFACE IV APP VIN Camera G2Grab Images that have been acquired will lock the ringbuffer

17 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

18 IGRAB2 WAIT MODES ADVANCED WAIT MODES FOR MANY FRAME GRABBERS OR CAMERAS Select the mode in driver 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

19 IGRAB2 WAIT MODE = 1 (DEFAULT) APP VIN Camera G2Wait The next image in acquisition order will be used

20 IGRAB2 WAIT MODE = 2 APP VIN Camera G2Wait The last image in acquisition order will be used, all previous images will be removed

21 IGRAB2 WAIT MODE = 0 APP VIN Camera G2Wait The driver will wait until the next image has been acquired, all previous images will be removed

IRINGBUFFER DYNAMICALLY CHANGE THE NUMBER OF BUFFERS AVAILABLE TO IGRAB2 Limited by the available host memory ~1GByte under Windows 32 70GByte

22 IRINGBUFFER DYNAMICALLY CHANGE THE NUMBER OF BUFFERS AVAILABLE TO IGRAB2 Limited by the available host memory ~1GByte under Windows 32 70GByte successfully tested under Windows 7 64Bit Supports manual and automatic Lock modes Allows for a simple implementation of high speed recording systems

23 STILL GOT QUESTIONS? Join our LinkedIn group EUROPEAN VISION TECHNOLOGY FORUM and continue discussing with our experts.

24 THANK YOU FOR YOUR ATTENTION! STEMMER IMAGING GmbH Gutenbergstr Puchheim Germany Phone: Fax: Your contact: Martin Kersting

Independent and future-proof: decoupling of hardware and software through image abstraction

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,