[libcamera-devel] Potential integration of thermal cameras into v4l

[Jacopo Mondi]

Hi Sophie and Pekka

On Tue, Jan 10, 2023 at 10:46:26AM +0200, Pekka Paalanen wrote:
> On Sat, 7 Jan 2023 22:58:41 +0100
> Sophie Friedrich <lkml at flowerpot.me> wrote:
>
> > Hello people,
> >
> > over the past months I've written a driver for the Guide MobIR Air¹
> > USB-C thermal camera. The driver uses v4l2loopback and runs in user
> > space with python.² The driver manages camera state, calibration and
> > conversion of the raw microbolometer to temperature values.
> >
> > In my research I couldn't find any mentions of a thermal camera support
> > in the Linux kernel nor the media subsystem, so I assume I'm the first
> > to ask here and we would presumably need lay out some ground work.
> >
> > The current camera driver outputs the temperature in the Y16 format as
> > Kelvin * 100 (i.e. 28056 (raw) -> 280.56K -> 7.41°C). This allows for
> > further processing down the line with i.e. OpenCV, but has its
> > limitations. Especially as temps of only up to 382.2°C can be displayed
> > currently.
> >
> > Does it seem feasible to integrate support for thermal cameras in the
> > Linux kernel and more specifically in the v4l2 subsystem?
>
> Hi,
>
> since no-one else replied to you yet, I thought to mention my 2c
> (I don't really do camera stuff myself so far):
>
> Perhaps the best place is to reach out to the libcamera community:
> https://libcamera.org/
>

cc-ed the libcamera list

I agree it would be interesting to better understand what you mean by
driver here.

The camera seems to be a UVC camera, does it deliver frames with the
current UVC driver or do you need kernel patches to support it ?

I would also be interested why it needs to go through v4l2loopback..

> It sounds to me like you want to do some hardware-specific
> processing in userspace, and it might not be great to try to come
> up with a generic thermal camera API at the kernel UAPI level.
> That's where libcamera fits in.
>
> As for the pixel type, maybe use a floating-point type to avoid
> range/precision problems? E.g. DRM_FORMAT_R32F for application
> facing API. That format does not seem to exist yet, but it's
> trivial to add into kernel's drm_fourcc.h and should be well
> accepted IMO.
>
>
> Thanks,
> pq
>
> >
> > [1]:
> > https://www.guideir.com/products/mobileaccessories/mobirair/data_300.html
> > [2]: https://github.com/tyalie/pyMobirAir-v4l2/

This link is broken :)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20230110/cbce9b30/attachment.sig>