@michel:
Il a l'air super ton appareil smile.
Pour les vidéos qui sont déjà au ralentit, j'avais remarqué ce souci.
Je n'avais pas pensé que l'utilisateur puisse connaître le nombre d'images par secondes exact de la capture. Je vais voir comment on pourrait en tenir compte quelque part.

D'autre part je serais intéressé par un (petit) échantillon de vidéo HD qui fait planter le programme. (joan at kinovea point org)



@sylpub:
- Conservation de l'espace de travail => déjà ajouté récemment pour l'affichage/non affichage de l'explorateur. Pour la config écrans j'hésite encore... 
- Conservation de l'outil utilisé: modifié récemment aussi pour crayon et ligne. Pour les autres la priorité est donnée à la modification plutôt qu'à l'ajout d'un nouvel élément.
- Export SWF: Ca serait très sympa mais pour l'instant je n'ai pas assez de temps pour m'y pencher de façon complète...
- Version Linux: Pareil que précédemment avec en plus des difficultés techniques plus importantes...

Merci pour le feedback !

1,877

(5 replies, posted in Bug reports)

Hmm... The bad news is that the FFMpeg update that fixed the problem on those videos also introduced several regression on other videos... (Some regular MOV files will simply not play.)
I haven't find the root cause of the problem and unfortunately I'll need to revert to the previous version of the lib for the time being.
(Argh. sad )
I'll try new versions as they come to see if the regression is somehow fixed.

Il y a eu de bons retours sur la version 0.7.6 et plusieurs remarques intéressantes.

Je me suis rendu compte que certaines parties ne correspondaient pas au niveau de qualité souhaité, en particulier l'outil Crayon mais également d'autres fonctions.

Donc avant de partir tête baissée dans les effets spéciaux, la capture DV, ou le support du son pour la version 0.8.x, il semblait important d'améliorer l'existant.

Périmètre à prévoir:
- Amélioration de l'outil crayon.
- Dessins apparaissant et disparaissant sur plusieurs images autour de leur image clé de référence.
- Zoom direct dans l'image.
- Tracking semi automatique.
- Correctifs.

L'objectif est d'obtenir une dernière version 0.7.x la plus stable possible, car lorsque le développement de la 0.8.x va commencer les nouveaux bugs vont pleuvoir.

Il est donc très important de rapporter tous les bugs que vous trouvez, manipulez les options dans tous les sens, essayez de le faire crasher volontairement, etc.
(Un de ces jours il y aura une plateforme plus formelle pour lister systématiquement les tests à effectuer mais pour l'instant il faut fouiner et tenter de vérifier tout ce qui parait suspect.)

Merci big_smile

1,879

(6 replies, posted in General)

The feedback on 0.7.6 has been good (thanks) and several good points have been made.

It occurred to me that some parts weren't up to the quality standard I wanted. This was especially true of the Pencil tool but of some other bits aswell.
So before diving into special effects, DV capture, audio support or other features of 0.8.x, some polishing of the existing is necessary.
This new 0.7.x won't take 4 month to be completed though, and it should be out within the next 4 weeks now.

To be expected:
- Better pencil tool.
- Drawings that fade in/out of their key frame or stay visible for ever.
- Direct zoom into picture.
- Semi automatic tracking through template matching.
- Plus as many bug fixes as possible.

It must be as stable and bug free as possible since future versions will add many new areas for bugs to hide into.
So please, I emphasize that bug reports are the very important contribution you can do.
Try all options systematically, try to make it break, and please report when it does.

Thank you big_smile

1,880

(15 replies, posted in General)

1. The chronometer export problem should be fixed in the next release.

2. Shapes as drawings is another feature that will be worked on, I'm not too sure when though.
I want to take the best approach on this one to enable people draw shapes as complex as they want.

3. This is an interesting point.
The current tracking function was done with technical sport analysis in mind. (Incentive was for exemple: how does the knee joint moves over time ?)

Having it tweaked for team sports/tactical position sports would be a great enhancement.

So please comment/expand on this tentative "feature spec" :
- In edit mode, the trajectory display wouldn't change much.
- In normal mode you could choose between several styles through the configuration dialog:
a. Analysis trajectory (same as existing),
b. Arrow pointing towards the point being tracked, (the trajectory in itself wouldn't be visible not to clutter the view)
c. Label attached to the point being tracked.

Hi, thanks for the feedback.

It will be taken into account when building the roadmap/features goals.
It turns out the priorities vary greatly from users to users...

@Tampai: Because of perspective it is not easy to give a meaningful value for line size.
As for the angle it will only be accurate if the line is on a perpendicular plane. But unlike angles, if you want to compare several line sizes, all lines would have to be on the exact same plane.
I think this is too much a constraint and will not be practical.
However, I'm considering using the new 3d grid to let the user define a reference plane. All angles and lines could then be computed relatively to this plane.

@mag: The "12" I had in mind will be included in a new 0.7.x release soon. However I think what you describe is more of an object tracking scenario. Putting a line and have it following an object on subsequent frames. This won't be in the very next release, I still need to have a stable/consistent tracking for single points first.

1,882

(5 replies, posted in Bug reports)

Short anwser:

Will be fixed in next version.


Long answer:

I tried the file and reproduced the problem. Then I tried it in MPlayer and VideoLan, and got the same issue...
This generally means it's an issue in FFMpeg itself (the decoding library we all use) which is out of my league to fix.

I looked for topics related to errors on this specific codec and found some interesting posts on the subject.
The root cause is the little watermark in the bottom right corner, which is actually superposed in a metadata layer and modifies the way the file is encoded...
It turns out this was fixed in FFMpeg very recently.
I'm using the "unofficial builds for Windows" done by Ramiro Polla and he just made a release today ! (previous one was in august)
I integrated the new build and I can confirm that the problem is fixed. big_smile

All the credit goes to the FFMpeg developpers and the Windows builds manager. (This is definitley Open Source in motion smile)

1,883

(5 replies, posted in Bug reports)

Hi,
It can have several causes... Would you be able to provide a sample so I can have a look ?

1,884

(3 replies, posted in Bug reports)

Thanks for the follow-up and glad it finally worked !
It still means there is a problem somewhere because the installer is supposed to detect and warn you when the .NET framework isn't there...
Will have to test that part again someday.

1,885

(1 replies, posted in Bug reports)

Hi, thanks for the feedback.

1. It will be possible at some point because it is actually easy to do in .NET
The plan is to have a number of improvements of this nature, including a "focus region" (for a lack of a better name) where you simply zoom in/out and pan sidewise and also making the "mirror" option available anytime...
All this has an impact on many things (drawings, magnifier, exports etc.) and will need to be carefully tested to avoid regressions...

2. The "fine-tune" function is trigerred automatically depending on the size of the working zone (and the settings in Preferences>Play/Analyze>Switch to Analysis mode sliders.)
I know the meaning of the settings is not very straightforward but I wanted for casual users not to have to bother about it.
You can learn more about it in the article "General Tasks > Preferences" of the Help.

3. And renaming too... I'll append that to the todo-list with medium priority.

4. You map them on an existing plane of the video or you set them to reveal a plane that is not visible.
For example, say you study a tennis match, you could map the grid to the court. That way you can better assess where the players are evolving, and if you know the size of the court you can even infer the size of a single cell and make rough measurements.

5. Hmm... In the current design if you have defined a working area the resulting video will only contain this working area.
So, it will not be possible without modifying the workflow...
There might be something to do with the meta data file (drawings etc.) to save this information though...

1,886

(3 replies, posted in Bug reports)

Hi,
This behavior has been reported for at least one other person, and frankly I have no clue as to the origin of the problem...
Can you please state your Windows version, Service Pack, .NET version, etc.
Hopefully we can start seeing a pattern and assess the problem.

1,887

(3 replies, posted in Français)

Bonjour,
Merci d'avoir tout de même pris la peine de rapporter le problème.

Une autre piste peut-être, êtes vous sous Windows Vista 64 bits ? (Il y avait un soucis de ce type avec certaines versions précédentes, normalement corrigé mais peut-être une régression...)

Oh, and sorry if this has been proposed by some of you already. I just had to rephrase it with the technical aspects and existing architecture in mind.
Sometimes the same idea needs to come from several people, expressed differently, to provoke insights about its full potential smile

I was just thinking a bit more about that onion skinning thing for drawings and having the next keyframe's drawing showing through...
It is definitely the way to go ! big_smile

Here's what came out as tentative functionnal specification :

- One drawing is still associated to one and only one key image.
- You can enable/disable fading.
- When enabled, it means each drawing will be seen on a few frames before and after its reference key image.
- The opacity of the drawing peaks on its key image, and is lowered as the play head moves away.
- The default fading value for new drawings is modifiable via general settings.
- Each drawing can have a custom value, modifiable through its configuration window.
- You can disable fading altogether for all drawings if you want.

So far I guess its standard fading / onion skinning and exists in other packages. Now the specific stuff:

- You can set a drawing to have an infinite fading value, meaning it would be visible during all the video.
- It stays linked to its reference key image but it doesn't matter anymore.
- This solves the issue of not being able to have persisting drawings; all without introducing a new set of tools or a new drawing mode...

This also almost solves the custom guides feature:

- Manually draw a circle or more complex shape on the first frame and turn its fading to infinity.
- Save as .kva file.
- import it in another video and you can now move it around, change its color, etc. and use it like a reference frame.
- It won't do all you could expect from a custom guide though, but with some tweaks we could have something very useful, that you can import and resize.
and share with anyone. ( Heck I could even host a repository of custom guides on kinovea.org...)

Opens new horizons !

1,890

(15 replies, posted in General)

And maybe:
- If you start to draw and it detects you are right upon an existing [line, angle, chrono, text, etc. except another doodle] then it switches to the "Hand tool" on its own automatically.

That may prove counter intuitive though.