Mise à jour du Lundi 15 juin 2009. (Le post d'origine a été modifié en conséquence)

Changement de statut :
smile -> big_smile - (Lecture) Nouveau format d'affichage temporel : "Temps + numéro image".
smile -> big_smile - (Lecture) CTRL+Up et CTRL+Down modifie la vitesse par tranches de 25%.
hmm -> big_smile - (Lecture) Un mode "aperçu de la vidéo" qui présente un fichier sous la forme de plusieurs vignettes.
smile -> big_smile - (Images clés) Séparer le traitement du titre et la mise à jour du temps dans les miniatures.
sad -> big_smile - (Dessins) Outil reglette/mesure de distance.
smile -> big_smile - (Publishing) Kinogramme basique dans une image composite.
hmm -> smile - (Publishing) Presentation OpenOffice.org Impress.

Ajoutés : Invisibles.

Hi,
Try to do menu: Image > Deinterlace.

As for the 0.7.x series, there will be a lot of 0.8.x versions.
The early ones will be less stable and less featured than late ones.
As with previous versions, there will also be "experimental" versions and "stable" versions. (One change in release management will be that "experimental" ones will be openly available on the forum)

The first experimental 0.8.x version will probably be out in july. It will feature a few new stuff, usability improvements here and there, and some invisible ground work to prepare for the next big features.

As for trajectory tracking, the main issue is that the best parameters for a given tracking won't be the same for another.
(size of the template to match, size of the search window to look it up into, algorithm to compute the similarity between source and target, image preparation to improve the matching, etc.)

I haven't tried all variations (especially, I haven't tried to increase contrast or similar enhancements before performing the template matching)
I still welcome sample videos where it blatanly doesn't work. I have a few, but the more the better.

One solution would be to let the user set all these parameters, but that will obviously complexify the tool a great deal, so I'd rather find the optimal parameters that will suit almost every cases.

1,819

(3 replies, posted in Français)

Pour l'instant vous pouvez avoir une idée des fonctions qui sont en cours d'implémentation dans le sujet qui reprend les suggestions et leur état.

1,820

(3 replies, posted in Français)

Bonjour,
La première opération n'est pas faisable dans l'état actuel du programme. Il faudra attendre les fonctions d'indexation/feuille de match, etc.
Vous devriez pouvoir recoller les fichiers entre eux à l'aide d'un logiciel tiers, par exemple VirtualDub (fonction "Append Avi segment" ou quelque chose dans le genre.) ou bien un logiciel de montage comme windows movie maker.

Pour la seconde opération: Qu'avez vous enregistré exactement ? une vidéo, une image, les méta-données ?

1,821

(5 replies, posted in Français)

J'ai peut-être mal compris le problème...

Quand vous jouez la vidéo avec le bouton de lecture, l'action se déroule à vitesse normale ou bien au ralenti ?
Si l'action se déroule au ralenti il n'y a pas de soucis et toutes les images sont bien là. La différence étant qu'1 seconde d'action filmée ne correspond plus à une seconde de vidéo mais à 20.

Si par contre quand vous jouez la vidéo elle se déroule à vitesse normale (en temps réel par rapport à l'action) alors là il y a effectivement un problème. Le programme ne supprime pas d'images mais je doute fort que l'APN ait fabriqué une vidéo a 600fps. Si vous voulez vous pouvez m'envoyer un exemple de vidéo sortant de l'appareil à l'adresse mail : joan at kinovea point org. (si moins de 3-4 Mo)

1,822

(5 replies, posted in Français)

Hmm... Kinovea ne peut pas (encore) rajouter des images où il n'y en a pas. Donc à voir sur l'appareil (mais ça m'étonnerais).

La question est : est-ce nécessaire ? Je veux dire: vous avez bien vos 600 images par secondes.

Par exemple si un tir a duré 1 seconde, vous l'avez bien de décomposé en 600 images dans la vidéo.
Vous pouvez utiliser l'ajustement du temps pour savoir si l'armé du bras est intervenu 30 millièmes après l'impulsion ou autre.
La seule chose que vous ne pouvez pas faire c'est relire en vitesse réelle. (mais à 600 fps le PC ne suivrait probablement pas)

1,823

(5 replies, posted in Français)

Bonjour,
Je pense que la fréquence de 600 images par secondes est seulement la fréquence de capture ?
Le camescope ou l'APN a capturé à 600 im/s puis étalé les images dans un fichier contenant au final 30 images/secondes.
1 seconde d'action correspond alors à 20 secondes de film (effet ralenti).

Pour ajuster la mesure du temps à la fréquence de capture:
- Faire un click droit sur l'image puis "Spécifier la vitesse d'origine..."
- Dans la boîte de dialogue indiquer "600" puis "Appliquer".

1,824

(8 replies, posted in Français)

Ah... Ok.
note: A priori vous aviez déjà le framework 2.0 (le message d'erreur l'implique et Kinovea n'aurait pas voulu s'installer)
il devait être corrompu / cassé...

Merci d'avoir persévéré smile

1,825

(8 replies, posted in Français)

Merci, je verrai ce que je trouve.
Pas la peine de chercher à sélectionner la suite. De toute façons pour ce type d'erreur il n'y a pas beaucoup plus d'infos à obtenir. (Je pensais que c'était un autre type d'erreur, dans lequel on peut avoir la chronologie des appels de fonctions dans le rapport d'erreur.)

1,826

(8 replies, posted in Français)

J'oubliais,
merci également d'indiquer votre système d'exploitation (XP / Vista + 32 bits / 64 bits).

1,827

(8 replies, posted in Français)

Bonjour,
Si vous avez eu la fenêtre classique de Windows "Voulez vous envoyer un rapport d'erreur"... Le rapport d'erreur est envoyé chez Microsoft et je n'en suis pas informé.

Vous pouvez par contre rapporter un bug pour Kinovea à http://www.kinovea.org/bugs. Copiez-y le contenu du rapport si possible (bloc sous *** Exception Text *** ).

Il y avait un soucis de lancement sur certaines machines dans la version 0.7.6, vous confirmez que vous avez installé la version 0.7.10 ?

Hi,

@jenki:
I don't think that capture should be deprioritized at all (it has been requested a lot):
Eventhough one can use the software bundled with the camcorder or say, Windows Movie Maker, these programs are lacking many features we will expect.
The most basic one would be the "delayed live", not present in those packages but very interesting in sport for self coaching and unattended feedback.
There is an hardware abstraction layer that most vendors follow, so I'm hoping that hardware support will not be too troublesome.

@neil:
For everything regarding video formats, Kinovea is 100% relying on the FFMpeg libraries set.
Fortunately the guys at FFMpeg are the ultimate gurus in this topic and if it's doable, they will do it.
It's actually very possible that the current versions of the libraries are already supporting AVCHD, it's been a while since I last checked. (Of course the current version of Kinovea is shipped with an older version of the libraries).

1,829

(1 replies, posted in Bug reports)

Hi,
I am sorry for the data loss.
Please add more infos about the issue in the other thread here.

Comments:
- It might be tied to issue #2 of the other thread. Try to only save a video if you are in analysis mode.
- You can save the data without saving the video. Saving the data only (just the description of drawings, trajectory etc.) has less chances to crash than saving the video as a whole, and doesn't recompress the video.

Here is a tentative sum up of what is known about these defects so far.
Please any additional infos or other defects specific to saving.

1. Saved files are 0 bytes or not created at all.

Reproduction scenario :
- Open a video in the program VirtualDub and do "save as avi" uncompressed. (default value in compression options)
- Open resulting video in Kinovea: reading is fine.
- Save video to file, the progress bar appears and disappears instantly.
- Resulting file is 0 bytes or non existent.
- No error message is displayed.

Expected :
- Video saved to file correctly.
- In case of an error, an error message should be displayed.

Workaround :
- Do not use the uncompressed mode of VirtualDub, go to Video > Compression and choose a codec from the list.

Root cause analysis :
- Unknwown at the moment.

Estimated date of fix :
- Unknown at the moment.


2. Saving progress hangs at some point, memory usage peaks.

Reproduction scenario :
- Video is in normal mode (not analysis mode where frames are uncompressed to memory)
- Save the video to file, starts fine, then goes slower, then hangs.

Expected :
- Video saved to file without memory usage increase.

Workaround:
- Do not save videos in normal mode. Restrict the selection until it goes to Analysis mode before saving.

Root cause analysis :
- Memory leak in the saving process.

Estimated date of fix :
- Fixed. Available in next release.

3. Saving causes the application to crash.

Reproduction scenario :
- Unknown. Please provide one if you experience this issue. (Include error log from Windows if possible)


4. Saving function creates files much bigger than original.

This is to be expected for the moment. Will be fixed later on.
Conflicting goals : simplicity of usage, quality of output, size of file, readability of the code.