5 ms·
I read through, and I didn't find a reason that the resolution is 640x64@660 other than that is what was input into the raspiraw program. Could this record at
by jermaustin1 7y ago
I read through, and I didn't find a reason that the resolution is 640x64@660 other than that is what was input into the raspiraw program.
Could this record at a higher resolution?
- sp332 7y agoIt's probably bottlenecked by how fast the sensor data can be read.
- djsumdog 7y agoYea they mention in the video, but don't mention what happens with a higher aspect ratio. I suspect it will cause artifacts, like part of one frame appearing on the previous or tearing or other distortions. Remember these sensors read a single row at a time. There's a Smarter Every Day video where they show how cellphones get those weird effects when recording plane propellers due to the way they scan images.
- HermannSW 7y agoYes, for objects moving with high speed vertically, rolling shutter capturing produces weird frames. But v1 camera can do "global external shutter" as well. See examples on "extreme rolling/global external" shutter for propellers here: https://github.com/Hermann-SW/Raspberry_camera_gallery/blob/master/propeller/README.md https://github.com/Hermann-SW/Raspberry_camera_gallery/blob/...
- bufferoverflow 7y agoLimited by the chip that reads the data off the sensor - ASIC of FPGA. Or maybe by the sensor design itself.
- pfranz 7y agoI haven't read through everything yet, but in the examples video[1] it's stated that they can only read a portion of the sensor to keep a high frame rate and that the camera returns one row at a time. A square image requires reading more rows and takes more time. [1] https://youtu.be/-gMy8k4nHtw?t=154 https://youtu.be/-gMy8k4nHtw?t=154
- michaelt 7y agoMany image sensors have a 'windowed readout' function that lets you throw away lots of pixels' data, in exchange for a higher framerate. So for example, a sensor that 1920px × 1080px × 30fps has the ability to output 62,208,000 px/second - and with the same ADC and MIPI bus, halving the number of pixels can double the number of frames per second. You'll note this article's demo, 640px × 65px × 660fps = 27,456,000 px/second. So you might plausibly get it a bit larger - maybe 640×120 - but you're not going to get HD resolution at this framerate using this hardware. (Obviously, there's also questions like exposure time and light levels so it's not quite as simple as I just made it sound)
- gambiting 7y agoI'm mostly confused by the low vertical resolution. Would something like 320x240 work?
- timbilty 7y agoNo. The camera image is read row-wise. One could perhaps stitch together the output of multiple cameras and RPis though differing perspectives may make this impractical under some circumstances.
- londons_explore 7y agoThis depends on the design of the sensor. Basic sensors effectively have one analogue to digital convertor (ADC) per column of pixels. That would mean that if you wanted to reduce the horizontal resolution, you would be disabling some ADC's, which in turn would reduce how many pixels can be converted per second, giving you no benefit.
- ZeikJT 7y agoWould it be possible to buy a second camera and wire up its ADCs to the sensors on the first camera and then read the next set of vertical pixels? Effectively doubling the vertical resolution?
- HermannSW 7y ago
- HermannSW 7y agoFind diagram showing the achievable framerates for 640xH frames for v1 and v2 camera here: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=212518&p=1310445#p1320034 https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=2125... Deal is basically "halve vertical resolution, and get roughly double framerate" (up to cap imit of around 665fps for v1 and exactly 1007fps for v2 camera). In addition "tools/*_s" tools double vertical FOV while keeping the framerate.