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.
1,741 2009-11-24 11:06:59
Re: Messurement feature for Trajectory analysis (3 replies, posted in General)
1,742 2009-11-23 12:56:09
Re: Videoanalyse (3 replies, posted in Bug reports)
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…
1,743 2009-11-23 12:47:23
Re: new user - i apologise if these have been mentioned before (2 replies, posted in General)
Hi,
colournoise wrote:
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.
colournoise wrote:
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.
colournoise wrote:
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.
1,744 2009-11-23 11:17:01
Re: Messurement feature for Trajectory analysis (3 replies, posted in General)
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
1,745 2009-11-22 12:36:36
Topic: Experiments on Paths (trajectories) (2 replies, posted in General)
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 
.
1,746 2009-11-17 17:26:10
Re: Version expérimentale - 0.8.3 (2 replies, posted in Français)
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é.
1,747 2009-11-16 21:54:53
Re: Experimental version - 0.8.3 (5 replies, posted in General)
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. 
1,748 2009-11-16 19:32:33
Re: Video equipment (7 replies, posted in Bug reports)
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.
1,749 2009-11-12 01:08:22
Re: Experimental version - 0.8.3 (5 replies, posted in General)
Hmm, might be some last minute regression introduced… I couldn't test the last 2 versions on Vista or 7 though, so I might have missed something.
Can you send me the logs in Application Data folder (from menu > Help > Open log folder…)
Thanks
1,750 2009-11-11 23:31:27
Re: Crash at startup (20 replies, posted in Bug reports)
Ok, the issue with the Norvegian based systems should be fixed in the new 0.8.3.
However I didn't test on an actual Norvegian based system so please report if it worked out.
1,751 2009-11-11 23:12:12
Topic: Experimental version - 0.8.3 (5 replies, posted in General)
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: Please get 0.8.4 instead.
Not many new features since 0.8.2 but bugfixes, including an important one fixing the memory leak on deinterlace.
Plus two new options in the General Preferences to always force an image aspect ratio or deinterlace mode if needed.
For general comments and suggestions related to new additions: post in this thread.
For bugs, you can directly feed the bug tracker.
And here's a small snapshot - Mosaic filter in action (menu Motion > Mosaic…):
(Incredible video from Danny MacAskill)
1,752 2009-11-11 22:55:12
Topic: Version expérimentale - 0.8.3 (2 replies, posted in Français)
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 : Merci de passer à la version 0.8.4.
Pas énormément de nouveautés sur la 0.8.2 mais surtout des correctifs dont un important sur une fuite mémoire lors de l'utilisation du mode "désentrelacé".
D'autre part deux nouvelles options dans les Préférences générales pour forcer systématiquement le format d'image et le désentrelacement si besoin.
Commentaires généraux et suggestions : dans la suite de ce sujet.
Pour les bugs, vous pouvez aussi directement alimenter le bug tracker
Une petite capture pour la route - le mode mosaïque en action (menu Mouvement > Mosaïque…) :
(vidéo incroyable de chez Danny MacAskill)
1,753 2009-11-10 11:48:34
Re: View 16:9 and 4:3 (9 replies, posted in Bug reports)
Hi,
yes, as I wrote above this will be part of a future enhancement. A setting will be put in the global preferences to persist the value.
1,754 2009-11-09 14:28:38
Re: drawing will stay visible (3 replies, posted in Bug reports)
In the drawing's configuration, setting the number of frames to persist to "1" and disabling persistence should have the same effect.
This is why the slider in the main preference setting is starting at "2" (and I would say it's the one in the local settings that is buggy for being able to go down to 1 frame.)
Now the extra limitation of not being able to display the drawings while playing is a remnant from the time where persistence / fading did not exist. The idea was that being visible on a single frame wasn't going to be noticeable anyway.
This limitation may be removed in a future version.
1,755 2009-11-09 10:58:57
Re: drawing will stay visible (3 replies, posted in Bug reports)
Hi,
Right click on the drawing > Persistence… > uncheck "Enable Persistence".
It can also be a global setting if you dont want the fading effect for any of the drawings. In that case you disable Persistence altogether from the Drawings tab in the Options > Preferences…