Hacker News Reader

Comment by jermaustin1 | Hacker News Reader

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?

View on HN

Many 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)

I'm mostly confused by the low vertical resolution. Would something like 320x240 work?

No. 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.

This 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.

Would 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?

Yes, you can do 320x240 with modified raspiraw parameters. But you will get the same framerate as for 640x240, for v1 as well as for v2 camera.

You can do the opposite and increase horizonatal resolution for line scanner type of application with still impressive framerates:

"v2 camera can do 3280x32@720fps and 3280x64@500fps with frame skip rate less than 1% (tools attached)."

https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=1091...

You can do quite impressive gobal external shutter capturings (with v1 camera only!), eg. capturing a 109m/s airgun pellet in flight on a single multiple exposure frame 10x: https://github.com/Hermann-SW/Raspberry_v1_camera_global_ext...

I 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

Find diagram showing the achievable framerates for 640xH frames for v1 and v2 camera here: 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.

It's probably bottlenecked by how fast the sensor data can be read.

Yea 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.

Yes, 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/...

Limited by the chip that reads the data off the sensor - ASIC of FPGA. Or maybe by the sensor design itself.

Reply on news.ycombinator.com