You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
And just today they released Pylon 5.2.0. Release notes: https://www.baslerweb.com/fp-1551786538 … otes~1.txt
It's not binary compatible with previous builds so Kinovea users should not update yet.
Applications built with earlier versions of pylon are incompatible with pylon 5.2.0.
I'll double check with the newest Pylon to see if that could be the issue. I had initially tested 0.8.27 with a Basler camera and knows at least one other person for whom it worked. So it might be context specific. (Version I currently have on my machine is 5.1.0.12681).
Can you double check that you have the Basler runtime in your Path variable?
During installation make sure the option pylon C .NET Runtime is checked, under pylon Runtime option group. You may have to use the "Custom" install profile to be able to select that option.
edit: I realized you are using Pylon 5.0.x. Kinovea has to be built against a specific version of Pylon as they change their API. So please install Pylon 5.1.x if possible, and see if it works with 0.8.27.
Thanks for the investigation!
I installed a second version of Kinovea in its own directory so that the two instances would not share files, but it appears that they both are still using the same C:\User\App Data\Capture History\Date.xml file.
You need to use the .zip version for this. It's not installed but just extracted to wherever you want, and it will contain its own AppData subdirectory where everything should go.
Thanks.
1.
I checked and there is no artificial capping at the display refresh rate, at least not in the current codebase, so it shouldn't make a difference to use a 120Hz display I think. I'll double check in an actual test that it works as intended.
It's possible the slowing down is coming from other parts, especially the fact that it has to decompress the image for display and then recompress for recording. Very interesting that it works twice as fast when using two instances. Maybe a threading issue, can you check in task manager, (on performance tab, right click to show logical processors), when you have 2 cameras in one instance vs one camera in each instance if the CPU usage is confined to one core vs spread out.
2.
Regarding the unhandled exception, I don't see the error in the log. There should be other files in the log folder dedicated to the unhandled exceptions, can you attach one of these to the bug? What is "x.xml"?
If you use the .zip version of the install you could duplicate the entire folder and have the two instances work on their own directories, to make sure they are not trying to write in the log at the same time or whatever.
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?
Kinovea - Forums → Posts by joan