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.
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:
- 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.
- 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.
50 comments
Steven Wright
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.
Gordon Hollingworth
There will be an option to install Buster, we’re just in the process of creating a new Buster release
Jon
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…
jamesh
VLC should work, but there are also be options with V4L2 and gstreamer pipelines should you wish to write your own player/scripts.
russel shepherd
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 ????
what’s new?
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.
Gordon Hollingworth
VLC should be suitable as a replacement for OMXPlayer
Kevin Shumaker
OMXPlayer is not dependent on X which VLC is. I use omxplayer with many RPiOS Lite programs (lots of camera apps, video players, etc).
Bertelchen
cvlc is vlc for the cli.
Anton
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).
David Plowman — post author
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!
NS Labs
Why don’t you make a new version of raspistill and Python picamera for Bullseye, which just call the respective libcamera function.
Jim Harris
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.
Michael Horne
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!
Anton
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.
Michael Horne
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.
Jim Harris
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. . .)
MW
One can still use the *old* software, has been discussed in the Forum.
MW
https://forums.raspberrypi.com/viewtopic.php?t=323390
Aeluvidu
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 !
David Plowman — post author
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.
Robert Johnson
thanks for sharing this infomation
Javier
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.
JL
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.
David Plowman — post author
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.
Aeluvidu
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) !?!
David Plowman — post author
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.
Michael
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!
Matha Goram
Well, “someone” is probably too young to remember the history recap about WordPerfect.
Regards.
Eoin
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.
Anders
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.
Denis Carl Robidoux
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,
Stéphane ROUGES
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.
David Plowman — post author
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.
Stéphane ROUGES
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.
Rob
Firstly thanks for all the work you and the team has done on this, is much appreciated and I by no means want to be critical!
Can I ask though that you possibly add a note to the top of the download page specifying that this is a potential issue please? https://www.raspberrypi.com/software/operating-systems/
It seems that I and a number of other commenters have burnt a number of hours working this out which is a little frustrating…
Something along the lines of “if you need Python camera support for your project please use Buster until PiCamera2 is ready for release”
I checked the release notes (I only occasionally read) and this isn’t really made clear
* New default camera subsystem based on libcamera
* New camera demo applications (libcamera-still and libcamera-vid) have replaced raspistill and raspivid
Any thanks again to everyone that gives their time for the community
dingo27mobile
Is there any beta / alpha access to picamera 2? I want to try it, in whatever state it is. I don’t feel like installing everything back to buster.
Wilhelm (Bill) Edenhofer
I translated your article Bullseye camera system into German and made it available on my website https://www.edenhofer.at/doku.php?id=bullseye_cam_1. If you or the Raspberry Foundation can use it, please access it.
If I have violated a copyright as a result, please send a short report and the article will of course be removed immediately.
With best regards, Wilhelm Edenhofer
Raspberry Pi Staff Liz Upton
Don’t worry about it – it’s all CC BY-SA, so you’re very welcome indeed – and thank you for the translation!
Benjitino
This is really a painful update…
I’m new to raspberry and I have a raspberry pi 3B. I installed the latest os and do everything according to official guide.
And I just cant simply use camera… When I run libcamera-hello it gave me “libegl warning dri2 failed to authenticate”. I also checked this error and them were just not working…
Benjitino
Ok. Thanks god. I tried the workaround above and it works now.
Please add this workaround for pi 1~3 in official docs. It will help more people like me get stuck.
aoijun1
hello, I am having the same issue too, how did you resolve it? it’s been days of researching, and I don’t know what to do. I really appreciate if you reply with my comment..
bacaon bob
Why not make a new version of raspistill and Python picamera for Bullseye, which just calls the libcamera function respectively.
martin Green
Thank you for the Bullseye update. With the change of video library to libcamera should I expect linux applications such as Cheese and web apps for e.g Jitsi-meet to work with the camera modules now or in the future. Many thanks.
Manuele
Hello, as of today the comment on this article related to camera module v2 not yet working on Pi Zero 2W is still valid or it has been fixed in the meantime?
SixSixSevenSeven
3 pi 4’s, 2 official pi cameras and 1 3rd party. Not one works with libcamera in a fresh install, full updated bullseye. Not a great experience
Rob Thomas
Hey David – great articles, but it seems that the instructions for installing piDNG (formerly PyDNG) on your article about processing raw data on the RPi HQ camera, are not complete now and need to be updated. I tried to reach you on that comment list but it had been closed. Hope you get this. Thanks, Rob T
Rob Thomas
It’s me again responding to myself (huh?) it just occurred to me that the actual (i.e. working) instructions are not even on the github site, which they should be! But as it is now you have to clone the repository and look into the docs/README.md to find the ACTUAL instructions which indicate that you have to then remove the “gitted” (gotten?) repository and install with “Python3 -mpip . . . .”! But anyway that’s only one of several ways to install – it depends on your Pi setup. Not sure why the README on the git site would not be updated with the one that’s in the clone repository but there ya go. Hope that helps your readers. Soldier on! RT
Rob Thomas
Hey – where are my comments? they are critical to one of your articles where the comments are closed. That means the article is
1. no longer relevant and 2. misleading
Please fix. Thanks!
Raspberry Pi Staff Liz Upton
Mate, they just didn’t get approved for just over an hour because it was the end of the day on a Friday and we are human beings. Nobody is maliciously censoring you.
Comments are closed