It's a shame that, being based on a full-blown Linux SBPC, it has an absolutely unacceptable boot time for a camera. 22 seconds. I can have my iPhone camera out and ready to capture an ephemeral moment of child's play in under 3 seconds, most commercial cameras boot in seconds as well. A film camera can be ready to go the second the lens cap is off. 22 seconds is an eternity in the world of photography. It's a shame that the SoC the Raspberry Pi line is based on has no kernel support (or IIRC hardware support) for S3 or anything similar.
It's unfair to compare an idling deep sleep device with a cold boot.
However, there is a shortcut: Just don't boot a full OS (thinking of custom firmware which boots in fractions of seconds, standard in the Microcontroller world). Or boot an optimized Linux user space. I am confident with a bit fiddling one can bring down a standard SBC Linux to a few seconds from cold to ready.
Functional comparisons among devices within a category are always fair. Pointing out a device’s perceived shortcomings is not an attack on the people that made it. One crucial role designers play (ideally) in product development is seeking out honest feedback, filtering it, and figuring out if that feedback can help make the product better for end users. The FOSS landscape needs a lot more of that.
i built my own camera out of a Zero 2W [0] and by disabling Picam2 and letting the OS (Debian Bullseye) idle, i can get 2 days of shots and some videos while i walk around the city/hiking out of 3 18650 batteries... bringing 3 spare batteries in my backpack never put me needing battery in any situation! starting Picam2 takes a fraction of a second
I bet this could be changed to seconds if a unikernel type approach were used. There’s no need to boot a full OS. I understand the developer starting with Linux, though, as I’m sure it’s easier for debugging.
yeah it's pretty fair if you compare them apples to apples.
an iphone boots in 15-20s depending on how stale things are, you'll presumably need to unlock it, and then navigate to the camera app however you do so.
it's just presumed you wont have to boot your phone.
No disrespect to the project here, of course, but I'm wondering why there's no truly high-quality camera for Pis. I have the so-called "high-quality camera" and it still blows. I use it to monitor my 3-D printer with OctoPi, and that's about what it's good for.
There's Will Whang's boards - IMX585 [1] (16:9 1"-ish) and even IMX283 [2] (1") and even IMX294 [3] (Micro 4/3). But just those camera boards run $199 to $399, and released in "artisanal quantities"... so you have to pounce when Will restocks. Soho Enterprise has some IMX585 boards as well and I've seen some IMX585 MIPI CSI boards on aliexpress afair but never tried them
I'm experimenting with and have built a rangefinder-style camera [4], built around the IMX585 or IMX283 (the only boards I got my hands on) but using a CM5, this thing gets hot. It works though! Not too much bigger than my Leica Q. Haven't released anything yet but I tend to work on it and the model is in OnShape. Currently planning a complete screen-less redesign in FreeCAD... so that's _really_ different and slow, but I'm so over proprietary software :/
There's also the CinePi project using those sensors on a full-size Pi with a pretty active discord server.
While many camera sensors use MIPI/CSI, you need enough lanes to transfer the data, the driver support in the kernel and other pipeline bits to get good images from the bayer. Almost all “real” cameras use ASICs or FPGAs to clock out the images. Additionally sensor companies are miserable to deal with in small volume and datasheets are under NDA. You’re much better off buying a camera from a machine vision company over USB3 or Ethernet, but you need one which properly enumerates as a video device (many do not). You can still do nice stuff like hardware sync/trigger from the Pi.
I wonder why this doesn't use the 4608x2592 resolution the sensor is capable of. It produces cropped 2592x2592 images. Stylistic choice, hopefully not too hard to reconfigure?
I loved this project the first time it came around. As much as I wanted to build it out myself, I was shocked at how much the components actually cost to put together. It definitely seems like an improvement on the charmera though, so it all comes out in the wash.
I was looking around but either I missed it or it’s not spelled out. Do you recall a ballpark cost for the components? I didn't feel like individually pricing out the many components.
However, there is a shortcut: Just don't boot a full OS (thinking of custom firmware which boots in fractions of seconds, standard in the Microcontroller world). Or boot an optimized Linux user space. I am confident with a bit fiddling one can bring down a standard SBC Linux to a few seconds from cold to ready.
[0] https://happort.org/camera
still slower than a hot phone with an app, but it's faster than 22s.
an iphone boots in 15-20s depending on how stale things are, you'll presumably need to unlock it, and then navigate to the camera app however you do so.
it's just presumed you wont have to boot your phone.
https://www.arducam.com/imx519-autofocus-camera-module-for-r...
I'm experimenting with and have built a rangefinder-style camera [4], built around the IMX585 or IMX283 (the only boards I got my hands on) but using a CM5, this thing gets hot. It works though! Not too much bigger than my Leica Q. Haven't released anything yet but I tend to work on it and the model is in OnShape. Currently planning a complete screen-less redesign in FreeCAD... so that's _really_ different and slow, but I'm so over proprietary software :/
There's also the CinePi project using those sensors on a full-size Pi with a pretty active discord server.
[1] https://github.com/will127534/StarlightEye
[2] https://github.com/will127534/OneInchEye
[3] https://github.com/will127534/FourThirdsEye
[4] https://cad.onshape.com/documents/29c9488b2d4b80b73bcf3980/w...
While many camera sensors use MIPI/CSI, you need enough lanes to transfer the data, the driver support in the kernel and other pipeline bits to get good images from the bayer. Almost all “real” cameras use ASICs or FPGAs to clock out the images. Additionally sensor companies are miserable to deal with in small volume and datasheets are under NDA. You’re much better off buying a camera from a machine vision company over USB3 or Ethernet, but you need one which properly enumerates as a video device (many do not). You can still do nice stuff like hardware sync/trigger from the Pi.
Edit s/camera/sensor/