Bullseye camera system

When we released our first Raspberry Pi OS image based on Debian Bullseye last week, we pointed to a change that is hugely important to people who have written code to use cameras with Raspberry Pi: the driver that Raspberry Pi uses to access camera modules has been replaced with libcamera.

These very significant changes mean less closed-source code, and they make it easier for people outside of Raspberry Pi to develop new camera hardware and software; but they also mean that new Raspberry Pi OS releases will no longer support the familiar raspicam apps and Picamera Python library.

In the place of this older camera system is the new and almost entirely open source camera stack based on standard Linux frameworks such as V4L2 (Video for Linux) and libcamera. Our kernel drivers have been moving in this direction for some time too, and have just recently taken further large strides towards the preferred new Media Controller architecture.

But the principal difference that users will notice is that OS releases from Bullseye onwards will no longer support the older camera system and applications, and Raspberry Pi’s libcamera-apps will be built and pre-installed instead. Before we go further, note that Raspberry Pi OS Buster is still available to download if you’re not ready to use Bullseye. If you are using camera applications with your Raspberry Pi, we recommend you take some time to weigh up whether to move to Bullseye at this point. This blog post considers why, and why not, you might want to do so.

What are libcamera-apps?

Libcamera-apps are designed to copy most of the functionality that users will know from raspistill, raspivid and raspiyuv. There are some unavoidable differences, which are examined in greater detail here. The new applications include:

  • libcamera-hello – a simple “hello world” application which starts a camera preview stream and displays it on the screen.
  • libcamera-jpeg – a simple application to run a preview window and then capture high-resolution still images.
  • libcamera-still – a more complex still image capture application which emulates more of the features of raspistill.
  • libcamera-vid – a video capture application.
  • libcamera-raw – a basic application for capturing raw (unprocessed Bayer) frames directly from the sensor.
  • libcamera-detect – this application is not built by default, but users can build it if they have TensorFlow Lite installed on their Raspberry Pi. It captures JPEG images when certain objects are detected.
Libcamera-detect: identifies cats, apples, and other less useful objects

Why should I use libcamera-apps?

We’d encourage users to move to Bullseye because libcamera-apps bring numerous benefits:

  • They offer improved image quality, which, furthermore, a user can tweak to their own tastes.
  • We can fix bugs and develop new features – all of which was extremely difficult in the proprietary Broadcom stack. For example, we’re very excited to be planning autofocus functionality in the near future.
  • Because it’s open source, third parties can fix problems and add new features too – we’re happy to consider pull requests in our Github repository. (Contributions to the kernel or to libcamera itself need to be upstreamed in the usual way.)
  • It’s much easier to add support for new cameras, and indeed for third-party cameras – a number are supported already (including the Sony imx290, imx327, and imx378, and the Omnivision ov9281). We’re keen to work with vendors, and more are already in the pipeline.
  • The applications are designed to be easy to understand, so that users can customise them to suit their own requirements.
  • We show how the camera applications can be augmented with powerful third-party image processing libraries, such as OpenCV and TensorFlow Lite.
  • We provide an image post-processing framework that includes examples of motion detection, HDR (High Dynamic Range) imaging, face and object detection, pose estimation, and image segmentation. We’d be delighted if users would like to contribute more!
  • It is fully supported in the 64-bit version of Raspberry Pi OS.

Nevertheless, libcamera and Raspberry Pi’s libcamera-apps remain a work in progress. Reasons for staying with an older OS release and continuing with the legacy camera system include:

  • There is no Python interface yet. An alternative to the old Picamera, imaginatively named Picamera2, is in development. This too will integrate much more directly with established Python libraries to access things like windowing and graphics functions. Picamera2 will be developed by Raspberry Pi (unlike Picamera itself, which is actually third-party code), and this will facilitate both support and continuing future development.
  • There is currently no support for stereo imaging within libcamera, though it is in our future development plans.
  • Users of low-powered Raspberry Pis (such as Zero) who wish to use X Windows at the same time may get better camera performance with the legacy stack, as this does more work on the GPU and less on the ARM cores (which can struggle with X Windows in any case). Note that libcamera-apps still work well on these systems when X Windows is not running, or when a live video window is not required.
  • There are still a few known issues in libcamera.

As mentioned further up, for those wishing to use it, the previous Buster release is still available to download.

How do I try libcamera?

Users of the new Bullseye OS will find that libcamera-apps are pre-installed and will work with no further intervention. You don’t even have to “enable the camera” any more, though you do still have to plug one in!

Note that there are a couple of known issues with the initial release:

  1. The preview when running under X Windows does not work on Raspberry Pi Zero or Raspberry Pi 1, 2 or 3 devices without this workaround. Users of Raspberry Pi 4, or those not using X Windows, are unaffected.
  2. The Raspberry Pi Camera Module 2, Raspberry Pi Camera Module 2 NoIR, and Raspberry Pi High Quality Camera are not yet working on the new Raspberry Pi Zero 2 W.

Both these problems will be fixed shortly.

Meanwhile Buster users with an up-to-date version of the OS can install libcamera-apps from the apt repositories.

More information on getting started with the new applications can be found on our official documentation page, where there are many example commands.

More Information

34 comments
Jump to the comment form

Avatar

I think there should be a simple option to install Buster via Pi Imager – especially with such functionality gaps. Lack of Python is a real pain, and selecting a camera port (i.e. with a CM4) doesn’t seem possible (unless I’m mistaken) with libcamera. I know stereo imaging isn’t supported, but at least picking a camera would be handy. Sorry to sound grumpy – overall, I’m very happy, but just feel a little like Bullseye ain’t quite hitting the target yet.

Reply to Steven Wright

Avatar

There will be an option to install Buster, we’re just in the process of creating a new Buster release

Reply to Gordon Hollingworth

Avatar

Is there going to be a replacement for OMXPlayer? I use this on so many video art installations and need to start thinking about what I am going to use instead…

Reply to Jon

Avatar

VLC should work, but there are also be options with V4L2 and gstreamer pipelines should you wish to write your own player/scripts.

Reply to jamesh

Avatar

what is wrong with raspberry pi OS bullseyes Its don’t work
youtube will not login if you just go to youtube and play video there’s no sound I have try this on rpi 4 B 1G,2G,8G and raspberry pi 400 its the same why release a OS when it don’t work ????

Reply to russel shepherd

Avatar

Is OMXPlayer going to be replaced? I use this on so many of my video art installations and I should think about what I will use instead.

Reply to what's new?

Avatar

VLC should be suitable as a replacement for OMXPlayer

Reply to Gordon Hollingworth

Avatar

OMXPlayer is not dependent on X which VLC is. I use omxplayer with many RPiOS Lite programs (lots of camera apps, video players, etc).

Reply to Kevin Shumaker

Avatar

Thank you again for all the hard work!
And could you please elaborate on that “improved image quality” bit? It is still using the same hardware after all (for example the de-bayer algorithm from ISP, as you explained to me last time).

Reply to Anton

David Plowman

The “tuning” of the parameters that configure the hardware are improved.
Most obviously the colours should be better, they often seem a bit washed out to me in the GPU stack. Unwanted artefacts like colour shading should be reduced. Things like denoise and sharpening should be be more predictable as we finally have a proper handle on what parameters are being fed to the hardware.
All these different aspects of the “tuning” are in fact now user-controllable, for those who like to tweak such things!

Reply to David Plowman

Avatar

Why don’t you make a new version of raspistill and Python picamera for Bullseye, which just call the respective libcamera function.

Reply to NS Labs

Avatar

This is going to break so many things going forward – especially the lack of Python support. Python is (supposedly) the “official programming language” for the PI and I have trouble understanding how this got left out.
At the very least, there should be some kind of workaround for Python, or as a previous user suggested, the current Python “raspicam” routines could be re-written to encapsulate the new libraries so that existing software will continue to work, and new software can use additional features.
So far, this is a total deal-breaker for me – there are just too many changes in too many areas that are totally incompatible with everything else.
Sorry, no bullseye, no cigar.

Reply to Jim Harris

Avatar

Breaking all the educational resources out there which use raspistill and, especially, the picamera library is NOT a good look for an educational charity. I appreciate you are Raspberry Pi Trading… but your two arms NEED to talk to each other. This is embarassing!

Reply to Michael Horne

Avatar

Faster horses and all that.
I only reply to you because I value the work of Raspberry Pi (both Foundation and Trading) and posts like yours show massive ignorance toward the exercised effort.
Next time please consider another vocabulary as there really is nothing even close to “embar[r]assing” in it.

Reply to Anton

Avatar

I think you misunderstand me. I am very far from ignorant of the amount of effort that goes into it. However, the testing regime is clearly deficient (although apparently being worked on).
Oh no, I spelled a word wrong. How awful of me.

Reply to Michael Horne

Avatar

This is my previous comment:

> This is going to break so many things going forward – especially the lack of Python support. Python is (supposedly) the “official programming language” for the PI and I have trouble understanding how this got left out.
>
> At the very least, there should be some kind of workaround for Python, or as a previous user suggested, the current Python “raspicam” routines could be re-written to encapsulate the new libraries so that existing software will continue to work, and new software can use additional features.
>
> So far, this is a total deal-breaker for me – there are just too many changes in too many areas that are totally incompatible with everything else.
>
> Sorry, no bullseye, no cigar.

Yes. I understand that the original camera libraries were something of a closed-source “hack” and going to a more open-source model is the wave of the future, but do we have to do *ALL* of it, *RIGHT NOW*?

A much better way to handle this would be to phase it in.

1. Keep the original Raspberry Pi camera utilities intact.
2. Work on the updated libcamera utillities “in the background” so to speak, invite people to use them and comment, with the understanding that this is seriously beta level stuff.
3. Once the software has been sufficiently debugged, and compatibility layers have been created and tested, then it could be considered for mainstream release.

What they’re doing now is reminiscent of Windows Vista – releasing a significant software library that is used by virtually everything under the sun – way before it’s ready for prime time.

(Shakes head. . .)

Reply to Jim Harris

Avatar

One can still use the *old* software, has been discussed in the Forum.

Reply to MW

Avatar

Thank a lot for these news David ! Even if it is big changes, I really hope this will give us more possibilities in the future. All your reasons to make this big change make sense for me, even if as everybody I’m a bit stressed to have to take a lot of code again on the workbench. You are right color rendering was sometimes “milky” until now but already very very good for a camera in this price range ! Concerning python binding do you have an approximative time schedule, can we expect it for christmas :-) ??? It would be so cool to have time to make astronomy during the holidays. By the way is there somewhere a beta version to test, any github repo or something like that ? Thank a lot in advance for your feedback and all the best for the ongoing jobs !

Reply to Aeluvidu

David Plowman

Hi, thanks for your message. We don’t have a timescale for Picamera2, I’m afraid, though we are working on it. Christmas sounds a bit optimistic but maybe we could roll out some “preview/prototype” versions well ahead of the final version. We’ll look into this.

Reply to David Plowman

Avatar

thanks for sharing this infomation

Reply to Robert Johnson

Avatar

Absolutely disgusting that there is not python support for this new version. I was doing a new development with the Raspberry Cam and now I have to change all the things that I have thought to that proyect.

Reply to Javier

Avatar

Another call for an early test release of Picamera2. :) I’ve a work-in-progress film scanner project that has a Python GUI, and uses Picamera to set a fixed shutter speed and retrieve a bayer array of a full resolution HQ camera image for each frame. OpenCV and Numpy are used to analyse and process the images. This works well, if a little slow. It’ll be good to be able to use the newer version of Python that allows multiprocessing to handle large arrays in shared memory to speed the processing up a bit – not possible on Python 3.7 in Buster. At the moment I’m using an upgraded Buster->Bullseye – but will revert back as something’s broken the picamera live preview that is used in my app for critical focusing.

Reply to JL

David Plowman

In your /boot/config.txt, is it configured to use the vc4-kms-v3d display driver? You might need to switch back to vc4-fkms-v3d instead.

Reply to David Plowman

Avatar

Am I right if I understand that we can go on to use picamera under Bullseye if we make this change in /boot/config.txt (vc4-fkms-v3d instead of vc4-kms-v3d) !?!

Reply to Aeluvidu

David Plowman

Sorry no, I was simply referring to the fact that the legacy stack will require fkms rather than kms if you want to see any kind of preview image, however it is driven. I expect there will be more discussion of this on the camera forum.

Reply to David Plowman

Avatar

Is there any way to get it to login into Youtube’s live streaming service and start streaming without having to manually login to Youtube and hit that irritation “Go Live” button from Youtube Studio? Thanks!

Reply to Michael

Avatar

Well, “someone” is probably too young to remember the history recap about WordPerfect.
Regards.

Reply to Matha Goram

Avatar

Some heated debate going on here.

I understand the desire to improve and roll out new feature rich libraries, and support progress where it enhances and develops the end results. Equally continuing to support the previous incantations is desirable.

Is it not the case Buster will continue to be supported for a number of years to come? Can project developers not choose to remain with the older OS for the time being? Thus any legacy setups or things in development will have some continuity.

Reply to Eoin

Avatar

Of course people can continue to use Buster.
Or they can use Bullseye and just revert to the old camera stack. No need for people to get worked up about it.

Reply to Anders

Avatar

You mean that all these efforts I made these last 4 weeks to make an app that uses picamera were for nothing? Just great…
thank you, really, thank you.
In mid-october I get the latest raspbian, I work my software for weeks, I release it 2 days ago and then the first user that comes back to me and show me these error messages..

Really thank you really much,

Reply to Denis Carl Robidoux

Avatar

Can you explain how, at a time when Apple, Qualcomm or Mediatek design incredible SoCs, with many integrated co-processors among which ISP, can you do without the GPU optimization?
One explanation I can imagine is some financial dispute with Broadcom? Can you communicate on that?
If this is not the reason, why the new V4L2 driver couldn’t continue using GPU optimization?
Thanks for the work done.

Reply to Stéphane ROUGES

David Plowman

Hi, the answer is that we are still using all the hardware blocks on the GPU to optimise the processing. The difference is in the APIs we’re using to drive them. We’re switching over to more standard Linux frameworks and APIs, but they’re still driving blocks like Broadcom’s ISP underneath.

Reply to David Plowman

Avatar

Great news! I thought the contrary because of your note about the RPi Zero. I will be then happy to switch to Bullseye when the software work is done.
Cheers.

Reply to Stéphane ROUGES

Leave a Comment