fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

[SOLVED] Inconsistencies with raspiraw at different resolutions

Sun May 13, 2018 5:09 pm

I am using the latest versions of raspiraw and dcraw from GitHub (6by9 repos), running on Zero W with Pi Camera V2.1. For _s versions of the tools I use d option for raw2off2anim but it makes the images stretched :( What could be the reason?
Also, why there is a second "ghost" image? How to eliminate it?

P.S. Couldn't attach more than 3 files, will attach to my own answer.
Attachments
640x128_s.png
640x128_s.png (27.11 KiB) Viewed 2152 times
640x128_s_d.png
640x128_s_d.png (28.41 KiB) Viewed 2152 times
Last edited by fliker09 on Tue May 15, 2018 9:07 pm, edited 1 time in total.

fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

Re: Inconsistencies with raspiraw at different resolutions

Sun May 13, 2018 5:09 pm

Rest of the files.
Attachments
640x32.png
640x32.png (14.04 KiB) Viewed 2151 times
640x64_s_d.png
640x64_s_d.png (14.86 KiB) Viewed 2151 times
640x64_s.png
640x64_s.png (14.22 KiB) Viewed 2151 times

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Inconsistencies with raspiraw at different resolutions

Mon May 14, 2018 6:54 am

Hi,

nice to see somebody else but me using high frame rate modes of raspiraw!
Until now (current 6by9's raspiraw branch of raspiraw) only has few tools that work with v2 camera.
I am working on many more v2 tools for raspiraw, will commit&push soon.
My branch is already synced with 6by9's branch:
https://github.com/Hermann-SW/raspiraw/network

I have to do all in one commit&push for doing a pull request to 6by9's branch.
Please see this thread on details, what you will be able to do ("640xheight" frames up to 1007fps with v2 camera!):
viewtopic.php?f=43&t=212518
Image


I did not have vertical/horizontal increments under control until I learned recently that v2 camera (unlike v1 camera) cannot work with vertical odd row increments changed without matching horizontal odd columns increment):
viewtopic.php?f=43&t=212518#p1313456


With current 6by9's version of raspiraw these are the tools that work with v2 camera:

Code: Select all

1280x720
1640x1232
1640x922
1920x1080
640x480

You can play with at least 640x75 mode at 1007fps if you take the changes attached to this posting and apply the diffs:
viewtopic.php?f=43&t=109137&p=1309989&s ... 3#p1309546

But if you wait a few days you will be able to get all from my raspiraw branch without any work on your side.

As appetizer you can see here a 1007fps video of yo-yo going down(left) and the quicker up(right) again. Animated .gif played at 25fps, 40 times slower than real. In general you need bright light for high speed modes up to 665fps (I used 1000lm light with v1 camera), and very bright light (I use 5000lm) for 1000fps videos:
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

Re: Inconsistencies with raspiraw at different resolutions

Tue May 15, 2018 5:39 pm

Yeah, I have a project where a desperately need high fps! :geek:

Are both ghosting and stretching explained by the fact that 6by9 tools are not working correctly with V2 camera?

Do I have to apply diff to your repo or to 6by9 repo?

And RPi 3B is a must for 1007fps, isn't it?

Impressive result with yo-yo! ;)

fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

Re: Inconsistencies with raspiraw at different resolutions

Tue May 15, 2018 9:07 pm

Had no patience, applied your patch on 6by9 repo :D Re-compiled, added your 2 new tools and... all good! 1000fps achieved! Thanks for the help :!:
Attachments
640x150_s_d.png
640x150_s_d.png (40.12 KiB) Viewed 1954 times

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Wed May 16, 2018 8:52 pm

> ... all good! 1000fps achieved!
>
That is good!

But your 640x150_s frame looks not nice like my first 640x150_s frame:
Image


I found the reason in this posting, for v2 camera (unlike v1 camera) you have to change both, x- and y- odd column/row increments to 3 or none:
viewtopic.php?f=43&t=212518#p1313456


This is 640x150_s tool captured frame at 1007fps with code I have not commited/pushed to github yet:
Image


Effectively only 320x75 pixels are captured,
Image

but line numbers 1,4,5,8,9,12,...,h-3,h (column numbers 1,4,5,8,9,12,...,w-3,w). Therefore the doubled in both dimensions frame correctly represents the 640x150 fov captured.

I am not completely done with my changes, and currently 6by9 deals with another pull request. I will have to wait after that is completed, sync again and then submit my changes.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Fri May 18, 2018 1:33 pm

Wow, looks great! Is it possible to get another diff? It's up to you - against 6by9 repo or on top of your previous diff, I don't care, just want this code running on my Pi :D

fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Sat May 19, 2018 10:12 am

I found another issue - photos are not take in the middle of the frame. Why? Is it again related to V2 camera?

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Thu May 24, 2018 3:12 pm

> I found another issue - photos are not take in the middle of the frame. Why? Is it again related to V2 camera?
>
Reason is that "--top" option is implemented for v1 camera only currently, needs to be made working for v2 as well. Therefore the 640xH tools take the topmost H lines of 640x480 video window.

I typically start with "raspivid -md 7 -w 640 -h 480 -p 706,20,640,480 -fps 180 -t 0" and adjust the top of 640x480 preview window (on HDMI monitor) to what I want to record. Next I record a small video with raspivid, play it with totem video player, stop video, use "Edit->Take Screenshot", open that screenshot with gimp and then cut out eg. 640x75 window starting at coordinate 0x0. That way I can verify whether scene setup is good or not before using raspiraw.

Code: Select all

        if (cfg.top > 0)
        {
                if (!strcmp(sensor->name, "ov5647"))
                {
                        int val = cfg.top * (cfg.mode < 2 ? 1 : 1 << (cfg.mode / 2 - 1));
                        modReg(sensor_mode, 0x3802, 0, 3, val >>8, EQUAL);
                        modReg(sensor_mode, 0x3803, 0, 7, val &0xFF, EQUAL);
                }
        }

> Wow, looks great! Is it possible to get another diff?
>
I am working on a next drop allowing you for all tools shown in previous diagram, but for both cameras and not only for v2 camera (of course with less framerate for v1 camera for same frame dimension than v2):
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Thu May 24, 2018 6:26 pm

To be honest I didn't quite understand the explanation for why raspiraw is shooting not in the center :oops: May be I miss something?

Regarding the code - eagerly waiting!

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Thu May 24, 2018 8:43 pm

fliker09 wrote:
Thu May 24, 2018 6:26 pm
To be honest I didn't quite understand the explanation for why raspiraw is shooting not in the center :oops: May be I miss something?
v2 image sensor area is 3280x2464 (in fact few pixels more around).

x start and end coordinates for mode7 (640x480), from imx219_modes.h:

Code: Select all

      {0x0164, 0x03}, x_addr_start  1000
      {0x0165, 0xe8},                   
      {0x0166, 0x08}, x_addr_end    2279
      {0x0167, 0xe7},
x_addr_end - x_addr_start = 1280

y start and end coordinates for mode 7:

Code: Select all

      {0x0168, 0x02}, y_addr_start   752
      {0x0169, 0xf0},
      {0x016a, 0x06}, y_addr_end    1711 
      {0x016b, 0xaf},
y_addr_end - y_addr_start = 960 

x and y output size:

Code: Select all

      {0x016c, 0x02}, x_output_size  640
      {0x016d, 0x80},

      {0x016e, 0x01}, y_output_size  480 
      {0x016f, 0xe0},

x and y odd increments (even are 1 fixed):

Code: Select all

      {0x0170, 0x01}, X_ODD_INC_A      1
      {0x0171, 0x01}, Y_ODD_INC_A      1

Horizontal as well as vertical x2-analog binning mode:

Code: Select all

      {0x0174, 0x03}, BINNING_MODE_H_A  x2-analog (special) binning
      {0x0175, 0x03}, BINNING_MODE_V_A  x2-analog (special) binning
This binning mode reduces pixels from 1280x960 fov to 640x480, per 5-2 Pixel Binning Mode in imx219 spec.

So mode 7 top left corner in pixel array is (1000,752), bottom right is (2279,1711).
The 640x480 pixels are extracted from that area.
1711+752=2463 and 2279+1000=3279, therefore that 1280x960 area is centered in 3280x2464.

All 640xH modes have top left corner (1000,752) and are just top H lines in the mode7 area, therefore not centered.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Fri May 25, 2018 11:01 pm

fliker09 wrote:
Thu May 24, 2018 6:26 pm
Regarding the code - eagerly waiting!
OK, here is another code drop outside of github, just unzip and use, all compiled already.
3MB .zip archive too big to attach to this posting, get it from here:
https://stamm-wilbrandt.de/en/forum/ras ... _26_18.zip

Directories v1 and v2 contain new tools that will end up in tools directory before commit&push to github.
Those new tools are for Pi 2 or Pi 3, will add toggle for Pi Zero[W] with lower requested framerates later.

This is work in progress, allows you to do now all I did report on.
tools/camver determines Raspberry camera version.
Tools like "v2/640x150_200_s" are with reduced shutter time (200μs, needs very bright light, 5000lm is OK).
tools/raw2ogg2anim does double lines only (with "d" appended), as needed by "tools/*_s" tools.
v2/raw2ogg2anim does double lines and columns as needed by v2/640x150_s

Code: Select all

cd v2; ./640x150_s 2000; ./raw2ogg2anim name startframe endframe targetfps d

The 640xH tools in v1 and v2 directory were used to graph framerate versus height
(up to 500fps v2 camera does twice the framerate of v1 camera for same frame size):
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Sun May 27, 2018 2:34 pm

I really don't like this kind of .zip drops outside of github.

And I understand that 6by9 want's pull requests for his raspiraw branch in a single commit.

Today I learned how to create a fork of my own fork of 6by9's raspiraw:
https://www.tilcode.com/fork-your-own-repo-on-github/

So I created "Hermann-SW/fork-raspiraw" fork of my "Hermann-SW/raspiraw" that is a fork or "6by9/raspiraw".
This way I can commit&push to "fork-raspiraw" as I like.
Finally I can just do a pull request against "Hermann-SW/raspiraw", or just copy over all files.

I just did initial "bulk commit of everything contained in raspiraw.drop.5_26_18.zip" on fork-raspiraw:
https://github.com/Hermann-SW/fork-rasp ... c65f9d6461
Now all diffs I made sofar can be seen directly in that commit with the help of github👍
(I changed my signature to point to fork-raspiraw as well)

P.S:
Github magic, Hermann-SW/fork-raspiraw already has late commits from 6by9/raspiraw missing on Hermann-SW/raspiraw:
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

fliker09
Posts: 17
Joined: Tue Apr 21, 2015 7:19 am

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Sun May 27, 2018 5:14 pm

Very good explanation and great work! Thank you very much, Hermann!

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Sun May 27, 2018 9:01 pm

A lot of work, but I got automatic execution of camera_i2c if needed working, and framerate selection based on Pi revision and camera version! New tools/camera_i2c_ can be executed from anywhere, and new symbolic link tools/raspiraw to raspiraw executable results in only tools/ directory being needed to add to $PATH.

Completely rewritten "640x480" tool execution looks not that much different (analysis slightly changed):

Code: Select all

[email protected]:~/fork-raspiraw/t $ ./640x480 1000
removing /dev/shm/out.*.raw
capturing frames for 1000ms with 90fps requested
90 frames were captured at 90fps
frame delta time[us] distribution
     31 11080
     58 11081
after skip frame indices (middle column)
0 frame skips (0%)
[email protected]:~/fork-raspiraw/t $ 

But the tool is really small now:

Code: Select all

[email protected]:~/fork-raspiraw/t $ cat 640x480 
#!/bin/bash
if [ "$1" = "" ]; then echo "format: `basename $0` ms"; exit; fi

prep_raspiraw || exit

fps=$(fps_raspiraw 90 90 90 180) || exit
echo "capturing frames for ${1}ms with ${fps}fps requested"
raspiraw -md 7 -t $1 -ts tstamps.csv -hd0 hd0.32k --height 480 --top 0 --vinc 17 --fps $fps -sr 1 -o /dev/shm/out.%04d.raw 2>/dev/null >/dev/null

ana_raspiraw
[email protected]:~/fork-raspiraw/t $ 

New tools/prep_raspiraw aborts on no camera connected, determines whether camera_i2c_ needs to be called by executing raspiraw test wise capturing a single frame. And it aborts if after executing camera_i2c_ no frame can be captured:

Code: Select all

[email protected]:~/fork-raspiraw/t $ cat ../tools/prep_raspiraw 
#!/bin/bash
dt=`vcgencmd get_camera | grep "detected=1"`
if [ "$dt" = "" ]; then
  echo "no camera detected"
  exit 1
fi 

echo "removing /dev/shm/out.*.raw"
rm -f /dev/shm/out.*.raw

# test whether camera_i2c needs to get called, and do so if needed
#
raspiraw -md 7 -t 15 --fps 90 -sr 1 -o /dev/shm/out.%04d.raw 2>/dev/null >/dev/null
l=`ls -l /dev/shm/out.*.raw 2>/dev/null | wc --lines`
if [ "$l" = "0" ]; then
  camera_i2c_ >/dev/null

  raspiraw -md 7 -t 15 --fps 90 -sr 1 -o /dev/shm/out.%04d.raw 2>/dev/null >/dev/null
  l=`ls -l /dev/shm/out.*.raw 2>/dev/null | wc --lines`
  if [ "$l" = "0" ]; then
    echo "raspiraw does not work even after executing camera_i2c?!?!?"
    exit 1
  fi
fi
[email protected]:~/fork-raspiraw/t $ 

tools/fps_raspiraw is based on "camver" script determining Raspberry camera version, and camera_i2c revision detection, used to determine if Pi is slow or fast (Pi 2s and 3s, as well as CM3). Based on camera version and slow/fast Pi one of four passed framerates is returned that will be used by the tools:

Code: Select all

[email protected]:~/fork-raspiraw/t $ cat ../tools/fps_raspiraw 
#!/bin/sh
if [ "$4" = "" ]; then echo "format: `basename $0` v1slow v2slow v1fast v2fast (fps values)"; exit; fi 

v1=`i2cdetect -y 0 54 54 | grep " 36"`
v2=`i2cdetect -y 0 16 16 | grep " 10"`
if [ "$v1" = "" ] && [ "$v2" = "" ]
then
  echo "only v1 and v2 cameras supported"
  exit 1
fi

if [ "$v1" != "" ]
then
  slow=$1
  fast=$3
else
  slow=$2
  fast=$4
fi

# http://elinux.org/RPi_HardwareHistory#Board_Revision_History
rev=`cat /proc/cpuinfo | grep Revision | awk '{print substr($NF,length($NF)-5,6)}'`

case $rev in

'0002'|'0003'|'0004'|'0005'|'0006'|'000d'|'000e'|'000f'|'0010'|'0012'|'0013'|'1041'|'900093'|'920093'|'9000c1'|'0011'|'0014')
# B Rev1+Rev2, A+, B+, B2, and Zero[W], Compute Module CM1
echo $slow
;;

'a01041'|'a21041'|'a02082'|'a22082'|'a020d3'|'a020a0')
# Raspberry Pi2B/Pi3/Pi3+/CM3"
echo $fast
;;

*)
echo "Failed: don't know this board revision: $rev"
exit 1
;;
esac
[email protected]:~/fork-raspiraw/t $ 

New ana_raspiraw does compute the regexp pattern needed for frame skip analysis, no regexp editing in tool scripts needed anymore:

Code: Select all

[email protected]:~/fork-raspiraw/t $ cat ../tools/ana_raspiraw 
#!/bin/bash
if [ ! -f tstamps.csv ]; then echo "tstamps.csv does not exist"; exit; fi

us=`cut -f1 -d, tstamps.csv | sort -n | uniq -c | sort -n | tail -1 | cut -b9-`
l=$((`wc --lines tstamps.csv | cut -f1 -d\ `))
fps=$((1000000 / $us)) 
echo "$l frames were captured at ${fps}fps" 

echo "frame delta time[us] distribution"
tail -n +2 tstamps.csv | cut -f1 -d, | sort -n | uniq -c

D=`echo "0123456789" | sed "s/\`echo $((1000000/$fps)) | cut -b1\`//"`

echo "after skip frame indices (middle column)"
tail -n +2 tstamps.csv | grep "^[$D]" | sed "s/^/> /"

skips=`tail tstamps.csv -n +2 | grep "^[$D]" | wc --lines | cut -f1 -d\ `
stamps=`tail tstamps.csv -n +2 | wc --lines | cut -f1 -d\ `
per=`expr \( 100 \* $skips \) / \( $skips + $stamps \)`
echo "$skips frame skips ($per%)"
[email protected]:~/fork-raspiraw/t $ 

It is much work to rewrite all 640xH tools (in tools, v1 and v2 directories) with this new framework. First I have to determine the maximal v1 camera framerates for the 640xH modes for slow and fast Pis. Will commit&push when complete shortly.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1394
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: [SOLVED] Inconsistencies with raspiraw at different resolutions

Mon May 28, 2018 10:43 pm

I did determine the maximal framerates for "slow" Pi (Zero) with v2 camera.
Started with 640x480 and went down to 480x320 and then always 16 down in height.
Then I realized that the analysis sofar of type "90 frames were captured at 90fps" did report majority framerate.
I enhanced ana_raspiraw to report average as well as maximal framerates in addition.
For 640x208 those new values revealed that majority as well as average can be much below requested framerate.
For below run only 15 of 423 frames capured are captured at requested framerate.
I will have to find maximal framerates where at least the average is in range of requested framerate.
So I will have to redo all "fast" Pi measurements for v1 and v2 camera as well ...
And I just saw that I have to correct frame skip analysis, it is based on majority which is wrong here, should be 423-15=408 frame skips reported:

Code: Select all

[email protected]:~/fork-raspiraw/v2slow $ ./640x208 2000 | grep -v ">"
removing /dev/shm/out.*.raw
capturing frames for 2000ms with 421fps requested
423 frames were captured at 211fps(avg), 212fps(maj), 424fps(max)
21 frame skips (4%)
< frame delta time[us] distribution
<      10 2356
<       4 2357
<       1 2358
<       1 4707
<       1 4709
<       2 4710
<      23 4711
<     111 4712
<     228 4713
<      27 4714
<       6 4715
<       1 4716
<       1 4718
<       1 7069
<       1 9426
<       2 11781
<       1 11783
<       1 14138
[email protected]:~/fork-raspiraw/v2slow $ 

P.S:
97% frame skips now reported after correcting ana_raspiraw:

Code: Select all

[email protected]:~/fork-raspiraw/v2slow $ ./640x208 2000 | grep -v ">"
removing /dev/shm/out.*.raw
capturing frames for 2000ms with 421fps requested
419 frames were captured at 209fps(avg), 212fps(maj), 424fps(max)
409 frame skips (97%)
< frame delta time[us] distribution
<       4 2356
<       5 2357
<       1 4708
<       1 4709
<      24 4711
<     121 4712
<     214 4713
<      39 4714
<       1 4716
<       1 4717
<       1 7070
<       1 9424
<       1 9427
<       1 11782
<       1 11783
<       2 14138
[email protected]:~/fork-raspiraw/v2slow $ 

P.P.S:
I had to go down to 335fps requested (instead of 421), that looks good:

Code: Select all

[email protected]:~/fork-raspiraw/v2slow $ ./640x208 2000 | grep -v ">"
removing /dev/shm/out.*.raw
capturing frames for 2000ms with 335fps requested
671 frames were captured at 336fps(avg), 337fps(maj), 338fps(max)
3 frame skips (0%)
< frame delta time[us] distribution
<       1 2954
<      33 2958
<      99 2959
<     383 2960
<     115 2961
<      34 2962
<       1 2963
<       1 2967
<       1 5920
<       2 5921
[email protected]:~/fork-raspiraw/v2slow $ 

P.P.P.S:
Just did connect v2 camera to Pi3B+ for runs with new analysis -- the 1000fps are real(!)

Code: Select all

[email protected]:~/fork-raspiraw/v2slow $ ./640x75 2000 | grep -v ">"
removing /dev/shm/out.*.raw
Set state of 133 to 1
capturing frames for 2000ms with 1000fps requested
1994 frames were captured at 999fps(avg), 1007fps(maj), 1009fps(max)
13 frame skips (0%)
< frame delta time[us] distribution
<       1 990
<       3 991
<      56 992
<    1511 993
<     400 994
<       8 995
<       1 996
<       8 1986
<       2 1987
<       1 2978
<       2 2979
[email protected]:~/fork-raspiraw/v2slow $ 
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

Return to “Camera board”