You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
Hi,
Apparently the bowling file (video10.wmv) plays well on VLC > 0.9.8, but displays the same issue than Kinovea on VLC 0.9.6 that I happen to have at home.
So I guess that pinpoints the issue to the older version of FFMpeg used by Kinovea. (haven't updated yet because it broke some other file types, I'll have to get around this one day.)
Thanks
Hi,
I would be interested by the file, if it's small enough, (say < 3.0 MB), you could send it by email: joan at kinovea dot org.
Otherwise, maybe you can put it up through a free file hosting service like rapidshare or megaupload, or similar.
I'm not sure I'll have time to really assess the issue in the near future though.
You can also try to read it with another FFMpeg based software, like VLC or MPlayer and report the result.
edit: I forgot about the bug tracker. You can create an issue there and then attach a file to it. (up to 5MB). This action might requires registration though.
Hi,
Overlay as in placing one video on top of the other during synchronisation has been added in the latest experimental version.
Please check the 0.8.4 thread.
For stroboscopic effect, it's not implemented yet, but maybe in the meantime you can play with the Mosaic filter in menu "Motion > Mosaic".
Thanks 
Well, I should add that this is not supposed to be the "ultimate" superposition tool.
There also are plans for a longer term feature that would really blend seamlessly and only import the moving person from one video on the other.
For this "quick and dirty" superposition, I wanted to get it out in the simplest way possible, and then read what you all think are the most important limitations. (alignment, scale / zoom, image aspect ratio, etc.)
So, I take note of your comment .
Hi,
I got some questions on this, people indeed did not always realize that it was already possible but through the regular Open File dialog.
I sometimes like the automatic filtering on videos but it's just a matter of organization I guess. And your example of not always having a video of someone but still being able to compare is very interesting.
As an experiment, I have enabled the images file formats in the Explorer on version 0.8.4.
Anyone that thinks its practical or on the opposite annoying, please have your say here.
thanks.
Rappel:
Les versions « expérimentales » sont disponibles publiquement sur le forum.
Le but de la manœvre est que vous puissiez tester et commenter les nouveautés alors même qu'elles sont en cours de construction.
Donc à vous de jouer le jeu et de remonter les bugs trouvés et des suggestions d'ergonomie 
L'installeur est disponible ici : Lien retiré, voir le sujet sur la version 0.8.5, merci.
C'est une version expérimentale au vrai sens du terme:
1. Tout d'abord la nouvelle fonctionnalité de superposition des images lors de la synchronisation qu'il faut expérimenter et commenter. (voir capture).
2. Durant la correction d'un bug sur la synchronisation j'ai complètement changé l'approche de la synchronisation dynamique en interne. (synchronisation dynamique = quand on utilise le bouton commun de lecture).
Il faut donc absolument retester cette fonction et remonter toute régression potentielle.
3. J'ai activé la visibilité des fichiers d'image dans l'explorateur. Ça vous gène, ça vous arrange ?
D'autre part il est maintenant possible de spécifier l'origine du repère de coordonnées des trajectoire depuis leur fenêtre de configuration.
(Pour ceux qui exportent vers les tableurs.)
Petite capture rapide - Superposition des images durant la synchro :
Reminder:
"Experimental" versions are available on the forum.
The goal of this change is that you can test and comment on new features while they are being built.
So it's your turn to play now, and report bugs and usability suggestions ;).
The installer is available here: Link removed. -> 0.8.5 thread.
This is an experimental version in the true sense of the word.
1 - First there is the new "superposition" feature that I need you to experiment. Let me know what you think. (see snapshot)
2 - Second, while fixing a bug on synchronization, I completely changed the way the "dynamic synchronization" is done under the hood.
(dynamic sync = when you hit the common "Play" button).
I need you to test it as much as you can and report if there are any regressions.
3 - Third, I enabled the view of images files in the explorer. Feedback on this goes in this thread.
- In addition to that, you can now set the origin of the coordinate system for Paths, from their configuration window.
This can be useful if you export them to spreadsheets and work with the data afterwards.
Quick snapshot - Superposition of images during synchronization:
Ok, I understand better, thanks.
However, remember that to get meaningful results, all the points on the trajectory will have to be on the same plane, perpendicular to the camera axis.
Otherwise distances get distorted by perspective.
Hi Peter.
I'm not too sure of how to approach this issue…
Would you be able to send me a small sample VOB file that exposes the problem ?
Maybe we can detect the specific encoding used and make a special case for it and compute duration in a different manner…
Hi,
1 - the magnifier is very useful for the sort of work i want to use kinovea for but as far as i can tell you cant render the magnifier into an exported video - is this correct ? - if you can do this then how do you do it ? - if you cant do this is it likely to make it into a future version ?
Yes, I confirm the magnifier does not get exported.
I don't remember why, but it is a defect. I'll have to recheck that.
2 - the text persistence feature is useful for exported videos but would it be possible to add the ability to trigger the appearance of a 'persisting' text label actually on a specific key frame rather than having it fade in and out either side of the key frame like it does now ? (if its already possible to do this and ive missed it then how do you do it ? )
Hmm, there are a number of things that may enhance the drawing appearance, but each of them mandates a configuration option and in the end it makes the usage a bit more complex each time.
I'll leave it like that for the moment, and add this to the suggestion list. If others want to add their voice to this request please say so and we will try to find a tradeoff.
For the time being, maybe you could use a StopWatch with a label ?
It will only start to be visible on the very frame you add it, and will stays visible until you set a "hide" frame. If you right-click > Configuration, you can set a custom text to be displayed above the time value.
3 - total feature request - any chance a future version might include the ability to synchronise and compare two or more video clips overlaid on each other with transparency rather than side by side ? (this would be HUGELY useful for repetitive technique sports like archery)
Definitely. And it's not the first time that this request is made (which is not wrong, It's a way to tell that it's important).
I have addressed this in the coming version, it will go both ways (each video merges with the other, you can still move them independantly).
I hope to be able to release this tonight or in the next few days if I can get around a seemingly unrelated bug during synchronisation.
Hi,
What do we need to measure exactly ?
The total length of the trailing path ? The length of each segment ?
What would be the best way to display the measures without too much confusion ?
Thanks
This week-end I tried some experiments to improve the automatic tracking feature.
Currently the tracking is done by comparing "pixel to pixel" the images, trying to locate the best "look-alike" zone.
This has a number of drawbacks, it get lost easily when the object or point of view rotates, when blur happens, luminosity changes, etc. and even in "normal" conditions.
In the following pictures you can see how the program fails on what should be a straightforward task (snooker).
On the left the tracking follows, but it slowly shifts away from the ball and ends up on its side.
On the right, the tracking got lost after a while.
These two were done with very similar set up for the initial point to track.
It looks like this technique is highly dependant on starting conditions and small errors accumulates… 
The new method I'm trying is called SURF. It's a very powerful algorithm, I'm leveraging open source code from the OpenSURF project.
The idea is to describe the initial point and the candidates by a set of 64 descriptors parameters, and then compare the points using the descriptors.
The main advantage is that it is invariant to rotation, blur, etc.
However the way I need to use it makes it really slow compared to the original "template matching", and as you will see I couldn't get it to work in a satisfying way yet 
These are just done with varying some internal parameters.
What happens apparently is that the target attaches itself to the border of the ball, and then finds that the best match is on the other side of the ball !
Maybe it's considering the ball rotation 
It didn't get lost, but the output path in unusable…
So, this is not conclusive and this will need more experimentation to get something working. But I wanted to share these with you anyway.
I'm afraid we'll have to resort to manual tracking for a little longer 
.
Bonjour,
Important : pour les utilisateurs de Windows 7, un bug critique empêchant le chargement de toute vidéo a été identifié dans cette version 0.8.3. Le correctif devrait être disponible bientôt.
@lof123:
À terme oui, il faudra avoir une fenêtre permettant le choix précis de l'origine du repère.
Pour l'instant ce référentiel est relatif au premier point.
Étant donné que les points sont relatifs, les coordonnées et distances (en pixel ou autre) des différents points de la trajectoire sont les mêmes, quelque soit la façon dont ce point est déterminé en interne par rapport au centre du carré bleu.
Donc le point 2 n'a pas vraiment d'incidence.
Je sais pas si c'est très clair,
Tu poses le premier point, il est à {0,0}, tu pose un point 10 pixels plus loin vers la droite et le bas, il est à {10,-10}.
Ceci est vrai quelque soit le pixel réel qui est utilisé pour faire le calcul, tant qu'on utilise le même pixel de référence dans l'autre.
Donc que l'on utilise le centre du carré, le coin haut/gauche, ou même un point qui serait 100 pixels à droite, la différence entre les deux pixels de référence donnera toujours la même chose que la différence entre les deux centres du carré…
Conclusion: c'est un détail d'implémentation, tu peux considérer que c'est le centre du carré qui est utilisé.
The bug that some of you reported on Windows 7 has been identified and corrected in dev version. Thanks !
It will be fixed in the next experimental release, available I don't know when.
Hi,
Yes, I think I remember someone over the french part of the forum reporting using an Exilim.
And for these high speed cameras, there is a special option to match the time display and the capture speed of the video.
Kinovea - Forums → Posts by joan