You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
Thanks for the report.
If you open the two videos but invert the screens they are loaded in, does the desynchronization go in the same direction or in the opposite direction?
It's possible that the right screen gets less CPU time but 640x480@30 shouldn't be an issue. Do you see the right video lagging behind?
What happens if you open the same video twice and sync it, does one of them also drift compared to the other?
This is Kinovea 0.8.26.
This version introduces new kinematic analysis tools and focuses on polishing existing features and fixing bugs.
1. General
It is now possible to run multiple instances of Kinovea at the same time by changing the option under Preferences > General > Allow multiple instances of Kinovea.
2. Annotation
The management of the opacity of drawings was simplified.
Instead of having a needlessly complicated dialog on each drawing with a "persistence" value, all the drawings are now either always visible or follow a global option for fading in/out of their reference frame.
The global value for this fading is set under Preferences > Drawings > Opacity.
3. Measurement
General
It is now possible to export the time series of trackable drawings like the angle tool and custom tools. See Angular kinematics and Linear Kinematics below.
The "data analysis" menu has been removed from individual trajectory drawings and placed in a global menu at Tools > Linear kinematics, as the window now combines data for all trajectories. See Linear kinematics below.
Angle tool
The angle tool was improved to be more versatile. It supports three new options to switch between signed or unsigned angle, change direction from counter clockwise to clockwise, and switch display to the supplementary angle.
The following screenshot shows the same angle object with different options applied.
Linear kinematics
The linear kinematics window is now found under the menu Tools > Linear kinematics and supports multiple sources. You can check/uncheck trajectories to be included in the analysis. The name and color for the plot are taken from the objects configuration.
When comparing several trajectories, three time models are available: absolute, relative and normalized. "Absolute" time will simply respect the original timeframe of the trajectory. "Relative" time will align all trajectories to a common starting point, to compare how they evolve over time. "Normalized" time will stretch trajectories to a common starting and ending point, to compare their "shape" over time.
Exporting trajectory data to CSV will export a common time column first and then one column per trajectory.
The trackable drawings (point, line, angle, custom drawings, etc.) have their individual points included in the trajectories. So if you track and angle drawing, its three points will show up in the linear kinematics window as three distinct trajectories that you can treat as any other trajectory.
Angular kinematics
A new kinematics analysis window has been introduced for angular kinematics. It is available under the menu Tools > Angular kinematics.
This window will let you visualize angular kinematics values like angular velocity or tangential velocity for angles that were tracked in the video.
Trackable drawings that have an angle, including custom tools, will show up in the list of sources and can be checked/unchecked.
The time options "relative" and "normalized" are also available.
Angle-angle diagrams
A new analysis window for angle-angle diagrams has also been introduced at Tools > Angle-angle diagrams. These are diagrams that directly map the angular value of two angles against each other.
This is useful to get insights into the dynamics of a specific motion. A typical example is to plot the knee angle against the ankle angle over a few cycles of running or cycling. The overall shape of the cyclic curve can be compared to the literature or between athletes or sessions.
The diagram is defined during the overlapping period of time of the two angles considered.
The angle-angle diagram will also work for custom tools that contain angles. This is possibly the most practical way to use this feature, for example with the bike fit tool or a tool dedicated to the angles you want to review.
In addition to the raw angle value, it is also possible to map the angular velocities or tangential velocities of two joint angles against each other.
General tracking
If you need to track the same joint angle at distinct times in the video, create several angle tools and track them independently. Each tracked point has an underlying timeline of positions that is not exposed to manipulation. Filling this timeline with discontinuous sequences will cause unexpected behavior.
It is now possible to completely bypass the data filtering by changing the global option under Preferences > Drawings > General > Enable coordinates filtering. Note that this filtering is to remove the high frequency noise created by the digitization process, it should be left enabled unless you intend to run your own filtering algorithm on the data.
4. Capture
Recording modes
In order to restore the ability to record delayed videos, a new recording mode option is available in the global preferences under Capture > Recording.
The Camera recording mode is the default and will record the video stream straight from the camera to disk, compressing it on the fly if necessary. This is the best performance path. For some combinations of framerate and image size, it is the only usable option.
The Display recording mode will let the video go through the buffering system for the delayed live feature and the composition system for mosaicing (if active), and it is the final image that will be recorded to disk.
Here is a simplified diagram of the capture pipeline and where each recording mode operates.
As an example, let's say we have a 10 second delay active and we record for 20 seconds. Let's define the press of the record button as time "0".
- In camera mode, the video will contain the action from time 0 to 20.
- In Display mode, the video will contain the action from time -10 to +10.
Camera modules
An entirely new camera module was written to support IDS cameras.
The Basler camera module was improved and updated to support Pylon 5 API.
Memory buffers
The maximum allocated memory for the capture module is now based on whether Kinovea is currently running on 32-bit or 64-bit Windows. This should allow for much longer delay when memory permits.
The option to increase the memory allocated for delay buffer can be changed under Preferences > Capture > Memory.
5. Feedback
Feel free to use this post for feedback, bug reports, usability issues, feature suggestions, etc.
This should be fixed in the next version. Added the trajectory label as a comment line above the corresponding data.
I'll look into this.
Moving forward the preferred way to export trajectory data is through the linear kinematics window and its CSV export. It's under the trajectory objects context menu in 0.8.25, but will be under "Tools" in the next version and will allow reviewing and exporting the kinematic data of several trajectories at the same time.
Yes the timing information by default depends on the framerate of the video, so time intervals will be wrong. If you know it's wrong and you know the correct framerate, you can fix it in menu Video > Configure video timing > in the bottom pane you will see what Kinovea reads from the file. In your case you can change the value to 29.97 and apply, and the playback speed as well as all time dependent measurements should be correct.
If you can see two balls in just one frame, it could very well suggest that the original footage was indeed interlaced and that it got deinterlaced. When an object moves a lot between the two half-frames the deinterlacing algorithms tend to "reconstruct" the object twice.
To improve the automated tracking you can change the size of the search and object box used by the trajectory tool. For some objects it's best to reduce the "object" window to avoid tracking background. You can also adjust the position of the object manually to get the most control. This will work better with the camera higher above the ground. Then if you go to the trajectory data analysis you can find all the measurements and export them quickly to the clipboard or CSV file. This uses a smoothing pass on the data to minimize the noise introduced by the digitization process. The exact procedure is described in the "About" tab of the data analysis dialog.
Note that you can also correct the distortion of the GoPro directly in Kinovea, it will not undistort the images but it will distort the coordinate system to match the lens. The calibration procedure is not very well documented at the moment though. But in theory it could be more accurate than using the stock de-fishing algorithm of GoPro studio which will use standard values for all devices, whereas here you would calibrate exactly for your camera lens. (Depending on how the sensor is glued on the board the optical axis may not be exactly aligned with the center of the image).
This is only relevant if you are making spatial measurement on the images though, if you just do time measurements because you already know the distance between markers visible on the images I don't think you need to correct the distortion at all.
Hi ysag, could you try with 0.8.25 first to see if the problem persist?
Also there is a nasty bug in 0.8.15 when trying to export the video on top of the file currently opened. Avoid doing this as it could corrupt the file.
Thanks for the file. I see that the action is indeed sped up, but I also get the same in VLC and SMPlayer. Kinovea reads the file as 4,989s long, 299 frames, 59.93982fps. VLC also says 59.93982fps. Using VLC 2.26.
Are you sure it's not the pre-processing that introduce this effect?
Did you shoot in 1080p or 1080i in the GoPro? I've read there are issues with the 1080i mode not really being interlaced. Maybe the defisher or converter thinks it's interlaced when it's actually not, and it tries to deinterlace it. This could merge pairs of frames and end up twice as fast as expected.
Great!
Regarding the video speed, could you convert/create a very small file and send it over by mail so I can have a look? Thanks.
Hi,
Some issues may arise if the perspective grid is at a very steep angle, as is the case when placing it on the floor seen from a camera that is not very high above ground. Try to stay above 30° or so between the camera axis and the plane. Move the camera higher up and look down if possible.
At a steep angle the coordinates aren't going to be very precise since one pixel in the image will cover a lot of real world area.
Also, the coordinate system origin can be moved independently from the grid, maybe you have moved it inadvertently? If the origin of the coordinate system is outside of view it could yield unexpected results. If it's above the horizon line it is effectively at infinity and things will be completely broken. Once the calibration is active, if you move the grid's corners it's going to move the coordinate system with it.
It's possible to see the actual coordinate system with menu Tools > Coordinate system. If you don't see the origin where you expect it, this should be fixed first. The primary axes are thicker than the other lines and can be dragged around. Move the grid's corners around to make it more rectangular to check where the origin is, and place it where you want relatively to the grid. Then move the grid back to match the real plane.
Hi,
One immediate thing to check is if the video file produced by the filming camera is marked as 120fps or not. Usually for such speeds the camera will create a file marked as 30fps or 60fps, even if the content is 120fps, when reading the video normally it appears in slow motion.
Assuming Kinovea 0.8.25, go to menu Video > Configure video timing. In the lower panel, check the "Framerate read in the file: XXXfps". If this is not 120, then this is the source of the difference.
In this case, in the same dialog box but in the top panel ("High speed camera"), change the Capture framerate to 120. This should make Kinovea understand the mapping between the time in the file and the real time of the action captured.
Edit: thinking of it, the difference would go the other way compared to what you describe, so it's probably not the culprit.
Another thing is if the SD card on the action camera is not capable of writing fast enough. In this case it will drop frames and the resulting video will be faster than normal.
To check this, record a running stopwatch (tip: you can type "stopwatch" in Google to get one), and review the video in a regular player. If you record 10 seconds of the visible stopwatch but the video doesn't run for that long then the problem is at the recording step in the camera.
Just using class 10 SD card may not be enough depending on the resolution you are using. You can check this page: fastest microsd cards for info about write speed, ratings, etc.
I added an option to allow multiple instances of Kinovea running at the same time. I'm not 100% sure of the implications of this regarding some file access, but we'll see how it pans out. It will be disabled by default.
The panel containing the capture thumbnails has been rewritten from scratch between 0.8.15 and 0.8.25 so it's possible the issue with dual recording slowing down is fixed already.
What were the other issues that prevented you from using 0.8.25? I remember the ability to record with delay was one and this should be addressed in the next version as well.
Hi,
The halving of the maximum delay is by design actually, as it is backed by memory. You may go to Options > Preferences > Capture > Memory, and check the total memory used for capture buffers. When using dual screen, this amount of memory is split between the screens. The maximum memory that you can allocate will be much increased in the next version when using the x64 build.
The image should only freeze if your current delay value places you inside the second half of the delay buffer, where the buffer has to be reconstructed.
For a Kinovea side-by-side comparison there could be a total of 4 different frame rates for the 2 source videos:
1) video #1 - source frame rate
2) video #1 - recording frame rate
3) video #2 - source frame rate
4) video #2 - recording frame rate
Yes, this scenario gets confusing very quickly. To add to the confusion, there is also the "display" framerate, when you change the "speed slider" value. The final framerate of the composite video takes the speed slider value into account. Note that the speed slider value is given with regards to the recording framerate, not the file framerate.
When you have two videos with differing "recording" framerates, you need to be aware of the value of the following setting: Options > Preferences… > Playback > General > Link speed sliders when comparing videos.
If checked this option will force the speed sliders of both videos to use the same value (ex: 50%), which should make them use the same reference time scale. So if you had filmed the same performance with two different cameras at different recording framerate and the cameras output different file framerates the videos should still be synchronized out of the box ( as long as you set the recording framerate).
I think it's easier to think about all this in terms of frame intervals. The inverse of the recording framerate gives the real world duration between the captured moments.
Would frame rates of the two source videos be found in 'metadata' of the source videos?
Yes the framerate of the video is a metadata. The default display framerate of the video can be found in Kinovea in the top bar above the player screen or in Video > Configure timing in the bottom panel. In Windows by right clicking the file and going into Properties > Details > Video > Frame rate.
Kinovea produces a video file with another frame rate. How does Kinovea select a default frame rate? Does the selected Kinovea default frame rate depend on the frame rate of which source video happens to be on the right or the left?
It should not depend on which video is on the left or right.
Each video has its frame interval computed, for the synchronized playback. The common player uses the smallest frame interval to drive the dual video playback. Unless there is a bug, this smallest interval is what should be used in the final composite file.
There is an extra check to limit the interval to 10ms at the smallest, so the final file should never be faster than 100fps.
How can/should the user select a different frame rate than the Kinovea default frame rate?
You cannot manually specify the output framerate of the composite video at the moment.
If the user selects a Kinovea video frame rate that is accepted by, for example, Youtube or Vimeo, then if frames are still skipped it would probably be a video website issue. ?
You can reopen the composite video in Kinovea and verify frame by frame that everything is there. Maybe it's possible that some combinations of framerates would result in missed frames in one video? Normally since it's driven by the smallest frame interval this shouldn't happen. Instead, the lower frequency video should have duplicated frames.
Are the source video frame rates (metadata) still in a side-by-side Kinovea video file? Could one of those source video frame rates somehow be mistaken for the Kinovea frame rate by a video hosting website?
No the default display framerate of the original videos is no longer present in the final composite video.
If you want to make some experiments you could use the KSV test file format. Here is a KSV file:
<?xml version="1.0" encoding="utf-8"?>
<KinoveaSyntheticVideo>
<FormatVersion>1.0</FormatVersion>
<ImageSize>800;800</ImageSize>
<FramesPerSecond>20</FramesPerSecond>
<DurationFrames>100</DurationFrames>
<BackgroundColor>255;128;0;0</BackgroundColor>
<FrameNumber>true</FrameNumber>
</KinoveaSyntheticVideo>Copy this in a new text file and save with extension .ksv. Kinovea has special code to interpret this as a video, for testing purposes. You can change the FramesPerSecond field for experimenting. And inside Kinovea you can change the "recording" framerate as if it was a regular video.
Next to those issues, I have found a small bug in the implementation of the hotkeys (in all versions I've tested):
When you use the keyboard to increase or decrease the delay, the GUI updates, but the actual delay isn't changed. In the code (below), the value is changed and the control is invalidated, but a 'ValueChanged' event is lacking.
Super thank you for finding and debugging the issue! I have made the correction in the code.
Unfortunately, I can't get source code compiled in Visual Studio Community 2017 (.NET 4.7), so I can't propose a (tested) fix for this.
Yeah sorry for the state of the build process. At the moment I'd like to keep targetting .NET 3.5 for at least one more version. This has consequences on the build because of the C++/CLI project. Recent versions of Visual Studio don't know how to compile C++/CLI for 3.5. The entire build actually requires VS2008 and VS2010 to be installed on the machine. I'm in the process of writing down a proper guide.
When does Kinovea save videos as 30 fps and when at 100 fps? Is there a way to control the playback video frame rate before saving the Kinovea analysis video file on Kinovea 8.25?
Yes, menu Video > Configure video timing > Video. (bottom section).
The value put here will set the framerate value reported by the file in its header, so video players will be "tricked" into playing the video at that framerate. Or, in the case of Vimeo, it should be tricked into not changing the framerate of the video.
This will distort the scale of time when playing back the video. So for example if you were to take a 100fps input video and change this value to 50fps, the live action would be reproduced half as fast as it should. However, step by step operation should correctly visit all the original frames without skips.
Kinovea - Forums → Posts by joan