Re: Kinovea 0.9.3 (beta)

most of the handy-cameras recorded videos did NOT use a constant framerate. Therefore, it may be favorable
to convert the video to a constant framerate. Furthermore it may help to convert the video to "mjpeg" to store a full frame to every frame. MP4 is the container but does not control the content of the video. Be aware of creating a hugh file using the mjpeg-options.

using FFmpeg the option -c:v mjpeg creates a video that contains a full frame for EVERY frame, not only the difference from one frame to the other. This type of video can be read in Kinovea and it is possible to scroll back and forth from one frame to the other. Furthermore, you could experiment of using a constant framerate for the output-video using the -r option. The quality is controlled by -q:v 2 (highest quality, 23 lowest).

Example
ffmpeg -i input.mov -c:v mjpeg -q:v 3 -r 30 output.mp4

17 (edited by joan 2020-Jul-22 23:31:01)

Re: Kinovea 0.9.3 (beta)

Dr.Dank wrote:

the graphs don't follow the scale set by calibrated lines and all accelerations are shown as zero.

You're right, there is something weird going on. If you go to Preferences > Playback > Units and simply hit save, then open the diagrams dialog again, it should be in the correct units… I'll investigate.

Being the second derivative acceleration is super sensible to even the smallest noise in the positions, and the normal filtering usually don't fix it, and you will get values that go up and down when they really shouldn't. Use this as an approximation. To give an idea, we tested with a simple ball in free fall and it was already hard to get a consistent g, instead we got something varying between 8 and 10 m/s².

The diagrams are somewhat interactive by the way, you can hover the mouse over the Y axis values and scroll, and it will rescale the axis. Inside the graph you can right click and drag to move around.

edit: OK I think I found the issue with the initialization of the speed and acceleration units. This should work in the next version.

18 (edited by Dr.Dank 2020-Jul-29 20:23:29)

Re: Kinovea 0.9.3 (beta)

The systems I'm analyzing are simple enough that they can be modeled with only a few parameters, so I've actually been able to somewhat bypass the problem of numerically differentiating noisy data. As an example, when free fall position vs time data are fit by a quadratic the coefficient of the square term is a measurement of g/2. Being a global operation, linear regression is less sensitive to the small-scale noise than local differentiation is so I've gotten values pretty close to the accepted value this way.

To help with my error budget, do you have any estimates for the uncertainty in the position values generated by the path tracker?