1

I have problems with the function of the markers when using the calibrated perspective grid. When setting the markers, sometimes the coordinates are right and in line with the calibration of the grid, sometimes the coordinates make absolutely no sense. Are there any ideas in which cases this problem might occur?
Before opening the video in Kinovea, I have used GoPro Studio in order to remove the fisheye of a GoPro camera and I have used WinFF in order to converte the .avi-videos (from GoPro Studio) to .mpeg videos (readable in Kinovea). However, I have tried to set the markers in the Original mpeg-Videos (the fisheyed ones) and the problem still exists.

Maybe it might help to have an extract from the kva-file when setting the markers in the calibration grid.

<Calibration>
    <CalibrationPlane>
      <Size>500;200</Size>
      <Quadrilateral>
        <A>428.6288;334.7157</A>
        <B>862.0736;317.8595</B>
        <C>876.5217;486.4214</C>
        <D>431.0368;505.6856</D>

I am very thankful for any ideas concerning a possible solution and I am looking forward to hear from you!

2

Hi,
Some issues may arise if the perspective grid is at a very steep angle, as is the case when placing it on the floor seen from a camera that is not very high above ground. Try to stay above 30° or so between the camera axis and the plane. Move the camera higher up and look down if possible.

At a steep angle the coordinates aren't going to be very precise since one pixel in the image will cover a lot of real world area.

Also, the coordinate system origin can be moved independently from the grid, maybe you have moved it inadvertently? If the origin of the coordinate system is outside of view it could yield unexpected results. If it's above the horizon line it is effectively at infinity and things will be completely broken. Once the calibration is active, if you move the grid's corners it's going to move the coordinate system with it.

It's possible to see the actual coordinate system with menu Tools > Coordinate system. If you don't see the origin where you expect it, this should be fixed first. The primary axes are thicker than the other lines and can be dragged around. Move the grid's corners around to make it more rectangular to check where the origin is, and place it where you want relatively to the grid. Then move the grid back to match the real plane.

3

Hi Joan,

thank you so much für your fast reply. Actually, the wrong coordinate system was the problem and after setting the origin on the right place, it now works fine!
Now, I have another question concerning the execution speed of the videos. Unfortunately, after converting the videos, they are played twice as fast as normally. This is only the case when opening the videos in Kinovea, but not when opening the videoy with the VLC player?

I am again very thankful for any kind of help concerning this problem!

4

Great!

Regarding the video speed, could you convert/create a very small file and send it over by mail so I can have a look? Thanks.

5

Perfect! I sent you a video by mail!

6

Thanks for the file. I see that the action is indeed sped up, but I also get the same in VLC and SMPlayer. Kinovea reads the file as 4,989s long, 299 frames, 59.93982fps. VLC also says 59.93982fps. Using VLC 2.26.

Are you sure it's not the pre-processing that introduce this effect?

Did you shoot in 1080p or 1080i in the GoPro? I've read there are issues with the 1080i mode not really being interlaced. Maybe the defisher or converter thinks it's interlaced when it's actually not, and it tries to deinterlace it. This could merge pairs of frames and end up twice as fast as expected.

7

Thanks for your help. Now, the file is also speed up both in VLC and Kinovea, in both players with 59.93982fps. Actually, I think that this is the right resolution as we have chosen 720p/60 as resolution mode in GoPro. Thus, as you said, it actually might be a problem of the converter and we are trying to solve this possible interlacing problem in the prgoramming of the converter at the moment (I think this might be a problem despite using a p-mode).
However, I am wondering whether the fastened speed in Kinovea actually causes a problem for our data analysis. Maybe you have an idea on that when I briefly describe what we want to measure: In this scientific study, we want, among other variables, measure the speed of football penalty shots during 3 time periods: In the first part of the kick (the time when the ball leaves the foot till 5 clicks later when setting the time in Kinovea on milliseconds), in the last part of the kick (when the ball hits the goal line till 5 klicks less) and the hole average speed for the kick. This is why we want to set the markers in this standardized points and then we manually want to calculate the speed during the mentioned intervalls as we know how much time passes between two klicks. Now I am wondering whether the fastened speed changes the time interval for one klick? And may this also be concerned with the fact that when speed is fastened,when clicking from one frame to another, there are two balls visible?

I know, that for measuring speed, there is also this tracking option in Kinovea. When testing this, we had the impression that it is not very precise and sometimes the tracking doesn't work. Might this also be due to the fact that the camera is not high enough above ground? The thing is, that when publishing our data, we have to be very precise in describing how we measured speed. This is one reason why I was struggeling to use the tracking option.

8

Yes the timing information by default depends on the framerate of the video, so time intervals will be wrong. If you know it's wrong and you know the correct framerate, you can fix it in menu Video > Configure video timing > in the bottom pane you will see what Kinovea reads from the file. In your case you can change the value to 29.97 and apply, and the playback speed as well as all time dependent measurements should be correct.

If you can see two balls in just one frame, it could very well suggest that the original footage was indeed interlaced and that it got deinterlaced. When an object moves a lot between the two half-frames the deinterlacing algorithms tend to "reconstruct" the object twice.

To improve the automated tracking you can change the size of the search and object box used by the trajectory tool. For some objects it's best to reduce the "object" window to avoid tracking background. You can also adjust the position of the object manually to get the most control. This will work better with the camera higher above the ground. Then if you go to the trajectory data analysis you can find all the measurements and export them quickly to the clipboard or CSV file. This uses a smoothing pass on the data to minimize the noise introduced by the digitization process. The exact procedure is described in the "About" tab of the data analysis dialog.

Note that you can also correct the distortion of the GoPro directly in Kinovea, it will not undistort the images but it will distort the coordinate system to match the lens. The calibration procedure is not very well documented at the moment though. But in theory it could be more accurate than using the stock de-fishing algorithm of GoPro studio which will use standard values for all devices, whereas here you would calibrate exactly for your camera lens. (Depending on how the sensor is glued on the board the optical axis may not be exactly aligned with the center of the image).

This is only relevant if you are making spatial measurement on the images though, if you just do time measurements because you already know the distance between markers visible on the images I don't think you need to correct the distortion at all.

9

ok thanks. Now I manually adjusted the framerate to 29,97 what actually reduces the speed of the video, but the two balls in the video/ picture remain. Does this mean that the time dependent measures will still not be fine? If yes, could you help me out how to correct the distortion in Kinovea? As I want to measure the precision of the kick I think I need to correct the distortion.

Again, thank you very much for your help!