1,606

(7 replies, posted in Bug reports)

ylatuya wrote:

Do you guys know Elpel cameras? It's free hardware and software cameras.

Thanks for the link, it's very interesting. I hadn't heard of them.
Open source hardware in video could open so many possibilities smile

1,607

(9 replies, posted in Bug reports)

Hi,
This is strange… Would you be able to record two very small files (few seconds) in HD and SD and send them to me (joan at kinovea dot org).
I'll have a look at them and see if there is a defect in the source that I can fix.
thanks.

Hi,
Thanks for the input. I'll try this out.

1,609

(20 replies, posted in Bug reports)

Hi,
Which version are you using ? Is it 0.7.10, 0.8.* ? Is it an older one like 0.7.6 ?

When the problem occurs, you should be able to click a button to display the details of the error report.
Please post the paragraph that is under the line: ************** Exception Text **************.
This might help assessing what is going on.

Thanks for taking the time to report.

1,610

(5 replies, posted in Français)

Salut,
Petite précision concernant la capture avec DF.
Pour autant que je sache la connectique FireWire n'offre pas assez de bande passante pour faire de la capture de camescopes HD.
Le flux qui est perçu par le PC est donc converti préalablement par le camescope en définition standard.

1,611

(4 replies, posted in Français)

@tabory: Il n'y a pas de fonctions spéciales pour gérer les tablettes graphiques. Elles devraient rester utilisable dans les mêmes proportions que dans les autres logiciels.

Une personne qui utilise Kinovea pour faire du commentaire d'animations 3D avait suggéré que les outils de dessins puissent tirer parti du stylet et gérer notamment les différences de pression, comme dans un Photoshop.

À l'heure actuelle il n'est pas prévu d'intégrer ce genre de fonctionnalité. D'une part Kinovea reste un outil d'analyse avant d'être un outil de dessin, et d'autre part je n'ai pas de tablette pour tester. (même si je compte en acquérir une pour d'autres raisons).

@vaiotest: tabory parle de tablette graphique (à ne pas confondre avec un Tablet PC) - c'est un périphérique surtout utilisé par les graphistes.

Je n'ai aucune idée de la compatibilité de Kinovea avec le Tablet PC, mais a priori si c'est sous Windows XP cela devrait fonctionner.
Si tu peux l'installer et nous faire un retour se serait super ! tongue

Salut,
Je vais l'ajouter à la liste des suggestions.
Pour l'instant pas vraiment prévu, mais si ça intéresse du monde on pourra réfléchir aux modalités d'implémentation.
smile

1,613

(4 replies, posted in Français)

Bonjour,
Voulez vous parler d'une tablette graphique ?

1,614

(7 replies, posted in General)

Hi Stephan,
I just sent you a mail.

1,615

(2 replies, posted in Bug reports)

Hi,

For the slideshow function, due to a technical limitation which is currently out of my reach, the saving function needs to repeat the frames over and over several times into the output file, until the specified interval is matched.
Basically, there is a minimum of 8ms or something for the frame interval, so at some point frame repetition is unavoidable.
This frame repetition is causing the file to grow.

I don't think there is a solution to this issue right now and unless many persons find it unacceptable, I would rather work to improve other areas.

In a general sense, the file size of the various saving options won't be correlated to the original video because Kinovea will not use the same encoding profile than the original.
I had to weight several factors into account and file size suffered of the tradeoff (Couldn't find a reliable way to compute an adequate quality factor, so I use an arbitrary high value, which gives large files).
Thanks smile

1,616

(0 replies, posted in General)

Hi,

Here are the various activities involved in keeping the project running.
I'm awful at asking for help, suggesting areas, managing people etc. so I figured I would just list whatever there is. (What I can think of right now at least).
You may or may not have realised that it was this lot. Right now I'm doing most of the stuff apart from internationalised things obviously.
In no particular order.

Project Management
1. Establishing the long term direction of the project.
2. Choosing the mid term direction of the project.
3. Keeping all the users suggestions in a coherent list.
4. Assessing the potential and feasibility of the all suggestions.
5. Establishing release plans.
6. Making sure the short term decisions do not confilicts with broader goals.
7. Pronouncing feature freeze - (starting point of a formal release).
8. Packaging the release and uploading it to the site.
9. Making sure the main downloading sites have the latest version.
10. Keeping up to date about latest developements in related fields to get new ideas.

Communication
1. Posting blog posts about the project and future enhancements, media coverage, etc.
2. Translating these blog post from english to french or the other way around.
3. Posting some announcements or call for help and tests in the forum. Translating these too.
4. Filling the [s]super secret[/s] contributors wiki (en) (more on that soon hopefully).
5. Webmastering the site.
6. Answering questions about software usage in the forum.
7. Writing about the software in other forums.
8. Redirecting questions about the software in personal mails to the forum.
9. Chatting about possible future enhancements in the forum.
10. Answering requests from sports federations or private companies (and having no clue how to handle that).

Translation & documentation
1. Translating interface to new languages. (to all involved: thank you so much !)
2. Proof reading interface and help files in all languages available.
3. Consolidating the various localisation efforts in the language file.
4. Creating and maintaining the documentation (help files).

Quality Assurance
1. Doing basic testing.
2. Monitoring the bug report tool, reproducing reported defects.
3. Creating test cases to avoid regressions in future releases.

Code & tools
1. Managing scripts to ease release and internationalisation process.
2. Designing architecture at various scales.
3. Implementing features.
4. Creating or selecting icons and visual elements of the interface.
5. Fixing defects found in previous versions.
6. Improving features of previous versions, possibly removing unused ones.
7. Reconsidering architecture and refactoring the code so it's easier to work with in the future.

Needless to say, this takes a lot of (my free) time.
And beside my daily work (which is unrelated), I also have other hobbies tongue That is why you want to help the project moving forward.
Sure, I could do it all. But it's taking ages. The project is Open Source for this reason too.
joan at kinovea dot org
smile

1,617

(2 replies, posted in General)

Hi, yes, they are in the SVN repository (along with some more recent modifs).
You can check out with a SVN client at

http://svn.codingteam.net/kinovea/trunk/

(BTW, here is the link to the svn log history)

1,618

(1 replies, posted in Français)

J'ai trouvé ce papier sur le sujet:
- [PDF - 439Ko] - A Lightweight Method for Computing Ball Spin in Real Time

Pour l'instant ils utilisent des séquences générées par ordinateur.
Leur idée est d'utiliser un marquage spécial espacé de façon homogène, de sorte d'avoir toujours plusieurs marques visible. En fonction du mouvement apparent de ces marques, ils en déduiraient les paramètres de la rotation.
(si on a un seul point/disque et qu'il est immobile, la balle peut quand même être en rotation sur l'axe de la caméra, dans un sens ou dans l'autre…)

Au niveau matériel ils comptent utiliser une caméra 100 images/s car il n'y aurait pas plus de 10 révolutions de la balle par seconde…

À voir aussi leur section Références, il semble y avoir d'autre littérature sur le sujet.

1,619

(5 replies, posted in Français)

Bonjour,
Je vais recopier ce que j'ai pu écrire par ailleurs:

FAQ wrote:

- Pourquoi la vitesse de ma vidéo diminue toute seule ?
    Cela se produit lorsque Kinovea détecte qu'il ne peut pas extraire les images de la vidéo assez vite pour maintenir la cadence demandée.
    La vitesse se stabilise alors à un seuil tolérable mais il est conseillé de la diminuer manuellement à nouveau pour retrouver une lecture fluide.

le 10-08-2009 joan wrote:

Pour l'instant je n'ai pas trop de pistes convaincantes pour améliorer franchement ce point. Il y a des optimisations possibles mais cela ne résout pas le problème entièrement donc pour l'instant je n'ai rien embarqué.
Le degré de ralentit forcé est également dépendant de la puissance de la machine.

Il n'y a pas de réglage optimal universel, cela dépend de la taille de l'image (full HD ou HD, progessif ou entrelacé), du profil d'encodage, de la fréquence intiale des images (30 images/s, 60 images/s), etc.

Une solution consiste à réduire la sélection courante suffisament pour enclencher le mécanisme d'extraction des images en mémoire. (Les seuils de déclenchement de ce mécanisme sont configurables dans les préférences.)
Cela n'est pas toujours possible en fonction de la vidéo ou du sport étudié, mais si c'est le cas cela devrait régler le problème.
(Les images étant complètement décompressées en mémoire, le temps de décodage est nul.)

En podologie par exemple, si 3 ou 4 secondes représentatives issues de la vidéo sont suffisantes, cela devrait autoriser une lecture fluide (si l'extraction des images ne se déclenche pas toute seule après que la sélection ait été réduite, augmenter le paramètre sur la mémoire vive).

jlf wrote:

Pourquoi pas la grille ? Elle me semblait justement parfaite pour éviter de rajouter une nouvelle technique d'interaction…

le seul (petit) pbm qu'elle pose est que les 4 points connus ne sont pas forcément les sommets d'un rectangle sur la scène réelle (ça m'arrive parfois)

Ah oui, bien sûr… Effectivement je suis toujours parti du principe qu'on la faisait coller à un rectangle existant.
Dans le cas contraire les subdivisions sont plus génantes qu'autre chose.

jlf wrote:

la capture et l'analyse sont a priori des tâches séparées, j'avoue que je ne comprends pas bien la nécessité de capturer à l'intérieur du logiciel d'analyse, pourquoi ne pas se contenter de le faire avec un des nombreux trucs gratuits qui existent déjà ?

On peut faire plein de choses intéressantes en couplant les deux qui ne seront pas dispo dans les trucs non spécialisés.
Une petite liste de fonctions qui à ma connaissance n'existent pas dans les outils de capture classiques (tiré du sujet dédié):
- dessiner sur l'écran pour faire des repères visuels pendant le tournage.
- ré-ouvrir facilement une des séquence qu'on vient de filmer dans l'outil d'analyse.
- pouvoir naviguer facilement dans ce qui vient de se passer. (sans nécessité d'enregistrer et ré-ouvrir)
- afficher l'image avec un temps de retard automatique (pour quand le coach n'est pas là).

Cependant je suis sensible à l'argument de la séparation des tâches et à se concentrer sur moins de choses pour les faire au mieux. Je ne souhaite absolument pas que Kinovea devienne une usine à gaz qui tente de tout faire.
La capture me semble tout de même suffisamment ancrée dans le « workflow » de l'entraînement. On filme un exo, on regarde ce que ça donne, on ajuste, on recommence. (J'ignore dans quelle mesure cette vision est biaisée par le fait que j'ai un background en athlétisme…)

Bien sûr cela n'a d'intérêt que pour ceux qui emmènent le portable et le caméscope à la séance d'entraînement (ou au cabinet de podo). Pour les autres effectivement, un Windows Movie Maker ou le logiciel fournit avec la caméra suffit à créer les clips de la séance… neutral

Comme tu le vois, je suis encore mitigé sur ce point et pas complètement persuadé que les priorités soient aux bons endroits.
Les personnes avec qui j'ai des retours en face-à-face considèrent la capture comme le b.a.ba dans leur workflow. Je suis probablement aussi influencé par ça.

jlf wrote:

[kinogramme de Videa]
j'objecterai en faisant des suppositions sur la proportion de nécessiteux en kino utilisant des plans fixes

si c'est 80%, c'est peut être cruel de les sacrifier au profit des 20% restants et vu l'augmentation probable de complexité de de leur consacrer plus de ressources qu'au 80% précédents ;o))
mais bon, j'en sais rien bien sûr, je sais même pas si les nécessiteux en kino sont si nombreux que ça, Dartfish l'a même pas mis dans sa version de base

Le problème c'est qu'il fallait un plan parfaitement fixe. Le moindre décalage de 3 pixels faussait tout. Il fallait donc du matériel supplémentaire (trépied, télécommande). Tenir le caméscope à la main en tentant de ne pas bouger n'était pas suffisant.
Je considère qu'une telle limitation est inacceptable d'un point de vue fonctionnel. On doit pouvoir a minima filmer un saut en longueur, un essai de gym, et filmer à la main.

Ah, si seulement on pouvait savoir la proportion de gens intéressés par une fonction donnée ou le degré de complexité à partir duquel elle va être utile à 80% des utilisateurs smile

Ce qu'il faudrait c'est qu'un étudiant fasse son mémoire sur le ressentit de l'utilité des divers apports de l'informatique dans les différentes activités.
Si ça se trouve ce mémoire existe déjà, et croupi planqué au fond d'une bibliothèque universitaire… Si quelqu'un veut partir à sa recherche tongue

(bon, il est complètement parti en HS ce fil… smile)