Access to complex video devices with libcamera

Posted Jul 25, 2019 22:35 UTC (Thu) by andy_shev (subscriber, #75870)
Parent article: Access to complex video devices with libcamera

While idea is good, I can’t get rid of picturing https://xkcd.com/927/ in my mind.

Access to complex video devices with libcamera

Posted Jul 26, 2019 4:12 UTC (Fri) by creemj (subscriber, #56061) [Link] (4 responses)

While xkcd:827 is often trotted out when someone proposes new interfaces or standards, in this case I am not so sure it is apt. There is a real problem with camera interfaces and the multiple standards: v4l2, libdc1394, gig-e (not natively supported on Linux), camera-link (though this is pretty much obsolete now), USB-3 protocols (often requiring closed propriety software), and I am sure there are more. If you want to write software that can support all (or even most cameras, particularly machine vision cameras) then you have to support multiple protocols. So I this as one space where a library that manages all these protocols and provides one unified interface to access cameras would be a very significant advance.

Access to complex video devices with libcamera

Posted Jul 26, 2019 19:01 UTC (Fri) by guus (subscriber, #41608) [Link] (1 responses)

GigE is definitely natively supported on Linux; there are multiple free (at least as in beer) SDKs that support it. USB-3 Vision is just dc1394 over USB, and is supported by libdc1394. The two most annoying experiences I've had while working with numerous scientific/machine vision cameras are:

1. Cameras and/or framegrabbers requiring firmware to be loaded before they work.
2. Cameras using a proprietary protocol for configuring parameters like exposure time, frame rate and so on.

UVC and DC1394 are very nice because they at least have a standard way of setting parameters that almost all cameras use. Gig-E has the GenICam standard, but it's not supported by all cameras.

For USB webcams, setting parameters is trivial nowadays, but actually getting the stream of images is getting more and more complex. The reason is that high end cameras are getting better resolution and framerates, yet are still bound by USB bandwidth limitations. So while early cameras sent simple YUV or JPEG-compressed images, now we have cameras that can actually send a H.264 stream. Videochat applications might want to get the H.264 stream because they can then send it out over the Internet without having to recompress anything.

Access to complex video devices with libcamera

Posted Jul 31, 2019 14:55 UTC (Wed) by loose11 (guest, #114677) [Link]

>> Gig-E has the GenICam standard, but it's not supported by all cameras.

Some camera manufactures claiming that they implemented the standard. I had a issue with GenICam, where the standard was "implemented" but they made some hidden calls for specific parameters in there library. At the end, they were overriding my parameters.

Access to complex video devices with libcamera

Posted Jul 27, 2019 5:49 UTC (Sat) by flussence (guest, #85566) [Link] (1 responses)

If this could do for video inputs what libinput did for HID devices, that'd be wonderful. I know quite a few people who have no choice but to keep win32 around because it's the only way to get their off-brand (or sometimes brand) HDMI-to-USB3 or whatever device to function.

Access to complex video devices with libcamera

Posted Aug 1, 2019 10:39 UTC (Thu) by swilmet (subscriber, #98424) [Link]

I also think that libinput is a quite good comparison as an analogous project. A good description of why libinput exists:
https://who-t.blogspot.com/2018/07/why-its-not-good-idea-...

In the talk/article:

> libcamera was started with the intent of being "the Mesa of the camera stack"; its purpose is to make it easy for applications to interface with camera devices.

I would be interested to know more about this comparison to Mesa, the libcamera website doesn't mention Mesa. What do libcamera and Mesa have in common?