[07:52] <johk> @waveform: good morning, any news on the pivariety cams ?
[08:34] <waveform> johk, morning -- sorry about the long delay! Been on holiday for much of the last week. There's not much news yet, I'm afraid -- two things I need to try and do this week related to it are to get libcamera bumped beyond Debian (preferably to RaspiOS' version if possible), and get some necessary detail to file bugs with the kernel team on why we can't (yet) successfully build the updated kernel module
[08:54] <johk> @waveform, was also on holidays last week.
[08:55] <johk> waveform, I managed to get the arducam patched libcamera to work on raspbian, but currently v4l2 is only suported indirectly with gstreamer... which is quite cpu intensive. opencv still seems to completely lack libcamera support.
[08:56] <johk> quite annoying... I would really like to avoid to use one of the closed industrial camera providers for this project
[09:02] <waveform> I'm not *too* surprised about opencv lacking libcamera support; it's (still) very new and in quite a lot of flux. That said, I haven't kept up with opencv development for a long time, and someone may be working on it for all I know
[09:03] <johk> waveform, there is actually a GSoC project for the libcamera support, but I have no idea if there was any progress
[09:03] <johk> https://libcamera.org/open-projects.html
[09:10] <waveform> johk, https://github.com/kbarni/LCCV seems to be an interesting attempt at getting libcamera to talk to opencv; they're handling the buffers manually but there's no gstreamer in the way and the buffer handling *seems* sane from a quick skim. Might be worth a look, anyway
[09:11] <waveform> still, it'll require an up to date libcamera; I'll go dive into what that's going to require for the archive (and the kernel bits) after the morning's meetings
[09:23] <johk> I have seen that, but that only works for C++ afaik, all our opencv code is in python
[09:26] <waveform> from what I can see the C++ is mostly just calling C bits in libcamera and opencv; at a bare minimum that could (painfully) be translated into ctypes though a "proper" wrapper would be preferable
[09:27] <johk> waveform: but why go to the effort instead of implementing the support directly into opencv?
[09:38] <waveform> that would be preferable, but I suspect that's not going to appear in the short term (a general integration of libcamera into opencv), so it rather depends what timescales you're willing to endure
[09:59] <johk> waveform, we're using ROS for the data acquisition anyways, so in the short term I'd just use one of the libcamera nodes 
[13:01] <johk> waveform, I'm actually a bit surprised that raspbian defaults to libcamera now, even though support is still so lacking
[13:06] <waveform> johk, there's ... a certain amount of politics behind that. One of the things that certain parties have always been rather vocal about is the Pi's closed-source bootloader. A very significant part of the closed-source blob is the camera/gpu firmware so this is part of them trying to reduce the amount in the closed-source blob (which is nice). Another part is this means all the layers get future support (mmal, part of the old stack, is basically 
[13:06] <waveform> unsupported by anyone)
[13:10] <waveform> why did they do the transition when they did? I have some vague recollections of our meetings with people in Pi trading from the time and IIRC (hoping I'm not divulging anything private), Bullseye was need for some bits of Pi4 support (CM4 particularly I think?) but bits of the old camera stack were broken in bullseye
[13:11] <waveform> so there was a choice between leaving people who were already working on libcamera hacking away at it, releasing it a bit prematurely and hoping things got better, or diverting those people (the camera experts) onto fixing the old stack, knowing they were likely to throw it out some way thru the bullseye life-cycle
[13:14] <waveform> anyway, I'm probably mis-remembering some details, but I think that was the gist of what went on
[13:17] <johk> hmm
[13:17] <johk> does rpi foudation actively support libcameraß
[13:19] <waveform> pi trading (as distinct from the foundation, who only work on the educational side of things) have several camera devs and they do work on libcamera support for the official pi cameras (i.e. not the arducams, but given it's all an open stack I'm sure they will incidentally benefit from that in the long run)
[13:20] <johk> ok I see? Are you affiliated with pi trading/foundation?
[13:22] <waveform> no, before I joined Canonical I did some contract work for them (some picademy bits, largely related to the python picamera library I wrote, and the Sense HAT desktop emulator). These days, given my role is "Ubuntu for the Raspberry Pi" I have some regular (monthly-ish) meetings with some of their engineers so we can keep abreast of hardware developments, common issues, etc.
[13:26] <johk> ah ok I wasn't aware you were working for Canonical.