1,561

(17 replies, posted in Français)

lof123 wrote:

2- Concernant le tracking : même si le tracking est déjà très satisfaisant et que les pertes du suivi sont assez rares,
penses tu pouvoir encore l'améliorer dans la future version?

Je pense qu'il a atteint un niveau « acceptable », et donc son amélioration a une priorité moindre que l'amélioration d'autres parties du programme, qui elles sont encore à un niveau « innacceptable ».

L'objectif de l'outil étant le suivi d'objets ou d'articulations (pas le suivi de personnes), les prochaines améliorations porteront surtout sur la possibilité de suivre plusieurs points simultanément, principalement pour mesurer l'évolution d'un angle au cours du temps.

lof123 wrote:

Si la fenêtre de recherche (le grand rectangle) était réduite en taille, est-ce qu'il y aurait moins d'erreur (changement d'objet suivi) ?

Hmm, la réduction de la fenêtre de recherche a surtout pour conséquence la perte du suivi dès que l'objet se déplace à trop grande vitesse.

Je pense que s'il y a un objet dans la fenêtre de recherche qui ressemble plus à l'objet recherché que l'objet lui-même, c'est que cet objet suivi n'est pas assez caractéristique.

L'utilisation de marqueurs autocollants ou autre peut aider, et le positionnement manuel est inévitable dans certains scénarios.

1,562

(7 replies, posted in General)

Hi,
Unfortunately I cannot answer that… I don't know how long it will take and I don't know when work on it will start.

What I know is that there are two ways to go about it:
- as a working zone filter, in that case it will be applied on the working zone when in Analysis Mode, similarly to Auto-contrast or Sharpen filters.
- as an painting time filter, in which case it would be applied on the image individually in real time.

The first option is much simpler from a coding point of view, but it will limit the functionnality to analysis mode, meaning only when the working zone can fit entirely in RAM when decompressed.
The second option is preferrable, but it involves a complete refactoring of the coordinate system, to get the drawings position, magnifier, zoom & pan to keep working, and keep their position relatively to the image when we apply the rotation.

I think like for the Mirror function, it will start as option 1 and then be moved to the option 2 later.
I'll try to see if we could have a third option that works like the second one here, but that doesn't try to keep the drawings at their proper location relatively to the original image.

1,563

(3 replies, posted in Français)

gilles wrote:

J'ai fait une copie d'écran des deux problèmes (désentrelacement et affichage) mais comment vous l'envoyer ?

Soit en créant un nouveau bug dans l'outil de suivi de bugs et en les attachant en pièces jointes, soit par mail (joan at kinovea point org).

gilles wrote:

Question : puisque la vidéo est à 29,97 i/s, un lecteur classique comme WMP ou VLC fait-il automatiquement la différence entre un fichier à 25 i/s et un fichier à 30 pour relire à vitesse réelle ? Je ne parle pas de caméscopes haute vitesse mais de caméscopes qui enregistrent directement à 25 (PAL) ou 29,97 (NTSC).

Oui la fréquence des images peut la plupart du temps être retrouvée par le lecteur à partir des infos stockées dans le ficher.
Ce qu'on a c'est une base de temps précise, par exemple au dix-millième de seconde ou sous forme de fraction, la durée de la vidéo exprimée dans cette base et le nombre d'images. (Malheureusement certains formats ne fournissent pas toutes les infos)

1,564

(1 replies, posted in Bug reports)

Hi,
Yes, it happens sometimes. There can be two reasons:

- The frames are not evenly spaced in time in the file.
When Kinovea tries to go the preceding frame, it computes the time position for it, and seek back to it. (The seek generally moves a few frames back and then the play head is moved forward again until we pass the target frame.)
When frames are not evenly spaced and the preceding frame has a bigger interval than the average, what can happen is that basically we don't realize it is the target frame (we think there is another one between it and the current), we keep going forward for the target, and end up on the current frame.

I'm not sure that paragraph was very clear, but the bottom line is that I think this is a defect in Kinovea. It should detect this type of issue and maybe try to go back 2 frames at once or something, to unstuck the situation.

- The other reason is when the file is broken or does not support seeking well. For some files (VOBs from DVD are an example) seeking does not work all the time. It may even happen that seeking back actually moves the playhead forward!
There is some protection code against this, but sometimes it's just impossible to fix.

I think you are experiencing the first issue. I'll add a bug to the tracker not to forget looking into it.
edit: m206.

1,565

(3 replies, posted in Français)

gilles wrote:

Bonjour,

Kinovea ne propose pas en ouverture directe le format mts mais arrive à le lire,  il est vrai de façon pas fluide, en passant par fichier.

Ok, ce sera ajouté pour les prochaines versions. Je ne connaissais pas cette extension, pour l'instant il y avait .m2ts, .m2t, .tod, .mod, qui sont exactement les mêmes fichiers avec un nom différent…

gilles wrote:

pourquoi dans Options puis Préférences, quand on coche sur "Toujours désetranlacer ...", cette option ne reste pas ?

Hmm, je n'arrive pas à reproduire ce problème. Une fois coché, je peux fermer Kinovea et le relancer, l'option est bien là. Est-ce qu'il y a un scénario particulier pour reproduire le bug ?

gilles wrote:

D'ailleurs, il y a un problème d'affichage puisque les unités de mesure, ... ne tiennent pas dans le cadre.

Dans la liste déroulante de la fenêtre des préférences ? J'ai beau tester avec différentes langues je ne reproduit pas non plus le problème d'affichage.

gilles wrote:

2ème point, j'ai un appareil photo Casio avec lequel je filme à 210 i/s et il serait bien de pouvoir relire la vidéo à vitesse normale (pas seulement au ralenti ou accéléré à "seulement" 200%)

Les Casio Exilim créent des fichiers à ~30 images par secondes, pour pouvoir rediffuser une capture 210fps en vitesse normale il faudrait donc pouvoir aller jusqu'à 700%.
Mais le problème c'est surtout que le traitement des images à 210fps va être impossible à suivre pour le PC.
De toute façon je ne pense pas que les cartes graphiques puissent envoyer autant d'images à la seconde à l'écran ni que celui-ci puisse les traiter.

Par contre effectivement on pourrait avoir un mode spécial "vitesse réelle" qui ne traite pas toutes les images, mais juste 1/n de façon à rediffuser le film à la même vitesse que l'action d'origine… Je vais ajouter ça à la liste des suggestions smile

gilles wrote:

et surtout d'avoir en plus un vrai indicateur temps (Chronomètre) en fonction du nombre d'image par seconde utilisé par l'appareil.

Clic droit sur l'image + menu "Spécifier la vitesse d'origine" + rentrer la fréquence de capture.
Voir aussi ici.

edit:
À ce propos, dans la prochaine version et à titre d'expérience, le pourcentage de vitesse sera affiché en fonction de l'action réelle et pas de la vitesse de lecture.
Donc pour ton exemple 210fps, le curseur de vitesse ira de environ 0.25% à 28%, ce qui représentera le vrai pourcentage de vitesse par rapport à l'action réelle.

edit2:
Pour l'affichage vitesse normale quand la vidéo a été prise en mode haute-vitesse (ex. aller à 700%). Après réflexion, la technique de sauter des images pour réussir garder le rythme ne tient pas vraiment la route puisque dans la plupart des profils d'encodage, pour afficher une image donnée il faut également lire et décoder la plupart des images précédentes directes… À creuser un peu plus donc…

1,566

(0 replies, posted in General)

Hi all,

When version 0.8.7 was released, I had plans to create a few help/example videos, to show the usage of some of the key features.
Two weeks have passed, and quite frankly, with the new (and great wink) features in the works, my motivation to do it is rapidly vanishing.

However, I realize it is still important to have this kind of videos. Both for new users to get quick feel of the program and as convenient help material.
So… It would be fantastic if you guys could do it big_smile

The idea is to focus on one feature or group of feature, and record yourself using it. The duration should be somewhere between 45 seconds and 3 minutes.

Method:
- You can use whatever screencasting software you want. (I generally use CamStudio to record the program window reduced and save to .avi).
- You may have to record yourself a few times to get it right…
- We can add some text labels afterward to explain what is hapening on screen if needed.
- You can also use a completely different approach, audio comments or anything. It's your call. As you have guessed, I'm no expert in screencasting tongue

Topic:
- Choose something you feel confident with or have already used a few times.
- Here are the 4 most popular topics on the online helps, sorted by view counts (It'd be nice to have these covered)
1. Tracking objects, 2. Comparing, 3. Drawings & Key images, 4. Grids.

Scenario:
- It is best to first write down a few key points you want to address during the video.
- If you don't know where to start, check the user guide pages about the topic you are going to cover.

Output:
- I may upload it on Kinovea blip.tv account and post on the blog.
- You would agree to use a Creative Commons CC-BY or CC-BY-SA license for your video. (Also, please try to use videos from your personal collection.)

If you want to do one, please state so as an answer to this thread.

Thanks!

It means it has been pushed to the source code tree at revision 268. (If you want to build from sources).

It will be released in a more formal download in the next experimental release, which would be early June if all goes well.


edit: This has been released in version 0.8.8.

1,568

(17 replies, posted in Français)

lof123 wrote:

une colonne avec le titre de l'image (revers, ....) et dans l'autre le temps correspondant.

Oui effectivement ça parait indispensable smile

lof123 wrote:

Comme je n'ai pas une version récente d'Excel je ne sais pas si cette option est deja presente dans la derniere version ded Kinovea.

Sauf bug, tous les exports (à l'exception de "texte") sont maintenus en parallèle avec exactement les mêmes données et format.

D'autre part si tu as d'autres idées sur des données à mettre dans l'export n'hésites pas. Je ne peux pas garantir que ce sera intégré, mais on pourra essayer.

Techniquement, le code de l'export est en partie à l'extérieur du programme (fichiers .XSL dans le dossier \xslt), ce qui fait qu'on pourrait aussi imaginer avoir des exports customisés, spécifiques aux besoins de certains utilisateurs, sans que cela n'impacte forcément tout le monde. (Chacun travaillerai avec ses propres feuilles de style .XSL ou celles par défaut).

1,569

(17 replies, posted in Français)

Ça fera parti de la prochaine version expérimentale. Donc normalement début juin, peut-être wink

1,570

(17 replies, posted in Français)

Oui j'avais oublié.
Bon, dans tous les cas je viens de corriger l'export XHTML pour que ce soit sur deux colonnes.

1,571

(17 replies, posted in Français)

Tu utilises le format XHTML en sortie ?
Chez moi ça mets bien en deux colonnes pour les formats ODF et Excel XML, mais effectivement il semble qu'il y ait un bug sur l'export XHTML.

Par contre si tu as le problème avec la sortie Excel MS-XML c'est plus mystérieux hmm

1,572

(17 replies, posted in Français)

lof123 wrote:

1- Quand tu dis que "tout ce qui est dans le rectangle intérieur est recherché dans les images suivantes" : c'est la couleur qui est recherchée ou des formes ?

Très globalement, les pixels sont comparés les uns aux autres à leurs emplacements respectifs et de façon générale. Cela tient compte de la couleur de chaque pixel, et de l'agencement des pixels les uns par rapport aux autres…
C'est donc plus la couleur, il n'y a pas d'analyse / reconnaissance des forme géométriques en tant que telle. (Mais ça n'est pas que la couleur, le contenu / la texture entre en ligne de compte.)

lof123 wrote:

2-Lorsque le logiciel suit un objet et que l'objet sort du champ de vision, dans certains cas le logiciel arrête le tracking et il faut repartir en enregistrant une nouvelle trajectoire et dans certains cas, le tracking ne s'arrête pas car la fenêtre de recherche s'est stabilisée sur une autre zone et ne bouge pas tant que l'objet suivi ne revient pas.

Existe t-il une solution pour éviter le cas n°1 et de devoir refaire une nouvelle trajectoire lorsque l'objet sort du champ de vision?

Cas n°1 (perte complète du suivi): retourner à la dernière image de la trajectoire + clic droit + "Reprendre l'édition de la trajectoire" et déplacer manuellement la fenêtre de recherche pendant les images où l'objet est masqué.

Pour le cas n°2 (stabilisation sur un mauvais objet), aller à l'image où le suivi se trompe d'objet pour la première fois + "Effacer la trajectoire après ce point" + déplacer manuellement la fenêtre de recherche sur le vrai objet à suivre, et relancer le suivi automatique quand cela semble ok.

lof123 wrote:

3- Lorsqu'on obtient le tableur Excel avec les données des images clés et des trajectoires :
Pour les images clés on ne peut pas utiliser les temps car dans la case il y a aussi du texte (exemple : Title : 00:00:20). Existe t-il un moyen d'avoir les colonnes de temps avec uniquement des chiffres comme pour les trajectoires ?

Hum, normalement ce sont deux colonnes différentes, la colonne B contient juste le titre de l'image clé (qui est par défaut sa position dans le temps si on ne l'a pas modifié).
Effectivement cela reste du texte, donc on ne peut pas faire d'opérations arithmétiques dessus. (mais c'est pareil pour les trajectoires)

Dans un premier temps regarde si cela fonctionne en changeant le type de marqueur temporel, (Options > Format des marqueurs temporels) en utilisant un marqueur numérique comme "numéro des images" ou autre. Je ne pense pas que les cellules vont automatiquement être configurées en mode numérique par contre… (?)

lof123 wrote:

4- Pour les images clés, il serait également intéressant de pouvoir inscrire un code devant chaque temps (par exemple en tapant une lettre différente pour les images intéressantes) pour différencier certaines images images.

Je ne suis pas sûr d'avoir compris…
Ce qui est exporté dans le fichier tableur pour l'instant c'est le titre de l'image, donc cela peut-être ce que tu veux.
Tu peux éditer le titre directement en cliquant dessus dans la petite miniature.

Well, if you have captured at say, 210fps, you can configure this by right clicking the image, and then menu "Set Original Speed…" and put 210 in the box.
(yes, the name of the menu is not the best… that will probably change to something like "configure for high-speed camera" smile).

The speed slider however, will still be expressed in % of the video speed. I'm wondering if it would be better to express it in % of real action speed.

When using a high-speed camera, you can currently configure Kinovea to show you the times expressed in the real action timeframe.
(So when the position label says "1 second", it's 1 second of action, not one second of video).

Currently though, the little slider for speed percentage is still relative to the video timeframe. If you set it to 5%, it just means the video is displayed at 5% of its original framerate.

What might be interesting is to have the speed percentage to be also expressed in the action timeframe. Then when you ask 5% it would mean that the performance you are watching is progressing at 5% of the speed of the real action.

I'm not sure if that was clear… To picture it, say you have captured at 250fps and the resulting file is 25fps. Then by default the middle of the speed slider would say 10% not 100%.

Would that be interesting ?
Should that be the default when you have configured for high-speed camera?

1,575

(1 replies, posted in Bug reports)

pstrikwerda wrote:

When importing the video and having it run to find the appropiate starting point for making a clip, both the arrow 'going back to beginning' and setting the starting frame bracket give a false starting point in 0.8.6. and 0.8.7.

Do you mean it was working with older versions ?
Could you send a small sample exposing that behavior ?

edit: Sample received. Thanks.