1,276

(13 replies, posted in Français)

Je ne suis pas spécialement le mieux placé pour répondre, ce serait bien que d'autres utilisateurs nous fassent part de leur expérience !

Si c'est pour utiliser avec le module de capture, une bonne webcam devrait aller. La PS3Eye (à la base pour la PlayStation mais un internaute a écrit un pilote gratuit pour Windows) a pas mal de succès il me semble car elle est peu chère et permet de monter à plus de 60 images/s en 640x480 pixels. (à condition qu'il y ait une bonne luminosité quand même)

Pour le problème de recul s'il n'y a vraiment pas la place, voir si une caméra avec une lentille grand angle pourrait corriger le problème, mais là c'est plus le même budget !

1,277

(1 replies, posted in Français)

Tout ce qui est mesure de distances, coordonnées, suivi de trajectoire, calcul de vitesse, etc. est très sensible à la perspective.
Il est malheureusement quasiment impossible de faire des mesures vraiment rigoureuses à partir de la vidéo seule.
Donc n'oubliez pas que les mesures seront des ordres de grandeur, qui seront plus ou moins précis en fonction de la mise en œuvre.

La règle n°1 est que tout ce qui est mesuré doit être sur un plan parallèle au plan de l'image.
Pour plus de détails voir la page mesurer des distances.

1,278

(1 replies, posted in Français)

Il y aura peut-être un outil pour indiquer les rotation dans une future version…
Pour l'instant la seule option est de dessiner la flèche à la main avec l'outil crayon.

Oui c'est un problème connu et malheureusement compliqué à corriger.
Pour l'instant il n'y a pas grand chose à faire hmm

Well I wish there was a way to express the subtleties of the various options and be concise at the same time, but yes, the dialog will probably have to be more verbose to work.

I mix and matched ideas from your post and what I had in mind.
Here is the new tentative. Feedback appreciated on wording, grammar, etc.

http://www.kinovea.org/screencaps/0.8.x/savedialog.png

Guidelines
- Forbidden/obscure words: metadata, stream, muxed.
- option title: as simple as possible while retaining the meaning and not be ambiguous with other options.
- hint text: explain what will be saved and what will be the behavior of the exported file in other players as well as in Kinovea.

1,281

(6 replies, posted in Bug reports)

I tried various combinations but I couldn't reproduce the issue. Whatever I do, the mirrored video in the dual file exported is fine. Is there any specifc context I am missing ?

One bug I stumbled upon, when saving a single video with the mirror option, it's not mirrored.

1,282

(6 replies, posted in Bug reports)

www.kinovea.org/bugs/

Thanks for the samples.
I confirm the videos will work in next version.

1,284

(6 replies, posted in Bug reports)

Thanks for the report.
Can one of you guys add it to the bug tracker ?
Thanks.

1,285

(5 replies, posted in Bug reports)

Re: Drawing loosing sync with the video. There is maybe a remaining issue with a specific input format / framerate and MKV as output format. Please detail your case.

Re: other experiments.
- It is not normal that key images with no drawing don't show up in the slide show export.
- The persistence (ghosting) is irrelevant for slideshow saving.
- There shouldn't be any limit to the number of key images to be exported in the slide show. Admittedly it wasn't tested thoroughly, so maybe there is a bug somehow.

To make further experiments and help with the diagnosis:
- Deactivate the ghosting if you want (Options > Preferences > Drawings > Persistence > uncheck "Enable persistence").
- Identify the key images by drawing big numbers on them with the pencil tool. Then check what goes out in the exported video.

Thanks

1,286

(1 replies, posted in Bug reports)

Did you use the "Save video with a pause on each key image" saving method ?

1,287

(1 replies, posted in Bug reports)

Hi,
The problem is in Kinovea, not with the file formats. It is a known problem but quite tricky.
Sorry for the loss of time information in your analysis session.

Hello,
This is an important known issue that is being worked on.
The problem boils down to not knowing the framerate of the video we are saving, because we don't receive frames at the same frequency when simply viewing compared to recording.
The discrepancy depends on the CPU load…

Added to the idea backlog in the Saving category, as "Option to take slow motion into account when using the time freeze export".

Discussion follows in this thread.