They expanded the lineup for the Camera Module 3 to include a standard (75°) and wide (120°) FoV lens on both the regular and NoIR (no IR filter) camera modules, and all variants use the Sony IMX708, which bumps resolution from 8 to 12 megapixels, and almost doubles the sensor size.
The most important upgrade is the inclusion of autofocus (using PDAF) with full support from libcamera and Picamera2. It is pretty snappy though not quite as good as something like a Pixel or iPhone.
There's also a new M12-mount HQ camera, for the same price of $50, which is useful for some more specialty lenses (though I haven't run into any M12 lenses in my own work!).
Of course. Still no ability to go above 120FPS. I have tons of comments on this in my history about trying to extract raw frames from the RPi camera modules and go faster if anyone cares to help.
So ridiculous these sensors and data lanes on everything embedded can't get us 240FPS at even VGA resolution.
Edit: Raspberry Pi compute module 4 has all 4 CSI-2 data lanes exposed. So you can get full bandwidth of this interface and could use high resolution sensors.
Fiddling with "struct mode_def imx477_modes[]" when you already have the rest of the header file would be the obvious thing to do and would probably work out fine but that is mostly trial-and-error and not a proper method.
Well you need a datasheet from your sensor’s vendor. There are whole description of the register and initialization sequence. Few hundred values. And from these values you can construct your own register map for the sensor in the way as it was done for supported sensors. For popular sensors datasheets can be obtained just by searching.
AFAIK the normal RPi boards only provide 2 MIPI lanes while 4 MIPI lanes would be possible by most camera modules and the processor. Therefore we only have half of the possible the bandwidth available. For higher resolutions the bandwidth is a limiting factor. There are some boards and camera modules that use 4 lanes. Those boards use different connectors and therefore are not compatible with the default RPi camera cables this is probably the reason why the 4 lane option is not offered by default.
In order to enable higher framerates you need to set up additional "modes" in some configuration file. I assume that by default only "relatively reliable modes" are configured. That's where the limitation to 120 FPS comes from. Calculating other modes requires some special tool that is specific to the camera chip. Also you need some luck that those modes actually work for you.
It’s so frustrating that the entire CSI camera module ecosystem has been completely handicapped by the choice of connector for the camera module.
The V1 camera module (OV5647) only supported two lanes, so it was a fair enough decision then, but they had a chance to change it when they changed connector on the PiZero.
The connector even had the 4 extra pins specifically to support 4 lane CSI, but it was as if it was forgotten about. The V2 camera came out not long after so the combination would have made for a massive upgrade.
I think they ended up back peddling from the new connector due to the horrific combination of a too thin custom flat flex cable with a connector that could barely meet its 10 mating cycle rating.
It didn’t have to be that way, a standard 0.5mm FFC with decent swing down latch connector is 10x more robust.
I think this is a typical case of nice-to-have but not-important-enough for >90% of customers. The decision is not optimal but the want-to-change is not big enough to overcome the existing installation base. The new camera reinforces this. We could have a new connector with more lanes and a cheap little adapter PCB to adapt to the old connector and cables. But even that seems too much right now.
I reverse-engineered the first Pi camera and you can make it record at all sorts of combinations of frame rate and resolution if you bypass the libraries provided.
The limiting factor is how long it takes to shift a row of pixels out of the CCD and into the ADC - wide-but-short videos can be recorded at 200+ fps pretty easily.
The Pi foundation believes supply will steadily improve as this year progresses & will be back to ”you can buy any Pi you want today” by the end of the year.
It’s not /great/, but given the supply chaos of the last few years it is what it is.
Last I heard they were making 7M a year, with very few reserved for end users. To improve the situation they promised 100k reserved for end users. Seems much like the GPU fiasco where a company reserves all their product, leaving none for end users, and the market collapses (worst GPU sales in 20 hears).
Even in its height of "unobtainable" I was able to get one without having to try too hard and I was being picky about the configuration I wanted. I did have to buy from a German site but it was obtainable.
I managed to get one via a rpilocator.com alert (used the rss feed to send myself an email alert) within about 2-3 weeks of setting it up. It's not perfect but it worked and I managed to get an 8GB Pi 4.
the height of unobtainable was just a couple of weeks ago, and it lasted for almost a year in which rpilocator was only showing a few shops in the world selling a few dozen pis in a different form factor you are looking for at a time.
I don't think a Pi webcam is worth the complexity and hassle unless there is a need for processing video on-device on the cheap, but even then, a USB camera may be preferable. For serious streaming quality will still be too far a cry from a Lumix with OBS and for video calls the pricier commercially available webcams like the Razer Kiyo Pro or the Logitech Streamcam give pretty good quality too and they'll actually work in an instant when needed, at not (much) higher cost than a Pi 4 plus accessories plus camera.
But before getting a better camera I'd try to improve lighting, try to have lots of uniform white diffused light coming from at or behind the camera; simple things like white LED strips at the back of the monitor bounced off a wall or other surface behind it can work well because Teams/Zoom will compress and shrink your video to death anyway, so high resolution and fine detail are wasted, but a kinda well-lit person will still look decent even in a tiny and brutally compressed thumbnail on a laptop screen and I'm not aware of any AI filter that actually does a good job at simulating that, and any that did probably wouldn't fit on a Raspberry Pi anyway.
And before doing even that, I'd make sure my audio is actually decent, since that's what most people take for granted since it is for granted in real-life meetings, but being hard to understand or sounding harsh and jarring is something people react to a lot more strongly and viscerally to than bad-ish video, often without even realizing that's what bothers them about a person. Think of it like meeting to get work done in a dimly-lit room vs. in the middle of a construction site – people sometimes do the former on purpose, e.g. to improve projector image quality, but the latter will feel jarring to most, especially if you're the only person who sounds like that. Important to use the test call functionality in Zoom/Teams/... since their compression may reduce quality by a lot. External USB microphones can be a good inexpensive option, something like a Behringer C-1U, anything bluetooth tends to sound rather ugly.
And before doing even that, I'd think real hard if even that's actually needed. Most people seem to not give a damn and are just fine not sounding and looking like a newsperson. There might be more profitable things to put that time and money towards.
Auto-focus seems like one of the lesser useful features for webcam (or rather, the use case of a webcam seems to not require auto-focus that much) since the object distance remains largely the same for the duration of the video call, at least the video calls I'm usually in.
Maybe people have a different setup that I, but I usually remain the same distance away from my monitor at most times.
Good webcam setups have a sharp depth of field, which makes the speaker look sharp and the background blurred. This requires auto-focus because a few centimetres matters to be in field.
> Good webcam setups have a sharp depth of field, which makes the speaker look sharp and the background blurred
I'm guessing you mean "shallow depth of field" rather than "sharp" here.
And you probably don't want it to be so shallow so a few centimeters would matter, then your nose could be in focus but your ears not, or vice-versa. That's a bit too shallow.
It also doesn't require auto-focus, it requires you to be able to put the camera at a good distance with the correct f-stop, or being able to change the f-stop one way or another.
Auto-focus is more for cases when the subject/object moves a lot forward/backward from the perspective of the camera, so you don't have to manually adjust things.
It all depends on your setup. In my experience, effective autofocus provides a bigger quality improvement than the step from 720p to 1080p.
Webcams in poor lighting conditions benefit from autofocus, because autofocus makes it easier to use a larger aperture, improving low light performance.
Laptop webcams benefit from autofocus because there's no room for manual focus controls, and the distance to the user will vary substantially depending on if the laptop's in a docking station, if the user's leaning in to read some small text, etc.
Meeting room webcams benefit from autofocus so you don't need a technician to attend every time it gets knocked out of focus.
PC webcams sometimes benefit from autofocus, because the cable usually weighs more than the camera, meaning the camera often gets moved and knocked about. Plus about 95% of home users with manual focus webcams don't even know they need to focus them.
Streamers have great lighting and cameras firmly mounted on solid tripods - but they're often using mirrorless interchangeable-lens cameras, so they get autofocus for free anyway.
I built one at the time. Imo the lack of auto-focus was a plus, as I'm not moving that much and hate the complete blur to refocus some cameras do occasionally.
Back then you needed a Pi Zero for USB device mode and a specific software version for this to be supported other than that it just worked.
I have the exact same experience with mine. I have been running a specialised software build on my pi zero that I found somewhere and have been very happy with it.
My money is 2023. Eben never announces releases early so what he did/didn't say in that recent interview is meaningless. With the added bonus that this time he can also screw over all the scalpers. Let's see!
He said "don't expect a pi 5 next year [2023]". In my optimistic mind that's because he wants to maintain the surprise. I know this is foolish, I know the background of his statement, but I'm going to keep the faith for something in Q3. Maybe it'll be a 4+ instead.
For the past month I've been seeing some supply of RPi 4 on rpilocator.com almost every day.
Not much, but better than when there were only like a dozen per week. And Eben Upton says it should improve and not be an issue by the second half of this year.
I sure hope that's the case, because it feels like it's been 2 years since I could just buy one at Micro Center, and the other SBC boards I've been testing are either too unsupported/unpopular or quite expensive as well.
I have a video up on YouTube with some comparisons up close, and a blog post with one in particular that looks at center sharpness (my website's in my bio). I haven't had a chance to upload the originals anywhere yet, though.
I'd say the sensor is very good but the lenses they're using aren't capable of a full 12 MP of resolution. The wide angle lens controls distortion pretty well, but the standard lens shows a little distortion around the sides.
Still a huge improvement over the Camera Module v2 in every aspect. Autofocus worked especially well, even better than the ArduCam models I tested last year.
The camera modules(with PIR, PTZ, auto-focus, night-mode) on a 38mm*38mm board were a solved problem at lower cost due to huge volume of IP cameras from China. However the code on those modules are fully closed(most running an older version of Linux).
RPi's modules are priced reasonably enough to compete against clones from China's vendor, really hard to do, but it did it so far like a magic.
Is anyone aware of any projects to do auto-zoom on a fisheye lens? (ie, the camera is set up to see the whole room, and then software crops that to just show the area with a person in it, and then re-export that video as a new source so that other software can use it without needing to be fisheye-aware)
I want to build a device/product that needs a board+wide-angle-camera combo? Board does not need to be fast. I suspect, even a fast arduino might work.
i love the raspberry pi ecosystem but I really see it as a stopgap until we have wide support for open risc V based soc devices across the industry. the DRM really is a major limiting factor for the platform in a number of ways.
What does the DRM prevent, specifically? Any use of the camera ribbon cable interface by any non-licensed camera?
Edit edit: I still have no idea...see reply from 'mrbteveman below.
Old first edit (wrong): Apparently, yes. This comment[0](2019) explains it slightly more. Evidently the ribbon cable ("CSI interface") can be used by pretty much anything...as long as that thing is not a camera / doesn't need the usual on-board image processing.
Evidently this prevents anyone from coming out with pi-compatible cameras with different features, e.g. different resolutions/framerates/night vision/infrared/zoom/etc.
in my experience you're better off just going with a USB camera most of the time. it's a cleaner abstraction point and supports more hardware and operating systems.
> What does the DRM prevent, specifically? Any use of the camera ribbon cable interface by any non-licensed camera?
> Apparently, yes. This comment[0](2019) explains it slightly more. Evidently the ribbon cable ("CSI interface") can be used by pretty much anything...as long as that thing is not a camera / doesn't need the usual on-board image processing.
This isn't accurate, the only thing they do is limit specific sensors from being used unless there is a matching authentication chip on the module, because those specific sensors are the ones they have manufactured camera modules with.
So for example the Pi Camera v2 module uses an imx219 sensor from sony and an authentication chip that the Pi firmware can check to verify the module was actually made by the Raspberry Pi company.
If you buy a 3rd party imx219 camera module (which would not have that authentication chip), it will not work on the regular Pi boards (but it will work with the Pi compute module boards because they don't do the authentication chip verification).
There have been plenty of 3rd party camera modules with entirely different sensors that work on the Pi for years, though with quirks related to the closed source drivers, but the modern libcamera stack on the Pi is explicitly designed to enable 3rd party camera modules.
Yes, we can forgive them if a vendor refuses to release specs or source (Broadcom, for example), but implementing their own DRM to prevent others from making compatible cameras seems hypocritical and needlessly anti-user.
Is there some legitimate, user-serving benefit to this move that isn't apparent?
They have no business locking it down and preventing people from implementing higher-quality cameras, which would only add value to the Pi camera-interface "stack" anyway. No matter how you slice it, it's anti-community and encourages someone to come along and undermine the entire platform... which would REALLY squander the investment made.
I get your point. the problem these days is if you develop a completely open product your design will be copied and your device will be undercut and often beaten to the market by Chinese competitors.
How is the pi foundation supposed to make money in order to continue manufacturing and designing computers if they are unable to make any money? donations?
They're obviously selling computers as fast as they can make them. Locking down an interface on said computers doesn't seem to be protecting their core business; it seems to limit the usefulness of their core business. And make no mistake: I want them to survive and continue to churn out very cool products.
I just want a really high-quality (even if "only HD") camera, which would cost much more than what the Pi Foundation is targeting. I don't think it would cannibalize sales from anything they're trying to put out.
The Arduino ecosystem seems to have survived being truly open, hasn't it?
Are you talking about DRM as in "Digital Rights Management"? As far as I know, cameras have nothing to do with that type of DRM, that's up to the playback device, not the recording.
Does that actually mean you can use a knock-off v3-like camera? There is no contradiction between an open source driver and the camera having to authenticate against closed-source videocore firmware.
Ah, I see. I'm more familiar with the terms "hardware restrictions" or "vendor lock-in" in that case, as I see DRM to be strictly software enforced restrictions, guess the "Digital" in DRM throws me off or something.
If DRM is still needed (no idea) then you'd expect an official product to support it. I can't think of a use case where lack of DRM support by the camera could possibly be a problem for you.
DRM might be not exact term here, basically "original" cameras had a chip that identified itself to the rPi driver and driver required that to work.
That was because the previous camera was widely copied and they wanted to not put money into making driver for a camera just for user to go and buy cheap copy
There's a warning in the article that the official Zero case does not support the new camera. According to the specs it is around 30% thicker than the original camera module, and the fish eye variant is even thicker still. Many cases fit pretty tightly and will not be compatible.
According to Pi Locator, there hasn't been an 8gb RasPi in USA since October 2022. Best to move on to another company that prioritizes retail rather than donation-commitments.
For the most part I've found that RaspPis are over-dimensioned for many projects I'm inclined to do, for example around the house, and have switched to much more readily-available and cheaper ESP32 and STM32 boards.
I do have a RasPi in use that runs some heavier software like a Hue bridge emulator written in Python (diyHue), and for some of my projects I now have that Pi do more intensive computation centrally and then just dispatch results to esp32s.
I'm currently building one of those refresh-once-a-day framed e-ink "newspaper on the wall" projects. In the picture frame I just have the panel, an IT8951 display controller and an esp32, all running off a LiPo pouch, mostly in deep sleep. The RSS scraping and pdflatex+ghostscript pipeline to produce the image is running on the central Pi in this.
A single Pi may be all you need if your projects live on a network!
Yeah, I have a single 4b doing everything from openhab to shinobi to LoRA bridging, MQTT brokering, VPN termination, DNS, routing, pretty much anything where I need a Linux box to do a thing - we live off grid, so having a handy utility server that uses very little power is dead handy.
Plans to get another, as some redundancy would be good and it strains transcoding video, but you can pile a surprising amount onto one.
Time will tell, but I'm hoping for at least a couple of months on a 1100 mAh. Napkin calculations had me at 6-7 months.
It's e-ink, so I can shut down the entire display and controller after the refresh, and the ESP32 is in deep sleep until it wakes up on timer and performs a network fetch and display update, then back to sleep.
> If it's "on the wall", why isn't it powered by an ac adapter?
Effort :-) It's a picture frame on a wall, I don't want to have an externally visible cable going into it and burying a cable in the wall is more work than all the rest of it.
Wow, I'm not used to thinking of batteries in those terms. If you hit 3 months, you deserve to crack a bottle of champagne, that's a really impressive bit of engineering. Although now that I think about it, smoke detectors have been lasting a year on a 9-volt for all my life, so maybe I'm just short-sighted. :-)
An ESP32 just draws about 0.15mA or less in deep sleep mode, even less if the ULP co-processor is turned off - down to about 5 µA if you're willing to keep no state/data around and just need timer wakeup. That's 220000 hours of hibernation on an ideal 1100 mAh battery (i.e. one that doesn't lose charge by itself over time)!
In practice this is unattainable, because batteries are not ideal, and there's quite some efficiency loss from e.g. voltage regulators. But you can realistically get to years of hibernation.
Of course the power draw is much higher if you e.g. need to permanently keep a WiFi connection open and can't sleep (there's lower-power alternatives to WiFi like ESP-NOW for some applications), but I just need a connection for a very short time to fetch a 1600x1200x4 image. And to power a full display refresh on the e-ink panel.
If you think about it, a Kindle or similar also runs for days to weeks off a single charge, and that has a lot more interaction and computation going on during use, a more powerful processor with higher power draw and it sleeps less deeply and for shorter time. My application is suitable to extend beyond that by a large factor.
That's so cool. Did you build this from instructions somewhere or just using your imagination and seeing what works? Perhaps a build log article maybe?
Not sure there have been any in New Zealand for a couple of years. It is something of a cruel joke each time new hardware is announced knowing there is no chance I am getting my hands in it.
The new Orange Pi 5 has a good price for the RK3588s it uses, and can support up to 32gb of RAM. My testing shows it being 3-4x faster than the Raspberry Pi 4 4gb.
Down side is it just released, so the software support is still in its infancy. And it doesn't have wifi+bt built in, so you need to use a dongle or use up the NVME slot for adding that functionality.
Various kernel-devs on ActivityPub had some very very nasty things to say about rk3588 board stability. Different folk, on different boards. Maybe this time will be better, who knows, and maybe better drivers will improve things, but seeing such sad kernel devs has been demoralizing.
Not sure if I'm lucky, or if things have improved. But I've probably ran it at all cores busy compiling for 100 hours so far, and had uptime in the weeks, currently at 5 days.
I did use a beefy usb-c power brick, rated for 40 watts to ensure it's never getting less power than it asks for.
So far I'd say it's at least as stable as my RPi, and doesn't have anything ugly like storage or network connected via USB.
I would love to read the rants if you can find them. I was really considering getting some RK3588 based boards since it seems to be the most powerful ARM based SoC you can actually buy.
Glance through the Radxa and orange pi forums; there are plenty of growing pains still at this point, from power issues, Imagination GPU lacking support in Linux, and mostly other hardware/driver related quirks that will take time to sort out.
For some use cases they're great though, as long as you don't need specific features.
As a router or small server for running DNS, PiHole, and related services I'd recommend one of the Rk3588 systems, I bought a NanoPi R6S. The 8gb flavor is $120, $140 with a nice metal case. It's pretty fast, I compared compiling rust and it was 6-7 times faster than a RPi4 8GB. Even has two 2.5gbe interfaces.
Odroid is my go to low cost SBC. If you just need something like a WiFi connected display/sensor/switch, esp32. I really like the M5stick. Other than that specific projects usually have a list of alternatives which can help. There's a multi board build for Octoprint for example
I had a pretty bad experience with Odroid. I purchased a home assistant blue, which uses the Odroid N2+ and the USB ports died on it, which is a non-starter since I use Zigbee and Zwave USB sticks. Apparently this issue is not uncommon, and there was no way to get it warrantied or do an RMA.
I had a pretty bad experience with a Sandisk branded "Industrial" SD I purchased directly from Odroid (they put their sticker on it, partitioned it then added the payloads) as died within 1 year of very very low use.
I'm wondering if it was a real Sandisk.
Since I got about 10 at the same time it sucks: I'd have to individually test them before entrusting any of these with any data.
That's good to know. I've used them in the past for embedded vision for FIRST robotics. I was actually thinking about getting the N2+ to replace my Rpi4 for HA, but might just go with a NUC.
Agreed. I’ve used refurbished thinkcentres recently. They are more power hungry (and powerful), but within the realm of an 8GB rPI+power adapter+housing+SD card. Upside: x86-64!
The goal is to eliminate that altogether, at least in the design phase. You put down the modules, they see each other, can communicate, do the coding about which modules' signal goes where, what processes what etc., and when you are done it either works as is or an automated thing can create the final boards/cabling/wiring for you.
The less hurdles in the prototyping phase the better. I know it sounds impossible, but this wiring this to that always gets on my nerves.
So a software wiring kinda thing with a "wireless" approach would be very much welcomed.
The most important upgrade is the inclusion of autofocus (using PDAF) with full support from libcamera and Picamera2. It is pretty snappy though not quite as good as something like a Pixel or iPhone.
There's also a new M12-mount HQ camera, for the same price of $50, which is useful for some more specialty lenses (though I haven't run into any M12 lenses in my own work!).