You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
@wumastah: Apparently there was an issue related to TV Capture cards recently fixed in the AForge library (that Kinovea uses to support DirectShow cameras). I'll try to integrate this for the next version.
@SteelAl: if you use the experimental version, try to get the log and send it by mail.
I do most of DirectShow testing with a Sony DCR-HC47 so it should definitely work.
The way it works for now is that each time you manually moves a point, it will reset the series of saved positions for this point. From that moment, it will start tracking the new point.
i can't find it.....if you time and will can you please take a look at you computer and tell me? thanks
Hi,
First of all, you need the experimental version if it's not the case already.
Then check this topic : Experimental version - 0.8.18 for a visual description of the new toolbar.
You make a very good point about the pencil tool. At the moment there is no secret function to fix the problem.
Holding down a key would be a solution but I'm not sure if it would be very convenient while drawing.
Another idea would be to automatically group the new pieces of the drawing with the existing pencil pieces of the same color on that image. So until you change color, or change key image, the pencil would be adding to the existing group. On a given image, all pencil pieces of a given color would actually be a single drawing.
Or be in this additive mode only until you switch to another tool. This would allow to have several groups of the same color.
I just posted a more in depth article about measuring angles on the perspective grid.
However, loading the kva-file is very slow when I have 10 minutes of video with one information point every second (which gives 600 keyframes). Loading the video now takes several minutes (during which Kinovea hangs). So I guess there is a need for a more dedicated function.
Thanks for the sample files, it is helpful.
The slowdown/freeze is coming from the fact that upon loading the kva, the file is seeked to create the key images thumbnails on the fly. It will inevitably slow down the loading. Worse, on some formats seeking itself is problematic and can take even more time for each seek.
The final feature shouldn't necessarily create key images, just overaly the data in real time.
When using the perspective grid, it would also be interesting to be able to treat KVA files themselves as input for an overlay, to provide the view of data as seen from above.
Don't really have time to dive into this right now, but it solves several recurring needs so it's definitely climbing the todo list.
Currently there is no workaround for this issue. Besides, I don't really know how it should be adressed. Maybe one day if we have finer settings for persistence that would allow specifying named key images as cue points.
Hi,
Thanks for working on this.
Could you send me some sample files so I can later look where the slowing down is coming from ? If you send the .kva I guess I can load it on my own 10min video and see what happens. Having the gpx would be interesting too.
There is certainly a lot of interesting things to do in this area. Overlaying raw data, graphs, cloud of points, or maybe even maps would be super cool.
The spec for .KVA files can be found in the source under Tools/XML/Schema. (online here).
I admit it wasn't really thought out to scale to 500+ key images…
You can also disable fading entirely, the drawing should only be visible on the exact key image it is attached to.
<InfosFading>
<Enabled>false</Enabled>
BTW I think your mailbox is full...
Should be fixed now !
Another possibility is that the frames are sent by the camera as individual snapshots rather than a continuous video stream. As I understand that is the common way of doing things for cameras with external trigger capability.
At the moment this is not supported in Kinovea but it might not be very hard to implement as it is supported in AForge.NET, the library used to communicate with the DirectShow layer.
Hi,
If I understand correctly from your post and e-mail, you disable acquisition frame rate from the Basler configuration dialog accessed from the Properties button so the video doesn't really have a fixed frame rate. Instead the images just come in at variable intervals depending on the external trigger. This disabling is not honored correctly by Kinovea, which forces a fixed frame rate.
Kinovea doesn't really interact with the device properties dialog, it's just displayed when you click properties. Whatever happens there is not reported back to Kinovea in any way.
Kinovea will indeed try to automatically select a frame rate, which is interfering with your goal I guess.
What I'm not quite sure I undertand perfectly is how you go from the single images grabbed from the Basler down to the AVI video: are you using Kinovea to capture single snapshots and then another program to consolidate them in an AVI, or directly using the recording function ?
Anyway, I'll try to see if the selection of the framerate can be disabled entirely… I'm not quite sure if DirectShow allows this.
Pas sûr d'avoir tout compris… Quand on enregistre et que le différé est de 10s par ex., on enregistre l'action avec 10s de retard (on enregistre ce qui passe à l'écran, pas ce qui est filmé en temps réel). Mais s'ils s'observent (en différé) puis décident de s'enregistrer ou non, ils doivent mettre encore plus de différé (20s) pour rembobiner à nouveau et enregistrer, c'est ce qui se passe ?
Effectivement il faudrait des scénarios d'enregistrement de type pré/post déclenchement. On spécifierait la durée avant, la durée après, et en un seul clic on lancerait l'enregistrement correspondant. Ça reste encore à spécifier clairement en termes d'interface et d'architecture, ce n'est pas prévu pour la prochaine version.
Bonjour,
Le module de capture va être en grande partie réécrit pour la prochaine version (si vous avez d'autres remarques c'est le moment !).
Pour le choix de la caméra, j'essaie de reprendre la même interface que pour les vidéos : la liste des caméras serait directement visible sous forme de vignettes dans l'explorateur, et pour lancer directement la bonne caméra il suffirait de double cliquer dessus ou de faire un glisser-déposer depuis la liste à gauche.
Quelque chose comme ça :
(Normalement on voit quelque chose sur les vignettes mais là il fait nuit 
)
Hi,
Some complications I hadn't considered.
As you might know, Kinovea builds upon third party open source libraries for various aspects. To create a pure .NET 4.0 build, I need to have all these references in pure .NET 4.0 as well.
At the moment, this means : AForge.NET, EmguCV, ExpTreeLib, SharpZipLib, log4net and SharpVectorGraphics.
As far as I am aware, none of these projects have ready made pure .NET 4.0 builds.
They all share source code of course, so I could rebuild them myself to be pure 4.0, but at the moment I'm not convinced that it's the right approach.
Are you sure none of the application you will use on this machine will need .NET 3.5 as well ?
Please double check with your vendor about his arguments regarding not installing older versions of the .NET framework on Windows 8.
Meanwhile, I'll try to get to a Windows 8 install and do the test.
Sorry, I didn't have time to look into it. Will do!
Kinovea - Forums → Posts by joan