Search options (Page 98 of 133)

It's dependant on the CPU load so it's not linear and can't be corrected manually like this. Sometimes the problem is not there, e.g. if the image size is small, the machine powerful and the capture frame rate low.

The issue is that the rate at which images are grabbed is estimated and used as frame rate for the final video.
However, when the recording starts, the CPU is more heavily used and images come less frequently to the program.
What is needed is to completely decouple the recording from the frame grabbing.

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.