Skip to content

Libcamera migration#953

Draft
newtonick wants to merge 2 commits into
SeedSigner:devfrom
newtonick:libcamera-migration
Draft

Libcamera migration#953
newtonick wants to merge 2 commits into
SeedSigner:devfrom
newtonick:libcamera-migration

Conversation

@newtonick

Copy link
Copy Markdown
Collaborator

Related to SeedSigner/seedsigner-os#114. Should be tested with and merged with this SeedSigner OS PR ideally.

Problem or Issue being addressed

SeedSigner's camera code depends on picamera, which only drives the legacy Broadcom/MMAL camera stack. That stack is Buster-only and has been deprecated for years, which is a big part of why manual dev builds are still stuck on Debian 10. picamera also drags in numpy as a transitive dependency purely for frame buffer handling. The picamera stack is also closed source and no longer maintained.

Solution

Replace picamera with the native libcamera python bindings and drop numpy entirely.

The old pivideostream.py is replaced by a new camera_stream.py with three pieces:

  • LibcameraVideoStream drives the QR scanning feed. It hands grayscale frames straight to pyzbar, with a separate RGBA path for the live preview.
  • LibcameraStillCapture handles single-frame capture. It locks auto-exposure/AWB at their converged values to reproduce the old picamera shutter_speed/awb_gains freeze.
  • rgba_buffer_to_image converts a raw libcamera buffer into a PIL image without numpy.

camera.py is reworked to drive these classes, and the background import warmup now preloads libcamera instead of numpy.

I also rewrote raspberry_pi_os_build_instructions.md. It now splits into Part 1 (libcamera on Debian 13 "Trixie", for current dev), Part 2 (legacy picamera on Buster, for v0.8.7 and earlier), and Part 3 (config shared by both). requirements-raspi.txt is removed since it is no longer needed.

Additional Information

The libcamera bindings behave differently from picamera in a few spots worth flagging for reviewers: methods raise on error rather than returning status, and YUV420 buffers come back with stride padding that has to be handled when building images. Code after v0.8.7 will not run on Buster (no libcamera module), and v0.8.7 and earlier will not run on Trixie (no legacy picamera), which is why the build doc keeps both paths.

Screenshots

No UI screens changed. This is a hardware/camera plumbing change, so there is nothing new to show.

Testing information

It'll be very important to perform regression testing. I want to make sure the QR scanning and New Seed from Camera all work as well or better before merging.


This pull request is categorized as a:

  • New feature
  • Bug fix
  • Code refactor
  • Documentation
  • Other

Checklist

I ran pytest locally

  • All tests passed before submitting the PR
  • I couldn't run the tests
  • N/A

I included screenshots of any new or modified screens

Should be part of the PR description above.

  • Yes
  • No
  • N/A

I added or updated tests

Any new or altered functionality should be covered in a unit test. Any new or updated sequences require FlowTests.

  • Yes
  • No, I’m a fool
  • N/A

I tested this PR hands-on on the following platform(s):


I have reviewed these notes:

  • Keep your changes limited in scope.
  • If you uncover other issues or improvements along the way, ideally submit those as a separate PR.
  • The more complicated the PR, the harder it is to review, test, and merge.
  • We appreciate your efforts, but we're a small team of volunteers so PR review can be a very slow process.
  • Please only "@" mention a contributor if their input is truly needed to enable further progress.
  • I understand

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant