Comment by ktpsns | Hacker News Reader

Comment by ktpsns | Hacker News Reader

Parent Full thread

Which brings me to this Gedankenexperiment: If you buy/build 10 of the raspberry pi based high speed cameras and run them in parallel and could make sure each camera sees the same (we don't consider details here for the time being), is it possible to merge the videos in order to reach the frame rate of a "top of the line high-speed camera"? I could imagine two scenarios:

  1. Start recording with time delay. Probably requires 
     excellent clock synchronisation, a real time kernel, 
     reliable/comparable hardware (gatter timings differ at 
     small timescales). If this works, this would provide a 
     high quality equidistand framerate.

  or

  2. Start recording randomly, synchronize by time or
     with an video event, and merge the frames. This will
     result in a stochastic distribution of frame rates. The 
     usefulness of such a movie depends on what it is 
     supposed to be used for (thinking of scientific usage). 
        Will probably not give nice slow-mo movies. But
     here comes the catch: With interpolation, the shortest 
     reachable frame rate dictates the quality of this
     "superposition camera". How many cheap cameras do we
     need to archieve, on average, the top line high speed 
     camera?

I leave the questions open for friends of Gedankenexperiments ;-)

The raspberry pi camera is rolling shutter, which adds some complications. To properly simulate a high framerate camera, you would want to build each frame from sections of several images that are being simultaneously exposed. Doing so without leaving artifacts at the borders would require some sort of really fancy interpolation, but might be possible.

That's a good question, I'm wondering though, if the shutter speed on commercial high speed cameras is faster, but I could be wrong?

"A Phantom camera he uses goes up to a maximum of 1000 fps in 4K — an exposure time of 1/2000 sec with a 180° shutter speed — and the image starts looking pretty dark on the screen."

I'm just trying to find what shutter speed you can get with the Pi camera.

Edit: Just having a little play:

./raspiraw -eus 500 -md 7 -t 1000 -ts tstamps.csv -hd0 hd0.32k -h 64 --vinc 1F --fps 660 -r "380A,0040;3802,78;3806,0603" -sr 1 -o /dev/shm/out.%04d.raw 2>/dev/null

500 microsecond exposure (1/2000 seconds) seems to run.

> I'm just trying to find what shutter speed you can get with the Pi camera.

You can reduce the shutter time nearly arbitrarily, as long as you increase light intensity. I did place fast rotating propeller just above a 5000lm led, and did two 9us long flashes. See this image on how bright the two blades of propeller look, at both captured locations (the rest is dark, image was taken inside a closed cardbox, without flash everything was just black): https://raw.githubusercontent.com/Hermann-SW/Raspberry_v1_ca...

pee cameras are clocked externally(EMI made them include 25MHz clock gen on camera module itself), so in theory you could connect them all to a single clock distribution source with appropriately shifted phases

How do you disable onboard clock or is it automatic?

You'd likely have to de-solder the one on the board and maybe do a few other small modifications to get it to work properly. I imagine you'd want to use a completely different kind of source and then use some op-amps to both shift the waveform and also then strengthen the signal so that the load of each camera doesn't cause issues.

no analog at those frequencies, you would want dedicated Multi-phase Clock Buffer chip, something like a couple CY7B9945V

I think you could probably just parallel connect the quartz clock terminals on the cameras.

As long as your leads didn't have too much capacitance, it ought to just work.

The phase shifting you can do in software by (for example) restarting the camera hundreds of times till by chance it starts a frame with the phase offset you want, and then just run on from there.

Won't two clocks interfere with each other?

As long as they're tuned close-ish to eachother, they will synchronize and oscillate in lockstep.

I'm talking the actual quartz crystal here, not the output of some digital clocking chip (which you're right, wouldn't work).

its already external, on the back of each camera

But it's only selectively enabled no?

I like this. It reminds me of an idea I had about making an ultra-hd projector by running consumer projectors in a grid with careful alignment and cooling. Your idea is similar, but over time instead of space. Both are just dimensions so I don't see why it couldn't work, so long as you had the timing circuit.

This isn't just a thought experiment, this is how some of the most influential slow motion to date has been shot, from the famous bullet dodge in the matrix to the first 1-billion fps camera. (Okay yes technically the 1-billion one is the same camera run many times but it's the same synchronization problem)

I think that would be possible, just a problem of adjusting all cameras to get overlapping FOV.

There was a MIT student project group that took 16 v1 cameras(!) global external shutter frames and created an animated .gif from that! "Ultra high-speed imaging, capturing matrix style bullet time" https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=2404...

Have some fun: http://graphics.stanford.edu/projects/array/

Reproducing something like this using cheap sensors would require some hardware acumen, but isn't unfeasible. Most industrial cameras, even cheap ones, have external triggers/clocks with nanosecond latency.

Reply on news.ycombinator.com