v2 camera can capture 1000fps videos ...

[HermannSW]

... using raspivid, and if you bring in very bright light (5000lm OK, 1000lm too dark).
I use a (<10$) 5000lm light that has no powerline frequency issues:
viewtopic.php?f=66&t=209041&p=1309474#p1309474


First some facts, new videos taken will get separate postings in this thread.

v2 camera hardware framerate limit
I found a hardware limit in v2 camera, you cannot get more than 1007fps, but you can get 1007fps:
viewtopic.php?f=43&t=109137&p=1309989&s ... 3#p1307795


v2 camera 1000fps resolution(s)
The resolution where this works is 640x75.


With setting odd vertical line increment from 1 to 3 you can get 640x150_s frames at 1000fps.
But dcraw program needed to process raw Bayer frames has some problems for v2 camera (not for similar in v1 camera).
v2 camera capturing 75 lines this way covers 150 line area, and after dcraw duplicating each line gives 640x150_s:



Comparison with S9 super slow motion
800$ S9 can do HD 960fps super slow motion, but only for 0.2s:
http://www.samsung.com/global/galaxy/galaxy-s9/specs/

I did 7s 1000fps video with raspiraw into /dev/shm (required), leading to 100% use but still 3664K free.
And v2 camera does cost 25$, not 800.


first 1000fps v2 camera video taken
From this posting, screw driver quickly moving left/right above Lego pieces:
viewtopic.php?f=43&t=109137&p=1309989&s ... 3#p1307795



if you want to try now ...
... I did not commit/push the new features to github, will do that as single commit/push for pull request on 6by9's branch.

But you can start right now, diff you can apply as patch and 640x75 and 640x150_s tools are attached here:
viewtopic.php?f=43&t=109137&p=1309989&s ... 3#p1309546

[HermannSW]

Today I wanted to use 1000fps video for my favorite high framerate gadget, a classical mouse trap. I did 665fps recodings sofar with v1 camera resulting in 7 frames for the 1/90th second time mouse trap needs to close.

I started with a 180fps raspivid video for showing the scene. This frame shows that black piezo igniter on right has already been hit (the spark between cables in front proves that). But we cannot see the igniter being pushed down:
https://www.youtube.com/watch?v=p21fTmU ... e=youtu.be



Next I tried again with 1000lm light, you can see something, but pale:


With 5000lm light it looks much better, part of 1000fps video played at 1fps:


I took a 2s video with 640x150_s tool, with 1% frame skips.
Then I extracted frames 919-943 from it.
There was only one frame skip in that range, but after closing was complete (frame 937, 1986μs).
The closing happens in 11 frames, from frame 922 before start to 933 piezo igniter hit.
Average framerate in that phase is 1006.8fps:

Code: Select all

$ egrep ",(922|933)," tstamps.csv 
993,922,2847690251
993,933,2847701176
$ echo "(2847701176-2847690251)" | bc -ql
10925
$ echo "(2847701176-2847690251)/11" | bc -ql
993.18181818181818181818
$ echo "1000000/((2847701176-2847690251)/11)" | bc -ql
1006.86498855835240274599
$ 

I mentioned that dcraw has some problems with 1/3 increments for v2 camera 640x150_s tool.
This is the 11th frame which for the very first time (of many mouse trap closing videos) shows igniter pushed down (and spark between cables in front):



For comparison, this is the frame directly before with black igniter pin showing above mouse trap board:

[HermannSW]

I wanted to see clearer frames and did 640x75 tool 1000fps recording.

The video before was done with a 75° lens (from v1 Pi Noir camera with lens).
In order to get more into top 75 lines of 640x480 frame I used a 130° lens for this:


Only 75 lines in 640x75 video, but 1000fps and crystal clear!

This is frame 1281 from video with piezo igniter hit and spark between cables in front:

[HermannSW]

I posted on how to add millisecond timeoverlay to high framerate videos and rotate by 90° in this posting (for upload to youtube):
viewtopic.php?t=209794

The videos in that posting were created with raspivid (.h264). I have to figure out how to change the gstreamer pipeline described there in order to work with the .ogg videos created by raspivid's raw2ogg2anim tool.


I bought a 1$ yo-yo recently, with LEDs inside that get lit when yo-yo spins fast (no batteries), with the plan to use it for high framerate videos. Of course today I did a 1000fps video of it. The yo-yo was fixated 1m above the scene, so that its bottom point will not touch the wooden plate of my motor test station. After loading the yo-yo cord I did let yo-yo go down for 90cm alone.

Since in this scenario the most activity is vertical, I turned the v2 camera by 90°.
So the yo-yo goes from top(right) to bottom(left) first, and then goes up(to the right) again after reaching lowest point.
I wanted crystal clear frames and therefore did 640x75 1000fps video.
The video is played at 25fps, 40 times slower than real:
https://www.youtube.com/watch?v=eTFBV-M ... e=youtu.be


Frame 5842 is a sample where you can see the yo-yo's cord:



The yo-yo goes much faster up(right) than down, and its diameter is 5.3cm.

Frame 5998 where yo-yo just hits right border on way up:


Frame 6016 where yo-yo's center hits right border:


Frame 6037 where yo-yo's left hits right border:



yo-yo speed upwards at that moment is 1.37m/s:

Code: Select all

$ egrep ",(5998|6037)," tstamps.csv 
993,5998,10558503651
993,6037,10558542385
$ echo "(10558542385-10558503651)" | bc -ql
38734
$ echo "(10558542385-10558503651)/1000000" | bc -ql
.03873400000000000000
$ echo "0.053/((10558542385-10558503651)/1000000)" | bc -ql
1.36830691382248154076
$ 

[HermannSW]

I checked that the "special" dcraw behavior for v2 camera raw Bayer images with odd vertical line increment 3 does not exist for v1 camera (the *_s modes there are fine).

Now I tried to determine the maximal framerate depending on the height of the frame.

First I learned that framerate determination is like tuning very old antenna TV, if you do not get the exact frequency image was not good. While I can request arbitrary framerates, the effective framerates on v2 camera have discrete steps.

This is 640x80 frame captured at 950fps, image not good on top:



This is 640x80 frame captured at 968fps, image nearly good:



This is 640x80 frame captured at 987fps, image not good on bottom:



Since above are direct v2 camera framerate steps, the bottom line for 968fps cannot be avoided. If that hurts, then 640x79 can be taken at 968fps cleanly. "Best" framerate is v2 camera maximal framerate 1007fps, can be achieved with 640x75, not with 640x76.

I varied height in multiples of 16 and got this table/diagram:



Not sure what function/relation that is between framerate and height.
For (v2 camera) 640x128 we get 667fps, for v1 camera 640x128_s tool we get 665fps.
For that format v2 camera framerate is double that of v1 camera (it records 64 lines in that mode).


P.S:
This is secondary living place dev/debug environment, two PIs, v1 and v2 camera, 1000lm Ikea light and 5000lm light:

[HermannSW]

I wanted to know the formula to get an idea how framerate can go beyond 1007fps for smaller heights in case I will find a configuration register setting allowing for more.

After some unsuccessful attempts, I finally tried linear regression on (framerate, 1/height) pairs, and that went well.
With a little formula cosmetics the approximate values for height or framerate are pretty close to measured.
The framerate outlook for height 64 or 32 looks interesting:

Code: Select all

$ echo "(70077.1/64)+108.7" | bc -ql
1203.65468750000000000000
$ echo "(70077.1/32)+108.7" | bc -ql
2298.60937500000000000000
$ 

Code: Select all

410	224
438	208
471	192
508	176
552	160
604	144
667	128
744	112
841	96
968	80
1007	75

P.S:
Did 1000fps spark videos, find details here:
viewtopic.php?f=43&t=207537&p=1311923#p1311923

[HermannSW]

Today I came back to "--voinc 3" option that produced the not so nice raspiraw videos posted before.

Yesterday I was able to make raspivid change shutter speed for every frame recorded without issues:
viewtopic.php?f=43&t=212694&p=1313054#p1313054

So today I added "--voinc" option to my github userland branch with this small diff:
https://github.com/Hermann-SW/userland/ ... 0570204095

This is raspivid command with new option:

Code: Select all

pi@raspberrypi3Bplus:~/userland $ ./build/bin/raspivid -md 7 -w 640 -h 480 -stf 25 --voinc 3 -fps 180 -pts test.pts -t 4000 -o test.h264
pi@raspberrypi3Bplus:~/userland $

This is frame before frame number specified with "-stf" option:



This is frame after my I2C commands got injected, including the new voinc option:



Looks as bad as previously in this thread. This indicates I am missing some register setting to make increments of 3 work.
Interestingly none of the 7 modes for v2 camera in raspiraw has vertical increment of 3, all have vertical increment of 1 (default).

[HermannSW]

I thought symmetry does not hurt and added "--hoinc" option for odd column increments:
https://github.com/Hermann-SW/userland/ ... 36319457ab


With this command:

Code: Select all

pi@raspberrypi3Bplus:~/userland $ raspivid -md 7 -w 640 -h 480 -stf 25 --voinc 3 --hoinc 3 -fps 180 -pts test.pts -t 4000 -o test.h264
pi@raspberrypi3Bplus:~/userland $

Frame does not look perfect (only quarter of image area covered), but much better than with "--voinc 3" alone!

[HermannSW]

Next steps completed:

• added "--hoinc" option to raspiraw
• made raspiraw "--width" option work for v2 camera in addition to v1 camera
• modified double.c so that it can double dcraw generated .ppm in x-direction as well

This is frame from 1007fps framerate 640x150_s tool generated video (that records 75 lines and 320 columns, but with odd line/column increments of 3, covering 640x150 v2 sensor area), dimension is 320x75:



And this is post processed frame after doubling in x- and y-direction, dimension 640x150:



Of course the scene was lighted with 5000lm light, otherwise the frame would look much darker.
The frame is correctly representing the 640x150 area captured by v2 camera, just a bit coarser.
But at 1007fps ...

[HermannSW]

First 640x150_s tool video with odd line/column increments of 3, looks much better than the previous 640x150 1000fps videos in this thread. The small spark generated by mouse trap bar hitting piezo trigger can be seen on 10th frame of mouse trap closing. Video is played at 1fps:



Video captured with this command, scene lit with 5000lm light:

Code: Select all

pi@raspberrypi3Bplus:~/raspiraw/t $ ./640x150_s 3000
removing /dev/shm/out.*.raw
capturing frames for 3000ms with 1000fps requested
2980 frames were captured at 1007fps
frame delta time[us] distribution
      1 
      1 990
      5 991
      6 992
   2399 993
    530 994
      7 995
      1 996
     23 1986
      4 1987
      1 2979
      1 3972
      1 5959
after skip frame indices (middle column)
1986,276,23651810633
5959,313,23651852346
3972,321,23651863271
2979,326,23651870223
1986,570,23652113552
1987,575,23652119512
1987,670,23652214857
1986,770,23652315167
1986,871,23652416471
1986,972,23652517775
1986,1073,23652619079
1987,1174,23652720384
1987,1275,23652821688
1986,1375,23652921998
1986,1476,23653023302
1986,1577,23653124606
1986,1678,23653225910
1986,1779,23653327214
1986,1880,23653428518
1986,1945,23653494068
1986,1979,23653528829
1986,2080,23653630133
1986,2181,23653731437
1986,2282,23653832741
1986,2383,23653934045
1986,2484,23654035349
1986,2584,23654135660
1986,2685,23654236964
1986,2786,23654338268
1986,2887,23654439572
0% frame skips
pi@raspberrypi3Bplus:~/raspiraw/t $ 

Only 30 frame skips of 2980 frames captured at 1007fps.

The video was generated with this command (for now):

Code: Select all

./raw2ogg2anim m 835 859 1 d

There was no frame skip in that range:

Code: Select all

...
1987,670,23652214857
1986,770,23652315167
1986,871,23652416471
1986,972,23652517775
...

Next step is adding "--shutter" option to raspiraw to get not that blurry high speed frames short before mouse trap bar closes. 993μs is too long for such high speed motion. "--shutter 250" will address that.

P.S:
"shutter" registers and how to set identified:
viewtopic.php?f=43&t=212694&p=1313054#p1313917

[HermannSW]

Next step is adding "--shutter" option to raspiraw to get not that blurry high speed frames short before mouse trap bar closes. 993μs is too long for such high speed motion. "--shutter 250" will address that.

That was wrong, I just realized that this option is already available in raspiraw, but it is named "--expus" for setting the exposure in micro seconds.

P.S:
"shutter" registers and how to set identified:
viewtopic.php?f=43&t=212694&p=1313054#p1313917

This was good to be sure that "--expus" is what I wanted for "--shutter".

Looking into raspiraw.c for the code that does set exposure, it sets time in microseconds times 1000/line_time_ns (= 1000/19517 = 0.05123738279448685761) for v2 camera. The factor I determined in that posting was nearly the same: 1024/20000 = .05120000000000000000


Summary:
Setting shutter time in microseconds is done with raspiraw "--expus" option.


I am not at home and don't have access to the mounted mouse trap with piezo igniter here. Will do shorter shutter time/exposure with that when back home.

I have the yo-yo with me and did similar videos as before (left corresponds to top since camera is again rotated by 90°).

This is a frame from video without "--expus" option and therefore shutter time 993μs (because of 1007fps).
Movement of yo-yo from top(left) to bottom(right), the circles on yo-yo look blurry:



Here is similar frame from 640x75 video taken with "--expus 500". Only a single circle (because yo-yo moved slightly different in this video), but not blurry:



This is animated .gif from video with 500μs shutter time, played at 30fps, which is 33.5 times slower than real:



So really smaller shutter shutter times help with 1007fps videos for reducing blur.
(Videos taken for scene lit by 5000lm light, with 130° lens in order to get much scene into top 75 lines)

[gusgus]

Hello,

I've been following your work and I find it amazing. For my own project, I would like to get as many image per second from the camera, but then do some real time (and very light) analysis of the image, with as little latency as possible. The treatment involves checking the color of a few pixels in the image.

So far so good, however the code available one your repo only allow accessing the raw image and storing it in some file, and converting it after the recording is finished with another software.

I know myself a fair amount of C++ and thus I would like to add a function in your code that allows to query for the color of a specific pixel in a raw image, without having to convert the whole image (I'm not using the full image).
I think this might be of some use to others, so I hope this could be integrated in your repo. Hence If you have some time to spare, it would be nice if you could tell me where to start/ where to put the code, and maybe a bit on how the raw to bgr converter works - I had a look at the code and it's an horrible mess, treating a lot of different devices....

Thanks!

Ps: I intended to have this discussion as PM but it seems new users can't send PM

[HermannSW]

I've been following your work and I find it amazing. For my own project, I would like to get as many image per second from the camera,

640_128_s tool captures at 665fps with v1 camera.
640_150_s tool captures at 1007fps with v2 camera.

but then do some real time (and very light) analysis of the image, with as little latency as possible. The treatment involves checking the color of a few pixels in the image.

It has to be light at high framerates, and you can forget about useing OpenCV or similar. It tried OpenCV for edge detection in 320x240 images and prcesing a single frame did take 20ms, so 50fps at most

So far so good, however the code available one your repo only allow accessing the raw image and storing it in some file, and converting it after the recording is finished with another software.

Before doing all the high framerate work I started with thread
"raspiraw raw bayer data: how to use in callbacks for feature extraction and robot control".

In this posting of that thread I describe in detail where to extend raspiraw to automatically do robot's camera tilt calibration:
viewtopic.php?f=43&t=189661#p1231151

I know myself a fair amount of C++ and thus I would like to add a function in your code that allows to query for the color of a specific pixel in a raw image, without having to convert the whole image (I'm not using the full image).

Good news is that each frame is raw10 Bayer data, so 4 ten-bit values are stored in 5 bytes.
You can directly access pixel (x,y), determine its 10bit value and do what you want.
BUT raw Bayer images have red/green/blue pixels like this:
https://en.wikipedia.org/wiki/Bayer_filter


So you have to do some work to determine the color you search for (that is what dcraw does, create nice frames from this red/green/blue frames of camera).

I only need to determine a black line on white ground for line following. Both green pixels are brighter than the red or blue pixel of a 2x2 square, and the left bottom green is brighter than top right green pixel. I can take only left bottom green pixels (a quarter of all pixels), ingnore least significant two bits and intepret this as a 8bit gray scale image.

Ps: I intended to have this discussion as PM but it seems new users can't send PM

I think discussing here where others can see and/or comment is better than PM.

[HermannSW]

I did a step back framerate wise and took a 640x224 frame video at (only) 404fps
https://www.youtube.com/watch?v=pLLQ5sb ... e=youtu.be
(you can inspect details by stopping youtube video, and then single frame step fore/back with "."/"," keys)

Frame delta time is 2473±4 μs ...

Code: Select all

pi@raspberrypi3Bplus:~/raspiraw/t $ ./640x224 4000
removing /dev/shm/out.*.raw
capturing frames for 4000ms with 402fps requested
1605 frames were captured at 404fps
frame delta time[us] distribution
      1 
      2 2471
      5 2472
   1258 2473
    332 2474
      2 2476
      1 4945
      1 4946
...

... with 5 frame skips in total:

Code: Select all

...
      1 4945
      1 4946
      1 7419
      1 7420
      1 14839
after skip frame indices (middle column)
14839,993,1610581594
4946,997,1610593960
7420,998,1610601380
7419,999,1610608799
4945,1021,1610665682
0% frame skips
pi@raspberrypi3Bplus:~/raspiraw/t $

After converting single frames with raw2ogg2amin and inspecting them I found that interesting part of yo-yo run happened between frames 620 and 830, and there are no frame skips in that range. I created .ogg video playing at framerate 25fps for upload to youtube. Playing 404fps at 25fps is 16.16 times slower than real. Conversion took less than 3 minuts, biggest part being generation of animated .gif (from the .ogg video created first, which could be viewed then already):

Code: Select all

pi@raspberrypi3Bplus:~/raspiraw/t $ time ( raw2ogg2anim n 620 830 25 )
removing old auxiliary files
..
...
real	2m47.425s
user	2m31.020s
sys	0m2.340s
pi@raspberrypi3Bplus:~/raspiraw/t $ 

What went wrong with the video:

1) I did light scene with 5000lm light (otherwise you would not see much), but forgot to turn off room light running at 50Hz German powerline frequency. That is the reason for flicker you see (repeating pattern roughly every 404/(2*50) or 4 frames).

2) For some reason dcraw creates 640x240 frames from captured 640x224 frames, and fills last 16 rows with junk.

3) I installed Ikea desk light at high shelf and used that for top point of yo-yo cord. I prepared the scene so that the yo-yo lowest position was fully inside frame on right side. I forgot that the desk light has moving parts, and therefore the yo-yo lowered the desk light and moved outside of frame shortly before going up again.


Anyway, nice (and big) 404fps video:

[HermannSW]

I was wrong on reason for flicker in previous video.
I turned off room light, then turned on 5000lm light, and got same flicker in newly captured video.
I looked into capturing script and found copy&paste error (yeah, those are the best).
Script contained "... --height 240 ...", and that resulted in the junk below the 224 lines that can be captured at 404fps.
And that junk different in each frame confused dcraw.

I took a new yo-yo video at 404fps, this time really with 640x224 frames:
https://www.youtube.com/watch?v=2Yv4345 ... e=youtu.be

And I did (intentionally) NOT turn off room light.
Result is clean 640x224 video, played at 25fps, 16.16 times slower than real.
Of course normal 50Hz power line frequency room light effect is completely hidden by 5000lm light:

[HermannSW]

While 1007fps is available for small height of 75 only (640x75, or 640x150_s), there are applications.

Last year I did high speed outrunner motor tests in my motor test station (MTS):
https://forum.arduino.cc/index.php?topi ... msg3338067

One Raspberry camera did look horizontally through a peephole into MTS:



I used the recorded 90fps videos for high speed bump analysis (animation slowed down by factor 10):



For bump analysis the camera was adjusted to record video just flat on MTS ground board. A 640x75 video (instead 640x480) would have been totally sufficient for that.

At fastest run (18.77m/s or 67.6km/h) the robot did 18.77/1.28=14.66rps (rotations per second). With 90fps video capturing framerate that resulted in 90/14.66=6.14 frames per round only (a frame every 58.64°).

At 1007 fps (now no problem with v2 camera and raspiraw) I would have got 1007/14.66=68.7 frames per round, or one frame every 5.24°!!

P.S:
Wheel bumps were not only contra productive for achieving high speed, but also caused lost wheels at 52km/h. That was a threat for the 2nd Raspberry camera capturing video of MTS from above I had forgotten to close security glas on top of MTS after starting that run, resulting in almost hit of camera by flying wheel ... (90fps video played at 1fps, slowed down by factor 90):

[HermannSW]

Visual rpm detection for 20,140rpm RC airplane propeller with 640x75 video at 1007fps, see:
viewtopic.php?f=43&t=190407&p=1319617#p1319617

[HermannSW]

Made good progress on graphing framerate versus height of 640xH frames. Extended the set of heights measured in deltas of 16 to 320 and did measure 640x480 as well. And I did measure v1 camera in addition to v2 camera. Did measure on Pi 3B+, same measurements with Pi Zero[W] tbd soon.

Up to 500fps, v2 camera can do twice the v1 framerate for same frame size, above factor goes down to 1.75:
<add>I did cut off top and bottom extremal values, and did linear regression on (1/height, framerate).
Good approximation for v2 framerate is "76034/height+67", maximally off 859-841=18 for height 96.
Good approximation for v1 framerate is "42755/height+13", maximally off 153.64-151=2.64 for height 304.</add>

Code: Select all

height	v2	v1
480	202	95
320	295	144
304	309	151
288	324	160
272	342	169
256	361	179
240	383	191
224	410	204
208	438	219
192	471	237
176	508	258
160	552	282
144	604	312
128	667	349
112	744	396
96	841	458
80	968	543
75	1007	576
64		665

[HermannSW]

if you want to try now ...
... I did not commit/push the new features to github, will do that as single commit/push for pull request on 6by9's branch.

But you can start right now, diff you can apply as patch and 640x75 and 640x150_s tools are attached here:
viewtopic.php?f=43&t=109137&p=1309989&s ... 3#p1309546

Another code drop outside github with the v1/v2 camera 640xH tools used to create above chart is available per request here:
viewtopic.php?f=43&t=213482&p=1320044#p1320044

P.S:
I corrected this "outside of github", forked my own fork and commited&pushed there:
viewtopic.php?f=43&t=213482&p=1320505#p1320505

So my "fork-raspiraw" repository contains the most recent stuff, will use my "raspiraw" repo only for pull request to 6by9's raspiraw.

[HermannSW]

I still have found no way to get more than 1007fps with v2 camera.

Today I checked v1 camera. As the diagram showed v1 camera allows for 640x64@665fps. 640x32 tool allows for 750fps.
I went down with height captured as possible. Height 16 or below does not work anymore. So I used new 640x17 tool derived from 640x32 by just changing height and fps.

Requesting 1200fps is ridiculous because there are more frameskips than frames at target framerate. But what this little experiment shows is that v1 camera has no just above 1000fps hard framerate limit like the v2 camera (1007fps). v1 "maximal framerate" (reported wrong by script) is 1,000,000/825=1212fps! Not really useful because of way too many frameskips, but maybe doing 320xH captures instead of 640xH can get rid of the many frame skips:

Code: Select all

pi@raspberrypi3BplusX:~/fork-raspiraw/c $ ./640x17 4000
removing /dev/shm/out.*.raw
capturing frames for 4000ms with 1200fps requested
2667 frames were captured at 605fps
frame delta time[us] distribution
      1 
      1 823
     33 824
    317 825
    288 826
     31 827
      1 828
      1 1647
     40 1649
    238 1650
   1332 1651
    168 1652
...

[HermannSW]

In posting 'Re: [SOLVED] Question on [1-3]×5000lm "-set" exposure times' I described the aluminum foil inside cardboard setup that allow for 5000lm/10000lm/15000lm focused lighting of a scene:
https://www.raspberrypi.org/forums/view ... 4#p1428384

I will use that cardboard setup for investigation of the smallest shutter time possible v2 camera allows to make good 1007fps videos from. I had done raspiraw recordings with as low as 100µs shutter time already, but would expect to go much below that if lighting scene with focused 15000lm light.

Yesterday I did the initial setup, again with v2 camera looking through middle hole of the three 5000lm leds on top of the cardboard construction. I had to do this since there is not enough space for classical mouse trap and v2 camera inside the 17cm side length cardboard triangle construction. You can see mouse trap at bottom of cardboard setup, and that I had to use coins for pointing the camera to exactly where I wanted ( I used 75° f=3.6mm lens, but 640x480 recording with v2 camera has reduced FoV):


This is the first animation generated from some frames of the 1007fps video without frame skips (played at 1fps), showing the triggering of the mouse trap and then its snap. I used 640x150_s tool resulting in 640x150 frame at the cost of coarser display compared to 640x75, but still at 1007fps. I did not restrict shutter time for this initial video taken with only one 5000lm led, so that was roughly 1ms which is definitely far too long for the fast movement of mouse trap bar:

[HermannSW]

It turned out to be better to have v2 camera slightly outside of cardboard construction, and using a bigger spot to look through than the small center hole. The camera is held by Realacc third hand, high enough that the cardboard can be taken away, mouse trap can be loaded again and cardboard brought back into position whithout touching v2 camera and having same view for several videos:



The current video was taken with 640x150_200_s tool with 200µs shutter time, and one 5000lm led on:

Code: Select all

$ ./640x150_200_s 2000removing /dev/shm/out.*.raw
capturing frames for 2000ms with 1000fps requested
1984 frames were captured at 1007fps
frame delta time[us] distribution
      1 
      1 989
      1 990
     13 991
     10 992
   1562 993
    360 994
     12 995
      3 996
      1 997
     15 1986
      1 2979
      2 2980
      1 3972
      1 3973
after skip frame indices (middle column)
2980,16,42168440935
1986,255,42168679297
1986,457,42168880912
2980,614,42169038828
1986,657,42169082528
3973,739,42169166948
1986,755,42169183832
1986,856,42169285136
1986,957,42169386440
1986,1058,42169487744
1986,1159,42169589048
1986,1259,42169689359
1986,1360,42169790663
1986,1461,42169891968
3972,1535,42169968442
1986,1559,42169993272
1986,1660,42170094576
1986,1862,42170296191
2979,1933,42170368693
1986,1961,42170397495
0% frame skips
$

There is no frame skip between frames 755 and 856. The video was generated by this command, no frame skip in between:

Code: Select all

raw2ogg2anim mt.1007fps.5000lm.150us 838 854 1

This is animated .gif generated:



While 200µs shutter time is far too long for getting clear frames of mouse trap bar at the end, it is already too short for capturing the spark generated by mouse trap bar hitting the piezo igniter. That makes sense, only 20% of the whole time gets captured with 200µs shutter time and 993µs between frames. So from now on, especially with smaller shutter times, capturing the generated spark becomes a game of pure chance.

[HermannSW]

Today I did recordings with significantly shorter shutter times (--expus option of raspiraw).
I was sceptical that 50µs shutter time would work, or even 12µs(!).
But the rule "reduce shutter time, increase brightness, get video" seems to work well !

This is first video of closing mouse trap from today, only 50µs shutter time, 5000lm focussed light.
Really sharp frames (remember that 640x150_s tool captures 640x150 frames, but only 320x75 pixels):



Next was 25µs shutter time, a bit darker, a bit sharper than 50µs video:



This is 12µs(!) video lit by 5000lm shutter time.
It is the first time that gifenc.sh tool (called from raw2ogg2anim tool) is not able to create a valid animated .gif from the .ogg video created from raspiraw captured frames, perhaps too dark. I uploaded the .ogg, perhaps somebody can explain:
https://stamm-wilbrandt.de/en/forum/mt. ... m.12us.ogg



And finally I just turned on two 5000lm leds resulting in 10000lm focussed light, with 12µs shutter time really clear and nice video:



P.S:
Just looked into raspiraw.c, if expus setting is used, this is how exposure gets computed:

Code: Select all

        if (cfg.exposure_us != -1)
        {
                cfg.exposure = ((int64_t)cfg.exposure_us * 1000) / sensor_mode->line_time_ns;
                vcos_log_error("Setting exposure to %d from time %dus", cfg.exposure, cfg.exposure_us);
        }
        
        update_regs(sensor, sensor_mode, cfg.hflip, cfg.vflip, cfg.exposure, cfg.gain);        

With mode 7 line_time_ns==19517 the resulting exposures are 2/1/0 (for 50µs/25µs/12µs shutter times) get written to imx219 registers.

P.P.S:
".exposure_reg = 0x015A", and 0x15[AB] is

[HermannSW]

Until now I always had used [very [very]] bright artificial light to take 1007fps v2 camera videos.

Today I was on a long train ride back home, heading south along river Rhine (longest river through Germany). It was very sunny outside, and I had my laptop and Pi3B+ with v2 camera running on desk in front of me. Both connected to wireless AP of smartphone. Because of the very bright light I did a 1007fps 640x150_s 2s video over river Rhine. You cannot see the Rhine, but the small hills on the other side. And the roofs of houses on the side my train was running passing through the view, as well as chimneys and other stuff. 640x150_s tool does capture 320x75 frames with wider spacing to cover 640x150 view. raw2ogg2anim tool creates a 320x75 .ogg video from the frames. I have uploaded that to youtube:
https://www.youtube.com/watch?v=HA7UtdO ... e=youtu.be

The normal gifenc.sh called last in raw2ogg2anim tool creates 640x150 animated .gif by scaling width to 640. I did run a modified gifenc.sh keeping width at 320, this is the resulting animated .gif:



The video is played at 25fps, 40 times slower than real. Good to know that sunny scenes can be captured at 1007fps with v2 camera -- OK, only 320x75 or 640x150 size, but 1000fps!

For completeness, this is how the video was captured:

Code: Select all

$ ./640x150_s 2000
removing /dev/shm/out.*.raw
capturing frames for 2000ms with 1000fps requested
1967 frames were captured at 1007fps
frame delta time[us] distribution
      1 
      2 992
   1579 993
    361 994
     20 1986
      1 1987
      3 7945
after skip frame indices (middle column)
1986,2,11456592288
1986,14,11456605199
1986,115,11456706504
1986,216,11456807808
1986,317,11456909113
7945,391,11456989560
1986,411,11457010417
1986,511,11457110728
1986,612,11457212033
1987,713,11457313338
1986,814,11457414642
1986,915,11457515946
1986,1015,11457616258
1986,1116,11457717562
7945,1182,11457790064
1986,1210,11457818866
1986,1311,11457920171
1986,1412,11458021475
1986,1513,11458122780
7945,1575,11458191309
1986,1606,11458223091
1986,1707,11458324396
1986,1808,11458425700
1986,1909,11458527004
1% frame skips
$

I extracted 1.8s of the video from 0.1s-1.9s, for playing at 25fps:

Code: Select all

raw2ogg2anim r 100 1899 25

[yt38]

Hi, would a black and white capture change anything in resolution, size, fps?