What was the first GenIcam module to be ratified in 2006 and what are the main developments since then?
Dierks: You need three modules to cover the key things in order to deal with a camera. First one is the configuration mechanics, which is the GenAPI module, the 2nd one is SNFC to get standardised names for the features. But there is a 3rd one which is the transport layer driver access. Because if you want to use drivers from 3rd parties, you need a standardised way of dealing with them. The reason why this wasn’t released in the beginning was mainly about IEEE 1394 and GigE Vision. For those interfaces, the camera manufacturers have already their own drivers. So the business needs for an interface dealing with drivers was not that much. But it changed with CoaXPress (CXP) because it is a frame grabber based interface. And the frame grabbers used to come from different vendors than the cameras.
Schmidt: Another important module is PFNC (Pixel Format Naming Convention), which standardises the names and formats of pixels. If someone uses, e.g. an 8bit Bayer format, they know how data formatting goes. But if you have a frame grabber the software has no idea how the frame grabber will provide the serial interface to the camera. Later came GenCP (Genric Control Protocol) a standardised protocol for the control channel that was used in USB3 vision. The idea behind it was: you do it once and then can use it for different transport layers. The latest edition was GenDC (Generic Data Container), a format to combine several image components in one container and provide a generic way to transport this container.
How might AI and embedded vision influence future GenIcam developments?
Schmidt: AI processing is usually done on a host system, like a GPU. Embedded systems sometimes provide accelerators that can be used inside a camera. Even if they typically act and feel like a regular Linux system, with one or more cameras attached to it, what we have is a standard system that looks like a camera. GenIcam has all that’s necessary, to connect a camera to an AI or embedded system. OptoMedias ultrakompaktes Mini SFF bringt zuverlässige, schnelle Glasfaserverbindungen in Industriekameras der nächsten Generation. ‣ weiterlesen
Fiber Mini SFF für GigE Vision
Dierks: There has been quite some attempt to make GenIcam useful for embedded, but we were not really successful. The reason for that are two technical and a political challenge. The technical challenge is that embedded use is implemented on video for Linux. People are using that functionality for cameras which are implemented in kernel mode drivers. It is not really suitable to be run in kernel mode because it’s quite a large thing. The other challenge is that in the embedded world, people are used to program using Gstreamer, a different programming model than the one we’ve chosen for GenIcam. The political challenge is that a lot of embedded systems are running under Linux and the Linux community is strongly insisting on Open Source software. But the reference implementation is currently not Open Source, because we wanted to make sure that it isn’t forked. When you are a camera manufacturer and you have to test a new product, you test it against the reference implementation and this is something every software vendor is using. Then you get away with much lower testing effort than if you needed to get the implementations from every software vendors. The same argument goes the other way around. If you’re a software vendor and you want to test with a camera, you can rely on. This is why GenIcam is not Open Source. The approach to solve the kernel mode problem is typically that you run the GenIcam reference implementation as a background service (daemon) and as a normal application software (userland). If the kernel mode gets kind of a call set, then you just switch to userland and ask the daemon what kind of register you have to set. Then you can set it from kernel mode. There are prototypes from that model which works pretty well. The GStreamer problem can also be solved: There are several implementations around where you can just make a GStreamer pipeline and put in the pipeline something like ‚gain minus ten‘, and you can seamlessly put that into the GStreamer syntax. The EMVA, which is hosting GenIcam, is currently discussing whether to make the reference implementation Open Source.
How do you expect GenIcam to evolve by 2036?
Schmidt: One major extension we are already working on is a standardised feature interface API (working title GenFire). The current GenAPI defines the format of the XML description, but the reference implementation to interpret the XML file is technically not a standard. It has many more functions than needed for feature access. Our idea is to specify the functions and application needs to enable different and simpler implementations. This will allow us to to bring devices up under the GenIcam umbrella that couldn´t be integrated so far. For example, devices, where you don’t have an XML description, but an API. Another possible extension is that the CCNs should gain more attraction. There might be a need to standardise the way these AI networks are configured.
