Search options (Page 102 of 136)

Hi,
First of all thank you for checking this.
It is very important that the results are right and I really appreciate these kind of tests.

Since it is exactly half the speed, the difference is most likely not how we computed the distance, but more likely how we get the frame time interval. My guess is that we get the same distance between points, but one of us use half the time frame interval of the other.

I get the time interval from the information contained in the file. One hypothesis that could explain this behavior is if the file is interlaced and the frame interval used for computations is actually the field interval (50 fields per second vs 25 frames per second). I'll have to double check that.

- How did you get to the 40ms value ?
- Can you post the info that Kinovea reads from the file ? Go to Help > Open log folder… > then open "log.txt" and look for the block of lines between the "--------------" lines.
It should look something like: [File] - Filename : fish.avi, [File] - Size (bytes) : 4024704, [Container] - Name: avi (AVI format), etc.
Post all the block if possible.
- Can you also go to menu Motion > High speed camera and read the fps value in the box. This is most probably what Kinovea is using for computations.

Thanks

Note: Euclidian distance = SQRT((xA - xB)² + (yA - yB)²).

It's also possible that the small difference in time stamps is due to rounding error in the output time representation. For example, a common frame rate is 29.97 fps, this would give time stamps that appear to last a tiny bit longer or shorter than the next, but they average out regularly, the frame rate itself does not change.

Ha! Now this just reminded me of bug 183. The export wouldn't work for some unknown reason, and then start to work again.
Please retry the Excel export. It may have magically fixed itself.

Distance and speed on trajectory are not currently exported.

You are doing it the right way (or at least I do similarly).
The data is not erased when you move back in the video to let you move back and re-adjust only a single point manually without changing the others.

Thanks
It is indeed probably the same issue as bug 220 but another variation. When the saving dialog box is closed, the screen try to refresh itself and the image is used from two different places at the same time (display and record).
To validate this hypothesis, you may try to relocate the saving dialog box somewhere not directly above any of the images, before clicking save, if it's possible.
I'll open a new bug to track this.

Edit: created bug 227.

Bonjour,

Hum, je pense que ceci est une anomalie. Je créerai un rapport de bug dessus.
Le problème se produit il me semble quand la taille de l'image est plus grande que l'espace disponible dans l'écran de lecture.
Du coup l'image est réduite en taille, et les indicateurs de vitesses sont réduits de façon proportionnelle, sans qu'ils ne soient limités.
(edit : bug 230)

Pour avoir une taille en mètres, il faut « calibrer » l'image. Ajouter une ligne quelque part sur un objet de taille connue et indiquer sa taille manuellement. Sinon, le logiciel n'a aucun moyen de faire le rapport entre les pixels et une unité réelle.
Voir l'aide à l'article « Utiliser Kinovea > Mesurer > Mesurer des vitesses ».

You might do this by launching Kinovea from the command line and passing arguments.
Unfortunately, I don't think this is documented anywhere, not even in the manual, although it has been there for a while now

To launch a file directly, and at 75% speed you can do this at the command line:

> kinovea.exe -file test.mpg -speed 75

Here is the missing doc:
Usage:
[-file <path>] [-speed <0-200>] [-noexp] [-stretch]

-file: complete path of a video to launch; default: 'unknown'
-speed: percentage of original speed to play the video; default: 100.
-stretch: The video will be expanded to the screen size; default: false.
-noexp: The file explorer will not be visible; default: false.

Exemples:
1. > kinovea.exe -file test.mkv -speed 50
2. > kinovea.exe -file test.mkv -stretch -noexp

To do this you need to run Kinovea directly from cmd.exe, from a .bat script or from another program that support running shell commands.

Are you referring to tracking a player during a whole match ?
The tracking fuction is intended to track joints or small objects. Speed measurement on it will only work in very controlled situations. (perpendicularity, line calibration, etc.)

Currently this is not possible and not to be expected in the foreseeable future.

The main reason is that some of the main usages include saving with drawings painted on which need recoding. When muxing to AVI, not all codec would be available, also, depending on codec, not all framerate are possible, which would mean yet another case for saving with slow motion.

It was initially trying not to reencode if not needed, but it proved too much of a hassle to maintain.
It's a bit of a shame but it's currently the only maintainable solution for me…