Hi Everyone,<p>I do have it already linked in the article, but I should point out that the work I did is based upon the work of (at least) several other key individuals:<p>A lot of the low-level sensor interaction code is found in:<p><a href="https://github.com/Hermann-SW/fork-raspiraw" rel="nofollow">https://github.com/Hermann-SW/fork-raspiraw</a><p>Also, check out his web site with lots of other high speed camera hacking stuff:<p><a href="https://stamm-wilbrandt.de/en/Raspberry_camera.html" rel="nofollow">https://stamm-wilbrandt.de/en/Raspberry_camera.html</a><p>The original fork of raspiraw is (I think) found here:<p><a href="https://github.com/6by9/raspiraw" rel="nofollow">https://github.com/6by9/raspiraw</a><p>And the code for converting RAW images into standard formats uses dcraw:<p><a href="https://en.wikipedia.org/wiki/Dcraw" rel="nofollow">https://en.wikipedia.org/wiki/Dcraw</a><p>I didn't personally write much code to put this together. I would say that my contribution here was mainly to pull together some impressive work done by others that wasn't getting much attention and market it well. Hopefully some of you get ideas and push this even further.
This is amazing. These framerates are 1/10th of what a cursory google search says I can get out of a top of the line high-speed camera, but for probably 1/100th the price. You could make so many awesome instructional videos with a tool like this.
> processor registers on the image sensor are set so that raw data is sent continuously (to be processed later)<p>Very slick.<p>Make me wonder what crazy high-speed imaging hacks might be possible with a top-of-the-line sensor used in iPhone/Pixel phones.
The demo videos don't have a good black level.<p>Is this processing method perhaps not using a correct dark image, or not correctly subtracting off the shaded calibration rows on the sensor?<p>If thats the case, it's probably screwing with the gamma conversion, making it look even worse.
Wow. Never thought about this approach to leveraging RAM for cameras. Awesome guide!<p>Can anybody chime in regarding the resolution limit (640x64) -- If this is for memory reasons, could we pick alternate values such as 200x200 as long as the total pixel count is the same?
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.<p>Could this record at a higher resolution?
if you put the sensor on a really fast step motor, you can pivot the sensor a tiny bit in two dimensions, to get way more resolution out of it, at a loss of framerate, and you'll need to do some post processing.<p>something like this: <a href="https://chriseyrewalker.com/the-hi-res-mode-of-the-olympus-om-d-e-m1-mark-ii/" rel="nofollow">https://chriseyrewalker.com/the-hi-res-mode-of-the-olympus-o...</a>
What was the lighting setup like for the demo videos? Did you do any processing to reduce flicker?<p>I get a lot of flickering from CFL and incandescent bulbs in my 240 FPS videos, though I’ve had better results with some LEDs. Considering how much light I’ve needed for good videos at 240 FPS, I’d imagine the lighting requirements at 660-1000 are fairly immense.
Are there any cameras at a higher price with better stats, but still lower than $2k for a used Chronos 1.4GP/s? I wouldn't mind buying a $1k camera to get 720p 1000+ fps.
1107 fps on the V2 IMX219 camera. I wonder how fast or how large of a frame it could do on a Pi4 or odroid (article mentions the 640x64 frame is limited by memory bandwidth).
Everything is doable if you have detailed description of the sensor. Do you know any sensor to get a better resolution with comparable frame rate and detailed specs?<p>Can RAM limits be improved with a simple compression?