You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
Hi,
You can drag the main play head in the bottom slider and it should update the image. This should work in recent versions, try the beta version on the download page.
You can also scrub using the mouse wheel.
You can also move back and forth using the keyboard arrows keys which might be easier than clicking the small buttons.
edit: Also just in case, make sure you have the Options > Preferences > Playback > General > "Update image during time cursor movement" option checked.
Please check in other DirectShow compatible programs first.
- VLC (Media > Open capture device)
- Skype
- OBS: https://obsproject.com/
Also check you don't have a software taking ownership of the camera. On my system I have a program called microSIP (VoIP) and it runs in the background and I can't get any DirectShow camera to work until I close it, even though I don't ever use it with cameras.
Also sometimes you have to go in Kinovea settings and change the resolution/framerate for it to initialize properly. And while you are in the settings make sure the exposure is not set too short a duration.
Do you see the rectangle of the image and it's pitch black, or you see the dark grey of the capture screen and there is no camera rectangle on it? Does the thumbnail snapshot work on Kinovea main screen?
Hi,
Please consider using the latest beta version from the download page, the angle tool is more versatile now and has a "supplementary angle" option that you can toggle in the menu which will give you the supplement to 180°.
You can also use the goniometer tool for a similar result to what you want.
The angles shown in the pictures are the actual angles formed by the two segments you put the angle on. Without more context the tool doesn't know anything else. Anatomical angles have various definitions depending on what is considered the anatomical rest position for the joint considered, in your case the 0° reference is when the leg is fully extended, so what you want to measure is the angle of the flexed leg relatively to the extended leg. This would not necessarily be the case if you wanted to measure the angle between the trunk and the thigh for example. It all depends on what is meant by 0° and in which direction the angle progresses.
See this image of the goniometer tool:
The dashed line extending the horizontal leg of the angle would be your anatomical reference.
The handling of timestamps read from the file was changed a bit in 0.8.27 to fix issues for some formats, please give this version a try and report if the problem is still there.
These issues are usually dependent on the file format or the encoder, could you send a sample file please?
Hi,
What version of Kinovea and how does it fail? The recording doesn't start or the result is wrong?
Hmm, interesting. I'll try to reproduce.
This type of artifact is usually either because the pixel format is wrong or because the final image size is not aligned correctly to the requirement of the output format.
What's probably happening is the final image width is not a multiple of 4. What is the width of the output video at the moment? Could you try to resize the screens and see if you can find a way that it works, just to confirm this hypothesis.
As you might have noticed I just updated the website.
I simplified the structure, removed a bunch of old pages, generalized HTTPS support, and improved the features/screenshots page.
If you miss anything or if you see a 404 or if something looks broken please report it here!
If you can't post here because the forum itself is not working please send a message at admin at kinovea.org.
Thanks
Known issues:
Top links in the table of content of the help page are somewhat broken.
Forum avatars have the wrong aspect ratio.
edit: everything is now redirected to HTTPS so forum CSS and posting should work again.
I also stumbled upon that page you linked from U Ottawa yesterday, I think the original Dempster parameters are in a paper from the 50's and this page is an adaptation for 2D. But they aren't really saying how they transformed the original parameters. Will check the Winter book in reference, I have it somewhere.
edit:
I uploaded the relevant table from Winter book (Biomechanics and Motor Control of Human Movement) here:
Table 4.1 - Anthropometric data.
The U Ottawa page for 2D studies is using the same parameters for relative segment weights and segments COM.
Hi,
It is the expected behavior for now. It's a trade off. When recording what is displayed on screen the images go through the delay buffer, painting pipeline (drawings and compositing) and generally undergo more conversions.
The two main use cases considered are live feedback and high speed capture. In order to support both as best as possible they are treated separately and optimized differently. So unfortunately doing live feedback on a high speed stream is going to suffer in one way or another.
The framerate you see is most probably the "display" framerate which is set on Preferences > Capture > General tab (25 fps by default). This is what gets saved when recording is set to display (a.k.a what you see is what you get). The other frames aren't pushed to the delay buffer in the first place.
You could try to increase it and see how high you can go. I don't remember if it's capped to the monitor refresh rate on the top of my head. I'm curious to see if you can get it to 300fps and where the bottleneck is, please report your results!
I imagine what you really would like is that when the audio from the golf club triggers the recording it still includes the few prior seconds of the swing, at the camera max framerate.
I reviewed the de Leva model and can say that it is not the one used in the tool. It's also not the Zatsiorsky-Seluyanov model.
One issue that always bugged me, I'm not too convinced that the full body models make a lot of sense when used on 2D images, as the segments and landmarks can't possibly be on the same plane, so the lengths and COM coordinates of some of the segments are going to be inaccurate relatively to the rest. Are you aware of existing research on how these full body model can be adapted to 2D or the magnitude of error to expect?
Hi,
First I want to say that I'm very motivated to improve this part of the application 
1) what inertial parameters (i.e., segment mass) do you use to estimate total body center of mass location for the "human model"? Dampster? De Leva? Etc..
I thought I had put a comment inside the XML to document the source but apparently I must have forgotten… Unfortunately at the moment I can't find the exact reference I used for the coefficients. It might have been from a book annex.
Please point to popular models that are used in your field and we'll build the corresponding tools. I want the user to be able to pick between several models anyway.
2) I might have missed something but...why I cannot modify the size (i.e., segments length) of the "profile" model?
Yeah the profile model is a bit restrictive. I actually considered replacing it for last release. It was created based on a specific scenario where it was not used to draw over a person segments but to act as a quick reference diagram on the side. The person would move the segments a bit to make a canonical pose as a note. I don't think this scenario is in use anymore.
3) could it be possibile in the future having a center of mass for the "profile" model too
Yes if we have the coefficients based on the existing segments. Post them and we'll build the tool.
I'm thinking at computing lumbar compression force and moment during deadlift/squat through inverse dynamics and it requires center of mass location as well as trunk angles
I started to update the format for last release, and plan to update it again to make it easier to display computed measures.
My goal would be to be able to display ratios, additions of two segments length, etc. There is a ton of these standard metrics that can be done based on anatomical landmarks and are referenced throughout the literature.
I'm still at the design phase for the framework to make these computations possible. My thinking so far is to add a concept of variables and operators and the tool would declaratively describe a resulting variable by using an algebraic expression tree. This would replace the "computed point" concept and be way more powerful.
There are also several primitives that are missing at the moment, like the possibility to get the angle between two non-intersecting segments, and get the center of a best-fit circle from a few points.
Please send how you perform the measure manually and any bibliographical references we can use. This will greatly help this design phase.
4) would it be even possible in the future to have a tool or add-on (a kind of GUI to friendly create a xml file) to build our own model by specifying body segments to use along with the relevant inertial parameters, joint angles and so on?
It has been a dream of mine but it would be a very big undertaking. For the initial skeleton structure it might be possible to use another application or a Kinovea key frame and convert/import the set of segments into a tool, but that won't help with variables and behavior. So it is going to be a manual process for the time being.
Yes, you can paste it under DrawingTools > Toolbars. The only difference is that there is an extra entry for the new custom tool. After closing and reopening Kinovea there should now be 3 custom tools with a human figure icon, the bottom one is the new one. The file for the custom tool itself has to be copied to DrawingTools > Custom.
Cool, thanks.
Yeah, I definitely want to make the distortion correction more robust. And also provide a number of presets for popular cameras, as a middle ground between not being able to measure anything and doing the manual calibration yourself.
I made a custom tool that matches the OpenPose's BODY_25 human model as per this documentation page. You can download it here: openpose_body25.xml.
It needs to be copied to Kinovea installation directory > DrawingTools > Custom.
Optional: in order to see it in the toolbar, you can add it by name to the player.xml file in DrawingTools > Toolbars. I also uploaded a premodified player.xml here.
I tracked the tennis video manually for a few frames with this tool to create a reference file. I uploaded the resulting KVA here.
Note: This kva is for the .mp4 video. Also, I just realized that if you try to open this kva without having copied the custom tool it will crash, so make sure you have the openpose_body25.xml copied under DrawingTools > Custom.
So this kva has the expected format for a full body pose tracked over time, that would ideally be generated by the conversion script from the OpenPose output. Basically there needs to be a keyframe with a GenericPosture drawing with a GUID (can be random), and then a Trackable drawing referencing this GUID. The trackable drawing contains timelines for each point.
Let me know of any issue if you start playing with this.
I tracked down the issue with the mp4 file.
The problem is when the KVA is imported in Kinovea. It's a bug in Kinovea I don't think you can work around it in the script. The mp4 file has timestamps that don't start at zero and when the track data is imported it wasn't adjusted to take that into account.
I want to be able to convert it to another type marker, in script. Just a plan...
Yes that would be great. As you may have noticed the tracking for angles and other drawings is handled differently. It's using the Trackability block at the end of the KVA and each point in each drawing has its own timeline there. The "id" field on TrackableDrawing references a drawing declared earlier in a Keyframe block.
It would be super cool to convert the OpenPose json into a tracked human figure. We can create a suitable custom tool to match the number of points output from OpenPose.
It's using 25 keypoints right?
Are all the keypoint locations always filled even when part of the body is occluded? If yes that would simplify things a lot.
Kinovea - Forums → Posts by joan