1 Topic by AlexanderH (edited by AlexanderH 2022-12-01 07:46:11)

  • AlexanderH
  • Member
  • Offline

Kinovea could be used for more accurate speed/distance calculation of a moving object if the movement was defined in relation to pixels before/after a defined border in the static video?

Instead of using the division of fps restricted by the camera (30, 60, 120...), the calculation would be related to the tracked frame before and after the crossing of a defined line. The division by the fps would be further split to the amount of displacement in pixels between two frames?

In a 30fps video the maximal accuracy with measuring frames alone, would be 0,03s...
If the object is moving  fast across the screen (8-10 frames....0,3s)....1000 pixels....100pixels/0,03s....and the border is in between two frames- 35 pixels off on the right side and 65 pixels on the left - 35/100*0,03s=0,0105s before and 65/100*0,03=0,0195s after the line....

Or is this within the calibration?

I would like to use Kinovea for timing athletic sprinters at fixed distances; 20m, 30m, 40m.....

2 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

If I understand correctly, this would be under the assumption that the movement is linear between the two frames. In reality the subject is most likely accelerating/decelerating but it could be a good enough approximation in many cases, better than nothing anyway.

Maybe this could be integrated into a line tool. You trace a line between two points that are supposed to be in two consecutive frames, and the line would have graduations corresponding to subdivisions of the frame interval, and show the corresponding time at each graduation.

Or a line with one sliding point in the middle, with a mini label attached, and you slide the point to where you are interested in reading the time.
Maybe called "time segment" tool, a segment of a timeline.

3 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

This will only give the time. For the crossing speed it's more complicated. Maybe an alternate metric that gives the ratio between the two parts, so you can do the computation later after export if needed.

4 Reply by AlexanderH

  • AlexanderH
  • Member
  • Offline
joan wrote:

If I understand correctly, this would be under the assumption that the movement is linear between the two frames. In reality the subject is most likely accelerating/decelerating but it could be a good enough approximation in many cases, better than nothing anyway.

Maybe this could be integrated into a line tool. You trace a line between two points that are supposed to be in two consecutive frames, and the line would have graduations corresponding to subdivisions of the frame interval, and show the corresponding time at each graduation.

Or a line with one sliding point in the middle, with a mini label attached, and you slide the point to where you are interested in reading the time.
Maybe called "time segment" tool, a segment of a timeline.

Yes. Primarily the idea could work for estimated timing in between video frames. The assumption of no acceleration/deceleration is one way to go, but the more complicated way would be using similar "shadow" lines in front and/or after this border and calculate the changes in pixels before/after those lines = change in linear speed....

"This will only give the time. For the crossing speed it's more complicated. Maybe an alternate metric that gives the ratio between the two parts, so you can do the computation later after export if needed."
That could be a good solution. I do think the timing is of greater important because of the FPS-limitation in videos....