Will there ever be a libdc1394-like API for USB3 Vision and/or GigE Vision cameras?

3.2k views Asked by At

As firewire cameras are becoming obsolete because of their bandwidth limitations, it seems as though camera manufacturers are switching to USB 3.0 or Gigabit Ethernet interfaces. Both have standards USB3 Vision and GigE Vision, which many manufacturers are adhering to.

However, it seems as though each manufacturer - Basler, Pointgrey, Ximia, and others - has its own SDK for interfacing with their cameras. When developing an application, developers would need to learn and interface with each API which is a pain, or stick to one manufacturer. I may be misunderstood but, in that case, what is the point of an industry standard if developers need to use manufacturer dependent APIs?

For firewire cameras, developers have access to libdc1394 cross-platform, high level API. They do not need to worry about who manufactures the camera and do not have to write separate drivers. Is something like this even possible for USB3 Vision and GigE Vision? If so, who would develop it?

4

There are 4 answers

2
AdamF On BEST ANSWER

I'm not very familiar with libdc1394, but I know a little bit most of all other interfaces. USB3 Vision, GigE Vision and all other standards may be connected using one common interface: GenICam :

The goal of GenICamTM is to provide a generic programming interface for all kinds of cameras and devices. No matter what interface technology (GigE Vision, USB3 Vision, CoaXPress, Camera Link HS, Camera Link, 1394 DCAM, etc.) they are using or what features they are implementing, the application programming interface (API) should be always the same.

The GenICamTM standard consists of multiple modules according to the main tasks to be solved:

GenApi: configuring the camera.

Standard Feature Naming Convention (SFNC): standardized names and types for common device features. Includes Pixel Format Naming Convention (PFNC).

GenTL: transport layer interface, grabbing images.

CLProtocol: GenICam for Camera Link.

GenCP: generic control protocol.

GenTL SFNC: recommended names and types for transport layer interface.

Most of the biggest camera producers supplies GenTL providers to work with their cameras.

Unfortunately I don't know any open source High Level Api for GenICam. I know 2 image processing libraries with GenICam support: Adaptive Vision Library and Halcon but they are not cost free.

Another less popular in industry common image grabbing interface is: DirectShow. DirectShow is supported for example by: Ximea, Net-Gmbh, Basler and almost all web cameras.

So in my opinion if you want to use one common interface for all cameras you should consider using GenICam interface.

0
IamSierraCharlie On

An old thread, but in case someone else comes looking...

Plus 1 for Aravis for opensource and in Linux. At the time of me writing this response, the project is now supporting USB3 Vision cameras although some are better than others. There is a lot of activity on the repo at Github at present

On the paid side of things (In windows at least) there is an API called ActiveUSB (for USB3 cams) and ActiveGigE by A&B Software. I've no experience with the GigE software, but have used the USB3 vision library that they provide and it is quite good across different cameras as long as they adhere to the GeniCam standard. It also offers a trial period allowing you to decide if its right for you or not. It is useable in Python, C, C# & VB languages. If you are developing for a commercial product/ solution then its worth taking a look at. On the other hand, if you don't want or can't afford to spend any money, then Aravis is the way to go although.

Its also worth noting that some manufacturers are starting to provide demos written in Python that can be used to create your own API. As already mentioned, this is limited for use with the manufacturers cameras and not easily interchangeable unless you have good code writing skills.

1
dom0d0mod On

At least for GigEVision, let me mention the Aravis project is available for linux. It is meant to be a GenTL/GenICam library but only supports GigE right now due to the driver-constraint problems outlined below.

First of all, I agree with Martin's point that creating a general SDK is not in the interest of the camera manufacturers themselves for competitive and support reasons. The manufacturers develop proprietary usb drivers (for USB3Vision) and NIC filter drivers (optional for GigE but highly recommended) in conjunction with their SDKs. It incentivizes them to lock in users to their ecosystem and to separate them from the competition.

This is the reason why I disagree with AdamF - I do not think that GenTL is widely supported by camera manufacturers, particularly for GigE or USB3Vision camera. Supporting GenTL would effectively allow users to use any general purpose SDK while still leveraging the manufacturer's proprietary drivers

I think it would be easier for OpenCV to support GenTL instead of GigE/U3V at this point because the giant hurdle to develop GigE/U3V drivers across the available hardware platforms. GenTL support would at least only be a software-based interface at this point.

1
user5318631 On

Check out https://github.com/ni/usb3vision

It implements the core USB3 Vision specification as a kernel driver. To control a camera, you would still need to wrap some usermode logic around it that connects it up to GenApi (the reference implementation of GenICam) as well as handles buffers queued/de-queued to the driver.

Also, regarding your question about if it is possible to implement a vendor-independent driver, of course it is. That is indeed the point of the standards. Most camera vendors provide their own proprietary SDK with their cameras for various reasons, but there are independent SDKs that will work with any standards-compliant GigE Vision and USB3 Vision cameras. Whether any of these are open-source is a good question, and I am not aware of any that are. The above-mentioned USB3 Vision driver is used by National Instruments's IMAQdx driver, which is commercial and closed source.