1 Topic by willfig

  • willfig
  • Member
  • Offline

I've used Kinovea for some time now to estimate burst swim speeds of fish in lab trials.  I've recently started using a GoPro to do the filming and have thus tried the distortion correction available in this latest version (by importing a calibration file from Agisoft lens).  The calibration seems to work quite well but I'm having an issue with the exported data. Specifically:
1. In the exported data, the time stamp is shifted by four rows relative to the x,y values.  So the first x,y coords of a track will have a time stamp which is four frames later.
2. If I correct this manually and then calculate speed, I'm not getting the same thing as what is shown using the display measure tool.  I thought this maybe had to do with rounding error of the time value as its available in many formats.  But even if I use what would be the most precise, microsec, I still don't get the same value.  So I'm not sure what's going on here.  here's an example:

Speed (cm/s) estimated using different time formats for a few point at random

mm:milsec    total milsec    total micsec   display measure
88.0              110.0           105.5             99
5.4                6.8               6.5                 8

2 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Export through spreadsheet from main menu or export through data analysis dialog from trajectory context menu?

3 Reply by willfig

  • willfig
  • Member
  • Offline

Main menu. Didn't know about the data analysis actually. I'll try that as well.

4 Reply by willfig

  • willfig
  • Member
  • Offline

I've tried exporting via the data analysis tool.  I compared the data as exported using the main menu vs the data analysis tool and calculated distance and speed from each data set.  I wasn't exactly sure how you calculate speed for a given time point (using the next time point or the previous one) or if you express it as a running average of one of those two so I tried all of them.  Some observations:

1. x/y coords are more precise in the data analysis export (3 vs 2 decimal places)
2. spreadsheet export is shifted by 4 frames.
3. The speed value in the data analysis export does seem to match that shown on the screen using the display measure tool.
4. None of the ways I calculated speed using either data set seem to match up with that calculated by Kinovea

I can send you the file if you'd like me to.

5 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

There is a filtering pass on the raw coordinates to remove the high frequency noise produced by the digitization. There is more information about the exact process and the cutoff frequency selected in the about tab of the data analysis dialog.

The approach comes from sport science literature, I don't know its relevance to burst swim of fishes. But I think it should still be better than the raw coordinates.

The spreadsheet export from the main menu does not have the filtering, it's just the raw data. The shift by 4 frames is strange. Maybe one of those files where the first image has a time coordinate different than zero and cause some issues.

6 Reply by willfig

  • willfig
  • Member
  • Offline

I see....so the spreadsheet has the raw data.  And the filtering explains why I don't get the same values.  For burst swim with fish its not common to apply any filtering.  So I'll export with the spreadsheet.  I have a macro script in Excel which batch imports files, calculates speed and summarizes the maximum.  I can add some code to this to deal with the 4 frame shift.

I note I didn't have an issue with the frame shift in the past when using .wmv files in the standard version.  I just opened one of those (and its key file) in the latest experimental version and exported to spreadsheet.  There is no shift.  So maybe this has to do with the video format?  It seems to be happening regardless of where I start the track...right at the beginning of the video, or somewhere past this.  And if i do multiple tracks and export them they each have this issue.

7 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Yes the frame shift most likely depends on the format. Or even the encoder in the camera. If you want you can send me a file with the problem so that I can see if it's a bug that could be fixed somehow. Less than 5MB send to joan at kinovea dot org, if more than that host it somewhere else and send me the link.

Regarding filtering, if it's possible, I would still suggest to test a digitization of a file for which you have ground truth available if possible. Ideally coming from a physical measurement system, not from another optical based system. The filtering helps smoothing the minuscule noise introduced by the manual or automated tracking process, where even subpixel placement at 600% zoom might not be enough to get the correct coordinates. I would assume this to be universally beneficial for precision/repeatability.

Note that the radial distortion calibration will also not be perfect, and usually less accurate at the periphery. The tracking works only in 2D so deviation from the the plane of motion is also going to add errors. If you are computing derivatives the noise is going to increase the error. If you compute or save acceleration data for example, I would definitely try to evaluate the accuracy first, to know where you are standing.

8 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

I just thought of the fact that you are filming underwater!

The lens distortion is going to be different due to the refractive index of water vs air. Ideally you should perform the lens distortion calibration underwater as well, not reuse the coefficients computed in air. I don't know exactly how much of a difference it will make but it's worth a test I think.