Search options (Page 67 of 133)

In the spreadsheet it is the x,y coordinates of each point.
In recent versions, these coordinates are relative to the origin of the coordinate system, as set up from Image > Coordinate system (or set up from a perspective grid system if using 0.8.20).

When using the "Distance" measurement label from the path configuration dialog, the label shows the total distance covered by the path up to the current point.

So the two functions are not meant to display the same values. In a way the data exported in the spreadsheet is lower level. You could recompute the total distance from the coordinates if needed.
Similarly, speed is not exported in the spreadsheet, but could be recomputed from the x,y,t coordinates.

Hope that helps.

The next experimental version(s) should be dedicated to updating/upgrading the capture features.

Voici une formule pour calculer la durée max du délai:

 durée = (mémoire × 1048576) / (largeur×hauteur×3×images par seconde)

Avec
- mémoire : voir dans Options > Préférences > Capture > Mémoire.
- On multiplie par 1048576 (=1Mo) pour avoir la valeur en octets.
- largeur, hauteur : en pixels, voir dans la fenêtre de configuration de la caméra.
- On multiplie par 3 pour avoir la valeur en octets.
- images par seconde : voir dans la fenêtre de configuration de la caméra.

Par exemple, 640×480 px @ 30fps avec en préférences mémoire 768Mo.

(768×1048576)/(640×480×3×30) = 29.13 s.

Il peut y avoir des variations car le nombre d'images par secondes est estimé à la volée plutôt que lu dans la configuration.

J'espère pouvoir faire dans le futur une version avec la possibilité de stocker les images pour le délai sur le disque plutôt qu'en mémoire vive, ce qui permettrait d'avoir des délais beaucoup plus longs.

Bonjour,

Pas tout à fait. Cependant dans la prochaine version on peut utiliser la grille de perspective en tant que système de coordonnées. Donc après avoir calibré la grille, en indiquant les dimensions de la table, il sera possible de récupérer les coordonnées des impacts dans le « repère table ». À partir de là il devrait être possible de recréer le nuage de points des impacts sur la table.

Ça me parait difficile en 2D. Si jamais la trajectoire de la balle est pile sur le plan de la caméra on ne verra pas de changement de trajectoire au moment du rebond… Surtout en vue verticale ? À moins que l'effet modifie systématiquement la trajectoire… J'avoue que je n'ai pas d'exemples de tennis de table vu de haut, si vous en avez ça m'intéresse.

Je ne sais pas si le suivi de trajectoire est suffisamment robuste pour faire le tracking d'une balle de tennis de table… Il faudra surement une bonne caméra à l'entrée.

En tout cas avoir un système qui dissémine des marqueurs le long d'une trajectoire en fonction d'évènements particuliers de cette trajectoire serait intéressant. À creuser.

Pour le tennis le système utilisé (Hawk-Eye) est très avancé. Il me semble qu'il y a 10 caméras haute-vitesse réparties autour du court et le logiciel reconstruit la trajectoire de la balle dans l'espace…

Ideally for me this feature would be provided by the video decoding library. I'd like to retrieve the images directly rotated and be oblivious to this fact in all the rest of the code.
Last time I checked the decoding library didn't offer this feature (although it was worked on I think). I'll have to check again.

Hi,
First the speed sliders. They are locked together until you change the settings in Preferences > Playback > General > Link speed sliders.

In general you shouldn't have to change this option. The preferred way is to adjust the high speed video settings (Motion > High speed camera) of the slow motion GIF.

In your case it's a bit special because the animated GIF was probably not shot with a high speed camera but rather slowed down programmatically at creation.

You can still fiddle with the high speed camera settings until the info in the bottom part of the dialog "Video is x times slower than original" matches the slow motion factor of the GIF, if you know it.

All this is not strictly necessary, but it's the more correct approach I think. It will display proper times and let you use stopwatches on the slowed down GIF for example. And the normal speed video will be automatically slowed down to match the GIF speed. And you will be able to use the speed sliders.

About the common frame navigator.
There are two different mechanisms, the common play button works by calling play and pause on the individual videos at the right time, to honor synchronization (based on speed settings of each video).

However, the common frame navigator, next button, previous button, etc. and the saving process, all work at the frame level, which causes the problem I think you're having.

Although I used to consider this an unfortunate limitation, I now think it's a bug induced by not using the right approach.

----

Thought a bit about it last night. The following might not make sense without the code, I'm writing it down to remember it

I think it is possible to express synchronization in terms of scaling and translating of two 1-D variables (the videos).
The scaling will map the fps from one video to the other (taking any slo-mo in account), and the translating will express the shift due to the synchronization point.

With this I think we can start with any time coordinate in the first video and find the corresponding time coordinate in the second video.
b = (a-t) * s.
b: time in second video.
a: time in first video.
t: translation = position of sync point in first video.
s: scaling = (fps of second video / fps of first video). (actual playing fps, not necessarily original fps of video).

Hopefully this will someday allow proper frame level synchronization.