libcamera, Librem 5 and autofocus

[Laurent Pinchart]

Hi Pavel,

On Tue, Apr 08, 2025 at 10:55:17PM +0200, Pavel Machek wrote:
> Hi!
> 
> I played a bit with libcamera on Librem 5, and got autofocus to work
> (slowly!) on Librem 5. I'll be likely busy with other stuff in next
> weeks, so I thought I'd share the results.
> 
> The tree is at
> https://gitlab.com/tui/libcamera/-/commits/l5?ref_type=heads . And no,
> patches are not yet in ready to merge state.
> 
> What might be interesting:
> 
> ad88b0bc9d46cd825873f3c16dd81ba7979384d7 -- that's port of autofocus
> tree to recent libcamera.
> 
> Other "af: " patches -- original AF code expected YUV data, this ports
> it to Bayer8. Needs more work, but if you are using bayer, this should
> be good start.

I'm curious, have you measured how much CPU time the AF statistics
gathering takes ? And do you have an idea on how easy or difficult it
would be to offload that computation to a GPU ?

> ucam: make "%" mean sequence number of frame.

I assume you mean cam here, not ucam.

> adf18d2336ab7c3f32d4a1948d197e8c1078b259 -- would adding "%x" formats
> to cam be acceptable? I'd really like filenames in timestamp.ppm form,
> likely other people will want other format specifiers, for example
> "640x480.RGGB8.raw" might be good name for stuff that can't go into
> ppm.

We're getting a bit into bike shedding territory, but I think this could
make sense, yes. Feel free to post this as a standalone patch for
discussions.

> cff1b23f7e212cc868fd27705a675abe83f2c92f ppm: add support for argb8888
> -- by default with swIsp, libcamera started producing ARGB
> data... which can't be written into ppm. This and next fix teaches
> libcamera to deal with that. Would it be acceptable after indenting
> properly?

Support for converting various pixel formats to 24-bit RGB to be stored
in a PPM file isn't something I'd like to see in cam, but expanding
support for other 8bpp RGB formats seems fine to me. I'll like the patch
better if you also add the RGB888 and ABGR8888, ideally in a way that
keeps the code clean and doesn't have much of a negative performance
impact.

On a side note, I want a universal container format to store images :-)

> 1b8a7edd28b75c7a134931ed2cf612b9234faacb -- adds note into help text
> explaining single frame capture does not work.

Rather than adding it there, I'd like to fix the kernel drivers.

> Plus I have two README updates, "doc: we need libtiff for dng" and
> "fix: newer meson is needed for build". I guess those are simple
> enough to do merge into one patch and submit properly.

I'd keep them as separate patches as they're not related. You can
already post them (with commit messages).

> Oh and this is the other half:
> 
> https://gitlab.com/tui/tui/-/tree/master/ucam?ref_type=heads
> 
> Python scripts; they allow me to get frames from libcamera, and
> display them in gtk window for viewfinder. Plus it displays
> exposure/gain/focus information, and it was able to take photos and
> record videos at one point.

-- 
Regards,

Laurent Pinchart